测试计划评审现场逐项核对清单

测试计划评审现场最怕两件事：材料没带齐，讨论跑偏；结论没落笔，会后无人跟进。这份核对清单按“范围与目标—测试策略与类型—环境与数据—进度与资源—风险与出口—评审结论”六段组织，每项给出可判断的通过标准、所需证据和负责人，并标出阻断项。测试负责人、计划编写人以及开发、产品评审方可以会前对照准备，现场逐项过表，当场形成“通过、有条件通过、不通过”的结论。

要点总览（TL;DR）

• 清单按范围与目标、测试策略与类型、环境与数据、进度与资源、风险与出口、评审结论六段组织，会前准备材料、现场逐项核对、会后跟踪整改都能对应到具体段落。
• 每项检查都给出可判断的通过标准、所需证据和负责人，现场统一用“通过/不通过/待补”三态记录，口头说明不计为证据。
• 测试目标不可度量、出口准则缺失、环境与数据未落实、关键风险无应对属于阻断项，任一项未通过即不能出具“通过”结论。
• 评审结论分为通过、有条件通过、不通过三种，结论记录须包含逐项结果、整改项负责人与期限、复评时点，记录缺失视为评审未完成。
• 会后把不通过与待补项登记为整改工作项，跟踪到全部关闭、计划版本更新、复评记录留存，才算完成闭环。

谁在什么时点使用这份核对清单

清单解决的是“什么时候看哪一段、由谁填、填到什么程度算完成”。它不替代测试计划正文，也不替代评审会议本身，而是把评审从口头讨论变成可记录、可复核的核对过程。

使用对象分为三类。测试负责人主持现场核对并做最终判定；计划编写人负责提供证据、解释设计思路；开发与产品评审方从需求理解、排期可行性和风险接受度提出意见。三类角色在现场各司其职，避免出现“写计划的人自己评自己”的情况。

时点	主要动作	参与角色	产出
评审前2–3个工作日	发出计划文档、范围依据、环境与数据准备说明、风险与出口准则草案	计划编写人	评审材料包，版本号明确
评审前1个工作日	评审方预读，标记疑问项	开发、产品评审方	预读意见清单
评审现场	逐项过表，记录通过/不通过/待补，附证据与负责人	测试负责人主持，全体参与	现场核对记录
评审结束后1个工作日内	整理结论，登记整改项与复评时点	测试负责人	评审结论与整改清单

填写方式统一为三态：通过、不通过、待补。“待补”表示现场无法判断、需要补充证据后再确认，不能等同于通过。每一项都要写明证据位置（文档章节、表格行号、附件名称）和负责人，口头说明不计为证据。

会前准备：评审前必须备齐的材料

现场空转多半源于材料缺失。以下材料应随计划一并发出，缺项在会前补齐；确实无法提前提供的，在评审开场时说明原因和补齐时间。

• 测试计划正文与版本：标明版本号、修订记录和本次评审对应的版本，避免现场讨论的是一份已被修改的旧稿。
• 需求或范围依据文档：需求说明书、产品需求文档或范围确认邮件，用于核对测试范围是否有据可依。
• 测试类型与范围覆盖说明：说明本次覆盖哪些测试类型、覆盖到哪些模块，以及明确不测的部分及原因。
• 环境与测试数据准备情况：环境清单、与生产的差异说明、就绪时间、数据来源与脱敏方案。
• 进度、资源与人力安排：里程碑、依赖项、人员分工与技能匹配情况。
• 风险清单与出口准则草案：关键风险、应对措施、责任人，以及出口准则和暂停/终止条件的初稿。

材料齐备性本身可以作为评审开场的第一项核对：六类材料中缺少任何一类，评审可以继续，但相关章节只能记为“待补”，不能给出最终通过结论。

现场逐项核对表：范围、策略与类型

这一段检查计划“测什么、怎么测、测到什么程度算完成”，是评审的核心内容。下表每项均可现场判断，证据指向计划文档的具体位置。

检查项	通过标准	所需证据	负责人
测试目标可度量	目标包含可验证的指标，如缺陷收敛趋势、关键用例通过率、性能指标阈值，而非“保证质量”一类表述	计划“测试目标”章节	计划编写人
测试范围与不测范围明确	列出覆盖的模块/功能清单，同时列明不测部分及原因（如本期不涉及、由其他团队覆盖）	范围章节与需求依据对照	计划编写人
测试类型覆盖	按项目需要说明功能、性能、兼容、安全等类型的取舍，选用的类型有对应策略，未选用的有理由	测试类型说明表	测试负责人
测试级别与阶段划分	单元、集成、系统、验收等级别的划分与项目实际匹配，各阶段的进入与退出条件可判断	阶段计划表	测试负责人
需求与用例追溯关系	关键需求能追溯到对应用例或测试点，反向可查用例覆盖了哪些需求，缺口有说明	追溯矩阵或关联记录	计划编写人
验收与出口准则	出口准则包含可量化条件，如遗留缺陷等级与数量上限、用例执行率与通过率下限，并说明谁有权判定达成	出口准则章节	测试负责人与产品评审方

现场核对时，追溯关系一项常被跳过。判断方法很直接：随机抽取三到五条关键需求，看能否在计划或关联记录中找到对应用例；再随机抽取若干用例，看是否指向明确需求。两个方向都能走通，才算通过。

现场逐项核对表：环境、数据、进度与资源

计划内容合理，执行保障不到位，同样无法落地。这一段检查“靠什么执行、什么时候能执行、由谁执行”。

检查项	通过标准	所需证据	负责人
测试环境与生产差异说明	列出环境配置、依赖服务、数据规模与生产的差异，并说明差异对测试结论的影响	环境清单与差异说明	环境负责人
环境就绪时间与责任人	每套环境有明确就绪日期和责任人，就绪时间早于对应测试阶段开始时间	环境排期表	环境负责人
测试数据来源与脱敏要求	说明数据来自生产脱敏、造数工具还是手工构造，涉及个人信息的数据有脱敏方案	数据准备说明	计划编写人
进度里程碑与依赖项	里程碑与开发提测、环境就绪、上线窗口对齐，外部依赖标注提供方与承诺时间	进度计划与依赖清单	测试负责人
人力分工与技能匹配	每个测试领域有指定执行人，性能、安全等专项有具备相应技能的人员或支持安排	人员分工表	测试负责人
工具与自动化支撑安排	明确使用的用例管理、缺陷跟踪、自动化与持续集成工具，自动化覆盖范围与维护责任有安排	工具清单与自动化范围说明	测试负责人

环境与数据两项最容易出现“计划里写了、实际没落实”。核对时要求责任人当场确认就绪日期，日期晚于测试开始时间的，记为不通过并进入整改，不能以“到时候再说”放行。

现场逐项核对表：风险、出口与变更应对

这一段检查计划对不确定性的处理：出了问题谁负责、什么条件下暂停、计划变了怎么重新评审。

检查项	通过标准	所需证据	负责人
关键风险识别与应对措施	列出影响进度或质量的关键风险，每项有对应缓解措施，而非只列风险名称	风险清单	计划编写人
风险责任人与触发条件	每项风险有责任人，并写明触发条件，如提测延迟超过若干天即启动降级方案	风险清单对应列	测试负责人
出口准则与暂停/终止条件	除正常出口外，说明何种情况暂停测试、何种情况终止本轮测试并转专项处理	出口准则章节	测试负责人与产品评审方
缺陷分级与处理约定	缺陷等级定义清晰，各级别的修复时限、复测责任和升级路径有约定	缺陷管理约定	测试负责人与开发评审方
计划变更与重评审机制	说明范围、排期发生重大变化时由谁发起变更、何时重新评审、变更记录保存在哪里	变更管理说明	测试负责人
遗留问题交接方式	明确未修复缺陷、未覆盖范围的记录方式、交接对象和上线后的跟踪安排	遗留问题清单模板	计划编写人

风险一项的判断标准是“可执行”：看到风险条目后，能回答“谁在什么信号出现时做什么”。只写“存在进度风险”而没有触发条件和动作的，记为不通过。

阻断项与评审完成条件

并非所有不通过项都同等严重。以下四项属于阻断项，任一项未通过，评审不能出具“通过”结论：

• 测试目标不可度量：目标无法用指标或可验证结果判断是否达成。
• 出口准则缺失：没有可量化的出口条件，或未说明判定责任人。
• 环境与数据未落实：环境就绪时间晚于测试开始时间，或测试数据来源与脱敏方案缺失。
• 关键风险无应对：影响进度或质量的关键风险没有缓解措施和责任人。

其余检查项不通过时，按非阻断项处理：现场记录问题、指定负责人和补齐期限，约定复评方式。复评可以采取书面确认或短会形式，由测试负责人判断是否需要对原结论做调整。

评审结论	适用条件	后续动作
通过	阻断项全部通过，非阻断项无重大遗留或已现场确认	计划进入执行，记录归档
有条件通过	阻断项全部通过，非阻断项存在待补项且有明确负责人与期限	限期整改，到期书面确认后转为通过
不通过	任一阻断项未通过	整改后重新提交评审，复评时点现场约定

结论记录应包含：评审日期、参与人、逐项核对结果、结论状态、整改项清单（问题、负责人、期限）、复评时点，并由测试负责人与计划编写人确认。记录缺失的评审视为未完成。

评审记录如何落到协作工具中跟踪闭环

现场结论如果只停留在会议纪要里，整改项很容易在下一个迭代被淹没。可行的做法是把核对结果转成可跟踪的工作项，让每条整改都有负责人、期限和状态。

具体流程可以这样走：评审结束后，测试负责人把每个“不通过”和“待补”项登记为整改工作项，填写问题描述、对应检查项、负责人和截止日期；工作项状态从“待处理”流转到“处理中”“待复评”“已关闭”。计划文档与评审记录保持版本对应，复评时对照原记录逐项确认，全部关闭后才更新计划状态。复评触发条件建议写成“整改项全部关闭”或“到达约定复评日期”，两者先到为准。

在工具承载上，ONES 测试管理支持测试计划与迭代关联、测试用例与需求和任务关联，形成测试流程闭环；测试计划可多维度概览并查看进度。评审产生的整改项可以作为任务登记并指派负责人，缺陷类问题可通过未通过用例快速创建缺陷任务，在测试与研发团队间流转。计划文档与评审记录的关联、评审结论状态流转，可按团队现有文档与工作项管理方式组织，具体能力以实际使用版本为准。

闭环完成的标志不是会议开完，而是整改项全部关闭、计划版本更新、复评记录留存。做到这三点，这份核对清单才算真正用到了位。

常见问题

评审现场发现材料没带齐，还能继续开吗？

可以继续，但相关章节只能记为“待补”，不能当场给出最终通过结论。建议在开场时先过一遍会前材料清单，缺哪一类就明确补齐时间和负责人，涉及阻断项的材料（如出口准则草案、环境与数据准备说明）缺失时，评审结论最多到“有条件通过”，待材料补齐并书面确认后再调整。

“待补”和“不通过”在现场怎么区分？

“不通过”表示现场已能判断该项不满足通过标准，例如出口准则没有可量化条件、环境就绪时间晚于测试开始时间；“待补”表示现场缺少证据、暂时无法判断，需要补充材料后再确认。两者都不能当作通过处理，区别在于后续动作：不通过项直接进入整改，待补项先补齐证据再复评。

阻断项在评审前已经知道无法满足，是否还要开会？

建议照常召开，但把会议目标从“给出通过结论”调整为“确认整改方案”。现场逐项记录阻断项的具体缺口、整改负责人和完成期限，约定复评时点，形成“不通过”结论。这样比直接取消评审更有利于把问题暴露在计划执行之前，也便于后续复评时对照原记录逐项确认。

评审结论和整改项用什么方式跟踪比较可靠？

把每个“不通过”和“待补”项登记为可指派、有期限、有状态的工作项，状态按“待处理—处理中—待复评—已关闭”流转，并与计划文档版本保持对应。复评触发条件可写成“整改项全部关闭”或“到达约定复评日期”，先到为准。ONES 测试管理支持测试计划与迭代关联、用例与需求和任务关联，未通过用例可快速创建缺陷任务并在测试与研发团队间流转，可作为承载整改跟踪的一种方式，具体以实际使用版本为准。

这份清单适用于哪些类型的测试计划？

清单面向测试计划的评审场景，功能、性能、兼容、安全等测试类型都可以按同一套维度核对，区别在于测试类型覆盖一项需要按项目实际说明取舍和理由。具体测试脚本编写、攻击技术与源码分析不在清单范围内；单份需求文档的质量评审属于需求评审与确认，应使用对应的评审清单。