测试计划评审检查表围绕范围与目标、测试策略与方法、环境与数据、进度与资源、风险与应对、准入准出与交付物六类维度展开。每个检查项都写明通过标准、所需证据和负责人，评审前由计划编写人自检并附证据，评审会上逐项核对，阻断项未关闭则计划不通过。这份检查表适合直接用于会前准备和现场核对。
要点总览（TL;DR）
- 检查表按范围与目标、测试策略与方法、环境与数据、进度与资源、风险与应对、准入准出与交付物六类维度组织，每项写明通过标准、证据和负责人。
- 会前由计划编写人自检并附证据，会中由测试负责人主持逐项核对，会后关闭阻断项并提交复检，三个时点的产出分别对应自检记录、评审记录和关闭记录。
- 范围未定、准入准出条件不可判断、环境无责任人、关键依赖无交付时间、风险无责任人等属于典型阻断项，未关闭则计划不通过。
- 评审结论分为通过、有条件通过和不通过，有条件通过需写明关闭时限和复检方式，结论与计划版本一并归档留痕。
- 通过标准要写成可判断、可举证的表述，证据指向文档具体章节或记录，负责人填写到角色或具体岗位。
谁在什么时点使用这份检查表
检查表的使用对象包括计划编写人、测试负责人和评审参与角色，三类角色在会前、会中、会后承担不同动作。计划编写人通常是测试计划的主要作者，负责会前自检、准备证据、整理待决问题；测试负责人负责组织评审、判定阻断项、确认结论；评审参与角色包括开发负责人、产品负责人、运维或环境负责人等，负责在会中按各自领域核对检查项并给出意见。
三个时点的动作可以对照如下：
| 时点 | 主要角色 | 动作 | 产出 |
|---|---|---|---|
| 会前 | 计划编写人 | 按检查表自检，补齐证据，列出待决问题 | 自检记录、待决问题清单、计划版本 |
| 会中 | 测试负责人主持，评审参与角色核对 | 逐项核对通过标准，记录意见，标记阻断项 | 评审记录、阻断项清单、评审结论 |
| 会后 | 计划编写人与责任人 | 关闭阻断项，更新计划版本，提交复检 | 关闭记录、新版本计划、复检结论 |
检查表与评审记录、计划版本需要绑定。每轮评审对应一个计划版本号，评审记录中注明所用检查表版本和各项判定结果；计划修改后版本号递增，阻断项关闭情况在新版本中体现。这样后续追溯时能看清某个结论是基于哪一版计划和哪一版检查表得出的。
会前准备：计划编写人先自检哪些项
会前自检的目标是让提交评审的计划具备可讨论的完整度，把能在会前补齐的信息补齐，减少会上临时找资料。计划编写人可按以下清单自检：
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 计划版本与变更说明 | 计划有明确版本号，相比上一版的变化有说明 | 计划文档版本记录、变更说明段落 | 计划编写人 |
| 评审范围 | 写明本次评审覆盖的章节和不在本次讨论范围的内容 | 评审通知或计划首页说明 | 计划编写人 |
| 需求与范围依据 | 测试范围能追溯到需求文档、设计文档或需求编号 | 需求链接、需求清单、追溯表 | 计划编写人 |
| 待决问题清单 | 尚未确定的问题已列出，并标注期望决策人和决策时点 | 待决问题列表 | 计划编写人 |
| 证据附件齐备 | 检查表要求的证据已随计划提交，缺项有说明 | 附件清单 | 计划编写人 |
自检完成后，计划编写人在提交评审时附上自检结果，标明哪些项已通过、哪些项需要会上讨论。测试负责人据此判断是否具备开会条件，避免在会上才发现基础信息缺失。
范围与目标检查项
范围与目标类检查项核对测试对象边界、目标与验收口径是否清晰可判断。范围含糊是评审中最常见的阻断原因，这一组检查项需要重点核对。
| 检查项 | 通过标准 | 证据 | 负责人 | 是否阻断 |
|---|---|---|---|---|
| 测试范围界定 | 列出被测系统、模块或功能清单，边界明确 | 范围清单、系统架构图 | 测试负责人 | 是 |
| 不测范围说明 | 明确本次不测的内容及原因，相关方已知悉 | 不测范围列表、沟通记录 | 测试负责人 | 是 |
| 测试目标与质量目标对应 | 每项测试目标能对应到质量目标或验收指标 | 目标对照表 | 测试负责人 | 是 |
| 需求覆盖与优先级 | 需求覆盖有清单，优先级划分有依据（如业务重要性、变更风险） | 需求覆盖表、优先级说明 | 计划编写人 | 否 |
| 验收口径 | 验收标准可判断，如缺陷密度、通过率、遗留缺陷等级 | 验收标准章节 | 测试负责人 | 是 |
范围与目标类检查项中，范围未定、不测范围未说明、验收口径缺失通常列为阻断项，因为这些内容直接影响后续策略和排期的合理性。需求覆盖和优先级划分属于改进项，可以在评审中提出优化建议，不阻断评审通过。
测试策略与方法检查项
策略与方法类检查项核对各类测试如何规划，包括测试类型取舍、分层策略和准入准出条件的设计依据。检查重点是取舍理由是否成立，而非测试类型是否齐全。
| 检查项 | 通过标准 | 证据 | 负责人 | 是否阻断 |
|---|---|---|---|---|
| 测试类型取舍 | 功能、性能、兼容、安全等类型有取舍说明，选择或排除均有理由 | 策略章节、风险分析 | 测试负责人 | 是 |
| 测试分层规划 | 单元、接口、系统、验收等层次的分工和覆盖比例有说明 | 分层策略表 | 测试负责人 | 否 |
| 用例设计方法 | 说明采用的设计方法（如等价类、边界值、场景法）及适用对象 | 用例设计说明 | 计划编写人 | 否 |
| 准入条件 | 进入测试的条件可判断，如构建通过、冒烟通过、环境就绪 | 准入条件章节 | 测试负责人 | 是 |
| 准出条件 | 退出测试的条件可判断，如用例执行率、缺陷收敛趋势、遗留缺陷等级 | 准出条件章节 | 测试负责人 | 是 |
准入准出条件缺失或写成“基本完成”“主要功能可用”这类无法判断的表述，应列为阻断项，要求改为可量化或可举证的表述。测试分层和用例设计方法属于改进项，评审中可以建议补充，但不影响计划整体通过。
环境、数据与工具检查项
环境、数据与工具类检查项核对准备计划是否落到责任人和时间点。这一组检查项常见的问题是写了“需要测试环境”但没有说明谁在什么时候准备好。
| 检查项 | 通过标准 | 证据 | 负责人 | 是否阻断 |
|---|---|---|---|---|
| 环境类型与数量 | 列出所需环境类型（开发、测试、预发、生产仿真等）和数量 | 环境清单 | 环境负责人 | 是 |
| 环境就绪时间 | 每类环境有就绪时间点，与测试窗口匹配 | 环境准备计划 | 环境负责人 | 是 |
| 测试数据来源 | 说明数据来源（生产脱敏、构造数据、第三方提供） | 数据准备说明 | 计划编写人 | 是 |
| 数据脱敏方式 | 涉及生产数据时有脱敏方案和审批记录 | 脱敏方案、审批记录 | 数据负责人 | 是 |
| 工具与缺陷跟踪配置 | 测试管理工具、缺陷跟踪流程已配置，责任人明确 | 工具配置截图、流程说明 | 测试负责人 | 否 |
环境无责任人、环境就绪时间缺失、生产数据无脱敏方案，通常列为阻断项。工具配置属于改进项，可以在测试启动前完成，不阻断计划评审通过。
进度、资源与协作检查项
进度、资源与协作类检查项核对排期、人力投入和跨团队依赖是否可执行。检查时把计划中的时间点与范围、策略对照，看是否匹配。
| 检查项 | 通过标准 | 证据 | 负责人 | 是否阻断 |
|---|---|---|---|---|
| 里程碑与测试窗口 | 测试窗口与开发提测、上线时间衔接，窗口长度与范围匹配 | 排期表、里程碑计划 | 测试负责人 | 是 |
| 人力与角色投入 | 各阶段人力投入有说明，角色分工明确 | 资源计划表 | 测试负责人 | 是 |
| 对外依赖 | 依赖的外部团队、接口、服务有清单和交付时间 | 依赖清单 | 计划编写人 | 是 |
| 交接点约定 | 提测、转测、回归等交接点有明确输入输出 | 交接约定说明 | 测试负责人 | 否 |
| 沟通机制 | 例会、日报或同步方式有约定 | 沟通计划 | 计划编写人 | 否 |
测试窗口明显短于范围所需工作量、关键依赖无交付时间，应列为阻断项。交接点和沟通机制属于改进项，可在计划执行中调整。
风险、应对与度量检查项
风险、应对与度量类检查项核对风险识别、应对措施和过程度量是否可跟踪。检查重点是每项风险是否有责任人和应对动作，度量是否有取数口径。
| 检查项 | 通过标准 | 证据 | 负责人 | 是否阻断 |
|---|---|---|---|---|
| 风险清单 | 列出主要风险，标注影响程度和发生可能性 | 风险清单 | 测试负责人 | 是 |
| 应对措施与责任人 | 每项风险有应对措施和责任人 | 风险应对表 | 测试负责人 | 是 |
| 度量取数口径 | 进度、质量度量指标有定义和取数方式 | 度量指标说明 | 计划编写人 | 否 |
| 异常升级路径 | 进度延误、质量不达标等异常有升级路径和决策人 | 升级流程说明 | 测试负责人 | 是 |
风险无责任人、异常无升级路径，通常列为阻断项，因为这两项缺失会导致执行中出现问题时无人决策。度量口径属于改进项，可在测试执行前补充。
通过标准、证据与负责人如何填写
每项检查的判定方式决定检查表是否可用。通过标准要写成可判断、可举证的表述，避免“合理”“充分”“基本完成”这类无法核对的词。写法上可以采用“有/无”“列出/未列出”“可追溯到/无法追溯”“时间点明确/未明确”等判断结构。
证据类型按检查项选择，常见的有：计划文档的具体章节、需求链接或追溯表、评审记录、环境准备计划或截图、工具配置截图、审批记录、风险清单。证据要能指向具体位置，例如“计划第3.2节范围清单”比“计划中有范围说明”更便于核对。
负责人填写到角色而非泛称。写“环境负责人”比写“相关人员”更明确；如果组织中没有该角色，写具体岗位，如“运维值班负责人”“测试环境管理员”。示例行如下：
| 检查项 | 通过标准 | 证据 | 负责人 | 是否阻断 |
|---|---|---|---|---|
| 准出条件 | 准出条件包含可量化指标，如用例执行率不低于约定值、遗留缺陷等级有上限 | 计划第5章准出条件 | 测试负责人 | 是 |
阻断项与评审完成条件
阻断项指未关闭则计划不能通过的检查项，改进项指可以会后补充、不影响本次结论的检查项。典型阻断项包括：测试范围未定、不测范围未说明、验收口径缺失、准入准出条件缺失或不可判断、环境无责任人、环境就绪时间缺失、生产数据无脱敏方案、关键依赖无交付时间、风险无责任人、异常无升级路径。
评审结论分为通过、有条件通过和不通过三种：
| 结论 | 判定条件 | 后续动作 |
|---|---|---|
| 通过 | 阻断项全部关闭，改进项记录在案 | 计划版本归档，进入执行 |
| 有条件通过 | 阻断项未全部关闭，但已明确责任人和关闭时限，且不影响近期执行 | 在约定时限内关闭并复检，复检通过后归档 |
| 不通过 | 存在影响执行的关键阻断项且无明确关闭计划 | 修改计划后重新提交评审 |
有条件通过需要写明关闭时限和复检方式，例如“环境就绪时间于评审后三个工作日内补充，由测试负责人复检”。评审结论与计划版本一并归档，后续复检结论追加在同一记录中，形成完整留痕。
把检查表落到评审流程中
检查表要在协作工具中承载，才能从一次性文档变成可跟踪的流程。落地时可以把计划文档与检查项关联：计划文档作为评审对象，检查表作为评审模板，每个检查项对应一条核对记录，记录判定结果、证据链接和负责人。
评审会上的意见转为待办并跟踪关闭。阻断项生成待办，指派给对应责任人，设置关闭时限；改进项也生成待办，但标记为不阻断。待办关闭时附上补充的证据，测试负责人复检后更新检查项状态。这样评审意见不会停留在会议记录里，而是有明确的关闭动作。
评审结论与计划版本的状态留痕同样重要。计划文档保留版本历史，评审记录关联具体版本，阻断项关闭后计划版本递增，复检结论追加记录。ONES 的文档与工作项关联能力可以把计划文档、评审记录和阻断项待办放在同一条流程中：计划文档作为评审输入，检查项和评审意见转为工作项跟踪，关闭状态和版本记录留在系统中，便于后续追溯某次评审的完整过程。
常见问题
检查表里的阻断项太多，评审会开不完怎么办？
阻断项多通常说明会前自检没有做到位。可以先让计划编写人按会前自检清单补齐基础信息，把能在会前确认的项确认掉，会上只讨论仍有分歧或需要跨角色决策的项。如果时间仍然紧张，可以按影响面排序，优先处理范围、准入准出、环境责任人和关键依赖这几类直接决定计划能否执行的项，其余阻断项约定会后限时关闭并复检。
小团队没有专职测试负责人，检查表怎么分工？
角色可以合并，但动作不能省略。计划编写人同时承担自检和证据准备；评审主持可以由项目负责人或开发负责人担任，负责判定阻断项和确认结论；环境、数据等领域的核对由实际承担该职责的岗位负责，例如运维人员或开发人员。检查表中的负责人一栏写具体岗位即可，关键是每项都有明确的人认领，避免出现无人负责的检查项。
计划在执行中发生范围变更，检查表需要重新走一遍吗？
取决于变更影响的范围。如果变更涉及测试对象边界、验收口径、准入准出条件或关键依赖，建议针对受影响的检查项做一次补充核对，更新计划版本并记录变更说明，由测试负责人确认后归档。如果只是用例层面的调整，不影响计划整体结论，可以在执行记录中说明，不必重新组织完整评审。
有条件通过之后，复检由谁来做、怎么留痕？
复检通常由测试负责人执行，也可以指定原评审中的对应领域角色核对本领域阻断项。复检时逐项确认关闭证据是否齐备，例如环境就绪时间是否已补充、脱敏审批记录是否已附上。复检结论追加在原评审记录中，计划版本递增，形成从首次评审到复检关闭的完整记录，便于后续追溯。
检查表需要随项目类型调整吗？
六类维度可以通用，具体检查项和阻断项判定需要结合项目特点调整。涉及外部依赖多、上线窗口紧的项目，可以加强进度与依赖类检查；涉及生产数据的项目，数据脱敏相关项应设为阻断项。调整后的检查表要保留版本记录，并在评审记录中注明所用版本，避免不同轮次评审依据不一致。
