静态测试计划模板：评审对象与入口准则字段清单

静态测试计划模板的核心是一张“评审对象—入口准则—职责—记录”对照表：先按需求文档、设计文档、接口与数据定义、用户文档、代码与配置等类别列出评审对象，再为每个对象写清可判定的入口准则，最后落到负责人、评审人和结论记录。本文直接给出一张可复制填写的空白表，并配套字段说明、必填规则、完整示例与维护方法；评审记录需要多人协作流转时，可放在ONES这类工具中承载。

要点总览（TL;DR）

• 模板主体是一张“评审对象—入口准则—职责—记录”对照表，评审对象按需求文档、设计文档、接口与数据定义、用户文档、代码与配置等类别逐行列出。
• 入口准则要写成可判定状态：基线版本已冻结、评审范围已圈定、材料齐备、检查单已下发、参与人已确认到人、时间窗覆盖预读。
• 评审对象名称、入口准则各列、评审负责人、评审人、记录人、结论与关闭状态为必填；时间窗、裁决人、遗留项、参考文档可留空但需统一标注。
• 职责分工区分负责人、评审人、记录人与裁决人，结论限定为通过、有条件通过、不通过三档，遗留项写明责任人与关闭时间。
• 模板按项目类型裁剪行而非列，入口准则每个发布周期复核一次，模板本身保留版本号与变更记录。

可复制空白模板：评审对象与入口准则表

下表可直接复制到文档或表格工具中使用。行结构按评审对象逐条展开，一个对象占一行；同一类别下有多个对象时，继续增加行并复用类别名称。列顺序建议保持不变，便于不同项目之间横向比对。

序号	评审对象类别	评审对象名称	基线版本	评审范围	材料齐备度	检查单	参与人确认	评审时间窗	评审负责人	评审人	记录人	裁决人	结论	问题数	遗留项	关闭状态	参考文档
1
2
3
4
5
6

表格上方建议保留三行表头信息：项目名称、计划版本号、模板版本号。这三项用于区分不同项目复用的同一份模板，避免记录混用。评审对象类别一列可参考以下常用取值，按项目实际增删：需求文档、设计文档、接口与数据定义、用户文档、代码与配置、测试计划自身。

字段说明：每一列填什么、怎么判定

模板能否被不同人一致填写，取决于每个字段是否有明确的判定口径。以下按列说明，与上表表头一一对应。

对象识别字段

• 评审对象类别：从预设类别中选一个，用于分组统计。类别决定后续必填项的差异，例如代码与配置类对象通常需要额外的静态检查工具结果作为附件。
• 评审对象名称：写到可定位的粒度，例如“订单结算需求说明书 V2.1”而非“需求文档”。名称应包含文档名与版本，便于与基线版本列互相印证。

入口准则字段

入口准则是判断“这个对象是否具备开始评审的条件”的依据，每一列都应写成可判定的状态，避免“基本完成”“大致齐全”这类无法核对的描述。

• 基线版本：填写已冻结的版本号或提交标识。判定口径是该版本在配置库中处于冻结状态，评审期间不再变更；若评审中发生变更，需重新走入口检查。
• 评审范围：写明本次评审覆盖的章节、模块或文件清单，以及明确排除的部分。判定口径是范围边界可被评审人复述，不存在“整份都看”的模糊表述。
• 材料齐备度：列出评审所需的输入材料及齐备状态，例如“需求说明书、接口清单、数据字典三项齐全”。判定口径是清单内材料全部可访问。
• 检查单：填写所用检查单的名称与版本，或标注“已下发”。判定口径是评审人已拿到检查单，且检查项与本次评审范围匹配。
• 参与人确认：记录关键角色是否已确认出席，例如“需求、开发、测试三方已确认”。判定口径是各角色有明确到人，而非仅通知到组。
• 评审时间窗：填写计划开始与结束时间。判定口径是时间窗覆盖材料预读时间，且与参与人日历无冲突。

职责分工字段

• 评审负责人：组织入口检查、主持评审、推动问题闭环的人。建议不由记录人兼任。
• 评审人：实际执行检查并提交问题的人，多人时用分号分隔并注明各自负责的范围。
• 记录人：负责记录问题、维护问题数与遗留项状态的人。
• 裁决人：对“有条件通过”与“不通过”之间的分歧做最终判定的人。建议与评审负责人分开，避免组织者同时充当裁决者。

记录字段

• 结论：限定为通过、有条件通过、不通过三档，不使用其他自由文本，便于统计。
• 问题数：填写本次评审提出的问题总数，与问题清单条目数一致。
• 遗留项：列出未在评审中关闭的问题编号或简述，注明责任人与计划关闭时间。
• 关闭状态：取值建议为未开始、进行中、已关闭。判定口径是所有遗留项关闭后才可标记为已关闭。
• 参考文档：填写评审依据的上游文档、规范或检查单编号，选填。

必填与选填：哪些字段不能空

必填字段的作用是保证每条评审记录都能被追溯和判定。以下对照表给出默认规则，项目可在模板版本说明中调整，但调整需统一生效。

字段	默认属性	留空条件与标注方式
评审对象类别	必填	不可留空
评审对象名称	必填	不可留空
基线版本	必填	不可留空；未冻结时填“待冻结”并注明责任人
评审范围	必填	不可留空
材料齐备度	必填	不可留空；缺项时逐项列出缺什么
检查单	必填	无适用检查单时填“无适用检查单”并说明理由
参与人确认	必填	不可留空；未确认时填“待确认”并注明补齐责任人
评审时间窗	选填	可填“待定”，但需在评审开始前补齐
评审负责人	必填	不可留空
评审人	必填	不可留空；至少一名
记录人	必填	不可留空
裁决人	选填	评审负责人兼任时填“同负责人”
结论	必填	评审前填“待评审”，评审后必须改为三档之一
问题数	必填	评审前填“—”，评审后填实际数字，无问题填 0
遗留项	选填	无遗留时填“无”
关闭状态	必填	不可留空
参考文档	选填	可留空

不同对象类型下必填项存在差异。代码与配置类对象通常需要把静态检查工具的结果作为材料齐备度的一部分，检查单列应指向对应的编码规范检查单；用户文档类对象的参与人确认中应包含文档使用者代表；测试计划自身作为评审对象时，评审范围需明确覆盖哪些测试类型与阶段。留空统一使用“待定”“待确认”“无适用检查单”等固定标注，并在备注中写明补齐责任人，避免空白格被误读为已完成。

填写示例：一份完整的静态测试计划评审安排

以下示例为演示情景：某项目在迭代启动前对静态测试计划相关文档做一轮评审，范围限于文档与定义，不含具体测试脚本与源码分析。示例中的项目名、人名以角色代替。

序号	评审对象类别	评审对象名称	基线版本	评审范围	材料齐备度	检查单	参与人确认	评审时间窗	评审负责人	评审人	记录人	裁决人	结论	问题数	遗留项	关闭状态	参考文档
1	需求文档	订单结算需求说明书 V2.1	V2.1 已冻结	第 3–5 章结算规则与异常分支	说明书、规则附表齐全	需求检查单 v1.2 已下发	产品、开发、测试三方到人确认	3 月 4 日 14:00–16:00	测试负责人	测试工程师 A；开发工程师 B	测试工程师 C	同负责人	有条件通过	6	Q-12 异常金额边界待产品补充	进行中	需求检查单 v1.2
2	接口与数据定义	结算接口定义 V1.4	V1.4 已冻结	接口入参、出参与错误码	接口文档、字段字典齐全	接口检查单 v1.0 已下发	开发、测试到人确认	3 月 5 日 10:00–11:30	测试负责人	开发工程师 B；测试工程师 A	测试工程师 C	架构师	通过	2	无	已关闭	接口检查单 v1.0
3	测试计划自身	结算模块静态测试计划 V1.0	V1.0 待冻结	评审对象清单、入口准则、职责分工	计划正文、本模板齐全	测试计划检查单 v1.1 已下发	测试组内到人确认	待定	测试负责人	测试工程师 A；测试工程师 C	测试工程师 C	同负责人	待评审	—	无	未开始	测试计划检查单 v1.1

示例中第 1 行体现了选填字段的取舍：裁决人由负责人兼任，填“同负责人”；结论为有条件通过，遗留项写明具体问题编号与责任方，关闭状态保持进行中。第 3 行展示评审前的状态写法：结论填“待评审”，问题数填“—”，时间窗填“待定”，这些占位符在评审完成后必须替换为实际值。结论字段的写法统一为三档之一，并在遗留项中说明有条件通过的具体条件，避免结论与遗留项脱节。

调整与维护：模板如何随项目演进

模板的价值在于长期复用，需要建立裁剪规则与版本维护机制，否则不同项目各自改写会导致记录无法横向比较。

按项目类型裁剪评审对象行

裁剪的对象是行，不是列。小型迭代可只保留需求文档、接口与数据定义、测试计划自身三类对象；涉及对外交付的项目应增加用户文档行；包含配置管理的项目应增加代码与配置行。裁剪时在模板版本说明中记录删除了哪些行及理由，后续项目可据此恢复。

入口准则的定期复核

建议在每个发布周期结束时复核一次入口准则：检查是否存在多次因同一准则无法判定而卡住评审的情况，若有则改写该准则；检查基线版本、检查单版本是否已更新；检查参与人确认是否仍按角色而非按人填写。复核结果记入模板变更记录。

模板版本与变更记录

模板本身应有版本号，与项目计划版本分开管理。变更记录至少包含：版本号、变更日期、变更内容、变更原因、影响范围。字段增删属于结构性变更，需通知所有在用项目；仅修改填写说明属于说明性变更，可在版本号末位递增。

在协作工具中承载模板与评审记录

当评审对象较多、跨角色流转频繁时，可把每个评审对象作为一条工作项，入口准则作为准入检查项，结论、问题数与遗留项作为记录字段，评审负责人和记录人作为责任人字段流转。ONES 支持测试计划与迭代关联、为测试计划单独配置权限，并提供可自定义组装的测试报告模板，可作为承载评审安排与记录的参考；具体字段配置与权限粒度以实际版本为准。这样做的直接结果是：入口准则未满足时工作项无法进入评审状态，遗留项关闭后记录状态随之更新，评审结论可按计划维度汇总查看。

常见问题

评审对象很多时，一张表放不下怎么办？

按类别拆成多张表，共用同一套表头和同一份模板版本号，类别之间用序号连续编号，避免跨表重复。也可以把每个评审对象作为一条工作项承载，入口准则作为准入检查项，结论与遗留项作为记录字段，这样对象数量增加时仍能按计划维度汇总查看。拆表后需在模板版本说明中注明拆分方式，保证不同项目复用时口径一致。

入口准则在评审前没有全部满足，能否先开始评审？

建议先做入口检查并记录未满足项，由评审负责人判断是否影响评审有效性。若缺项属于材料齐备度或检查单未下发，通常应推迟评审；若属于时间窗未定这类选填项，可先进入评审并在记录中标注补齐责任人。无论哪种情况，未满足项都要写进记录字段，评审结束后复核关闭状态，避免入口检查流于形式。

有条件通过的结论，遗留项应该记到什么程度？

遗留项要写到可追踪的粒度：问题编号或简述、责任方、计划关闭时间，以及该条件对后续测试活动的影响。结论为有条件通过时，遗留项不能只写“待补充”，否则关闭状态无法判定。建议在评审结束时由记录人逐条确认遗留项已登记，裁决人确认条件可接受，再更新关闭状态。

模板里的字段能否按团队习惯增删？

可以增删，但要区分结构性变更与说明性变更。增删列属于结构性变更，需更新模板版本号并通知所有在用项目；只改填写说明可在版本号末位递增。裁剪时优先调整行，即按项目类型增减评审对象类别，列顺序和必填规则尽量保持稳定，这样不同项目的评审记录才能横向比较。

评审记录放在协作工具里，和表格模板如何衔接？

可以把表格模板作为字段设计的依据，在工具中把每个评审对象建成一条工作项，入口准则设为准入检查项，结论、问题数、遗留项、关闭状态作为记录字段，负责人与记录人作为责任人字段流转。ONES 支持测试计划与迭代关联、为测试计划单独配置权限，并提供可自定义组装的测试报告模板，可作为承载评审安排与记录的参考；具体字段配置与权限粒度以实际版本为准。