关于 qa-data-seeder
qa-data-seeder 是面向 QA 的技能,用于分析功能实现、规划覆盖业务类别的数据集,并将有效测试数据写入确认过的非生产环境。它要求先批准类别和数量,并为数据添加统一标记以便核查和清理。
主要功能
- 01分析实体、字段与校验规则
- 02规划常规与边界数据类别
- 03获批后生成并写入测试数据
- 04核对数量并提供清理指引
适用场景
- 01为新功能准备手动测试数据
- 02按业务状态和字段边界覆盖测试
- 03核验测试环境中的数据写入结果
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ testomatio/ skills --skill qa-data-seeder安装后在 Claude Code 中输入/qa-data-seeder确认已加载。
详细介绍
QA 数据播种器
分析功能的实现方式,设计一个覆盖 QA 所需所有类别的均衡数据集,并将其填充到目标环境中,以便通过手动或自动化方式测试该功能。
关键约束
- 绝不向生产环境播种数据。 写入任何数据前,确认目标环境是测试、开发或预发布环境。如有疑问,立即停止并询问。
- 绝不生成无效数据。 每条播种记录都必须通过应用自身的验证。边界情况应使用极端但有效的值,而非损坏的数据。格式错误的输入应仅用于实时执行的负面测试,绝不可保存在播种数据中。
- 均衡数据集:常规(预期)数据至少占 70%,边界情况最多占 30%。
- 在用户批准类别和确切条目数量之前,不要播种数据(第 3 步关卡)。
- 凭据、令牌和连接字符串必须来自环境变量或用户输入,绝不可硬编码。
- 优先使用项目现有的播种机制(工厂、播种脚本、固定数据、管理控制台),其次使用 REST API 或 MCP。播种脚本应使用应用所用的语言编写。
- 生成的产物(数据集计划、一次性播种脚本)应放入被 Git 忽略的
.testeiya/seed-data/;如果.gitignore中没有.testeiya/,则添加它。 - 为每条播种记录添加一个可识别的标记(使用架构允许的名称、备注或标签字段),以便 QA 找到数据并在之后清理。整个运行过程使用相同的标记。
工作流
步骤 1:了解功能
在提出任何方案之前,先阅读实现。收集以下信息:
- 功能涉及的实体和模型,以及每个字段的详细信息:类型、格式、长度限制、数值范围、枚举值、必填或可选、唯一性、默认值。
- 验证规则——应用级验证和数据库约束/迁移。
- 关系和前置条件:创建其他记录之前必须先存在的记录。
- 会改变行为的业务差异:角色、状态、类型、套餐/等级、地区设置、功能标志、时间相关逻辑。
- 用于创建这些记录的 API 端点(或 UI 流程)及其要求。
如果无法访问代码,则改用 API 架构(OpenAPI/Swagger、GraphQL introspection),或向用户索取文档。如果有 MCP,则使用它。
步骤 2:收集环境详情
❓ 询问代码无法告知的信息:
- 平台:Web、移动端,还是仅 API。
- 如果是 Web,提供基础 URL;用于播种的 API 基础 URL。
- 环境类型(本地、开发、预发布)——确认不是生产环境。
- 可用的访问渠道:现有播种机制、REST API、数据库/控制台访问。
- 身份验证方式:令牌或凭据存放在哪些环境变量中。
- 要在哪个账户/租户/工作区中播种,或者是否要新建一个。
按以下顺序选择播种渠道:现有播种机制 → 应用控制台/代码 → 新建小型脚本 → REST API → MCP。 对于本地环境,可以通过后端播种数据。
步骤 3:提出类别并询问数量
- 根据步骤 1 推导类别:每种业务差异对应一个类别,并添加边界情况类别(最小/最大长度和金额、Unicode、日期边界、每个枚举值和可到达的状态、可选字段为空与填满、集合和关系的极限情况)。
- 提供一张表格,列出:类别、可供 QA 测试的内容、常规/边界情况、计划占比。
- 常规类别占总数的比例至少为 70%;边界情况类别占比最多为 30%。
- ❓ 询问用户确切的条目总数,然后重新计算各类别的条目数量并确认。
- 在生成任何内容之前,根据用户反馈调整类别。
步骤 4:生成数据集
- 使用真实感强的值:看起来像生产数据的姓名、电子邮件、地址和金额;在架构要求唯一的地方确保值唯一。
- 如果可用,请使用 Faker/lorem ipsum 生成器。
- 按依赖顺序排列记录:先放置前置记录(父记录在子记录之前,被引用的记录在引用它的记录之前)。
- 为每条记录应用运行标记。
- 在播种之前,将数据集(记录或生成规则)保存到
.testeiya/seed-data/,以便审查和重复运行。
步骤 5:为环境播种
- 按依赖顺序通过选定的渠道播种;如果渠道支持,则批量处理。
- 写入每个批次时进行验证:API 响应代码、返回的 ID 和记录数量。
- 如果应用拒绝某条记录,请修正生成器以符合要求——绝不要通过直接写入 DB 来绕过验证。
- 如果某个类别连续 3 次尝试失败,请报告失败情况及错误输出,并询问如何继续。
步骤 6:验证并交接
- 按类别重新查询环境,并将数量与已批准的计划进行比较。
- 报告一张表格,列出:类别、请求数量、创建数量,以及如何定位记录(标记)。
- 提供环境 URL;对于 Web,还需提供 QA 可以查看播种数据的页面。
- 提供清理说明:如何通过标记查找记录,并通过相同渠道删除它们。
- 提供后续选项:使用
qa-write-test-cases针对播种的数据编写测试用例,或使用qa-thinking探索该功能,找出数据集应扩展覆盖的场景。
评论
支持 Markdown