SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场test-data-management

test-data-management

测试与质量

查看项目

更新于 10-16 10:25

技能介绍

测试数据管理（Test Data Management / TDM）

参考来源：GDPR / CCPA 数据保护、Google Test Data Best Practices、合成数据生成（Faker / Mockaroo）、Stripe Test Mode。

适用场景

  • 功能测试数据准备
  • 性能测试大规模数据生成
  • 生产数据脱敏后用于测试
  • 多租户 / 多环境数据隔离
  • 测试数据清理和回收
  • 合规要求下的 PII 处理

核心原则

  1. 测试数据要可重复创建：不能"手工造一次，丢了重造"
  2. 测试数据必须隔离：不能污染生产 / 不能跨用例污染
  3. 不能用真实 PII 做测试：GDPR / CCPA 红线
  4. 数据要"真实但假"：足够真实能触发真 Bug，但不是真用户
  5. 自动清理：测试结束后状态可恢复

测试数据策略

1. 工厂模式（Factory）

代码定义 + 参数化 + 默认值。

示例（Python factory_boy）： class OrderFactory: user = SubFactory(UserFactory) amount = 100 status = 'draft' created_at = LazyFunction(now)

使用： OrderFactory() # 默认订单 OrderFactory(amount=999) # 自定义金额 OrderFactory.create_batch(100) # 批量

优势：可重复、参数化、可组合。 适用：单元测试、集成测试。

2. Fixture 文件（JSON / YAML）

固定测试数据，提交到版本控制。 适用：API 测试、UI 测试、回归套件。

3. 合成数据生成

工具：Faker / Mockaroo / Synthetic Data Vault。 特点：随机但符合分布。 适用：性能测试、机器学习、Demo。

4. 脱敏生产数据

流程：生产 DB → 脱敏脚本 → 测试 DB

脱敏方式：

  • 哈希：邮箱 → MD5(邮箱) + @test.com
  • 随机化：电话号码替换
  • 通用化：精确地址 → 城市
  • 加噪：金额 ± 10%
  • 删除：身份证、密码、token

适用：性能测试、UAT、复杂业务场景。

数据隔离三层防护

  1. 物理隔离：独立数据库 / Schema；独立实例
  2. 逻辑隔离：tenant_id / env 字段；WHERE env='test' 强制过滤
  3. 命名隔离：前缀 test_user_xxx, _test_order_xxx；标记 metadata: {"test": true}

PII / 敏感数据处理

绝对不能用真实数据：

  • 身份证 / 护照
  • 银行卡 / CVV
  • 真实姓名 + 真实手机号
  • 真实邮箱
  • 健康记录
  • 地理位置精确坐标

替代方案：

  • 测试身份证号（11000019900307XXXX 区间）
  • 测试银行卡（4242 4242 4242 4242 - Stripe 测试卡）
  • 假人姓名（Faker 库）
  • test@example.com 这类专用邮箱
  • 城市级地址（北京市，不到具体街道）

测试账号体系

角色矩阵：

  • guest_01：未登录访客
  • user_01_a：普通用户，租户 A
  • user_02_a：普通用户，租户 A（用于测协作）
  • user_03_b：普通用户，租户 B（用于测租户隔离）
  • manager_01_a：管理者，租户 A
  • admin_01_a：管理员，租户 A
  • admin_global：超管

每个账号：

  • 固定密码（仅测试环境）
  • 固定邮箱
  • 完整业务数据（不同状态）
  • 文档化（README）

数据生命周期

  1. 创建（Setup）：用例开始前；工厂模式生成；标记 _test_xxx
  2. 使用（Test Body）：不被其他用例污染；修改后只影响本用例
  3. 验证（Assert）：检查数据库状态；不留中间状态
  4. 清理（Teardown）：删除 / 重置；异步清理脏数据脚本兜底
  5. 归档（Optional）：失败用例数据保留 24h 以排查

工作流程

  1. 列数据需求：用例需要什么数据；多少条；什么状态分布
  2. 选择策略：单元测试 → Factory；API 测试 → Fixture / Factory；E2E 测试 → 预置账号 + Factory；性能测试 → 合成生成；UAT → 脱敏生产数据
  3. 实现数据生成：工厂代码 / 脚本
  4. 隔离机制：标记 / 命名 / 独立 DB
  5. 清理机制：Teardown / 定时清理
  6. 文档化：测试账号清单；数据规模；使用说明

大规模性能数据生成

目标：百万级数据，< 1 小时生成

技术：

  • 数据库批量插入（COPY / INSERT batch）
  • 关闭索引 → 插入 → 重建索引
  • 关闭外键约束 → 插入 → 启用
  • 直接生成 SQL 文件再 LOAD

示例（PostgreSQL）： COPY orders FROM '/data/orders.csv' WITH CSV; → 100 万条 < 30 秒

测试数据污染应对

症状：

  • 用例顺序变了就失败
  • 周一过、周五挂
  • CI 不稳定

排查：

  • 是否清理了？
  • 是否有共享状态（缓存 / 静态变量）？
  • 是否依赖测试顺序？

防御：

  • 每个用例独立 transaction，结束 rollback
  • 用 unique 后缀（timestamp / uuid）
  • 测试容器（每跑一次新建 DB）
  • 异步清理脚本兜底

质量自检

  • 测试数据可程序化生成
  • 测试数据隔离三层防护
  • 不使用真实 PII
  • 测试账号文档化
  • 数据清理机制完备
  • 性能测试数据规模接近生产
  • 脱敏脚本无可逆性
  • 测试数据进版本控制
  • 数据规模有上限（防爆磁盘）
  • 跨环境数据迁移有审计

常见坑

  • 手工造数据——下次环境重置全没了
  • 用真实邮箱 / 手机——给真实用户发了测试短信
  • 测试数据进生产——污染线上
  • 清理不彻底——脏数据累积
  • 共享测试账号——并发用例互相干扰
  • 依赖固定 ID——数据库 reset 后 ID 变了
  • 性能数据太小——压测结论失真
  • 脱敏不彻底——昵称 / 备注暴露 PII
  • 测试时区与生产不同——时间相关用例错乱
  • fixture 文件不进版本控制——团队各自维护

配套模板

templates/test-data-strategy-template.md — 数据策略 + 隔离方案 + 清理机制 + 测试账号矩阵 + 脱敏规则

与其他 skill 的协作

上游：

  • 数据库工程师工作流 → 数据模型 / Schema
  • test-strategy → 数据规模需求

下游：

  • test-case-design → 用例使用数据
  • api-testing → API 测试数据
  • performance-testing → 大规模数据
  • acceptance-testing → UAT 数据
  • 自动化测试工作流 → 自动化数据准备