第2章 测试用例评审与基线锁定
测试用例评审与基线锁定是连接测试设计阶段与正式执行阶段的关键质量关口。本章聚焦评审流程、基线版本管理及变更控制规则,确保进入验收环境的每一份测试用例都经过同行确认、版本可追溯、变更受控。
适用场景
- 测试设计完成后,正式执行前需要进行用例质量把关的项目阶段
- 涉及多个跨职能团队(开发、测试、产品、运维)协同评审的大型/中大型发布
- 合规性要求较高的行业(金融、医疗、自动驾驶等)需要保留完整评审记录
- 已有测试用例基线,但需求/设计发生变更需要重新锁定用例版本
前置条件
| 条件项 | 检查标准 | 验收方式 |
|---|---|---|
| 测试用例编写完成 | 符合用例模板规范,覆盖率≥95%,通过工具自检 | 测试管理平台状态标记 |
| 关联需求/设计文档锁定 | 需求文档已基线化,PRD版本号明确 | 文档管理系统归档标记 |
| 评审资源就绪 | 至少2名非编写人员的评审员已经确认日程 | 会议日历确认 |
| 评审环境可用 | 用例管理平台(如TestLink、Xray、ALM)可正常发起评审流 | 平台连接测试 |
操作步骤
- 发起评审:测试负责人从用例管理平台创建评审单,选择评审范围(新增/修改用例集),设置截止时间。
- 预审阶段:评审员在24小时内完成独立预审,在用例上添加评论(通过/不通过/建议修改)。
- 评审会议(可选):对于复杂变更,召集所有评审员面对面或线上会议,逐一过有争议的用例。
- 结果整理:测试负责人汇总所有评审意见,标记“通过”“需修改”“不通过”。
- 用例修改:编写人员根据意见修改用例,并在平台中更新版本号(如 v1.2 → v1.3)。
- 二次确认:原评审员确认修改内容,必须回复“确认通过”才能进入下一阶段。
- 基线锁定:确认所有用例通过后,测试负责人在平台执行“基线锁定”操作,生成只读基线包。
- 归档通知:通过邮件或即时消息通知项目组基线版本号、存储位置及锁定时间。
输入输出物
| 类型 | 输入 | 输出 |
|---|---|---|
| 文档 | 测试用例设计稿(v1.0+) | 评审意见汇总表 |
| 元数据 | 需求版本映射表 | 基线版本号(如 TC-Baseline-v2.1) |
| 配置 | 用例管理平台评审模板配置 | 基线锁定时生成的只读快照包 |
| 通知 | 评审预约日历 | 评审结论通知邮件/IM消息 |
责任边界
- 测试负责人:发起流程、组织会议、汇总意见、执行基线锁定、存档记录。
- 用例编写人:按意见修改、更新版本号、回复确认。
- 评审员:独立预审、参与会议(如需)、确认修改结果。
- 发布经理:监督基线锁定的时效性,确保变更控制流程被执行。
- 架构师/技术负责人:在争议用例评审中提供技术决策。
记录材料
- 评审单截图(含评审起止时间、评审员清单、结论)
- 每个用例的评审评论记录(平台导出为PDF或Excel)
- 基线锁定操作日志(平台审计日志片段)
- 修改前后的用例版本对比列表
- 变更控制审批单(如果涉及紧急变更)
📌 记录保存期限:基线锁定后的全部记录至少保留至发布后3个月,合规项目(如ISO 26262)保留至项目结束+2年。
异常处理
| 异常场景 | 处理措施 | 触发人 |
|---|---|---|
| 评审员超期未预审 | 先催办(提醒),2次催办后未响应→升级至评审员直属上级 | 测试负责人 |
| 用例修改后新增依赖 | 需重新走评审流程(从第1步开始) | 用例编写人 |
| 需求基线在评审期间变更 | 暂停评审,等待需求变动完成并重新对齐后再继续 | 发布经理 |
| 基线锁定后发现有遗漏 | 启动紧急变更流程:提交变更申请→审批→解除锁定→补充→重新锁定 | 测试负责人 |
| 平台故障导致基线快照失败 | 手动备份用例库JSON/XML快照,记录故障时间,通过工单联系平台运维 | 测试负责人 |
变更控制规则
- 锁定即冻结:基线锁定后,不允许直接修改已锁定的用例。
- 最小变更原则:任何变更必须经过变更申请→影响分析→审批→解除锁定→修改→重新锁定闭环。
- 变更层级:
- 紧急变更(影响执行阻塞)→ 24小时内完成审批,高优先级处理。
- 常规变更(优化/补充场景)→ 48小时内完成。
- 版本递增规则:每次变更后用例版本号+0.1,基线版本号+0.01;若累加超过整数位则进位。
💡 最佳实践:在测试管理平台中配置自动化规则——基线锁定后自动关闭用例编辑权限,变更申请通过后自动创建子任务并升级版本号。可减少人为遗漏。
验收标准
- 所有待评审用例的评审意见都已闭合(已回复且标记为“通过”)。
- 用例管理平台中显示“基线锁定”状态,且锁定时间戳在评审结论生成之后。
- 基线包可被测试执行人员以只读方式访问,无法编辑。
- 变更控制记录(如有)已归档至项目文档库,路径清晰。
- 评审记录(含评论、附件、会议纪要)已上传至指定共享位置。
❗ 常见陷阱:评审流于形式——评审员未认真阅读用例,导致执行阶段发现大量逻辑漏洞。建议引入“逆向检查”机制:评审员必须至少发现1个有效问题或确认无问题并签名,否则评审无效。