测试策略与计划评审应检查风险覆盖、资源匹配、可评审性和可执行性四类维度，并把文档完整性当作入口条件。评审前先明确对象、时点和结论用途，再为每个维度设定指标、证据与判定规则，结论才能落到放行、有条件放行或退回修改。
要点总览（TL;DR）
- 评审测试策略与计划时，先看风险覆盖、资源匹配、可评审性、可执行性四个维度，文档完整性只作为入口条件。
- 每个维度都要落到可核对的指标：风险覆盖率、人力缺口、环境可用率、关键项可追溯比例、入口条件就绪率，并写明单位与统计范围。
- 结论用证据支撑，文档证据、历史数据证据和定性证据分别对应不同判断；缺失值标注为“不可得”或“样本不足”，不默认按通过处理。
- 阈值按项目风险等级设定，不设通用达标线；结论分为放行、有条件放行、退回修改，整改项跟踪到关闭。
- 评审分数反映计划质量，不保证测试效果；上线后可用缺陷逃逸和风险项实际覆盖回看，并据此校准下一次评审。
评审要回答的质量问题与评估目标
评审对象是测试策略与计划本身，检查它能否指导接下来的测试工作。单份需求文档写得是否清楚，属于需求评审的范围，不在这里重复判断。评审时点通常有两个：计划定稿前，确认方向、范围和资源安排；迭代启动前，确认入口条件、依赖和排期已经落地。两个时点关注点不同，定稿前侧重策略合理性，启动前侧重执行准备度。
结论用途需要提前约定，常见三种：放行，计划可以按当前版本执行；有条件放行，列出必须在某个时间点前完成的整改项；退回修改，存在影响测试目标实现的缺口，需要重新提交。把用途写进评审通知，评审人才能对同一份计划给出一致判断。
评估目标分为两类。文档完整性回答“该有的内容是否都有”，例如风险清单、测试类型分配、资源与排期是否齐备；可执行性回答“写下的安排能否真正运行”，例如环境是否可用、依赖方是否确认、人力是否与范围匹配。完整性是入口条件，缺项可以直接退回补充；完整性通过之后，才进入可执行性判断。两类目标混在一起，容易出现文档齐全却无法执行的计划被放行。
据此可以形成一份评审目标清单，至少包含四项：评审对象及版本、评审时点、结论用途、本次待回答的质量问题。质量问题要具体，例如“高风险交易链路是否安排了足够的测试类型和深度”“测试环境在计划窗口内是否可用”，避免写成“计划是否完善”这类无法核验的表述。
评审维度与指标范围
四个核心维度分别对应不同的质量风险，每个维度需要落到可核对的指标，并写明单位和统计范围。下表给出维度与指标的对照，指标名称可按项目调整，统计范围必须在评审前固定，避免同一份计划在不同评审人手里算出不同结果。
| 维度 | 检查问题 | 指标示例 | 单位与统计范围 |
|---|---|---|---|
| 风险覆盖 | 高风险项是否都有对应测试类型与深度 | 风险覆盖率＝已分配测试类型的高风险项数÷风险清单中高风险项总数 | 百分比；统计范围为本次计划涉及的需求与变更，风险等级按项目既定分级 |
| 资源匹配 | 人力、环境、设备、时间是否与测试范围对得上 | 人力缺口＝计划所需人天－可用人天；环境可用率＝计划窗口内可用环境天数÷所需环境天数 | 人天、百分比；统计范围为计划执行周期 |
| 可评审性 | 计划能否被他人读懂、核对与追踪 | 关键项可追溯比例＝能关联到需求或风险条目的测试任务数÷测试任务总数 | 百分比；统计范围为计划内全部测试任务 |
| 可执行性 | 入口条件、依赖、排期是否落地 | 入口条件就绪率＝已确认满足的入口条件数÷列出的入口条件总数 | 百分比；统计时点为迭代启动前 |
风险覆盖是四个维度中最需要业务判断的一项。检查时逐条对照风险清单：每个高风险项是否指定了测试类型，例如功能验证、接口测试、性能测试、兼容性测试或安全测试；测试深度是否与风险影响相称，例如资金类链路安排多轮回归与异常场景，展示类页面安排基本功能验证。只统计“有没有安排测试”不够，还要看安排的类型能否暴露该类风险。
资源匹配检查数量关系。把测试范围拆成可估算的任务，汇总所需人天，与计划投入的人力对比；环境与设备按计划窗口逐项核对可用时间；排期要留出缺陷修复与回归的时间，不能把测试窗口压到只剩一轮执行。可评审性检查计划是否具备被他人核对的基础：任务是否有明确负责人、是否关联需求或风险条目、完成标准是否可判断。可执行性检查前置条件：测试数据是否准备、依赖系统是否就绪、准入标准是否写明。
数据口径与证据要求
每个维度的判断都要有证据支撑，评审表上只写结论、不附证据，结论就无法复核。证据分为三类，分别对应不同的取数方式。
文档证据来自计划本身及其附件，包括风险清单、测试类型分配表、资源与排期表、入口条件清单。这类证据用于核对“计划写了什么”，评审时逐项对照即可。数据证据来自历史记录，包括近几个版本的缺陷分布、遗留缺陷清单、环境可用记录、以往测试执行的实际耗时。这类证据用于判断计划中的估算是否合理，例如某模块历史缺陷密度高，计划却只安排一轮功能测试，就需要说明理由。定性证据包括评审记录、干系人确认、试运行反馈，用于支撑可评审性和可执行性中难以量化的判断。
数据口径要写清楚来源、时间窗和统计范围。例如缺陷分布取最近三个版本、同一产品线、上线后一个月内发现的缺陷；环境可用记录取计划窗口内的每日可用状态。口径不一致的数据不能直接比较，跨产品线或跨版本的数据需要标注差异。
缺失值要单独标注，不能默认按通过处理。某项指标因数据不可得无法计算时，在评审表中记为“不可得”，并说明原因和替代证据；样本过少时记为“样本不足”，只作定性判断。证据与结论的对应关系应当可追溯：每条结论后面注明依据的证据编号，整改项注明对应的缺口证据。这样复评时可以直接核对整改是否闭合。
评分与判定步骤
评审按固定步骤推进，保证不同评审人对同一份计划得出可比较的结论。步骤为：确定维度、确定指标、采集证据、计算或判定、汇总结论。前两步在评审前完成并写入评审表，后三步在评审会上完成。
定量指标给出公式、分子分母、时间窗和单位。以风险覆盖率为例，分子是已分配测试类型的高风险项数，分母是风险清单中高风险项总数，时间窗为本次计划范围，单位为百分比。计算前先核对风险清单是否经过确认，未确认的风险项不计入分母，避免用不完整的清单抬高覆盖率。
定性维度给出通过标准和证据门槛。可评审性的通过标准可以设为：全部测试任务有负责人，关键任务关联需求或风险条目，完成标准可判断；证据门槛为评审人抽查不少于一定比例的任务并记录抽查结果。可执行性的通过标准为：入口条件逐项有确认记录，依赖方有书面确认，排期包含回归时间。
特殊情况的处理规则需要事先约定。分母为零时，该指标不计算，记为“不适用”，并在结论中说明原因，例如本次计划不涉及高风险项；样本过少时只作定性判断，不给出百分比；数据不可比时分别列示，不做合并计算。阈值不设通用达标线，按项目风险等级设定：高风险项目对风险覆盖和入口条件就绪率要求更严，低风险项目可以适当放宽，但放宽理由要记录在评审结论中。
汇总结论时，任一维度存在影响测试目标实现的缺口，结论为退回修改；缺口可以通过限期整改解决且不影响启动的，结论为有条件放行，并列出整改项、责任人和完成时间；四个维度均满足设定阈值的，结论为放行。
一个可复算的评审示例
以下为演示情景，数据为假设，用于说明计算与判定过程，不代表任何真实项目。
某版本计划涉及一次订单模块变更，风险清单列出高风险项8项、中风险项12项。计划为其中6项高风险项分配了功能测试与接口测试，2项高风险项只写了“待补充”。风险覆盖率＝6÷8＝75%。按该项目高风险等级设定的阈值85%，风险覆盖未达标。
资源方面，计划估算测试执行需要40人天，可用人力为32人天，人力缺口8人天；计划窗口内测试环境需可用10天，实际确认可用8天，环境可用率80%。可评审性抽查20项测试任务，其中16项关联了需求或风险条目，可追溯比例80%，另有3项任务未写负责人。可执行性列出入口条件10项，已确认满足7项，入口条件就绪率70%，未确认项包括测试数据准备和依赖系统联调。
汇总判断：风险覆盖与入口条件就绪率均低于阈值，且存在未分配测试类型的高风险项，属于影响测试目标实现的缺口，结论为退回修改。整改要求包括补齐2项高风险项的测试类型与深度、补充3项任务的负责人、确认剩余入口条件；人力缺口需要通过调整范围或增加投入解决，并在复评时说明处理方式。
示例中的阈值、风险项数量和抽查比例均为假设，实际评审应按项目风险等级和团队约定设定。示例展示的是计算路径和结论形成方式，具体数值不可直接迁移到其他项目。
结果解读、限制与后续验证
评审结论反映的是计划质量，说明计划在风险覆盖、资源安排、可读性和执行准备上的完备程度，不能保证测试执行后的实际效果。计划写得完整，执行中仍可能因需求变更、环境故障或人员变动出现偏差，因此结论要写明适用范围和前提条件。
单指标不能替代整体判断。风险覆盖率高，可能只是因为风险清单列得粗；入口条件就绪率高，也可能因为条件本身定得宽松。评审时应结合证据质量看指标，发现指标与证据矛盾时以证据为准，并在结论中说明。
计划发生变更后需要触发复评。常见触发条件包括：测试范围新增或删减高风险项、排期调整超过约定幅度、关键依赖方变更、入口条件在启动前仍未确认。复评可以只针对受影响的维度，不必全量重做，但结论要更新并保留变更记录。
上线后可以用结果回看计划质量：统计缺陷逃逸情况，即上线后发现而测试阶段未发现的缺陷，按风险等级和模块归类；核对风险清单中的高风险项是否在实际测试中被覆盖；对比计划估算与实际执行耗时。这些结果用于校准下一次评审的阈值和检查重点，不直接作为个人绩效依据。
结论沟通与整改跟踪需要落到具体承接方式。评审结论、整改项、责任人和完成时间形成记录，整改项作为任务跟踪到关闭，复评时逐项核对。在ONES中，测试计划可以与迭代关联，用例分配执行人并跟踪缺陷，测试报告按模板生成，评审中识别的风险项和整改任务可以在项目工作项中承接并更新状态，使评审结论与后续执行保持在同一套记录里。具体评审检查表和评审状态字段需按实际配置确认。
常见问题
计划里风险清单列得很全，但高风险项只写了“待补充”，评审时怎么处理？
这种情况按风险覆盖维度判定为缺口。计算风险覆盖率时，未分配测试类型的高风险项仍计入分母，分子只统计已明确测试类型与深度的项，因此覆盖率会直接反映缺口。评审结论通常为退回修改，要求补齐测试类型、深度和对应负责人后再复评。如果缺口不影响本次启动且能在限定时间内补齐，也可以给有条件放行，但整改项要写明责任人和完成时间。
人力缺口和环境可用率都达标，是否就可以直接放行？
不能只看这两项。资源匹配达标只说明数量关系对得上，还要检查风险覆盖是否完整、关键任务是否可追溯、入口条件是否逐项确认。四个维度中任一维度存在影响测试目标实现的缺口，结论都应为退回修改或有条件放行。另外，指标达标也要看证据质量：人力估算如果缺少任务拆解支撑，数字本身的可信度有限，评审时应要求补充估算依据。
评审结论形成后，整改项和复评怎么衔接？
评审结论、整改项、责任人和完成时间要形成同一份记录，整改项作为任务跟踪到关闭。复评时逐项核对整改是否闭合，只针对受影响的维度重算，不必全量重做，但结论要更新并保留变更记录。常见复评触发条件包括：测试范围新增或删减高风险项、排期调整超过约定幅度、关键依赖方变更、入口条件在启动前仍未确认。在 ONES 中，评审识别的风险项和整改任务可以在项目工作项中承接并更新状态，测试计划可与迭代关联，便于把评审结论和后续执行放在同一套记录里；具体评审检查表和评审状态字段需按实际配置确认。
分母为零或样本太少时，指标还能不能算？
分母为零时该指标不计算，记为“不适用”，并在结论中说明原因，例如本次计划不涉及高风险项。样本过少时只作定性判断，不给出百分比，避免用几个样本得出看似精确的结论。数据不可比时分别列示，不做合并计算。这些规则要在评审前写入评审表，保证不同评审人对同一份计划采用一致的处理方式。
评审通过是否意味着测试执行一定有效？
评审结论反映的是计划质量，说明计划在风险覆盖、资源安排、可读性和执行准备上的完备程度，不能保证测试执行后的实际效果。执行中仍可能因需求变更、环境故障或人员变动出现偏差。上线后可以统计缺陷逃逸情况、核对高风险项是否实际被覆盖、对比计划估算与实际执行耗时，用这些结果校准下一次评审的阈值和检查重点。
