静态测试计划模板的核心是四块内容：评审对象、入口准则、职责分工和记录字段。职责分工表固定组织者、评审人、记录人、问题跟踪人和批准人五类角色；问题记录表逐条登记问题编号、对象与位置、问题描述、严重程度、责任人、状态和关闭依据。下面给出可直接复制填写的空白表格、字段说明、必填规则、完整样例和裁剪维护方法。
要点总览（TL;DR）
- 静态测试计划模板由计划主表、职责分工表、问题记录表三张表组成，统一使用计划编号作为问题编号前缀，便于按计划归档。
- 职责分工固定组织者、评审人、记录人、问题跟踪人、批准人五类角色；小规模项目可合并角色，但需在兼任说明中写明如何避免职责冲突。
- 问题记录表至少登记问题编号、评审对象与位置、问题描述、责任人、状态五项必填字段，严重程度与关闭依据在关闭前补全。
- 评审对象与入口准则应随研发流程定期复核，记录表按版本或迭代归档并保留最终状态快照，便于对比多轮评审的问题收敛情况。
- 多人协同维护记录时，可将问题记录落到工作项系统管理，把记录人、跟踪人和批准人的操作范围分开。
可复制空白模板：静态测试计划表与记录表
模板由三张表组成：计划主表说明本次静态测试的范围与安排，职责分工表固定角色与人员，问题记录表承载评审发现的问题。三张表使用同一套编号规则，计划编号作为问题编号的前缀，便于按计划归档。
表一：静态测试计划主表
| 字段 | 填写内容 |
|---|---|
| 计划编号 | |
| 计划名称 | |
| 所属项目/版本 | |
| 评审对象 | |
| 对象版本/基线 | |
| 入口准则 | |
| 评审方式 | |
| 计划评审时间 | |
| 计划人 | |
| 批准人 | |
| 出口准则 | |
| 备注 |
表二：职责分工表
| 角色 | 姓名 | 所属团队 | 主要职责 | 兼任说明 |
|---|---|---|---|---|
| 组织者 | ||||
| 评审人 | ||||
| 记录人 | ||||
| 问题跟踪人 | ||||
| 批准人 |
评审人一行可按实际人数展开为多行，每行注明其负责的评审对象或章节，避免出现“全员评审、无人负责”的情况。
表三：静态评审问题记录表
| 问题编号 | 评审对象与位置 | 问题描述 | 问题类型 | 严重程度 | 提出人 | 责任人 | 状态 | 关闭依据 | 登记日期 | 关闭日期 |
|---|---|---|---|---|---|---|---|---|---|---|
字段说明：每个字段记录什么、怎么填
三张表的字段承担不同任务：主表回答“评什么、什么时候评、达到什么条件算完成”，分工表回答“谁做什么”，记录表回答“发现了什么问题、处理到什么程度”。填写口径统一后，不同项目的记录才能横向比较和汇总。
计划主表字段含义
| 字段 | 记录什么 | 填写口径 |
|---|---|---|
| 计划编号 | 本次静态测试的唯一标识 | 建议采用“项目缩写-版本-序号”，如 PAY-V2.3-01 |
| 计划名称 | 计划的简短名称 | 写明评审对象类型，如“支付模块需求文档静态评审” |
| 所属项目/版本 | 计划归属 | 与研发计划中的版本号保持一致 |
| 评审对象 | 本次要评审的文档或代码产物 | 逐项列出：需求文档、设计文档、接口说明、代码规范、测试用例等 |
| 对象版本/基线 | 被评审产物的具体版本 | 填写文档版本号或代码提交标识，避免评审对象在过程中变化 |
| 入口准则 | 允许开始评审的前提条件 | 写成可核验的条件，如“文档已通过内部自检并完成版本冻结” |
| 评审方式 | 评审的组织形式 | 如会议评审、走查、个人检查，可组合使用 |
| 计划评审时间 | 评审活动的时间安排 | 写明起止时间，多人评审可分对象填写 |
| 计划人 | 编制本计划的人 | 通常为组织者 |
| 批准人 | 对计划负责的人 | 一般为测试负责人或项目负责人 |
| 出口准则 | 判定评审完成的条件 | 如“严重问题全部关闭、一般问题关闭率不低于约定比例” |
| 备注 | 补充信息 | 记录依赖、风险或特殊约定 |
职责分工字段含义
分工表固定五类角色。组织者负责确定评审对象、入口准则和日程，并推动评审按计划进行；评审人按分配的对象逐项检查并提交问题；记录人负责在评审过程中登记问题，保证描述准确、位置可定位；问题跟踪人负责推动问题修复、更新状态并核对关闭依据；批准人负责批准计划、裁定争议问题并确认出口准则达成。
“兼任说明”字段用于记录角色合并情况。小规模项目中组织者与记录人常由一人兼任，此时需在表中注明，并说明如何避免记录与主持相互干扰，例如评审过程中只记录不讨论，问题确认放到评审结束后统一处理。
记录字段含义与取值口径
| 字段 | 记录什么 | 取值口径 |
|---|---|---|
| 问题编号 | 问题唯一标识 | 计划编号加流水号，如 PAY-V2.3-01-003 |
| 评审对象与位置 | 问题所在文档及章节、页码或代码文件与行号 | 定位到可复查的最小单位 |
| 问题描述 | 问题是什么、为什么是问题 | 一句话说明现象，一句话说明影响或依据 |
| 问题类型 | 问题归类 | 如完整性、一致性、可测试性、规范性 |
| 严重程度 | 问题的影响等级 | 建议分三级：严重、一般、建议 |
| 提出人 | 发现该问题的评审人 | 填写姓名，便于回溯 |
| 责任人 | 负责处理该问题的人 | 通常为被评审产物的作者 |
| 状态 | 问题处理进度 | 限定为待处理、处理中、已关闭、不处理四类 |
| 关闭依据 | 判定关闭的证据 | 如“文档 V1.3 第 4.2 节已补充异常流程说明” |
| 登记日期 | 问题登记时间 | 评审当天填写 |
| 关闭日期 | 问题关闭时间 | 状态改为已关闭时填写 |
状态取“不处理”时，关闭依据中必须写明理由和裁定人，例如“经批准人确认属于下一版本范围”。这样记录表既能反映处理结果，也能保留决策痕迹。
必填与选填：哪些字段不能空
必填字段的判断标准是能否支撑追溯：一个问题从提出到关闭，至少要知道它在哪里、是什么、谁负责、当前什么状态。缺少其中任何一项，记录表就无法作为评审结论的依据。
| 表格 | 必填字段 | 选填字段 |
|---|---|---|
| 计划主表 | 计划编号、计划名称、所属项目/版本、评审对象、入口准则、计划人、批准人 | 对象版本/基线、评审方式、计划评审时间、出口准则、备注 |
| 职责分工表 | 角色、姓名、主要职责 | 所属团队、兼任说明 |
| 问题记录表 | 问题编号、评审对象与位置、问题描述、责任人、状态 | 问题类型、严重程度、提出人、关闭依据、登记日期、关闭日期 |
缺失必填项时按以下规则处理：计划主表缺少评审对象或入口准则，计划不得进入批准环节；分工表缺少任一角色的姓名，由组织者在评审开始前补齐，确实无人承担的角色需由批准人书面指定兼任人；问题记录缺少对象与位置或问题描述，该条记录退回提出人补充，不计入有效问题；缺少责任人时由问题跟踪人根据产物归属指定，并在记录中注明指定过程。
严重程度和关闭依据在问题登记时可以暂空，但状态改为“已关闭”之前必须补全。出口准则中若约定按严重程度统计关闭率，严重程度随之成为关闭前的必填项。
填写示例：一份静态测试计划的完整样例
以下样例为演示情景，用于说明三张表如何配合使用，不代表任何真实项目数据。
计划主表示例
| 字段 | 填写内容 |
|---|---|
| 计划编号 | PAY-V2.3-01 |
| 计划名称 | 支付模块需求文档与接口说明静态评审 |
| 所属项目/版本 | 支付平台 V2.3 |
| 评审对象 | 《支付模块需求规格说明书》、《退款接口说明》 |
| 对象版本/基线 | 需求文档 V1.2；接口说明 V0.9 |
| 入口准则 | 两份文档已完成作者自检并冻结版本；需求条目已分配唯一编号 |
| 评审方式 | 个人检查加会议评审 |
| 计划评审时间 | 3 月 4 日个人检查，3 月 6 日会议评审 |
| 计划人 | 测试组 李某 |
| 批准人 | 测试负责人 王某 |
| 出口准则 | 严重问题全部关闭，一般问题关闭率不低于 90% |
| 备注 | 接口说明依赖第三方支付渠道文档，若渠道文档延迟则顺延 |
职责分工示例
| 角色 | 姓名 | 所属团队 | 主要职责 | 兼任说明 |
|---|---|---|---|---|
| 组织者 | 李某 | 测试组 | 确定评审对象与入口准则，安排日程，主持评审会议 | 无 |
| 评审人 | 张某 | 开发组 | 评审需求文档第 1—4 章及全部接口说明 | 无 |
| 评审人 | 赵某 | 产品组 | 评审需求文档第 5—7 章 | 无 |
| 记录人 | 陈某 | 测试组 | 会议中登记问题，会后当日完成记录整理 | 由组织者兼任会议主持，记录期间不参与讨论 |
| 问题跟踪人 | 陈某 | 测试组 | 推动问题修复，更新状态，核对关闭依据 | 与记录人为同一人 |
| 批准人 | 王某 | 测试组 | 批准计划，裁定争议问题，确认出口准则达成 | 无 |
问题记录示例
| 问题编号 | 评审对象与位置 | 问题描述 | 问题类型 | 严重程度 | 提出人 | 责任人 | 状态 | 关闭依据 |
|---|---|---|---|---|---|---|---|---|
| PAY-V2.3-01-001 | 需求文档 V1.2 第 3.2 节 | 退款失败后的重试次数未定义，开发无法确定实现边界 | 完整性 | 严重 | 张某 | 赵某 | 已关闭 | 需求文档 V1.3 第 3.2 节已补充重试次数与超时规则 |
| PAY-V2.3-01-002 | 接口说明 V0.9 第 2 节 | 退款接口的错误码列表与需求文档第 6 章不一致 | 一致性 | 一般 | 赵某 | 张某 | 处理中 | |
| PAY-V2.3-01-003 | 需求文档 V1.2 第 5.1 节 | 对账时间窗口的描述无法转化为可验证的测试条件 | 可测试性 | 一般 | 张某 | 赵某 | 待处理 |
样例中问题 001 已关闭并写明依据，问题 002 和 003 尚未关闭，出口准则是否达成可直接依据记录表统计。评审结束后，问题跟踪人按状态汇总，向批准人提交关闭率与遗留问题清单，作为出口准则确认的输入。
当评审记录需要多人协同维护时，可以把问题记录表落到工作项系统中管理。ONES 测试管理支持测试计划与迭代关联，并支持为不同用户组、测试计划单独配置权限，便于把记录人、问题跟踪人和批准人的操作范围分开；未通过检查的条目可快速创建缺陷任务，在测试与研发团队间流转，缺陷也可关联至迭代。评审结论需要汇报时，可使用其测试报告模板组装汇总内容。静态评审的专用字段仍需按本文模板在项目内约定。
调整与维护方法：按项目规模裁剪模板
模板裁剪的原则是保留追溯链条，压缩管理开销。评审对象少、参与人少的项目可以合并角色、精简选填字段；跨团队、多产物的项目则需要拆分评审人分工并保留完整记录。
模板裁剪原则
- 角色裁剪：参与人不超过三人时，组织者、记录人、问题跟踪人可由一人兼任，批准人保持独立，并在兼任说明中写明。
- 对象裁剪：单一文档评审可省略“评审方式”中的组合形式，只保留实际采用的一种；多文档评审则需在分工表中按文档拆分评审人。
- 字段裁剪：问题类型在问题量少的项目中可省略，严重程度建议保留，它是出口准则统计的基础。
- 流程裁剪：走查形式可不设会议环节，但入口准则、记录表和关闭依据仍需保留。
记录表更新与归档
记录表在评审期间由记录人当日更新，评审结束后由问题跟踪人按固定节奏更新状态，建议每次状态变化都同步关闭依据。计划出口准则确认后，记录表随计划主表一并归档，归档时保留最终状态快照，避免后续修改影响历史结论。归档粒度按版本或迭代划分，同一评审对象的多轮评审使用不同计划编号，便于对比问题收敛情况。
评审对象与入口准则的维护
评审对象清单和入口准则应随研发流程变化定期检查。新增产物类型时，在计划主表的评审对象中补充，并为其写明可核验的入口准则；流程调整导致某类文档不再产出时，从清单中移除并记录调整原因。建议在每个版本规划阶段复核一次清单，确保模板中的对象类型与当前实际交付物一致，入口准则仍能有效拦截不具备评审条件的产物。
常见问题
小团队只有两三个人参与评审，职责分工表可以简化到什么程度？
参与人不超过三人时，组织者、记录人、问题跟踪人可以由一人兼任，批准人建议保持独立，以便对出口准则是否达成做最终确认。简化后仍需在“兼任说明”字段写明合并情况，并约定避免职责冲突的做法，例如评审过程中只记录不讨论，问题确认放到评审结束后统一处理。角色合并只压缩人力投入，入口准则、问题记录和关闭依据仍需保留。
问题记录表中的“不处理”状态在什么情况下使用，需要留下什么？
“不处理”用于经评估确认不在本次评审范围内、或转入后续版本处理的问题。选择该状态时，关闭依据中要写明理由和裁定人，例如“经批准人确认属于下一版本范围”。这样记录表既反映处理结果，也保留决策痕迹，后续复盘时能区分“已修复”和“决定不修”两类情况。
评审过程中文档又改了版本，记录表怎么处理？
计划主表的“对象版本/基线”字段用于锁定被评审产物的具体版本，评审开始后对象发生变化时，建议为新一轮评审使用新的计划编号，而不是在原记录上继续追加。原计划的记录表保留当时的问题与关闭依据，作为该版本的评审结论归档；新版本的问题记录独立编号，两轮之间可通过评审对象和版本号对照，观察问题是否收敛。
静态评审发现的问题较多时，用什么方式跟踪比较稳妥？
问题量较大或参与人分散时，可把问题记录表落到工作项系统中维护，让记录人、问题跟踪人和批准人各自在权限范围内操作。ONES 测试管理支持为不同用户组、测试计划单独配置权限，未通过检查的条目可快速创建缺陷任务，在测试与研发团队间流转，缺陷也可关联至迭代；评审结论需要汇报时，可使用其测试报告模板组装汇总内容。静态评审的专用字段仍需按本文模板在项目内约定。
模板用了一段时间后，评审对象清单和入口准则要不要定期改？
建议在每个版本规划阶段复核一次。新增产物类型时，在计划主表的评审对象中补充，并为其写明可核验的入口准则；某类文档不再产出时，从清单中移除并记录调整原因。入口准则的检验标准是能否有效拦截不具备评审条件的产物，如果多次出现文档未自检就进入评审的情况，说明准则需要写得更具体。
