zhaoxuya520 测试数据管理（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 数据
自动化测试工作流 → 自动化数据准备