test-case-writing

测试用例编写（英文）

中文版： 请参阅对应的中文技能。

适用场景

• 需要在真实项目场景中获得测试用例编写方面的帮助。
• 需要可直接用于执行、评审或后续跟进的输出。
• 需要将多个角色提供的场景候选项合并为一套可追溯的测试套件，避免按角色重复编写。

工作流

1. 阅读并遵循渐进式披露部分列出的主提示词（覆盖范围、结构、质量标准）。
2. 仅补充会影响结果的项目背景：范围、环境、约束、风险、依赖项、预期交付物，以及可选的、带有 source_role 的角色场景候选项。
3. 在生成统一测试套件前，根据需求追溯关系、触发条件、操作和可观测结果，识别等效候选项。
4. 如果输入不完整，先提供可用的初稿，并明确标记假设和信息缺口。
5. 默认使用 Markdown；仅在用户提出要求时切换格式。

核心约束

• 按风险／业务影响确定优先级，不要一视同仁。
• 将已确认事实与当前假设区分开。
• 不要编造用户未提供的端点、字段、环境或根因。
• 保持输出可执行：场景具体、优先级明确、后续步骤清晰。
• 不要按角色生成测试套件。等效候选项应合并为一个用例，并列出所有贡献方的 source_role、需求／验收追溯关系和风险标签。
• 仅当触发条件、执行方法或可观测结果的差异会实质性改变执行时，才拆分用例；措辞差异不足以成为重复编写的理由。

与 Plus 技能的路由边界

• 此技能仍是轻量级／默认的编写路径。它可以接收已成形的角色场景候选项，并将其合并，同时保留来源和需求追溯关系。
• 当任务要求在异构来源之间协调冲突并追溯来源、单独交付正式的追溯矩阵，或设定更高覆盖门槛（例如高风险路径必须覆盖正向、负向和边界场景，并包含数据准备与清理）时，选择 testcase-writer-plus。不要仅因为基本用例字段或此处已要求的 Trace 而切换。保持这两个技能彼此独立；不要合并或重命名。

渐进式披露

• 输出前，阅读并遵循 prompts/test-case-writing.md（最低覆盖范围、输出结构、质量标准）。
• 如果用户要求 Excel／CSV／JSON／Word：阅读 output-formats.md 并遵循相应格式。
• 如果有适用的现成模板：使用 output-templates/ 下匹配的文件。
• 对于深入的框架／故障排查／架构说明：仅阅读 references/ 下的相关文件，不要加载整个目录。
• 对于格式转换或辅助检查：优先使用现有的 scripts/，不要重复造轮子。
• 对此技能进行评估／回归测试时：使用 evals/ 和 skill-up。

交付前检查清单

• 遵循了主提示词的输出结构
• 聚焦最低覆盖要求：范围、用例优先级、前置条件、测试数据、步骤、预期结果、正向场景、负向场景、source_role 和需求追溯关系……（详情见主提示词）
• 生成了一套统一的测试套件；合并了等效的角色候选项，同时保留所有贡献角色
• 覆盖了最低检查清单，或说明了遗漏项
• 明确标注了高风险项的优先级
• 未编造用户未提供的细节
• 标记了假设和信息缺口

常见问题

• 范围／背景信息缺失时，不要假装内容完整。
• 不要把所有事项都视为同等重要。
• 不要遗漏假设和信息缺口。
• 不要将相同场景分别复制到产品、QA、UI/UX 或技术套件中；合并时也不要丢弃少数来源。
• 不要堆砌与当前工具链无关的通用理论。