测试规范层

本 skill 只回答：这次改动必须测什么、测到什么深度、什么情况不能交付。不要在本层写具体命令、账号、端口、脚本写法或项目工具细节；执行方式交给 test-execution-router 与项目执行 skill。

0. 第一原则

在纯 AI 开发 loop 中，测试是最后一道质量闸，不是可选收尾。没有测试矩阵、没有自动化执行证据、没有无法自动化的明确理由，不允许交付。

默认规则：

• 能由 AI 自动化的测试必须自动化。
• AI 可控制浏览器/开发者工具、读取 DOM/data、截图并用 VLM 判读时，仍属于自动化；“有 GUI”“需要看图”“工具是交互式”都不是手工理由。
• 只有 AI 无法操作的真实设备、原生客户端对象、支付/OAuth/原生授权等物理边界，才允许转人工手工验证。
• 手工验证必须有物理边界证明、runbook、客观观测点、回传材料和写明责任角色的计划内人工里程碑。
• 跳过任一测试类型时，必须说明本次改动为什么不命中，而不是写“暂不需要”。
• 每次测试矩阵对下列八面恰好各有一行；不命中写可核 N/A 理由，禁止省略行。

1. 必选测试面

每次改动都先判断是否命中下列测试面，并形成测试矩阵：

2. 改动范围到测试矩阵

按改动范围选择测试组合：

3. 数据策略

根据业务真实性和风险选择数据策略：

4. 最低断言深度

断言必须验证业务语义，不只验证“跑通”：

运行证据同样受本节约束：套件退出码、文件存在、日志/报告哈希、测试名或 AC 编号只能证明“执行载体发生过”，不能单独证明业务断言。每条通过结论必须能回到框架原生断言事件、真实扫描结果或采集时物理边界原始观测。

5. 交付阻断条件

以下任一情况必须阻断交付：

• 未产出测试矩阵。
• 直接命中的测试面没有执行证据。
• 跳过测试没有具体原因。
• 自动化失败被标成“手工通过”替代。
• AI 可控 GUI、开发者工具或 VLM 判读被降级成手工。
• 手工项缺物理边界证明、runbook 或计划内人工里程碑及责任角色。
• 用例失败后未分类就改断言或删除用例。
• 只跑冒烟测试，却宣称完成正式接口/业务验证。
• 视觉变化只有截图文件，没有判读结论。
• 数据写链路只有接口响应，没有 DB 终态校验。
• 用模拟/构造替身的结果冒充真实链路验证（未标注保真度 simulated，或未写明真实链路收口去向）。
• 改动命中死亡线/高风险区域，对应金标准用例未生效（无 execution_ref），却未显式登记豁免并上报。
• VERIFIED 只绑定套件成功、聚合哈希或换名后的通用观测，不能还原该 AC 的实际业务结果。
• 金标准只有正向返回值，没有不变量终态与负向副作用的原生观测事件。

6. 输出格式

使用本 skill 后，输出至少包含：

## 测试矩阵（固定八面，各一行）
| 测试面 | 本次是否命中 | 原因/N/A证据 | 自动化/手工 | 保真度(真连/模拟/手工) | 证据要求 |

## 数据策略
- 选择：DB 预置 / 接口造数 / 复用数据 / 人工前置
- 理由：
- 清理与隔离：

## 最低断言
- 接口：
- DB：
- UI/视觉：

## 阻断项
- 未覆盖测试：
- 不能自动化原因：

7. 与其他 skill 的边界

• 写具体用例：使用 test-case-design。
• 路由执行：使用 test-execution-router。
• 项目命令、凭据、浏览器、小程序、视觉工具：使用项目执行 skill。