multica-test-design

name	multica-test-design
description	测试设计功能：基于需求 / 设计 / API 契约产出功能用例与接口用例，自动化优先执行，出具逐条对照验收标准的测试报告。用于功能用例 / 接口测试用例 / 测试执行 / 测试报告。

Test Design（测试设计）

这是什么

测试设计是一个功能，不是一个角色。它回答一个问题：

验收标准有没有被真正验证？证据是什么？

关键：测试左移——用例在设计 / 写码阶段就准备，不等到代码完成才开始。实现完成时用例已就绪，测试立即可执行。

谁来执行

• 产出与执行：由 Tester 触发本 Skill——设计阶段出功能用例，契约阶段出接口用例，实现完成后执行并出测试报告。
• 判门：测试报告由 Leader 在 G3 复核（逐条对照验收标准），Tester 不自证。

Process

1. 功能用例（设计阶段，输入：需求 + 设计）：
   • 逐条覆盖验收标准（每条标准 → 至少一个用例）
   • 补边界 / 异常 / 回归场景
2. 接口测试用例（写码阶段，输入：API 契约）：
   • 正例 / 反例 / 边界 / 鉴权 / 幂等
   • 每条标注：方法、路径、参数、期望状态码与响应
3. 执行（G2.5 部署后，T3）：
   • 用 multica-test-automation + Apifox CLI 跑场景 / 测试套件
   • 无法自动化的才手动执行
4. 测试报告：
   • 逐条对照验收标准：PASS / FAIL / BLOCKED
   • FAIL 必须给出：复现步骤、期望行为、实际行为、证据、严重程度

Result

PASS —— 验收标准全部满足且证据充分。

FAIL —— 有标准未满足。必须给出：复现步骤、期望行为、实际行为、证据、严重程度。

BLOCKED —— 缺环境 / 数据 / 依赖，无法验证。如实报告，绝不转成 PASS。

与 verification skill 的关系

• multica-verification：判门（Leader 在门禁点复跑 / 核对 CI 结论）
• multica-test-design：产出用例 + 执行 + 报告（Tester）

测试报告是 G3 判门的输入；用例的自动化版本是 CI 硬门禁的一部分。两者互补：用例怎么来、怎么跑由本 Skill 定，判门由 Leader 定。

为什么有效

测试最容易做成「补作业」：代码写完才想怎么测，测过等于测了。左移 + 逐条对照 + 自动化优先三条规则，把测试从「事后证明」变成「设计的一部分」，也让判门有机器可复跑的证据。