测试计划评审检查表按范围与目标、策略与方法、环境与数据、进度与资源、风险与退出、交付与沟通六个维度组织检查项。每项写明通过标准、证据材料和负责人，评审时逐项判定通过、有条件通过或不通过。范围遗漏、退出标准缺失、关键依赖无责任人属于阻断项，未关闭前计划不进入执行。这份检查表可用于会前自查和会上核对，评审记录与整改项也可以在ONES中关联计划文档进行分派和关闭。
要点总览（TL;DR）
- 检查表按范围与目标、策略与方法、环境与数据、进度与资源、风险与退出、交付与沟通六个维度组织，每项写明通过标准、证据材料和负责人。
- 会前自查由计划编写人逐项准备证据并标注缺口，会上由评审人逐项判定通过、有条件通过或不通过。
- 范围遗漏、退出标准缺失、关键依赖无责任人属于阻断项，未关闭前计划不进入执行。
- 有条件通过的整改项需写明责任人、关闭时点和验证方式，复评时重点核对上次未通过项和受变更影响的维度。
- 检查项、证据与整改动作可关联到计划文档记录，评审结论与计划版本对应留存，便于追溯和复评。
谁在什么时点使用这份检查表
这份检查表服务三类人：测试负责人主持评审并对结论负责，计划编写人准备材料并回应质疑，开发与产品评审人从各自角度判断计划是否可执行。使用时机分两段，计划初稿完成后先做会前自查，评审会上再逐项核对。两段的动作不同，混在一起容易把评审会开成材料补交会。
会前自查由计划编写人完成，目标是让每一项都有证据可查。自查时逐项填写证据位置和负责人，对拿不出证据的项提前标注，会上直接说明缺口和补齐时间。会中核对由评审人完成，目标是逐项判定通过、有条件通过或不通过，并把不通过的项转成整改任务。会前解决“有没有”，会上解决“够不够、能不能执行”。
前置输入至少包括四类：需求范围说明、版本排期、环境与数据准备情况、上一版本遗留问题清单。缺少任何一类，对应维度的检查项只能判为有条件通过，并在结论中写明补齐时点。
| 角色 | 会前动作 | 会中动作 | 产出 |
|---|---|---|---|
| 计划编写人 | 逐项准备证据，标注缺口 | 说明依据，记录评审意见 | 自查记录、证据清单 |
| 测试负责人 | 抽查关键项证据完整性 | 主持逐项判定，确认阻断项 | 评审结论 |
| 开发评审人 | 确认提测范围与接口依赖 | 核对策略、环境与排期可行性 | 技术侧意见 |
| 产品评审人 | 确认需求范围与优先级 | 核对范围边界与验收口径 | 范围确认意见 |
范围与目标：计划是否覆盖了该测的内容
范围检查的核心是边界可核验。计划里的每一条需求都应能对应到测试范围条目，本期不测的内容要写明理由和后续安排。只写“覆盖本期全部需求”无法核对，需要列出需求清单或关联需求文档的具体版本。
测试目标要可度量。覆盖率、缺陷收敛趋势、准出指标都应给出计算口径和目标值，例如“核心功能用例执行率100%，遗留缺陷中严重及以上为0”。目标写成“保证质量”之类表述时，评审无法判断是否达成，应要求改写。
测试类型的取舍要说明理由。功能、接口、性能、兼容、安全等类型中，哪些做、哪些不做、做到什么深度，应与本期变更的风险相匹配。范围变更要有记录和确认方式，明确谁提出、谁确认、如何同步到用例和排期。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 需求与测试范围逐项对应 | 每条需求有对应范围条目，无遗漏 | 需求清单与范围对照表 | 计划编写人 |
| 不测项及理由 | 每项不测内容写明理由和后续安排 | 范围说明文档 | 计划编写人 |
| 测试目标可度量 | 目标有指标名称、口径和目标值 | 计划目标章节 | 测试负责人 |
| 测试类型取舍有依据 | 各类型做或不做的理由与风险对应 | 策略说明 | 测试负责人 |
| 范围变更记录方式 | 明确变更提出、确认与同步流程 | 变更流程说明 | 测试负责人 |
策略与方法：测试类型、分层与用例组织是否说得清
策略检查看的是可执行性。测试类型和分层比例应与风险匹配，高风险模块分配更多接口和异常场景用例，低风险模块以回归为主。分层比例写成固定数字而没有风险依据时，评审应追问依据。
用例来源、编写责任人和评审时点要明确到人。用例来自需求、设计文档还是探索式测试，各自占比多少，何时完成编写和评审，都影响后续执行。回归范围要说明取舍：全量回归还是影响面回归，自动化覆盖哪些部分，未覆盖部分如何人工兜底。
准入条件同样属于策略内容。什么状态下开始测试，例如提测版本通过冒烟、接口文档冻结、环境可用，需要写成可判断的条件，避免测试在版本不稳定时反复中断。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 测试类型与风险匹配 | 高风险模块有对应测试类型和深度说明 | 风险清单与策略对照 | 测试负责人 |
| 用例来源与责任人 | 每类用例有来源、编写人和完成时点 | 用例计划表 | 计划编写人 |
| 用例评审安排 | 评审时点、参与人和评审方式明确 | 评审排期 | 测试负责人 |
| 回归与自动化取舍 | 回归范围、自动化覆盖和人工兜底有说明 | 回归方案 | 测试负责人 |
| 准入条件可判断 | 准入条件写成可核验的状态描述 | 计划准入章节 | 开发与测试共同确认 |
环境、数据与工具：依赖是否落实到位
环境检查要落到清单和时间。每套环境写明用途、版本、可用时间窗口和责任人，涉及多套环境切换时说明切换方式。只写“测试环境已准备”不足以支撑排期，评审需要看到具体环境和可用日期。
测试数据要说明构造方式、脱敏处理和恢复方案。使用生产数据时，脱敏规则和审批记录是必要证据；使用构造数据时，说明覆盖哪些边界场景。数据被污染后的恢复方式也要提前约定，否则执行中途容易停摆。
工具与平台的就绪状态包括账号权限、License、流水线接入等。外部依赖如第三方接口、硬件设备，需要有对接确认记录和联调时间，不能停留在“对方会配合”的口头约定。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 环境清单与可用时间 | 每套环境有用途、版本、时间窗和责任人 | 环境清单 | 环境管理员 |
| 测试数据方案 | 构造或脱敏方式、覆盖场景、恢复方案明确 | 数据方案文档 | 计划编写人 |
| 工具与权限就绪 | 所需工具可用，账号权限已开通 | 权限申请记录 | 测试负责人 |
| 外部依赖确认 | 第三方接口或设备有对接人和联调时间 | 对接确认记录 | 计划编写人 |
进度、资源与职责：排期能否支撑计划
排期检查看测试阶段与提测、发布节点是否对齐。测试开始时间、各轮次时间、回归窗口和发布窗口应形成一条可追溯的时间线，留出缺陷修复和复测的缓冲。排期紧贴发布日而没有缓冲时，评审应要求说明压缩依据。
人力投入要与范围匹配，包括人数、投入比例和技能结构。涉及自动化、性能或安全测试时，确认执行人具备相应经验。角色职责要覆盖用例编写、执行、缺陷跟踪和发布确认，避免出现无人负责的环节。
加班或外部支持的预案属于排期的一部分。预案写明触发条件和支持来源，例如进度偏差超过一定天数时启动外部支援，比笼统写“必要时加班”更容易执行。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 测试排期与节点对齐 | 提测、测试轮次、回归、发布时间线完整 | 排期表 | 测试负责人 |
| 缓冲时间 | 缺陷修复与复测有明确缓冲 | 排期表备注 | 测试负责人 |
| 人力与技能匹配 | 人数、投入比例、专项技能有对应安排 | 资源计划 | 测试负责人 |
| 角色职责完整 | 编写、执行、缺陷跟踪、发布确认均有责任人 | 职责分工表 | 计划编写人 |
| 加班或外部支持预案 | 写明触发条件和支持来源 | 预案说明 | 测试负责人 |
风险、退出标准与交付物：什么情况下停止或放行
风险检查要求每项已识别风险有应对措施和责任人。风险可以来自需求变更、环境不稳定、依赖方延期或人力缺口，应对措施要具体到动作，例如准备备用环境、提前联调或调整测试顺序。
退出标准是评审的重点。缺陷等级分布、遗留缺陷处理规则、各等级缺陷的关闭要求都应写明。例如严重及以上缺陷必须修复并复测通过，一般缺陷经评估可带条件发布并登记跟踪。退出标准缺失时，测试结束与否只能靠临时判断。
交付物清单包括测试报告、缺陷统计、用例执行记录等，写明提交时点和接收人。暂停、回退或延期发布的触发条件也要提前约定，例如冒烟通过率低于阈值或关键依赖未就绪时暂停测试。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 风险与应对措施 | 每项风险有措施、责任人和跟踪方式 | 风险登记表 | 测试负责人 |
| 退出标准完整 | 缺陷等级分布与遗留缺陷规则明确 | 准出标准章节 | 测试负责人 |
| 交付物清单 | 交付物、提交时点、接收人齐全 | 交付物清单 | 计划编写人 |
| 暂停与回退条件 | 触发条件写成可判断的阈值或状态 | 计划应急章节 | 测试负责人 |
阻断项与评审结论：哪些问题不关闭就不能执行
阻断项是评审结论的硬边界。范围遗漏、退出标准缺失、关键依赖无责任人三类问题未关闭前，计划不进入执行。范围遗漏会导致该测的内容无人测，退出标准缺失会让放行失去依据，关键依赖无责任人则意味着风险无人跟进。
评审结论分三种：通过、有条件通过、不通过。有条件通过适用于存在整改项但不构成阻断的情况，每项整改写明责任人、关闭时点和验证方式。不通过时说明需重新评审的条件，例如范围重新确认或环境就绪后复评。
评审结论要形成记录，包含参会人、逐项判定结果、整改项清单和结论。计划归档后发生变更时，通过版本管理保留历史版本，复评时对照上一版结论检查整改完成情况。
| 结论类型 | 适用情形 | 后续动作 |
|---|---|---|
| 通过 | 全部检查项通过，无整改项 | 计划归档，进入执行 |
| 有条件通过 | 存在非阻断整改项 | 整改项分派到人，按关闭时点验证后执行 |
| 不通过 | 存在阻断项 | 阻断项关闭后重新评审 |
复评触发条件包括阻断项关闭、范围发生实质性变更、关键依赖状态变化。复评不必重复全部检查项，重点核对上次未通过项和受变更影响的维度。
把检查表落到协作工具里：记录、分派与关闭
检查表要在评审后持续发挥作用，需要把检查项、证据和整改动作放到可追踪的位置。一种做法是把每个检查项作为工作项或检查单条目记录，关联对应的测试计划文档，评审时直接在工作项上填写判定结果和意见。
证据附件和评审意见与检查项放在一起，避免散落在聊天记录或邮件里。整改项从检查项转出后分派给责任人，状态按待处理、处理中、待验证、已关闭流转，关闭时由评审人确认。评审结论与计划版本对应记录，后续变更时能追溯每个版本当时的判定结果。
ONES支持将工作项与文档关联，评审意见、证据附件和整改状态可以在同一处留存，测试负责人按检查项查看整改进度，复评时直接调取上一版结论。这样检查表从一次性文档变成可跟踪的评审记录，整改闭环有据可查。
常见问题
测试计划评审检查表需要覆盖所有测试类型吗？
不需要逐类铺开。检查表关注的是计划是否说明了测试类型的取舍及理由，而不是要求每类测试都做。功能、接口、性能、兼容、安全等类型中，哪些做、哪些不做、做到什么深度，应与本期变更的风险对应。评审时核对的是取舍依据是否成立、不做的类型是否写明理由和后续安排，而不是类型数量是否齐全。
评审会上出现争议项，应该判通过还是不通过？
先判断争议项是否属于阻断项。范围遗漏、退出标准缺失、关键依赖无责任人三类问题直接判不通过，争议不影响结论。非阻断项的争议可以判有条件通过，但要把争议点、待确认事项、责任人和关闭时点写进整改清单，避免会上口头带过。争议涉及需求范围本身时，建议先回到需求确认环节，再复评计划。
计划评审通过后范围发生变更，检查表还要重新走一遍吗？
不必重复全部检查项。范围发生实质性变更时触发复评，重点核对受变更影响的维度，例如范围与目标、策略与方法、进度与资源，同时检查上次整改项是否已关闭。复评结论与变更后的计划版本对应记录，保留上一版结论，便于追溯每次判定依据。
小团队或短周期版本，检查表可以精简吗？
可以按风险裁剪检查项数量，但阻断项相关的检查不能省。范围是否逐项对应、退出标准是否明确、关键依赖是否有责任人，这三类问题在任何规模的版本中都会直接影响能否放行。环境清单、交付物清单等条目可以合并简化，通过标准仍要写成可核验的状态描述，避免精简后只剩形式勾选。
检查表的整改项如何跟踪到关闭？
整改项从检查项转出后分派给责任人，状态按待处理、处理中、待验证、已关闭流转，关闭时由评审人确认。证据附件和评审意见与检查项放在一起，避免散落在聊天记录里。ONES支持将工作项与文档关联，评审意见、证据附件和整改状态可以在同一处留存，复评时直接调取上一版结论核对整改完成情况。
