测试计划评审会前准备清单:检查项与通过标准
测试计划评审会开得顺不顺,往往在会前已经决定。这份清单面向测试计划编写人、测试负责人和评审主持人,用于计划初稿完成到评审会开始之间的自查:确认评审对象与参会角色,按范围与目标、测试策略与方法、环境与数据、进度与资源、风险与应对、出口准则与度量六个维度逐项核对,每项写明通过标准、证据材料和负责人。缺失关键输入、出口准则不可判定等情况列为阻断项,未闭环不进入评审会。
Table of Contents
要点总览(TL;DR)
- 会前准备清单在计划初稿完成后、评审会前2–3个工作日启动,由编写人自检、模块负责人交叉核对、主持人汇总放行结论。
- 检查表覆盖范围与目标、测试策略与方法、环境与数据、进度与资源、风险与应对、出口准则与度量六个维度,每项写明通过标准、证据材料、负责人和阻断标记。
- 阻断项集中在范围与需求基线不一致、出口准则无法判定、关键环境或数据无着落、关键角色缺席四类;表述与格式问题可会后修订。
- 放行结论分通过、带条件通过、延期评审三种,阻断项闭环由测试负责人确认。
- 会中按清单逐项核对并记录意见,涉及范围、出口准则、环境依赖的修改完成后由测试负责人发起针对性复审。
谁在什么时点使用这份清单
清单的价值在于把“准备得差不多了”变成可判断的状态。使用对象和时点先定清楚,后续检查项才有执行主体。
| 角色 | 在清单中的职责 | 主要动作时点 |
|---|---|---|
| 测试计划编写人 | 完成计划初稿,按六维度逐项自检并附证据 | 评审会前2–3个工作日启动 |
| 测试负责人 | 确认范围、策略、出口准则的口径,裁定阻断项处置方案 | 自查期间及会前汇总时 |
| 模块负责人 | 交叉核对本人负责模块的检查项与证据 | 自查启动后1–2个工作日内 |
| 评审主持人 | 汇总自查结果,确认放行结论,组织会中逐项核对 | 会前1个工作日及评审会现场 |
| 开发、产品等评审参与方 | 提前阅读计划与证据材料,准备异议点 | 会前收到材料至评审会 |
启动时点建议放在计划初稿完成之后、评审会前2–3个工作日。这个间隔要留出交叉核对和补材料的时间;如果初稿在会前半天才成形,清单只能变成形式确认。完成时点的判断标准是:全部检查项自查通过,或者阻断项已有明确处置方案并确定责任人。达到这个状态,清单在会中转为逐项核对依据,按顺序过条目、记录结论与异议。
会前自查:六个维度的检查项与通过标准
以下检查表可直接勾选使用。“通过标准”一列描述可判断的完成状态,“证据”一列指向可查阅的材料,“阻断”一列标记该项未通过时是否影响开会。
| 维度 | 检查项 | 通过标准 | 证据材料 | 负责人 | 阻断 |
|---|---|---|---|---|---|
| 范围与目标 | 测试范围边界与不测项 | 写明本次覆盖的模块、版本与明确排除的内容,排除项有理由 | 计划文档“范围”章节 | 编写人 | 是 |
| 范围与目标 | 目标与验收口径 | 目标可对应到需求或验收标准,无“尽量覆盖”类模糊表述 | 需求基线、验收标准文档 | 编写人、产品 | 是 |
| 测试策略与方法 | 测试类型选取 | 功能、接口、性能、兼容、安全等类型的取舍有理由,与风险匹配 | 计划文档“策略”章节 | 测试负责人 | 否 |
| 测试策略与方法 | 覆盖关系说明 | 各类型测试与需求、模块的对应关系可追溯,无大面积空白 | 需求—用例覆盖表 | 模块负责人 | 是 |
| 环境与数据 | 环境清单与版本 | 列出所需环境、部署版本、配置差异,申请状态明确 | 环境清单、申请记录 | 编写人 | 是 |
| 环境与数据 | 测试数据准备 | 关键数据来源、脱敏方式、准备完成时间已确认 | 数据准备说明 | 模块负责人 | 是 |
| 进度与资源 | 里程碑与准入准出时间 | 提测、测试执行、回归、发布各节点有日期,与迭代排期一致 | 排期表 | 编写人 | 是 |
| 进度与资源 | 人力分工 | 各模块执行人明确,投入比例与冲突已协调 | 分工表 | 测试负责人 | 否 |
| 风险与应对 | 风险登记 | 已识别风险有影响面、触发条件、应对措施与责任人 | 风险登记表 | 编写人 | 否 |
| 出口准则与度量 | 出口准则可判定 | 缺陷收敛、用例通过率、遗留问题处理口径均给出数值或明确规则 | 计划文档“出口准则”章节 | 测试负责人 | 是 |
| 出口准则与度量 | 度量与报告方式 | 说明报告频率、指标口径与呈现形式,数据来源可获取 | 报告模板、指标定义 | 编写人 | 否 |
填写时有两点容易走样。一是通过标准写成“已考虑”“基本明确”,这类表述无法判断是否完成,应改成可核对的状态,例如“排除项列出且每项附一句理由”。二是证据材料指向口头确认,会中无法追溯,应落到具体文档或记录。策略与方法维度中,测试类型的取舍理由比类型数量更重要:一个版本只做功能与接口测试,只要理由与风险匹配,同样可以通过。
证据材料与责任人对照
检查项通过与否,最终落在证据上。会前把证据类型、责任人和存放位置对齐,催办和追溯都有明确对象。
| 证据类型 | 对应检查维度 | 提供人 | 核对人 | 存放与版本要求 |
|---|---|---|---|---|
| 测试计划文档 | 全部维度 | 编写人 | 测试负责人 | 统一存放,文件名含版本号与日期 |
| 需求与设计输入 | 范围与目标、策略 | 产品、开发 | 编写人 | 引用需求基线版本号 |
| 环境清单与申请记录 | 环境与数据 | 编写人、运维 | 模块负责人 | 标注环境版本与可用时间 |
| 排期表与分工表 | 进度与资源 | 编写人 | 测试负责人 | 与迭代排期同源,注明更新日期 |
| 风险登记表 | 风险与应对 | 编写人 | 测试负责人 | 每条风险有责任人与触发条件 |
| 出口准则与报告模板 | 出口准则与度量 | 测试负责人 | 评审主持人 | 指标口径写明计算方式 |
责任分工按三层推进:编写人先完成自检并附齐证据;模块负责人对本人模块交叉核对,重点看覆盖关系和环境依赖;主持人汇总全部结果,形成放行结论。证据统一放在约定位置并带版本标识,避免会中出现“最新版是哪份”的争议。某项证据在约定时点仍未提供,处理方式有两种:属于阻断项的,直接进入阻断清单并确定补交期限;属于非阻断项的,记录缺口,会后补齐并在复审时确认。
阻断项与放行条件
把所有未通过项都当成阻断项,评审会永远开不起来;把阻断项当普通问题放过,评审会就失去意义。分级标准要提前写清楚。
典型阻断项包括四类:测试范围与需求基线不一致,例如计划覆盖的模块与当前基线版本对不上;出口准则无法判定,例如只写“缺陷基本收敛”而没有数值或规则;关键环境或测试数据没有着落,导致计划无法执行;关键角色缺席,例如需求负责人或环境负责人无法参会确认。这些情况即使开会,也无法形成有效结论。
非阻断项主要是表述细节、格式与措辞问题,例如章节顺序不统一、术语前后不一致、图表样式待调整。这类问题记录后会后修订,不影响评审进行。
阻断项的闭环判定由测试负责人确认,必要时与需求负责人共同确认。确认方式是在阻断清单上写明处置方案、责任人和完成时间,并附对应证据。放行结论分三种:
- 通过:全部阻断项闭环,非阻断项已记录,按计划开会。
- 带条件通过:阻断项已有明确处置方案和期限,会议可开,但相关结论以条件满足为前提,会后按期限核验。
- 延期评审:存在无处置方案的阻断项,会议改期,重新确定自查完成时点。
会中逐项核对与会后闭环
评审会现场按清单顺序逐项核对,主持人逐条读出检查项与自查结论,参会方提出异议并当场记录。核对的目的在于确认结论,逐条重读计划内容并不必要。范围、出口准则、环境依赖这几类阻断项优先过,确保会议时间用在关键分歧上。
评审意见按统一字段记录,便于会后跟踪:
| 字段 | 填写要求 |
|---|---|
| 条目 | 对应检查项编号或计划章节 |
| 意见内容 | 具体到可修改的动作,避免“再完善一下” |
| 提出人 | 记录到人,便于澄清 |
| 处置方式 | 采纳修改、保留说明、转后续版本 |
| 责任人 | 修改或说明的承担人 |
| 期限 | 与复审时点对齐 |
会后跟踪的触发条件是:涉及范围、出口准则、环境依赖的修改完成后,由测试负责人发起复审,复审可只针对修改条目,不必重开完整评审。其余修订由主持人在约定时点汇总确认。清单与记录一并归档,下次评审直接复用同一套检查项,并根据上次的阻断项和意见分布调整重点。
当评审材料分散在文档、需求条目和排期表中时,会前汇总和会后跟踪容易脱节。ONES 测试管理支持测试计划与迭代关联,测试用例与需求、任务关联,计划的范围和覆盖关系可以在同一处核对;测试报告支持自定义模板并自动生成,出口准则中的通过率、缺陷情况有对应数据来源。评审意见可以落到工作项上,指定责任人与期限,修订状态在会前汇总时直接可见。对于需要按用户组控制计划可见范围的团队,还可以为测试计划单独配置权限。
常见问题
计划初稿在评审会前一天才完成,清单还能用吗?
可以用,但要压缩范围。把六个维度中标记为阻断的检查项先过一遍,确认范围与需求基线是否一致、出口准则能否判定、关键环境和数据有无着落、关键角色能否到场;非阻断项记录缺口,会后补齐。若阻断项无法在会前闭环,按延期评审处理,重新确定自查完成时点,避免会议开成材料补交会。
测试类型只做了功能和接口,评审时会被要求补齐性能与安全测试吗?
取决于取舍理由是否与风险匹配。检查表对策略维度的通过标准是“类型取舍有理由”,并不要求覆盖所有类型。计划中写明本版本变更集中在业务逻辑与接口契约、性能与安全影响面小且有既往基线可参照,这类说明通常可以通过。若变更涉及高并发路径或对外暴露的新接口,而计划未提及相应验证,评审方提出补充要求属于正常范围。
出口准则写到什么程度算可判定?
可判定的出口准则给出数值或明确规则,例如用例通过率达到约定比例、严重缺陷全部关闭、遗留问题有明确的分级处理口径和责任人。只写“缺陷基本收敛”“质量达到发布要求”这类表述无法在发布前判断是否达标,属于阻断项。指标口径还应写明计算方式,例如通过率按用例数还是按执行轮次统计,避免会后对数据产生分歧。
评审意见记在文档批注里,会后怎么保证不漏项?
批注适合表达意见,跟踪需要结构化记录。会中按统一字段登记:对应条目、意见内容、提出人、处置方式、责任人和期限,处置方式区分采纳修改、保留说明、转后续版本。记录集中存放,主持人在约定时点汇总确认。涉及范围、出口准则、环境依赖的修改完成后,由测试负责人发起复审,复审只针对修改条目。使用 ONES 时,评审意见可以落到工作项上并指定责任人与期限,修订状态在会前汇总时直接可见。
同一套检查表能直接用于下一个版本的测试计划评审吗?
可以复用,但建议每次评审前根据上一轮情况调整重点。上次出现的阻断项类型、意见集中分布的维度,可以在本次自查中提前关注。检查项本身保持稳定有利于横向比较,新增检查项应说明原因,避免清单逐版本膨胀到无人逐条核对。



