静态测试计划模板：职责分工与记录字段清单

静态测试计划模板的核心是四块内容：评审对象、入口准则、职责分工和记录字段。评审对象列清需求文档、设计文档、接口说明、用户手册等静态材料；入口准则说明每类对象满足什么条件才能进入评审；职责分工按计划负责人、评审主持人、评审人、记录人、整改责任人划分；记录字段用一张问题表固定评审编号、对象与版本、问题描述、严重程度、责任人、整改状态与关闭日期。下面给出可直接复制的空白表格、字段填写口径、必填与选填建议、完整示例和维护方法。

要点总览（TL;DR）

• 静态测试计划模板以评审对象、入口准则、职责分工、记录字段四块为核心，四张表通过计划编号和评审编号关联。
• 职责分工至少覆盖计划负责人、评审主持人、评审人、记录人、整改责任人，职责写动作和判断标准，交付物写具体物件。
• 记录字段的最小闭环是问题编号、问题描述、严重程度、整改责任人、整改状态、关闭依据和关闭日期，缺一项就难以分派和统计。
• 小型评审可裁剪问题类型、提出人、位置等统计类字段，保留可追溯链条；跨团队项目建议保留全部字段并增加审批记录。
• 模板本身要有版本号和变更记录，由测试或质量负责人按项目启动、评审结束、季度复盘三个时点检查维护。

可复制空白模板：静态测试计划职责与记录表

模板由四张表组成。基本信息表确定计划边界，评审对象与入口准则表确定“评什么、何时评”，职责分工表确定“谁做什么”，评审记录表承载每次评审产生的问题。四张表通过计划编号和评审编号关联，复制到文档或表格工具中即可使用。

表1 静态测试计划基本信息

字段	填写内容
计划名称
计划编号
计划版本
编制人
审批人
适用范围
计划起止日期
关联项目/迭代

表2 评审对象与入口准则

评审编号	评审对象	文档版本	入口准则	计划评审日期	评审方式	评审主持人

表3 职责分工

角色	姓名	职责	交付物	参与阶段
计划负责人
评审主持人
评审人
记录人
整改责任人

表4 评审记录（问题级）

问题编号	评审编号	对象与版本	位置	问题描述	问题类型	严重程度	提出人	整改责任人	整改状态	关闭依据	关闭日期

字段说明：每个字段填什么、怎么填

字段说明解决“同一列不同人填出不同口径”的问题。填写前先约定取值规则，尤其是严重程度、整改状态和关闭依据，这三列直接决定问题能否被追踪到关闭。

评审对象与入口准则字段

字段	填写口径
评审编号	计划内唯一，建议采用“计划编号-序号”，如 STP-01-001，便于与问题编号区分。
评审对象	写具体文档名称与类型，如“订单模块需求规格说明书”“支付接口说明 v1.2”，避免只写“需求文档”。
文档版本	填写送审版本号或基线标识；评审后文档升版时，在记录中保留原版本，便于追溯问题针对哪一版提出。
入口准则	写可判断的条件，如“文档已完成内部自检并附检查记录”“接口字段与需求条目一一对应”“上一轮问题已全部关闭”。条件应能回答“满足/不满足”。
评审方式	写明走查、同行评审、正式评审会等具体形式，以及是否线上进行。
评审主持人	填写对本次评审节奏和结论负责的人，与计划负责人可以是同一人，但需在职责表中说明。

职责分工字段

字段	填写口径
角色	使用固定角色名，不直接写人名，便于人员变动时替换。
姓名	填写承担该角色的具体人员；一人兼多角色时逐行列出，避免职责遗漏。
职责	写动作和判断标准，如“组织评审、确认入口准则满足、裁定问题严重程度分歧”，不写“负责评审工作”这类笼统表述。
交付物	写该角色在评审前后产出的具体物件，如评审通知、问题清单、整改回复、关闭确认记录。
参与阶段	标明计划、评审准备、评审执行、整改跟踪、关闭确认中的哪些阶段需要该角色介入。

记录字段

字段	填写口径
问题描述	写“位置＋现象＋影响”，如“3.2节接口超时阈值未定义，开发无法确定重试策略”。一条记录只写一个问题。
问题类型	按团队约定分类，如完整性、一致性、可测试性、歧义、遗漏。
严重程度	用固定档位，如严重、一般、建议。严重指不修改会导致返工或无法测试；一般指影响理解；建议指表达优化。
整改状态	使用有限状态，如待处理、整改中、待复核、已关闭、不修改。状态变化时更新日期。
关闭依据	写可核验的证据，如“文档 v1.3 第3.2节已补充阈值”“评审人复核确认”。仅写“已改”不足以关闭。
关闭日期	填写复核通过当天日期，与整改完成日期区分。

字段之间存在对应关系：问题编号关联评审编号，评审编号关联评审对象与版本；整改责任人来自职责分工表；关闭依据对应入口准则中“上一轮问题已关闭”这类条件。填写时保持编号一致，后续统计问题分布和关闭率才有依据。

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

最小可用模板只需保证问题可追溯、责任可落实。以下字段建议设为必填，其余按项目情况保留或删除。

类别	字段	理由或适用场景
必填	计划编号、计划版本、编制人、审批人	确定计划身份和责任人，缺少则无法判断执行的是哪一版计划。
必填	评审编号、评审对象、文档版本、入口准则	保证每次评审有唯一标识，问题能对应到具体文档版本。
必填	角色、姓名、职责	职责分工是计划可执行的前提，至少覆盖主持人、记录人和整改责任人。
必填	问题编号、问题描述、严重程度、整改责任人、整改状态	构成问题跟踪的最小闭环，缺一项就难以分派和统计。
必填	关闭依据、关闭日期	问题关闭时需要证据，否则状态无法被复核。
选填	关联项目/迭代、计划起止日期	单次小型评审可省略；跨迭代计划建议保留。
选填	问题类型、提出人	需要分析问题分布或做评审质量复盘时保留。
选填	交付物、参与阶段	角色较少的小团队可合并填写；角色多、交接频繁时建议保留。
选填	位置	文档较短时可并入问题描述；文档篇幅大时单独列出便于定位。

裁剪按项目规模处理：两三人参与的小型评审可保留基本信息、评审对象、职责和问题记录四张表的核心列，把问题类型、提出人并入备注；跨团队或合规要求较高的项目应保留全部字段，并增加审批记录。裁剪的原则是保留可追溯链条，删减只影响统计分析的列。

填写示例：一份完整的静态测试计划记录

以下为演示情景，用于说明各字段如何配合，不代表真实项目数据。

示例背景与评审对象

某团队计划对“订单模块需求规格说明书 v1.1”和“支付接口说明 v1.2”开展静态评审，计划编号 STP-2024-03，编制人为测试负责人，审批人为项目经理。两张文档分别设定入口准则：需求文档需完成产品内部自检并附检查记录；接口说明需与需求条目建立对应关系。

职责分工填写示例

角色	姓名	职责	交付物	参与阶段
计划负责人	张宁	编制计划、确认入口准则、汇总评审结论	静态测试计划、评审总结	计划、关闭确认
评审主持人	李珂	组织评审会、控制节奏、裁定严重程度分歧	评审通知、会议结论	评审准备、评审执行
评审人	王璐、陈默	按检查表逐条审查、提出问题并复核整改	问题清单、复核意见	评审执行、整改跟踪
记录人	赵晴	记录问题、维护问题状态、更新关闭日期	评审记录表	评审执行、整改跟踪
整改责任人	周远	修改文档、回复整改说明、提交复核	修订版文档、整改回复	整改跟踪

一条问题的完整记录示例

字段	示例内容
问题编号	STP-2024-03-001
评审编号	STP-2024-03-002
对象与版本	支付接口说明 v1.2
位置	第4.1节 退款接口
问题描述	退款接口未定义部分退款场景的返回码，开发无法确定异常分支处理方式
问题类型	完整性
严重程度	严重
提出人	王璐
整改责任人	周远
整改状态	已关闭
关闭依据	接口说明 v1.3 第4.1节补充部分退款返回码，评审人王璐复核确认
关闭日期	2024-03-18

示例中的问题编号、评审编号与评审对象表保持一致，整改责任人对应职责分工表中的周远，关闭依据指向升版后的文档并注明复核人。按同样方式逐条记录，评审结束时即可统计各文档的问题数量和关闭情况。

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

模板需要随项目类型和团队协作方式调整，否则会出现字段越填越多、关键列却被忽略的情况。维护工作集中在裁剪规则、版本记录、归档复用和检查时点四件事上。

按项目类型裁剪字段与角色

需求评审侧重完整性与一致性，可保留问题类型和位置字段；接口说明评审侧重字段定义和异常分支，可在问题描述中固定“接口名＋场景＋缺失内容”的结构；用户手册评审侧重可读性，严重程度可简化为“需修改/建议修改”两档。角色方面，小团队可由主持人兼任记录人，但需在职责表中写明兼任关系，避免问题无人跟踪。

模板版本与变更记录

模板本身应有版本号和变更记录，写明修改日期、修改人、修改内容和影响范围。新增必填字段时，同步更新字段说明和示例，避免旧记录与新模板混用。建议在计划基本信息表中保留“模板版本”一列，便于回溯某份计划使用的是哪一版模板。

评审记录归档与复用

每次评审结束后，将评审记录表与修订版文档一并归档，按计划编号和评审编号命名。归档记录可用于两类复用：一是作为下一轮评审的入口检查依据，确认上一轮问题是否关闭；二是汇总同类文档的高频问题，反哺检查表条目。评审问题需要跨角色跟踪时，可将每条问题登记为工作项，由整改责任人更新状态、评审人复核后关闭，使记录表中的状态与工作项保持一致。ONES 的工作项与文档管理可以承载这类评审问题跟踪，具体配置按团队流程确定。

维护责任人与检查时点

模板维护建议由测试负责人或质量负责人承担，检查时点包括：每个项目启动时确认模板版本和裁剪范围；每轮评审结束后检查必填字段是否完整；每季度汇总一次问题类型和关闭周期，判断是否需要增删字段。以下检查清单可直接使用：

• 计划编号与评审编号是否唯一且相互对应
• 每个评审对象是否写明版本和可判断的入口准则
• 职责分工是否覆盖主持人、记录人和整改责任人
• 问题记录的严重程度、整改状态是否使用约定取值
• 关闭的问题是否都有可核验的关闭依据和关闭日期
• 模板变更是否记录版本、日期和影响范围

常见问题

静态测试计划里的评审人和整改责任人可以是同一个人吗？

可以，但要在职责分工表中写明兼任关系，并保留复核环节。整改责任人负责修改文档和提交复核，评审人负责确认问题是否真正解决；同一人兼任时，关闭依据应写清复核了哪一版文档的哪一处内容，避免出现自己改、自己关、无人核对的情况。团队人数允许时，建议由另一位评审人做关闭复核。

入口准则写得太严会导致评审排不上期，怎么把握尺度？

入口准则的作用是判断文档是否具备评审条件，写法上要能回答“满足/不满足”。常见做法是设两三条硬条件，例如文档完成内部自检并附检查记录、关键条目与上游需求建立对应关系、上一轮严重问题已关闭。把格式美化、措辞打磨这类条件放进评审过程处理，不设为入口门槛。条件过严时，可在计划中记录例外放行的理由和补做安排，保持可追溯。

问题关闭后文档又升版了，原记录需要改吗？

原记录保留，不改写历史。关闭依据中写明是针对哪一版文档的哪一处修改完成复核，例如“接口说明 v1.3 第4.1节已补充返回码”。文档再次升版后如涉及同一位置，另开一条新问题记录并关联原评审编号，这样问题分布和关闭周期统计才不会被历史修改打乱。

评审记录用文档表格维护，还是登记成工作项？

取决于问题需要跨多少人跟踪。单次评审、参与人少时，文档中的记录表足够用；问题需要分派给开发、设计等不同角色，且要持续更新状态时，把每条问题登记为工作项更便于分派和统计。ONES 的工作项与文档管理可以承载评审问题跟踪，具体字段和状态流转按团队流程配置。两种方式并用时，以一处为状态准绳，定期核对记录表与工作项是否一致。

小团队只有三四个人，模板可以精简到什么程度？

保留四张表的核心列即可：基本信息中的计划编号、版本、编制人、审批人；评审对象表中的评审编号、对象、版本、入口准则；职责表中的角色、姓名、职责；问题记录中的问题编号、描述、严重程度、整改责任人、整改状态、关闭依据、关闭日期。问题类型、提出人、位置、交付物、参与阶段可并入备注或暂时删除。精简的判断标准是问题仍能追溯到具体文档版本并找到责任人。