test-case-designlisted

# 测试用例层 本 skill 只回答：AI 如何写高质量测试用例。不要写具体执行命令、端口、账号或工具步骤；这些交给 `test-execution-router` 与项目执行 skill。 ## 0. 第一原则 在纯 AI 开发 loop 中，用例质量决定交付质量。测试用例必须先于施工冻结，作为施工后的验收真值；施工阶段不得因为代码跑不过而就地改断言。 > [!CAUTION] > **用例不再只是验收资产，它是施工规格——是承重墙。** > 结果管控模式下，冻结用例的 `spec_hash` 是 goal 不得改写的施工锚；goal 只能产出候选件，最终完成由候选终审对真实断言与执行证据独立判定。**用例写虚了，后面的网再多也只会验收一个虚目标**（写虚/可对账的判据见 §2.1）。 > > **这一层松一寸，后面全线失守。** 所以本 skill 有两条硬要求（§2）：**每条断言有稳定编号**、**每条断言可对账**。 **防作弊的不变量：脚本断言集合 ⊇ 规格断言集合。** 脚本是规格的**翻译**——翻译可以修（写错了本来就该改），**但不能删原文**。因此： | | 用例规格（本 skill 产出） | 测试脚本（施工时产出） | |---|---|---| | 谁写的 | 施工**之外**，经评审 | 施工**之内**，第一道工序 | | 是什么 | 断言的**定义** | 断言的**翻译** | | 能不能改 | **语义不可变**（改了必须留痕） | 随便改，改错了本来就该改 | | 哈希�� | **`spec_hash`** ← 锚在这 | 没有，也不该有 | > **不要去冻结测试脚本的哈希**：脚本有 bug → 改了才能跑通 → 哈希变了 → 判定失败 → 死锁。**锚必须锚在规格上，不是锚在翻译上。** 每个重要功能至少同时考虑两条视角： - 白盒链路用例：从程序链路、状态分支、数据不变量、异常边界推导。 - 黑盒业务用例：从用户视角、业务流程、权限/空态/错误态推导。 只写“测试新增接口是否正常”“验证页面能打开”属于空壳用例，必须重写。 ## 1. 输入真值 按这个顺序收集来源： | 来源 | 提供什么 | |---|---| | L1 需求 | 用户目标、业务链路、业务规则、不变量、异常边界 | | L2 交互 | 页面状态、交互路径、视觉规格、空态/错误态 | | L3 契约 | 请求/响应字段、错误码、鉴权、状态流 | | L4 数据库 | 表结构、约束、索引语义、跨域 ID、终态不变量 | | L5 客户端方案 | 状态管理、页面链路、缓存/重试/降级决策 | | L6 服务端方案 | 状态机、事务边界、幂等、异步/补偿、外部依赖 | | 轻量设计方案 | 决策表 `DP-x` + **完整规范条目索引 `SD-x`** + 最终任务真值切片；用例必须覆盖所有可观察 SD，不能只覆盖 DP | | 用户裁决记录 | `_shared/用户裁决记录.md#DEC-x`；证明死亡线/业务结果/契约与数据语义来自用户，而非评审或测试层发明 | | diff | 本次真实改动面、风险面、回归范围 | 遇到上游不一致时，不要自行裁决；继续完成当前切片的有界只读检查，把真实决策缺口合并成一份裁决表。 > **例外——「设计没说」不是冲突，是缺陷**：写断言时发现**设计根本没定义这种情况下的结果**，这不是测试层可以代答的问题。 > 处置：若正式真值能唯一推出答案，回填设计；若必须