| name | multica-test-design |
| description | 测试设计功能：基于需求 / 设计 / API 契约产出功能用例与接口用例，自动化优先执行，出具逐条对照验收标准的测试报告。用于功能用例 / 接口测试用例 / 测试执行 / 测试报告。 |
Test Design（测试设计）
这是什么
测试设计是一个功能，不是一个角色。它回答一个问题：
验收标准有没有被真正验证？证据是什么？
关键：测试左移——用例在设计 / 写码阶段就准备，不等到代码完成才开始。实现完成时用例已就绪，测试立即可执行。
谁来执行
- 产出与执行：由 Tester 触发本 Skill——设计阶段出功能用例，契约阶段出接口用例，实现完成后执行并出测试报告。
- 判门：测试报告由 Leader 在 G3 复核（逐条对照验收标准），Tester 不自证。
Process
- 功能用例（设计阶段，输入：需求 + 设计）：
- 逐条覆盖验收标准（每条标准 → 至少一个用例）
- 补边界 / 异常 / 回归场景
- 接口测试用例（写码阶段，输入：API 契约）：
- 正例 / 反例 / 边界 / 鉴权 / 幂等
- 每条标注：方法、路径、参数、期望状态码与响应
- 执行（G2.5 部署后，T3）：
- 用
multica-test-automation + Apifox CLI 跑场景 / 测试套件
- 无法自动化的才手动执行
- 测试报告：
- 逐条对照验收标准：PASS / FAIL / BLOCKED
- FAIL 必须给出：复现步骤、期望行为、实际行为、证据、严重程度
Result
PASS —— 验收标准全部满足且证据充分。
FAIL —— 有标准未满足。必须给出：复现步骤、期望行为、实际行为、证据、严重程度。
BLOCKED —— 缺环境 / 数据 / 依赖，无法验证。如实报告，绝不转成 PASS。
与 verification skill 的关系
multica-verification：判门（Leader 在门禁点复跑 / 核对 CI 结论）multica-test-design：产出用例 + 执行 + 报告（Tester）
测试报告是 G3 判门的输入；用例的自动化版本是 CI 硬门禁的一部分。两者互补：用例怎么来、怎么跑由本 Skill 定，判门由 Leader 定。
为什么有效
测试最容易做成「补作业」：代码写完才想怎么测，测过等于测了。左移 + 逐条对照 + 自动化优先三条规则，把测试从「事后证明」变成「设计的一部分」，也让判门有机器可复跑的证据。
