mcpField
Q
qa-data-seeder

qa-data-seeder

github.com/testomatio测试与质量1675 次安装6 天前更新
代码仓库

关于 qa-data-seeder

qa-data-seeder 是面向 QA 的技能,用于分析功能实现、规划覆盖业务类别的数据集,并将有效测试数据写入确认过的非生产环境。它要求先批准类别和数量,并为数据添加统一标记以便核查和清理。

主要功能

  1. 01分析实体、字段与校验规则
  2. 02规划常规与边界数据类别
  3. 03获批后生成并写入测试数据
  4. 04核对数量并提供清理指引

适用场景

  1. 01为新功能准备手动测试数据
  2. 02按业务状态和字段边界覆盖测试
  3. 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