静态测试计划模板的核心，是一张“评审对象—入口准则”对照表：把需求规格、设计文档、接口说明、代码、测试用例等工作产品逐项列出，为每类对象写明评审方式、入口准则、责任人、记录字段和退出条件。本文直接给出四张可复制空白表，并配套字段说明、必填规则和一份完整填写示例，方便团队按项目情况裁剪后使用。
要点总览（TL;DR）
- 静态测试计划模板的主体是四张表：评审对象清单、入口准则表、职责分工表、评审记录字段表，四张表通过序号和记录编号相互引用。
- 入口准则要写成可独立判定的状态，例如“文档状态为已基线、版本号与评审通知一致”，并配套证据形式和确认人。
- 对象名称、对象类型、来源与版本、评审方式、入口准则判定条件与确认人、三类组织角色、评审结论、问题数与分级、关闭状态为必填项。
- 填写示例以需求规格说明书和测试用例两类对象演示，记录编号与入口准则证据相互引用，形成可追溯链条。
- 模板按项目规模裁剪行数、维护版本号与变更记录，并在评审后复盘触发入口准则修订。
可复制空白模板：评审对象与入口准则表
以下四张表构成静态测试计划的主体。使用时先填表1确定评审范围，再填表2为每类对象设定可判定的入口准则，表3和表4分别承载职责与记录。表格中的示例行仅作格式示意，复制后请替换为实际内容。
表1 评审对象清单
| 序号 | 对象名称 | 对象类型 | 来源与版本 | 评审方式 | 计划评审时间 | 责任人 |
|---|---|---|---|---|---|---|
| 1 | （示例）订单模块需求规格说明书 | 需求文档 | 产品部 / V1.2 | 正式评审 | （日期） | （姓名） |
| 2 | ||||||
| 3 |
表2 入口准则表
| 准则编号 | 适用对象 | 准则描述 | 判定条件 | 证据形式 | 确认人 | 确认状态 |
|---|---|---|---|---|---|---|
| EC-01 | （示例）需求规格说明书 | 文档版本已冻结 | 文档状态为“已基线”，版本号与评审通知一致 | 配置库版本记录截图 | （姓名） | 未确认 |
| EC-02 | ||||||
| EC-03 |
表3 职责分工表
| 角色 | 姓名 | 职责说明 | 参与对象 |
|---|---|---|---|
| 计划负责人 | 编制静态测试计划，确认入口准则满足情况 | 全部对象 | |
| 评审主持人 | 组织评审会议，控制节奏，宣布评审结论 | ||
| 记录人 | 记录问题、结论与整改要求 | ||
| 问题跟踪人 | 跟踪问题整改与关闭，组织复评 |
表4 评审记录字段表
| 记录编号 | 评审日期 | 对应对象 | 评审结论 | 问题数 | 问题分级分布 | 整改期限 | 关闭状态 | 复评状态 |
|---|---|---|---|---|---|---|---|---|
| R-001 | 通过 / 有条件通过 / 不通过 | 严重 / 一般 / 建议 | 未关闭 / 部分关闭 / 已关闭 | 无需复评 / 待复评 / 已复评 | ||||
| R-002 |
字段说明：每个字段填什么、怎么判定
四张表的字段各有明确填写口径。下面按表逐项说明，重点解释容易填得含糊的“评审方式”“判定条件”和“证据形式”。
评审对象类字段
| 字段 | 填写口径 | 常见填写问题 |
|---|---|---|
| 对象名称 | 写工作产品的正式名称，与配置库或文档管理系统中的名称一致 | 写“需求文档”这类泛称，无法定位具体文件 |
| 对象类型 | 从需求文档、设计文档、接口说明、代码、测试用例、用户手册等类型中选择 | 同一对象在不同行填写不同类型 |
| 来源与版本 | 写负责部门与当前版本号，版本号以配置库记录为准 | 只写部门不写版本，评审时无法确认评审的是哪一版 |
| 评审方式 | 走查：作者自查加一人复核；同行评审：同角色同事按检查单逐项检查；正式评审：多方参加、有主持人和正式结论 | 所有对象统一填“评审”，未区分投入程度 |
入口准则类字段
入口准则是判断“能否开始评审”的条件，写法上要能被第三方独立判定。准则描述说明要求，判定条件给出可观察的状态，证据形式说明用什么材料证明，确认人负责在评审前核对并签字或标注确认。
| 字段 | 填写口径 | 示例 |
|---|---|---|
| 准则描述 | 一句话说明要求，动词开头 | 上游评审已关闭 |
| 判定条件 | 写成可核对的状态或数量，避免“基本完成”“大致齐全” | 上游需求评审记录结论为“通过”，且严重问题关闭率为100% |
| 证据形式 | 写可归档的材料类型 | 上游评审记录单、问题跟踪列表导出件 |
| 确认角色 | 写负责核对该准则的角色，不写“相关人员” | 计划负责人 |
职责分工类字段
计划负责人对入口准则的满足情况负总责，在评审开始前逐条确认；评审主持人负责组织会议、控制讨论范围并宣布结论；记录人负责完整记录问题与结论；问题跟踪人负责整改期限内的跟进和复评安排。参与对象一栏填写该角色实际参与的表1序号，便于核对每个对象是否都有人负责。
记录类字段
评审结论限定为“通过、有条件通过、不通过”三档，避免出现模糊表述。问题分级按严重、一般、建议三档统计数量，整改期限写到具体日期。关闭状态反映问题整改情况，复评状态反映是否需要再次评审。记录编号建议按“项目缩写-年份-序号”编制，便于检索。
必填与选填：哪些字段不能空
模板字段并非全部必填。必填项决定评审能否被追溯，选填项服务于特定场景。下表给出对照，团队可在此基础上按项目要求增补。
| 字段 | 必填/选填 | 理由或适用情形 |
|---|---|---|
| 对象名称 | 必填 | 没有对象名称，评审范围无法界定 |
| 对象类型 | 必填 | 决定采用哪套检查单和评审方式 |
| 来源与版本 | 必填 | 保证评审的是冻结版本，避免评审后文档又变更 |
| 评审方式 | 必填 | 决定参与人数、会议时长和记录详细程度 |
| 入口准则判定条件 | 必填 | 没有判定条件，入口准则无法执行 |
| 入口准则确认人 | 必填 | 明确谁对“可以开始评审”负责 |
| 计划负责人、评审主持人、记录人 | 必填 | 三类角色缺一，评审组织与记录无法落实 |
| 评审结论 | 必填 | 评审完成后必须给出结论，否则无法进入下一阶段 |
| 问题数与问题分级分布 | 必填 | 反映评审质量，也是判断是否需要复评的依据 |
| 关闭状态 | 必填 | 跟踪整改闭环 |
| 计划评审时间 | 选填 | 计划阶段可先填时间窗口，临近评审再精确到日期 |
| 证据形式 | 选填 | 简单走查可口头确认；正式评审建议填写并归档 |
| 整改期限 | 选填 | 结论为“通过”且无问题时可不填 |
| 复评状态 | 选填 | 无问题或问题均为建议级时可不填 |
| 参考文档链接、风险备注 | 选填 | 对象依赖外部资料或存在已知风险时填写 |
必填项缺失时的处理规则：评审开始前发现必填项为空，由计划负责人补齐后再确认入口准则；评审结束后发现记录类必填项为空，记录人应在两个工作日内补录，补录内容标注补录日期。若对象名称或版本无法确认，应暂停该对象的评审，待信息明确后重新排期。
填写示例：一份静态测试计划评审表怎么填
以下示例以“订单模块需求规格说明书”和“订单模块测试用例”两类对象为例，演示四张表的填写方式。示例中的部门、姓名、日期均为演示情景，实际使用时替换为真实信息。
评审对象与入口准则
| 序号 | 对象名称 | 对象类型 | 来源与版本 | 评审方式 | 责任人 |
|---|---|---|---|---|---|
| 1 | 订单模块需求规格说明书 | 需求文档 | 产品部 / V1.2 | 正式评审 | 张（产品经理） |
| 2 | 订单模块测试用例 | 测试用例 | 测试组 / V0.9 | 同行评审 | 李（测试工程师） |
| 准则编号 | 适用对象 | 准则描述 | 判定条件 | 证据形式 | 确认人 | 确认状态 |
|---|---|---|---|---|---|---|
| EC-01 | 需求规格说明书 | 文档版本已冻结 | 文档状态为“已基线”，版本号V1.2与评审通知一致 | 配置库版本记录 | 计划负责人 | 已确认 |
| EC-02 | 需求规格说明书 | 上游评审已关闭 | 业务方需求确认单已签署，遗留问题均为建议级 | 需求确认单、问题列表 | 计划负责人 | 已确认 |
| EC-03 | 测试用例 | 需求基线已发布 | 需求规格说明书V1.2评审结论为“通过” | 评审记录R-001 | 测试组长 | 已确认 |
| EC-04 | 测试用例 | 检查单已分发且评审人已确认到场 | 检查单在评审前两个工作日发出，评审人书面回复参加 | 邮件或协作记录 | 记录人 | 已确认 |
职责分工与记录
| 角色 | 姓名 | 职责说明 | 参与对象 |
|---|---|---|---|
| 计划负责人 | 王（测试经理） | 编制计划，逐条确认入口准则 | 1、2 |
| 评审主持人 | 赵（质量工程师） | 组织两场评审，宣布结论 | 1、2 |
| 记录人 | 陈（测试工程师） | 记录问题与结论 | 1、2 |
| 问题跟踪人 | 李（测试工程师） | 跟踪整改，安排复评 | 1、2 |
| 记录编号 | 评审日期 | 对应对象 | 评审结论 | 问题数 | 问题分级分布 | 整改期限 | 关闭状态 | 复评状态 |
|---|---|---|---|---|---|---|---|---|
| R-001 | （演示日期） | 需求规格说明书 | 有条件通过 | 6 | 严重1 / 一般3 / 建议2 | 评审后5个工作日 | 部分关闭 | 待复评 |
| R-002 | （演示日期） | 测试用例 | 通过 | 3 | 严重0 / 一般1 / 建议2 | 评审后3个工作日 | 已关闭 | 无需复评 |
示例与空白模板的字段一一对应：表1的七列在示例中全部填写；表2的准则编号按对象分组连续编号，确认状态在评审前更新；表3的参与对象用表1序号引用；表4的记录编号与表2证据形式中的引用保持一致，形成可追溯的链条。
调整与维护方法：模板怎么随项目演进
模板的价值在于长期复用。团队规模、项目周期和交付节奏不同，评审对象数量和准则严格程度也应随之调整。以下规则可作为维护清单。
- 按项目规模裁剪对象与准则。小型迭代可只保留需求文档和测试用例两类对象，每类设两到三条入口准则；跨团队或对外交付的项目应增加接口说明、设计文档，并为每类对象补充上游评审关闭、检查单分发等准则。裁剪时保留表1至表4的结构，只增减行数。
- 维护模板版本号与变更记录。在模板首页增加版本号、修订日期、修订人和变更说明四个字段。每次调整字段或准则模板，升一个次版本号；调整表格结构，升主版本号。变更记录保留最近若干次即可，历史版本归档备查。
- 评审后复盘并更新入口准则。出现以下情况时触发准则修订：评审中反复因同一条件不满足而延期；评审后发现的问题本可被上游评审拦截；某条准则连续多个项目从未起到拦截作用。修订由计划负责人提出，在下一个项目启动前完成。
- 固定存放位置与复用方式。模板存放在团队共享的文档库中，按“模板/静态测试计划”路径归档，只读权限开放给全员，修改权限归计划负责人。新项目复制一份到项目目录后填写，不直接在模板原件上修改。
当评审对象、入口准则和评审记录需要在多人之间流转时，可以把表1和表2作为计划文档的固定章节，把表4的记录转为可分配、可流转的工作项：每条问题对应一个工作项，指定整改人和期限，关闭状态随工作项状态自动更新，复评时按记录编号回溯原始评审结论。这样模板中的字段与实际执行保持同一套口径，复盘时也能直接统计各类对象的评审通过率和问题分布。
常见问题
小型迭代项目是否也要保留四张表？
可以保留四张表的结构，只减少行数。小型迭代通常只列需求文档和测试用例两类对象，每类设两到三条入口准则，职责分工表可合并为计划负责人、记录人两个角色，评审记录表保留结论、问题数、关闭状态三列即可。表1至表4的字段口径保持一致，后续项目扩充对象时直接加行，不用重建模板。
入口准则在评审前未全部满足，能否先开始评审？
建议按准则逐条判断。若未满足的准则涉及对象版本或上游评审结论，应先暂停该对象的评审，待信息明确后重新排期；若未满足的只是检查单分发、评审人到场这类组织性条件，可由计划负责人记录偏差并与主持人确认是否延期。无论哪种处理，都应在评审记录中写明未满足的准则编号和处理方式，便于复盘时判断准则是否设置过严。
评审记录中的问题如何与整改跟踪衔接？
记录表中的每条问题建议单独编号，与记录编号关联，例如R-001-03表示R-001记录下的第3个问题。问题跟踪人按问题编号建立整改任务，写明整改人、期限和关闭标准；关闭状态按问题逐条更新，再汇总回记录表的“关闭状态”和“复评状态”两列。复评时以记录编号回溯原始结论和问题清单，避免只更新汇总列而丢失单条问题的处理过程。
模板中的评审方式如何选择走查、同行评审还是正式评审？
可从对象的影响范围和变更幅度判断。影响多个团队或对外交付的接口说明、需求基线，适合正式评审，有主持人、多方参加并形成正式结论；同角色同事按检查单核对测试用例、代码，适合同行评审；作者自查加一人复核的走查，适合改动小、影响范围有限的对象。同一对象在生命周期内可以升级评审方式，例如初稿走查、基线版本转为正式评审，模板中按版本分别记录即可。
模板维护由谁负责，多久检查一次？
模板修改权限归计划负责人，日常使用为只读。建议在每个项目复盘时检查一次：是否有准则连续多个项目未起拦截作用、是否有评审因同一条件反复延期、是否有问题本可被上游评审提前发现。出现上述情况即触发修订，修订在下一个项目启动前完成，并更新模板首页的版本号、修订日期、修订人和变更说明。
