评审有哪些形式
评审（review）是缺陷最早、最便宜的把关点：需求、设计、代码、用例在进入下一环节前由同行检查。形式从轻到重：走查（作者主导讲解）、同行评审（合并请求加检查表）、正式审查（含主持人、检查员与记录员分工）。测试视角里，用例评审与需求可测性评审是左移的抓手。
基本信息
| 常见类型 | 需求评审、设计评审、代码评审、用例评审、发布方案评审 |
|---|---|
| 轻量做法 | 合并请求加检查表，全员异步评 |
| 正式做法 | 主持人、检查员、记录员分工，先准备后会议 |
| 用例评审重点 | 覆盖等价类与边界、步骤可执行、预期明确 |
| 需求评审重点 | 歧义、缺失异常流、可验证性 |
| 产出 | 问题清单、修改责任人与截止时间 |
类型与检查重点
| 评审类型 | 检查重点 | 常见失效 |
|---|---|---|
| 需求评审 | 歧义与可测性 | 只讨论价值不纠措辞 |
| 设计评审 | 接口与异常路径 | 图上过了，细节没人看 |
| 用例评审 | 覆盖与可执行 | 对着写好的用例点头 |
| 代码评审 | 逻辑、边界与安全 | 只挑代码风格 |
| 发布评审 | 回滚与监控方案 | 形式化签字 |
典型使用场景
- 冲刺启动前：需求澄清与可测性确认
- 用例设计完成后：同行评审补漏与统一预期
- 关键模块合并前：代码评审把关逻辑与边界
- 发布前：回滚步骤与监控方案评审
- 事故之后：把新规则纳入对应环节的检查表
评审要限范围与时长：大变更拆批评审，百文件一次过等于没人看过，检查质量趋近于零。
检查表比「仔细看看」有效：把历史事故整理成检查项，评审按表走，新人也接得住。
评审意见要有闭环：改或不改都要有结论与记录，否则同样的意见会在下一次评审重复出现。