静态测试计划要回答的不是“安排一次评审”，而是“在什么范围内、用什么方法、由谁、在什么时点、产出什么证据”。计划需要把测试对象与范围、方法与深度、角色与时间、准入准出条件、问题处理与证据留存写成可核对的条目，让评审、走查或静态分析能够按计划启动、按标准判定、按记录关闭。下面给出一套约束清单、编制步骤、角色分工、示例和完成检查表，供测试负责人或质量人员直接套用。
要点总览（TL;DR）
- 静态测试计划的约束围绕四类展开：测试对象与范围、方法与深度、角色与时间、准入准出与证据，每类都要写成可核对条目。
- 编制顺序建议先定范围和方法，再倒推角色、时间与准出标准，最后定义问题记录与跟踪规则。
- 角色分工要落到交付物：计划负责人出计划与准出结论，主持人出会议记录与问题清单，评审人出书面意见，作者出修改说明。
- 计划是否可执行，用完成检查清单判断：范围有版本、方法有检查项、环节有负责人、条件可判定、问题能闭环。
- 计划应能直接回答谁在什么时间检查什么、按什么标准判定、结果记录在哪里。
静态测试计划先锁定哪些约束
静态测试不执行代码，检查的是需求、设计、代码、文档等静态工作产品，因此计划约束的重点在于“检查什么、查到什么程度、谁来判、何时算完成”。可以把约束归为四类，每类都要在计划中落到具体条目，而不是只写活动名称。
| 约束类别 | 需要明确的内容 | 常见写法示例 |
|---|---|---|
| 测试对象与范围 | 纳入静态检查的工作产品清单、版本或基线、明确排除的部分 | 本次覆盖需求规格说明书V1.2全部章节，接口协议文档不在本次范围 |
| 方法与深度 | 采用评审、走查还是静态分析；检查项清单；抽样比例或覆盖要求 | 需求评审采用正式评审，逐条核对检查单；代码采用静态分析工具扫描严重级别以上问题 |
| 角色与时间 | 计划负责人、主持人、评审人、作者、修改责任人；各环节起止时间与工作量 | 评审会安排在文档基线冻结后2个工作日内，评审人提前1天提交书面意见 |
| 准入准出与证据 | 启动条件、通过标准、遗留问题处理规则、记录与追溯方式 | 严重问题全部关闭、一般问题有处理结论方可基线；评审记录与问题单关联留存 |
这四类约束相互牵制。范围扩大而评审人不变，深度就要下调或时间要延长；准出条件写得模糊，证据就无法支撑“通过”的结论。计划编制时先把范围和方法定下来，再倒推角色、时间和准出标准，比先排会议时间更稳妥。
按步骤编制静态测试计划
编制过程可以按五步推进，每一步都应有明确输入、动作、输出和完成标志，避免计划停留在活动列表层面。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 确定对象与范围 | 项目计划、文档清单、代码基线、需求列表 | 列出纳入静态检查的工作产品及版本，标注排除项和理由 | 静态测试对象清单 | 每项对象有版本标识和责任人，排除项有说明 |
| 2. 选择方法与深度 | 对象类型、质量目标、团队经验 | 为每类对象指定评审、走查或静态分析，附检查单和判定标准 | 方法与检查项对照表 | 每类对象有对应方法和可勾选的检查项 |
| 3. 设定准入准出 | 上一阶段产出、缺陷分级规则 | 写明启动条件、通过标准、遗留问题处理方式和复评要求 | 准入准出条件说明 | 条件可判定，不依赖主观描述 |
| 4. 安排角色、时间与工作量 | 人员可用性、里程碑 | 指定各角色，估算准备、评审、修改、复评的时间 | 角色与排期表 | 每个环节有负责人和起止时间 |
| 5. 定义问题记录与跟踪 | 问题分级标准、跟踪工具 | 规定记录字段、分级、指派、关闭和升级规则 | 问题处理流程说明 | 每个问题有唯一编号、责任人和关闭依据 |
在计划编制和问题跟踪环节，可以用 ONES 承载相关工作项与文档协作：测试计划可与迭代关联，测试用例与需求、任务关联，未通过项可快速创建缺陷任务并在测试与研发团队间流转，便于把计划条目和问题处理放在同一流程中跟踪。静态评审记录、检查单等证据是否与工作项关联留存，需结合团队实际配置核验。
角色分工与交付物怎么定
静态测试计划能否执行，很大程度取决于角色是否清晰。每个角色既要写明职责，也要写明交付物，交付物是判断职责是否履行的依据。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 计划负责人 | 确定范围与方法，组织计划评审，跟踪整体进度和准出判定 | 静态测试计划、进度跟踪记录、准出结论 |
| 评审主持人 | 组织评审会，控制节奏，确认问题分级和结论 | 评审会议记录、问题清单、评审结论 |
| 评审人 | 按检查单提前审阅，提交书面意见，参与问题确认 | 个人评审意见、检查单填写结果 |
| 作者与修改责任人 | 提供受检对象，回应意见，完成修改并提交复评 | 修改说明、修订后的工作产品 |
| 质量或过程角色 | 检查计划与执行的一致性，汇总问题趋势，推动流程改进 | 过程检查记录、问题统计与改进建议 |
角色安排要避免两个常见问题：一是主持人同时担任主要作者，评审独立性不足；二是评审人只挂名不提交书面意见，导致评审会变成现场通读。计划中可规定评审人提前提交意见的最低要求，并把未提交意见视为未完成准备工作，作为准入条件之一。
示例：一份需求评审静态测试计划的约束写法
以下为演示情景，用于说明约束如何落到计划条目，不代表真实项目案例。
背景与范围：某业务系统进入需求基线阶段，对《订单管理需求规格说明书》V1.0 开展正式评审。范围覆盖功能需求、业务规则和异常场景描述；界面原型和非功能性需求中的性能指标不在本次评审范围，另行安排。
约束条目写法：
- 方法：正式评审，使用需求检查单，逐条核对完整性、一致性、可测试性和歧义。
- 准入：文档已完成内部自检，作者提交自检记录；评审人提前1个工作日提交书面意见。
- 准出：严重问题全部关闭；一般问题有明确处理结论或经负责人确认延期；评审记录归档并与需求条目关联。
- 时间与工作量：准备1个工作日，评审会2小时，修改与复评2个工作日。
检查项与完成标志：检查单按“需求描述是否可验证”“业务规则是否存在冲突”“异常场景是否覆盖”等条目组织，每条检查项有勾选结果和备注。完成标志为检查单全部填写、问题清单确认完毕、评审结论签字。
问题记录与关闭方式：每个问题记录编号、所在章节、问题描述、严重级别、责任人和建议修改方向。严重问题修改后由原评审人复评确认关闭；一般问题由作者修改并在问题单中说明处理结果，主持人抽查确认。问题单状态从“待处理”到“已修改”再到“已关闭”，未关闭问题在准出结论中列明。
完成检查：计划是否可执行
计划编制完成后，用下面的清单逐项核对。任何一项无法给出明确答案，都说明计划还不具备执行条件。
- 范围与对象：受检工作产品是否逐项列出，是否有版本标识，排除项是否有说明和后续安排。
- 方法与深度：每类对象是否指定了评审、走查或静态分析方式，是否有可勾选的检查项和判定标准。
- 角色与时间：每个环节是否有明确负责人，准备、评审、修改、复评的时间是否已排入里程碑，工作量是否与人员可用性匹配。
- 准入准出与证据：启动条件和通过标准是否可判定，评审记录、检查单、问题单是否规定了留存位置和关联方式。
- 问题处理闭环：问题分级、指派、修改、复评、关闭是否有规则，遗留问题是否有明确的处理结论和责任人。
核对通过后，计划应能直接回答“谁在什么时间检查什么、按什么标准判定、结果记录在哪里”。达到这一状态，静态测试计划就可以进入执行和跟踪阶段。
常见问题
静态测试计划里，范围和方法哪个先定？
建议先定范围，再定方法。范围决定受检工作产品的清单和版本，方法则要匹配对象类型：需求文档适合正式评审加检查单，代码适合静态分析工具扫描。范围一旦扩大，评审人数量或时间就要相应调整，深度也可能需要下调。先排会议时间再补范围，容易出现评审人不足、检查项对不上对象的情况。
评审人没有提前提交书面意见，还能按计划开评审会吗？
这取决于计划中准入条件怎么写。如果计划把“评审人提前提交书面意见”列为准入条件，那么未提交就属于准备未完成，可以推迟评审或要求补交后再开。另一种做法是允许会上口头提出意见，但需要接受评审质量下降的风险。无论选哪种，都应在计划中写清楚，避免每次临时判断。
静态测试发现的问题和测试执行中的缺陷要分开跟踪吗？
可以放在同一套问题跟踪机制里，但建议用类型字段区分“评审问题”和“执行缺陷”，因为两者的处理路径不同：评审问题通常由作者修改后原评审人复评关闭，执行缺陷则进入缺陷修复流程。使用 ONES 时，未通过的用例可以快速创建缺陷任务并在测试与研发团队间流转；评审问题是否也纳入同一工作项体系，需要结合团队实际配置确认。
遗留问题较多时，准出结论怎么写才不流于形式？
准出结论应逐条列出未关闭问题的编号、严重级别、责任人和处理计划，并说明放行理由和后续复评时点。严重问题全部关闭是常见底线；一般问题可以带条件放行，但要有负责人确认。只在结论里写“基本通过”而不列遗留项，后续就无法追溯哪些问题被接受、由谁接受。
静态测试计划需要覆盖哪些证据留存？
至少包括：受检对象的版本标识、检查单填写结果、评审意见与会议记录、问题清单及其状态变化、准出结论。计划中要写明这些证据存放在哪里、与哪个工作产品关联。ONES 测试管理支持测试计划与迭代关联、测试用例与需求任务关联，可作为计划与问题跟踪的承载；评审记录、检查单等静态测试证据能否与工作项关联留存，需结合团队实际配置核验。
