测试计划评审会开得是否有效，很大程度上取决于会前准备。这份清单围绕五件事展开：确认评审对象与参会角色、核对材料是否齐备、逐项检查计划内容、为每项检查落实证据与负责人、标出未满足即不能开会的阻断项。计划编写人先自检，评审主持人按清单预审，阻断项清零后再安排评审会。
要点总览（TL;DR）
- 会前准备按角色分工：计划编写人T-3起自检并补齐材料，评审主持人T-1完成预审并判断能否开会，参会角色提前阅读材料准备问题。
- 材料齐备性检查聚焦计划正文、需求或范围说明、进度与资源依据、风险清单，并单独核对正文与附件版本是否一致。
- 计划内容逐项检查范围与不测范围、测试类型规划、资源环境数据分工、里程碑依赖、风险应对、准入准出条件，每项都要有可判断的通过标准。
- 每项检查固定填写证据形式、负责人和通过/不通过/待确认三态结果，编写人自检结论与主持人预审结论分开记录。
- 范围未界定、无准入准出条件、关键资源未落实、材料版本不一致属典型阻断项，未清零应改期而非降格开会。
谁在什么时点使用这份清单
清单的价值在于把会前准备拆成有明确责任人和截止时点的动作。同一份清单在三类角色手里用法不同：计划编写人用它逐项自检并补齐材料，评审主持人用它做会前预审、判断能否开会，参会角色用它提前了解评审对象、带着问题进会场。
时间节奏建议从评审会前三个工作日启动。T-3由计划编写人完成自检，把计划正文与支撑材料整理到同一版本；T-2编写人补齐自检发现的问题，向主持人提交材料并说明未完成项；T-1主持人完成预审，确认阻断项状态，向参会人发出材料与议程。若项目周期紧张，可压缩到T-2至T-1，但预审环节不宜取消，否则阻断项会被带进会场。
| 使用对象 | 时点 | 主要动作 | 产出 |
|---|---|---|---|
| 计划编写人 | T-3至T-2 | 按清单逐项自检，补齐材料，标注未完成项 | 自检记录、材料包 |
| 评审主持人 | T-1 | 按清单预审，核对阻断项，决定是否按期开会 | 预审结论、议程 |
| 参会角色 | T-1至会前 | 阅读材料，准备与本角色相关的问题 | 问题清单 |
清单在两种场景下用法有差异。会前预审时，主持人关注的是“能否开会”，重点看阻断项和材料版本，非阻断问题可以留到会上；现场逐项核对时，主持人按清单顺序推进议程，逐项确认通过与否，避免讨论发散。预审阶段已确认通过的项，会上简要确认即可，把时间留给有争议或待确认的内容。
会前材料齐备性检查项
材料不齐是评审会最常见的返工原因。会前应确认以下材料已经准备好，并且版本与本次评审对象一致。判断标准是“参会人能否仅凭材料理解计划并形成意见”，达不到这一点的材料视为未齐备。
| 检查项 | 通过标准 | 证据形式 | 负责人 | 时点 |
|---|---|---|---|---|
| 测试计划正文 | 包含范围、策略、资源、进度、风险、准入准出等章节，版本号与评审通知一致 | 计划文档及版本记录 | 计划编写人 | T-2 |
| 需求或范围说明 | 本次测试覆盖的需求条目可检索、可对应，范围边界有文字描述 | 需求列表或范围说明文档 | 计划编写人 | T-2 |
| 进度与资源依据 | 里程碑日期、人力投入、环境需求有来源，能与项目排期对上 | 排期表、资源申请记录 | 计划编写人 | T-2 |
| 风险清单 | 列出主要风险、影响与应对措施，责任人有名有姓 | 风险登记表 | 计划编写人 | T-2 |
| 材料发出记录 | 参会人已收到材料，发出时间不晚于T-1 | 发送记录或通知 | 评审主持人 | T-1 |
材料版本一致性需要单独核对。常见问题是计划正文已更新，但附带的排期表或风险清单还是旧版，会上讨论的依据不一致。主持人在预审时应以计划正文版本号为基准，逐一核对附件版本，发现不一致即退回编写人统一。
测试计划内容的分项检查项
材料齐备只说明“有东西可看”，内容是否可评审要看各要素能否被判断。以下检查项按测试计划的核心要素组织，每项给出可判断的通过标准，评审人据此给出通过、不通过或待确认的结论。
| 检查内容 | 通过标准 | 证据形式 |
|---|---|---|
| 测试范围与不测范围 | 范围内需求条目可逐条对应；不测范围写明原因与影响，无“视情况而定”类模糊表述 | 计划范围章节、需求对应表 |
| 测试策略与测试类型规划 | 按需说明功能、性能、兼容、安全等类型的测试目标、方法与覆盖重点；未开展的测试类型说明理由 | 策略章节、测试类型清单 |
| 资源、环境、数据与人员分工 | 环境需求落实到具体环境或申请单；测试数据来源明确；人员分工到角色和姓名 | 环境申请单、分工表 |
| 进度里程碑与依赖 | 关键里程碑有日期和交付物；对外部依赖标注提供方与期望时间 | 排期表、依赖清单 |
| 风险与应对 | 每项风险有触发条件、影响评估和应对动作，责任人与时间明确 | 风险登记表 |
| 准入准出条件 | 准入条件说明何时可开始测试；准出条件给出可核验的指标或判定规则 | 计划准入准出章节 |
范围检查要特别关注“不测什么”。只写测试范围、不写排除项的计划，评审时容易在边界上反复讨论。排除项应写明原因，例如依赖外部系统未就绪、需求本期不交付，并说明对整体质量判断的影响。
策略检查按项目实际选择测试类型，不要求每类都写。写了性能测试目标却没有对应指标和场景，或列了安全测试但没有范围界定，都属于不可判断，应标为不通过或待确认。准入准出条件是阻断性最强的一项：准出条件若只有“测试通过”这类表述，评审无法据此判断发布与否，应要求补充缺陷收敛标准、用例执行率等可核验口径。
证据与负责人怎么落到每一项
检查项只有配上证据和负责人才可追溯。做法是：每个检查项在清单中固定填写证据形式和负责人，检查时以证据为准，不以口头说明为准。证据形式应指向可打开、可核对的对象，例如计划文档的具体章节、需求条目编号、排期表、风险登记记录、环境申请单。
负责人按检查项分配，而不是按材料整体分配。计划编写人对内容准确性负责，评审主持人对预审结论和开会决定负责，环境、数据等专项材料的提供人对其材料负责。编写人与评审人职责分开：编写人自检时填写“自检结论”，主持人预审时填写“预审结论”，两个结论不一致的项在预审记录中说明原因。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 检查项 | 与清单条目一致，不合并 | 准出条件是否可核验 |
| 证据 | 指向具体章节、条目或记录 | 计划第6章准出条件；需求条目REQ-102 |
| 负责人 | 填写到人，专项材料填提供人 | 计划编写人；环境负责人 |
| 结果 | 三态之一：通过、不通过、待确认 | 待确认 |
| 备注 | 不通过或待确认时写明缺口与补齐时间 | 准出条件缺缺陷收敛口径，T-1前补充 |
结果记录采用三态可以避免“差不多通过”的模糊结论。待确认项要写明由谁在什么时间前确认，超过时点仍未确认的，由主持人决定转为不通过或带入会上讨论。检查记录随材料一起归档，作为下次评审对比的依据。
当评审涉及多个计划或跨迭代时，检查记录分散在文档、表格和消息里容易失真。ONES 测试管理支持测试计划与迭代关联、多维度概览测试计划与进度，并可为测试计划单独配置权限，适合把计划、检查记录和责任人放在同一处流转；测试报告模板可按业务场景组装，便于把预审结论与后续执行情况对照。具体配置方式需按团队实际使用确认。
阻断项与开会条件
阻断项指未满足即不能进入评审会的问题。设阻断项的目的是避免会上讨论本应在会前解决的问题，把评审时间留给策略取舍和风险判断。以下为典型阻断项，团队可结合项目风险增减。
| 阻断项 | 判定标准 | 确认人 |
|---|---|---|
| 测试范围未界定 | 范围章节缺失，或范围与不测范围均无可核对条目 | 评审主持人 |
| 无准入准出条件 | 缺少准入或准出章节，或条件无法核验 | 评审主持人 |
| 关键资源未落实 | 测试环境、关键人员或测试数据无明确来源和时间 | 评审主持人，环境负责人提供说明 |
| 材料版本不一致 | 计划正文与附件版本号不符，或评审对象与发出材料不一致 | 评审主持人 |
非阻断项按影响程度分流：影响策略判断的，列入会议议程在会上讨论；属于表述完善、补充说明的，会后由编写人补充并在记录中注明完成时间。分流决定由主持人在预审时做出，并在议程中体现，避免会上临时增加议题。
阻断项清零的完成条件是：每一项阻断项都有明确结论“已解决”，并附证据，由评审主持人确认。确认后主持人发出开会通知，材料版本随之冻结；会前若有材料变更，需重新确认受影响的阻断项。阻断项未清零时，评审会应改期而不是降格召开，否则评审结论的可信度会打折扣。
常见问题
评审会前材料已经发出，但计划正文在会前又更新了，怎么处理？
材料版本变更后，需要重新确认受影响的检查项和阻断项。做法是以更新后的计划正文版本号为基准，逐一核对附件版本，由评审主持人判断变更是否触及范围、准入准出条件、关键资源等阻断项。触及阻断项的，重新走预审确认；只涉及表述完善的，在预审记录中注明变更内容与时间，会上以最新版本为准。会前材料变更频繁时，可约定一个版本冻结时点，冻结后的变更顺延到下次评审或会后补充。
项目周期很紧，能不能压缩会前准备时间直接开会？
准备节奏可以压缩，预审环节不宜取消。T-3至T-1的三天节奏在紧张项目里可压到T-2至T-1，编写人自检和主持人预审仍要各做一遍。取消预审的直接后果是阻断项被带进会场，评审时间被材料补齐和版本核对占掉，策略取舍和风险判断反而讨论不充分。若确实无法按期完成预审，更稳妥的做法是缩小本次评审范围，只评审已准备好的部分，其余内容另安排一次评审。
阻断项由谁判定，团队之间标准不一致怎么办？
阻断项判定由评审主持人负责，环境、数据等专项材料的提供人负责说明其材料状态。团队标准不一致时，可在清单中固定典型阻断项及其判定标准，作为默认约定，再按项目风险增减。判定分歧集中在“关键资源是否算落实”这类边界上，处理方式是要求提供方可出示的来源和时间，拿不出明确来源和时间的按未落实处理。每次评审后把实际遇到的阻断情形补进清单，标准会逐步收敛。
检查记录用什么形式保存，下次评审怎么用？
检查记录随材料一起归档，至少保留检查项、证据、负责人、三态结果和备注五项。下次评审时，把上一轮的待确认项和不通过项调出来对照，确认是否已补齐，避免同类问题重复出现。记录分散在文档、表格和消息里容易失真，可以在同一处承载计划、检查记录和责任人，让预审结论与后续执行情况能够对照。ONES 测试管理支持测试计划与迭代关联、多维度概览测试计划与进度，并可为测试计划单独配置权限；测试报告模板可按业务场景组装。具体配置方式需按团队实际使用确认。
测试计划里写了性能、安全等测试类型，但只有目标没有指标，算通过吗？
不算通过。写了测试类型却没有对应指标、场景或范围界定，评审人无法据此判断测试是否做到位，应标为不通过或待确认。处理方式有两种：补齐指标与场景后重新提交，或在计划中说明该类型本期不开展及理由。按需选择测试类型是合理的，关键是每种列入计划的类型都要有可核验的规划内容，未列入的类型写明原因与对质量判断的影响。
