test-data-management

Test Data Management (TDM)

References: GDPR / CCPA data protection, Google Test Data Best Practices, synthetic data generation (Faker / Mockaroo), Stripe Test Mode.

Applicable Scenarios

Functional test data preparation
Large-scale data generation for performance testing
Using masked production data for testing
Multi-tenant / multi-environment data isolation
Test data cleanup and reclamation
PII handling under compliance requirements

Core Principles

1. 测试数据要可重复创建
   不能"手工造一次，丢了重造"

Test data must be isolated Must not pollute production / must not pollute across test cases
Real PII must not be used for testing GDPR / CCPA red line
Data must be "real but fake" Real enough to trigger real bugs, but not real users
Automatic cleanup State can be restored after testing ends


## 测试数据策略

### 1. 工厂模式（Factory）
```text
代码定义 + 参数化 + 默认值

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

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

Advantages: repeatable, parameterized, composable Applicable to: unit testing, integration testing

2. Fixture files (JSON / YAML)

固定测试数据，提交到版本控制

适用：API 测试、UI 测试、回归套件

3. Synthetic data generation

工具：Faker / Mockaroo / Synthetic Data Vault

特点：随机但符合分布
适用：性能测试、机器学习、Demo

4. Masked production data

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

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

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

Three layers of data isolation protection

1. 物理隔离
   - 独立数据库 / Schema
   - 独立实例

2. 逻辑隔离
   - tenant_id / env 字段
   - WHERE env='test' 强制过滤

3. 命名隔离
   - 前缀：test_user_xxx, _test_order_xxx
   - 标记 metadata: {"test": true}

PII / sensitive data handling

绝对不能用真实数据：
  - 身份证 / 护照
  - 银行卡 / CVV
  - 真实姓名 + 真实手机号
  - 真实邮箱
  - 健康记录
  - 地理位置精确坐标

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

Test account system

角色矩阵：
  - 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）

Data lifecycle

1. 创建（Setup）
   - 用例开始前
   - 工厂模式生成
   - 标记 _test_xxx

2. 使用（Test Body）
   - 不被其他用例污染
   - 修改后只影响本用例

3. 验证（Assert）
   - 检查数据库状态
   - 不留中间状态

4. 清理（Teardown）
   - 删除 / 重置
   - 异步清理脏数据脚本兜底

5. 归档（Optional）
   - 失败用例数据保留 24h 以排查

Workflow

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

Large-scale performance data generation

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

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

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

Handling test data pollution

症状：
  - 用例顺序变了就失败
  - 周一过、周五挂
  - CI 不稳定

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

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

Quality self-check

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

Common pitfalls

Manually creating data——all gone after the next environment reset
Using real email addresses / phone numbers——test SMS messages sent to real users
Test data entering production——pollutes the live environment
Incomplete cleanup——dirty data accumulates
Sharing test accounts——concurrent test cases interfere with each other
Depending on fixed IDs——IDs change after database reset
Performance data too small——stress test conclusions are distorted
Incomplete masking——nicknames / remarks expose PII
Test time zone differs from production——time-related test cases become disordered
Fixture files not under version control——each team member maintains their own

Supporting templates

templates/test-data-strategy-template.md — data strategy + isolation plan + cleanup mechanism + test account matrix + masking rules

Collaboration with other skills

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

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