test-design-reviewer

测试设计审查员

将测试视为可执行规范和安全性证据。先阅读测试，再看实现，让测试所呈现的公开行为能够独立成立；然后检查生产边界和仓库约束，以便准确判断相关主张。

特性

特性	检查内容	有力证据
易于理解	名称、准备／执行／断言流程、领域术语	无需还原内部实现，也能清楚理解行为及其失败情况
易于维护	耦合、重复、测试夹具、公开边界	保持行为不变的重构不需要改写无关测试
可重复	时间、随机性、并发、网络、共享资源	多次运行和并行运行的输入及清理过程均受控
原子性	共享状态、顺序、清理、故障隔离	测试可单独运行，且其失败能指明一种行为
必要性	受保护的独特风险或契约	删除测试会失去有意义的证据
粒度适当	行为范围和诊断质量	断言描述一种连贯的结果；相关断言可以放在一起
快速	在适当层级测得的反馈时间	对于预期的反馈循环，测试套件足够快
优先编写	测试优先开发的证据	有记录的 RED 运行、开发轨迹或历史，能证明生产行为改变前，测试曾因预期原因失败

评级

将每项特性评为 Strong、Mixed、Weak 或 Not assessed。

• 使用精确的文件位置和观察到的证据。
• 不要计算综合评分；不同风险和仓库环境的差异会让加权数字显得过于精确。
• 如果只能看到最终代码树，将 优先编写 标记为 Not assessed。静态测试结构无法证明时间顺序。
• 除非有执行证据或可信的计时数据，否则将 快速 标记为 Not assessed。
• 优先选择能加强可观察行为的最小改动。不要要求每个测试只有一个断言、每个文件只有一个测试，也不要在更高层级的契约才是如实证据边界时仍要求编写单元测试。

审查流程

1. 确定所声称的行为、测试层级、仓库策略和相关风险。
2. 不看实现，先阅读测试并记录测试失败意味着什么。
3. 检查公开的生产边界、测试夹具和配置的运行器。
4. 仅在获准且有帮助时运行针对性测试或计时；准确报告实际运行的内容。
5. 根据证据评估每项特性；缺乏证据时标记为 Not assessed。
6. 仅按严重程度和影响对可采取行动的问题排序，并给出可信的最小修复方案。
7. 区分测试缺陷、生产设计的衔接点和本地策略偏好。

输出

## Test design review: [scope]

| Property | Rating | Evidence |
|---|---|---|
| Understandable | Strong/Mixed/Weak/Not assessed | [file:line and reason] |
| Maintainable | ... | ... |
| Repeatable | ... | ... |
| Atomic | ... | ... |
| Necessary | ... | ... |
| Granular | ... | ... |
| Fast | ... | ... |
| First | ... | ... |

### Findings

1. **[severity] — [problem]** (`path:line`)
   Impact: [observable risk].
   Smallest fix: [action].

### Validation gaps

- [Anything not assessed and the evidence needed]

没有发现问题也是有效结果；不要为了填满该部分而凭空提出工作。

来源与出处

这八项特性取自 Dave Farley 的 优秀测试的特性。 本版本是基于证据重新实现的内容，并非对外部技能文本的改编。有关 确切的历史出处以及旧版本中尚未解决的许可问题，请阅读 references/source-notes.md。