静态测试计划把代码评审、文档评审、静态分析等不运行程序的检查活动，提前落到对象、范围、规则、角色、时点和出口标准上，形成一份可执行的安排。制定时先确定检查对象与准入条件，再选定检查方法与规则集，明确谁在什么时点做什么、产出什么记录，最后设定问题分级、闭环方式和完成判据，并在版本节奏中留出复评与回归的位置。本文按对象界定、方法规则、六步流程、角色分工、条目示例和发布前核对展开，适用于版本迭代或项目启动阶段的计划编制。
要点总览（TL;DR）
- 静态测试计划的核心是把文档评审、代码评审、静态分析等不运行程序的检查，落到对象、范围、规则、角色、时点和出口标准上，形成可执行安排。
- 制定顺序为：先界定检查对象与准入条件，再建立对象—方法—规则对照表，然后按六步流程完成排期、问题闭环、出口判据与计划评审发布。
- 计划可执行的关键在于每项活动都有责任人、时点、产出记录和可客观判定的出口判据，阻断级问题清零等条件需事先写明。
- 单份需求文档的质量评审归需求评审流程，攻击技术与漏洞利用不纳入常规静态检查，计划中应写明排除项。
- 发布前用核对清单逐项检查范围、规则、判据、变更机制和记录留存，任一项不满足应补齐后再发布。
静态测试计划要覆盖哪些检查对象与范围
计划的第一步是划清边界：哪些文档、代码、配置和模型进入静态检查，哪些不进入。边界不清，计划容易写成“加强质量把关”这类口号，执行时无人知道该查什么。静态测试与动态测试的分工也应在此写明——静态检查针对不运行程序即可发现的问题，如需求歧义、设计遗漏、编码规范偏离、配置错误；功能行为验证、性能表现等仍需动态测试承担，两者在计划中各自列出，避免互相替代。
检查对象通常包括五类：需求与设计文档、接口说明、源代码、配置与脚本、数据模型。每类对象需写明具体范围，例如“本版本新增及变更的接口说明文档”“主干分支上本迭代合并的代码”。范围描述应能对应到版本基线，便于后续核对是否漏项。
准入条件决定检查能否按时开始，需逐项写清：文档达到可评审状态（内容完整、版本号明确、待决问题已标注）；代码可编译或可解析，静态分析工具能正常加载；分支与版本基线已确定，评审针对的是固定提交而非移动目标。准入条件不满足时，计划应说明是顺延还是降级处理。
排除项同样要写。单份需求文档的质量评审归需求评审流程，不在静态测试计划中重复安排；具体攻击技术与漏洞利用方法属于安全专项，不纳入常规静态检查范围。写明排除项，既减少重复劳动，也让计划评审时各方对边界有共同预期。
本节交付物是静态检查对象与范围清单，包含对象类别、具体范围、准入条件和排除项四列，作为后续方法选择和排期的输入。
按对象选择检查方法与规则集
范围确定后，需要把每类对象映射到具体方法，让计划中的每项活动都有可执行依据。文档类对象适合同行评审、走查和检查单评审：同行评审用于需求与设计文档的交叉审阅，走查适合接口说明的逐条核对，检查单评审则把常见缺陷类型固化为清单，降低对评审人经验的依赖。代码类对象对应代码评审、静态分析工具扫描和编码规范核查，三者可以并行，分别覆盖逻辑设计、自动化规则和团队约定。
规则集来源一般有三类：团队编码规范、行业标准、工具内置规则包。计划中应写明每类规则的来源和适用范围，并说明裁剪与豁免流程——哪些规则因项目特点暂不启用，豁免需谁批准、记录在哪里。规则严重级别与问题分类口径也要统一，例如按阻断、严重、一般、提示四级划分，并给出每级的判定描述，避免不同评审人对同一问题给出不同级别。
| 检查对象 | 主要方法 | 规则集来源 | 产出记录 |
|---|---|---|---|
| 需求与设计文档 | 同行评审、检查单评审 | 文档模板规范、需求检查单 | 评审意见记录、问题清单 |
| 接口说明 | 走查、检查单评审 | 接口规范、字段完整性清单 | 走查记录、修订版本 |
| 源代码 | 代码评审、静态分析扫描 | 团队编码规范、工具规则包 | 评审记录、扫描报告 |
| 配置与脚本 | 静态分析扫描、人工核查 | 配置基线规范、脚本检查单 | 扫描报告、核查记录 |
| 数据模型 | 同行评审 | 建模规范、命名与约束清单 | 评审意见、模型修订记录 |
这张对象—方法—规则对照表是本节的核心交付物。填写时注意两点：同一对象可以对应多种方法，需写明主次和先后；规则集裁剪要有书面理由，便于后续复评时判断是否恢复。
制定步骤：从输入到可执行计划的六步
以下六步给出从原始输入到可发布计划的完整路径，每步说明输入、动作、输出与完成标志，可按顺序执行，也可在已有计划上逐项补齐。
第一步：收集输入。输入包括版本计划、需求与设计基线、代码仓库与分支信息。动作是确认本版本的时间窗口、变更范围和基线版本号。输出是一份输入清单。完成标志是每项输入都有明确来源和版本标识，不存在“待定”的关键项。
第二步：确定对象、方法与规则。以第一步的输入为基础，填写对象—方法—规则对照表，逐项确认检查对象、采用的方法和适用的规则集。输出是对照表初稿。完成标志是每类对象至少对应一种方法和一套规则，无空白行。
第三步：估算工作量与排期。根据对象数量和规则规模估算评审与扫描所需人力，安排评审会议时间和扫描窗口，避开版本封版等关键节点。输出是排期表，含活动、责任人、起止时间和依赖关系。完成标志是每项活动都有时间窗口且与版本节奏不冲突。
第四步：定义问题记录与闭环。确定问题记录字段（对象、位置、规则、级别、责任人、状态）、分级标准和闭环责任人。输出是问题记录模板与分级说明。完成标志是字段可填写、级别可判定、每个级别都有对应的处理时限或流程约定。
第五步：设定出口标准与阻断条件。明确静态检查达到什么状态才算完成，例如阻断级问题全部关闭、严重级问题有明确处理计划。输出是出口判据清单。完成标志是判据可客观核对，不依赖主观判断。
第六步：评审计划并发布基线。组织相关角色评审计划本身，确认范围、方法、排期和判据，发布后约定变更方式——哪些调整需重新评审，哪些可由负责人直接更新。输出是基线版计划文档。完成标志是各角色确认无异议，变更规则写入文档。
角色分工与各阶段交付物
计划能否落地，取决于每个环节是否有人负责。测试负责人编制与维护计划、汇总检查结果；开发负责人组织代码评审并推动静态分析问题修复；文档作者提交待评审文档，评审人给出意见并跟踪闭环；质量或架构角色负责规则集裁剪和争议问题裁决；项目经理协调排期并确认出口。角色可以兼任，但职责需在计划中写明，避免出现无人认领的检查项。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 测试负责人 | 编制与维护计划、汇总结果、跟踪出口 | 计划文档、结果汇总、出口结论 |
| 开发负责人 | 组织代码评审、修复静态分析问题 | 评审记录、修复记录、扫描报告确认 |
| 文档作者 | 提交可评审文档、回应评审意见 | 待评审文档、修订版本 |
| 评审人 | 按检查单给出意见、确认闭环 | 评审意见、问题清单 |
| 质量或架构角色 | 规则集裁剪、争议问题裁决 | 规则裁剪说明、裁决记录 |
| 项目经理 | 排期协调、出口确认 | 排期表、出口确认记录 |
各角色的交付物应汇入同一份问题清单和结果汇总，便于出口确认时统一核对。计划条目、评审记录和问题闭环如果分散在多个工具中，容易造成状态不同步；ONES 测试管理支持测试计划与迭代关联、测试计划规划与执行，以及未通过用例快速创建缺陷任务并在测试与研发团队间流转，可作为计划条目和问题闭环的执行载体。具体承载方式需结合团队实际配置确认。
示例：一个版本迭代的静态测试计划片段
以下为演示情景，用于说明计划条目如何写成可执行形式，数值和时间窗口需按团队实际情况设定。
背景设定：某产品 3.2 版本迭代，周期四周，静态检查范围包括本版本新增的需求文档、接口说明、主干分支合并代码和部署配置脚本。
| 对象 | 方法 | 规则 | 责任人 | 时点 | 产出记录 | 出口判据 |
|---|---|---|---|---|---|---|
| 需求文档（新增 5 篇） | 同行评审 | 需求检查单 | 文档作者提交，两名评审人审阅 | 第 1 周周三前 | 评审意见记录 | 阻断级意见全部关闭 |
| 接口说明（变更 8 个） | 走查 | 接口规范清单 | 接口负责人组织，开发与测试参加 | 第 2 周周二 | 走查记录、修订版本 | 字段完整性与错误码一致 |
| 源代码（本迭代合并提交） | 代码评审 + 静态分析扫描 | 编码规范、工具规则包 | 开发负责人组织，扫描由测试负责人执行 | 第 2 周至第 3 周 | 评审记录、扫描报告 | 阻断级问题清零，严重级有处理计划 |
| 部署配置脚本 | 静态分析扫描 + 人工核查 | 配置基线规范 | 运维负责人核查 | 第 3 周周五前 | 核查记录 | 无高危配置项 |
问题分级与阻断示例：静态分析发现的空指针风险、配置中的明文密钥定为阻断级，必须修复后才能进入下一阶段；命名不规范、注释缺失定为一般级，可记录后集中处理。计划变更触发条件示例：需求基线在第 2 周发生重大变更时，重新评估接口说明和代码检查范围；扫描规则包升级时，对已扫描对象安排一次复评。
完成检查：计划可执行性的核对项
计划发布前，用以下清单逐项核对。任一项不满足，说明计划尚不具备执行条件，应补齐后再发布。
- 对象与范围是否完整，且与版本基线一致，每类对象都有具体范围描述。
- 每项检查活动是否写明责任人、时点和产出记录，无空白项。
- 规则集与问题分级是否已确认，并已告知执行人，裁剪与豁免有书面说明。
- 出口标准与阻断条件是否可客观判定，不依赖主观描述。
- 计划变更与复评机制是否写明，包括触发条件和审批方式。
- 记录留存与后续追溯方式是否确定，评审记录、扫描报告和问题清单可查。
核对通过后发布基线版计划，并在版本执行过程中按约定方式维护。计划的价值在于让每项静态检查都有明确的对象、方法、人和判据，执行结果可汇总、可追溯、可复评。
常见问题
静态测试计划与动态测试计划如何衔接，避免重复安排？
在计划的对象与范围部分写明分工：静态检查负责不运行程序即可发现的问题，如需求歧义、设计遗漏、编码规范偏离和配置错误；功能行为、性能表现等由动态测试承担。两类活动在排期上可以前后衔接，例如代码评审和静态分析在提测前完成，动态测试在提测后开始。衔接点应写清准入条件，例如阻断级静态问题清零后才进入动态测试阶段，避免同一问题在两个环节重复记录。
团队规模较小、角色兼任时，静态测试计划的角色分工怎么写？
角色可以兼任，但职责需在计划中逐项写明，避免检查项无人认领。小团队常见的做法是测试负责人同时承担计划编制与结果汇总，开发负责人组织代码评审并推动问题修复，文档作者与评审人由同一批人交叉担任。关键是每项活动都指定具体责任人，而不是只写岗位名称；争议问题的裁决人也要明确，可以由技术负责人或架构角色兼任。计划评审时确认兼任安排不会造成自己评审自己产出、问题无人裁决的情况。
静态分析规则集应该一次全开还是逐步裁剪？
建议按项目阶段和问题承受能力逐步启用。首次引入时先启用与阻断级问题直接相关的规则，例如空指针风险、明文密钥、严重安全配置错误，让团队先建立修复节奏；命名规范、注释缺失等一般级规则可以随后加入或集中处理。裁剪与豁免要有书面理由和批准人，记录在计划中，便于后续复评时判断是否恢复。规则包升级后，对已扫描对象安排一次复评，确认新增规则不会造成大量历史问题积压。
计划执行到一半需求基线发生重大变更，静态测试计划怎么调整？
在计划中预先写明变更触发条件，例如需求基线重大调整、接口范围扩大或规则包升级。触发后重新评估受影响的对象范围，补充新增文档和代码的检查安排，调整排期与责任人，并对已完成的检查判断是否需要复评。调整幅度超出原计划边界时，按约定的变更方式重新评审并发布新基线；小幅调整可由计划负责人直接更新并通知相关角色。变更记录与原因应保留，便于版本结束后回溯计划执行情况。
静态检查发现的问题如何与缺陷跟踪衔接，出口判据怎么定？
问题记录字段应统一，包括对象、位置、规则、级别、责任人和状态，使静态检查问题能与缺陷跟踪使用同一套分级口径。出口判据要可客观核对，例如阻断级问题全部关闭、严重级问题有明确处理计划并指定完成时点、一般级问题已记录并纳入后续迭代。判据不依赖主观描述，出口确认时逐项核对问题清单状态即可。ONES 测试管理支持未通过用例快速创建缺陷任务并在测试与研发团队间流转，可作为问题闭环的执行载体，具体配置需结合团队实际确认。
