返回技能市场
Test Data Engineering
当需要批量构造测试数据(造 1000 条订单、准备各种状态的用户数据)、或者需要使用真实生产数据但需要脱敏时使用此技能。覆盖造数策略(API 造数/DB 直接构造/数据工厂)、脱敏方案(敏感字段识别/替换/掩码)、合规要求(GDPR/等保/个保法)和数据工厂架构设计。手工一条条造数据效率太低——测试数据工程的目标是让造数变成一键操作。
SKILL.md
⚠️ 本技能单独使用效果有限,建议配合完整技能集(12 步工作流)使用。安装:npx skills add Kokxi/qa-test-skills
测试数据工程
核心原则
测试数据是测试的基础,好的数据管理让测试可重复、可追溯。
数据构造方法
手动构造
适用场景:
├─ 少量数据
├─ 复杂业务数据
├─ 一次性数据
└─ 调试用途
方法:
├─ 数据库直接插入
├─ 管理后台创建
├─ 接口调用创建
└─ 脚本批量创建
数据工厂
适用场景:
├─ 批量数据
├─ 标准化数据
├─ 重复性数据
└─ 自动化测试
工具:
├─ Faker(Python/JS)
├─ Mockaroo(在线)
├─ Factory Bot(Ruby)
└─ 自建工厂类
数据库脚本
-- 示例:用户数据构造
INSERT INTO users (username, email, phone, status, created_at)
VALUES
('testuser001', 'test1@example.com', '13800000001', 'active', NOW()),
('testuser002', 'test2@example.com', '13800000002', 'active', NOW()),
('testuser003', 'test3@example.com', '13800000003', 'inactive', NOW());
API构造
# 示例:通过API构造订单数据
def create_test_order(user_id, product_id, quantity=1):
response = requests.post(
f"{BASE_URL}/orders",
json={
"user_id": user_id,
"product_id": product_id,
"quantity": quantity
},
headers={"Authorization": f"Bearer {token}"}
)
return response.json()["order_id"]
加载时机
| 什么时候读 | 读哪个 |
|---|---|
| 做脱敏规则与实现时 | references/data-masking.md |
数据脱敏的完整内容已下沉至references/data-masking.md,避免每次触发都占用上下文。
数据清理
📌 本节与 qa-test-env-data「数据清理」内容同步,修改时请同步更新两处。
清理策略
├─ 按用例清理
│ ├─ 每个用例执行后清理
│ ├─ 优点:数据隔离好
│ └─ 缺点:效率低
│
├─ 按模块清理
│ ├─ 每个模块测试后清理
│ ├─ 优点:效率较高
│ └─ 缺点:隔离性一般
│
├─ 按批次清理
│ ├─ 每个批次测试后清理
│ ├─ 优点:效率高
│ └─ 缺点:隔离性差
│
└─ 定期清理
├─ 定期清理历史数据
├─ 优点:保持数据量可控
└─ 缺点:可能影响测试
清理实现
⚠️ 安全警告:以下 SQL 清理示例仅适用于隔离的测试环境,切勿在生产数据库执行。 执行前必须确认:
- 目标数据库已确认为测试环境
- 先用
SELECT COUNT(*)预览受影响行数- 使用事务包裹(
BEGIN; DELETE ...; ROLLBACK;)做无害验证- 数据表有
is_test等明确测试标记字段- 如无把握,先向 DBA 确认清理范围
-- 示例:清理测试数据
-- 方法1:按时间清理
DELETE FROM orders WHERE created_at < DATE_SUB(NOW(), INTERVAL 7 DAY);
-- 方法2:按标记清理
DELETE FROM orders WHERE is_test = 1;
-- 方法3:按用户清理
DELETE FROM orders WHERE user_id IN (SELECT id FROM users WHERE is_test = 1);
数据管理规范
命名规范
测试用户:
├─ 格式:test_[角色]_[序号]
├─ 示例:test_user_001, test_admin_001
└─ 标记:is_test = 1
测试数据:
├─ 格式:[类型]_test_[序号]
├─ 示例:order_test_001, product_test_001
└─ 标记:is_test = 1
数据生命周期
├─ 构造:测试前准备数据
├─ 使用:测试中使用数据
├─ 验证:测试后验证数据
├─ 清理:测试后清理数据
└─ 归档:历史数据归档
输出示例
构造100条用户注册测试数据 → 手动构造:录入10条核心数据(正常用户/边界值) → 数据工厂:编写SQL脚本批量生成80条 → API构造:调用注册接口自动化生成剩余
生产数据脱敏用于测试 → 脱敏规则:手机号(中间4位***)、身份证(生日****)、姓名(张三) → 脱敏实现:Docker部署Greenplum,配置脱敏策略执行
检查清单
测试数据管理完成后检查:
- 数据构造方法是否设计?
- 脱敏规则是否定义?
- 清理机制是否实现?
- 命名规范是否统一?
- 数据生命周期是否管理?
- 数据可追溯性是否保证?
评论与讨论
0/2000
还没有评论,分享你的体验吧。