mcpField
T
test-data-generation

test-data-generation

github.com/naodeng测试与质量28944 次安装今天更新
代码仓库

关于 test-data-generation

用于设计可复用测试数据集,并审查测试数据计划或证据的技能。重点关注风险覆盖、可复现性、隐私约束,以及事实与假设的区分。

主要功能

  1. 01设计可复用测试数据集
  2. 02覆盖边界与数据组合
  3. 03审查计划与证据
  4. 04检查可复现性和清理方式
  5. 05遵循隐私数据约束

适用场景

  1. 01为业务规则设计测试数据
  2. 02审查现有测试计划或结果
  3. 03在上下文不完整时形成初步方案

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/naodeng/awesome-qa-skills --skill test-data-generation

安装后在 Claude Code 中输入/test-data-generation确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

agents/
openai.yaml
evals/
eval.yaml
evals/cases/
basic-success.yaml
domain-method-regression.yaml
edge-incomplete-input.yaml
edge-risk-priority.yaml
evals/fixtures/
check_domain_decisions.py
check-domain-decisions.sh
domain-oracle.json
prompts/
test-data-generation.md
references/
domain-decision-example.md

详细介绍

测试数据生成

适用场景

  • 需要设计可复用的测试数据集,覆盖业务规则、边界、组合和隐私约束时,使用此技能。
  • 需要审查现有计划、结果或证据集并提出可执行的改进建议时,使用此技能。
  • 即使上下文不完整,但仍可先进行有范围限制的初步分析时,使用此技能。

输出格式选项

  • 默认使用 Markdown 进行审查、执行和迭代完善。
  • 用户要求表格、CSV、JSON 或工单字段时,保留风险、证据、优先级和边界信息。
  • 对于机器消费的输出,先确认架构、枚举值和必填字段。

使用方法

  1. 阅读并遵循 prompts/test-data-generation.md,包括其输入约定、执行规则、最低覆盖要求和输出顺序。
  2. 仅补充会影响决策的上下文:范围、环境、版本、约束、证据和成功标准。
  3. 审核输入,然后区分已确认事实、工作假设和待解问题。
  4. 根据风险和证据强度排序,并生成可直接执行或审查的产物。
  5. 如果信息缺失,提供有范围限制的初步分析,并说明哪些结论缺乏支持。

参考文件

  • 校准领域结果、有效对照或证据缺口时,请阅读 references/domain-decision-example.md,了解经过脱敏的输入、逐项判定标准和可复现的计算。

  • 始终阅读 prompts/test-data-generation.md;它是此技能的完整执行规范。

  • 进行评估或回归测试时,请阅读 evals/eval.yaml 和 evals/cases/ 下的相关案例。

  • 仅在相关目录存在且任务需要时,才加载 references/、examples/、scripts/ 或 output-formats.md。

领域执行要点

  1. 根据提供的架构、外键、唯一性、状态关系和场景判定标准推导数据组。固定种子和生成器版本;缺失的规则保持为 UNKNOWN,不得虚构字段或真实身份。
  2. 将有效的正常及边界数据与刻意构造的无效数据组分开。注明违反的约束以及预期的允许/拒绝结果,同时保留其他关系;无效行不得悄然混入有效数据组。
  3. 提供经过脱敏的实际样本,并检查唯一性、外键、类型/范围、状态和可复现性。相同种子必须复现相同的数据标识,而不能只给出策略说明。
  4. 使用隔离的 ID/命名空间,并记录来源、隐私限制和反向依赖清理方式。缺少授权时,不得收集真实个人数据;合成数据不能证明其具有总体代表性。

核心约束

  • 绝不使用真实个人敏感数据
  • 区分合成数据、脱敏数据和仿生产数据
  • 生成的数据必须可复现且可清理
  • 不得虚构证据中不存在的系统行为、字段、数据、指标或根本原因。
  • 重要结论必须关联证据;对缺乏支持的结论,应标记为假设并说明验证方法。
  • 根据业务影响、发生可能性或可检测性说明优先级。

交付检查清单

  • 覆盖:有效值和无效值、边界、等价类、组合、引用完整性、状态、角色、本地化、隐私、清理。
  • 区分事实、假设、缺口和建议。
  • 为高风险项目标注优先级、证据依据、负责人或后续行动。
  • 定义可验证的判定标准,而非泛泛建议。
  • 未执行未经授权的生产环境写入或破坏性操作。

常见陷阱

  • 列出检查项,却没有前置条件、预期结果或证据。
  • 将所有事项都标为高优先级,回避权衡。
  • 用工具名称或泛泛理论取代领域推理。
  • 因输入不完整而拒绝处理,或假装不完整的证据足以支持确定结论。

最佳实践

  • 优先检查最可能导致业务损失、安全问题或发布受阻的路径。
  • 通过最小且可验证的实验降低不确定性,并记录复现条件。
  • 确保产物可执行,且另一位工程师能够独立审查。

评论

支持 Markdown