安全测试计划的核心，是把安全目标拆成可验证的测试项，再明确风险范围、测试层级、执行角色、环境与数据前提、时间窗口和通过标准。本文按“定要素—生成测试项—排期与闭环—角色分工—示例—完成检查”的顺序展开，适用于版本迭代或独立安全测试轮次的计划编制。计划中的测试项、缺陷与证据需要在工作项和文档中流转时，可借助ONES的测试管理与文档协作能力承载。
要点总览（TL;DR）
- 安全测试计划先写清六类要素：目标与通过标准、范围边界、风险分级、测试层级与类型、资源与环境前提、角色与证据要求，缺一项执行时就难判定完成。
- 测试项清单由架构与数据流输入生成：识别关键资产与信任边界，列出威胁场景，映射到测试类型和验证方法，每项带风险等级、负责人和证据要求。
- 排期按风险安排轮次，高风险项进入第一轮；准入看环境、账号、数据、版本冻结四项，准出看高风险项通过与遗留风险书面接受。
- 五类角色各有交付物：安全测试负责人出计划与清单，研发负责人出修复计划，测试执行人出证据与缺陷单，业务负责人出风险接受记录，运维出环境就绪确认。
- 计划完成后用检查清单核对范围覆盖、测试项完整性、准入准出可判定、高风险缺陷闭环和变更记录留存。
安全测试计划先定哪几件事
一份可执行的安全测试计划，先要把六类要素写清楚：目标与通过标准、范围边界、风险分级、测试层级与类型、资源与环境前提、角色与证据要求。缺少任何一类，计划都容易停留在“本版本要做安全测试”的口号层面，执行时无法判定做到什么程度算完成。
安全目标要写成可验证的通过标准。例如“接口鉴权覆盖全部对外接口，越权访问测试项全部通过”比“提升系统安全性”更可判定。通过标准应说明判定方式（测试项通过、缺陷等级与数量、遗留风险接受），并与准出条件对应。
范围要同时写清在范围内和不在范围内的对象。系统、接口、组件、第三方依赖、管理后台、配置与权限模型分别列出；明确排除的部分要写明原因和后续安排，避免测试轮次结束后对覆盖范围产生争议。
风险分级决定测试优先级。可按资产重要性、暴露面、数据敏感度、历史缺陷分布综合定级，高、中、低三档即可操作。测试层级与类型通常包括静态检查、组件与依赖检查、接口与业务安全测试、配置与权限核查，每类对应不同的执行人和证据形式。
资源、环境、数据与时间窗口要提前确认：测试环境是否独立、测试账号与角色如何分配、测试数据是否脱敏、可用的测试时间窗口与回归窗口。角色分工与证据留存要求同步写入，明确谁执行、谁复核、证据存放在哪里。
| 要素 | 填写内容 | 负责人 | 完成标志 |
|---|---|---|---|
| 安全目标与通过标准 | 本版本要达成的安全结果及判定方式 | 安全测试负责人 | 通过标准可逐条判定 |
| 测试范围 | 范围内的系统、接口、组件；明确排除项及原因 | 安全测试负责人与研发负责人 | 范围清单经双方确认 |
| 风险分级 | 高、中、低分级依据与对应测试优先级 | 安全测试负责人 | 每个测试对象有风险等级 |
| 测试层级与类型 | 静态检查、依赖检查、接口与业务安全测试、配置与权限核查 | 测试执行人 | 每类测试有执行人和方法 |
| 资源、环境与数据 | 环境、账号、测试数据、时间窗口 | 运维与环境负责人 | 环境与账号在准入前就绪 |
| 角色与证据要求 | 执行、复核、风险接受人；证据形式与存放位置 | 安全测试负责人 | 证据要求写入测试项 |
从资产与威胁梳理到测试项清单
测试项清单是安全测试计划的主体。它的生成过程是：以架构和数据流为输入，识别关键资产与信任边界，列出威胁场景，再映射到具体测试类型和验证方法，最终输出带风险等级、负责人和证据要求的清单。
输入包括系统架构图、数据流图、账号与权限模型、历史缺陷记录和外部依赖清单。架构与数据流帮助定位信任边界，例如从公网到内网、从普通用户到管理员、从本系统到第三方服务之间的跨越点；权限模型决定越权类测试项的覆盖对象；历史缺陷提示高风险模块；外部依赖决定组件与依赖检查的范围。
动作分三步。第一步识别关键资产：数据、接口、账号体系、配置项、日志与密钥管理。第二步围绕资产列威胁场景，例如未授权访问、越权操作、敏感数据暴露、配置错误、依赖组件已知问题。第三步把场景映射到测试类型和验证方法，例如越权场景映射为接口与业务安全测试，验证方法写明用不同角色账号交叉访问并记录响应。
输出是一张测试项清单，每行至少包含：资产或场景、风险等级、测试类型、验证方法、证据要求、负责人、计划轮次。清单只描述测什么、怎么判定、谁来测，具体攻击技术和脚本编写属于执行环节，不写入计划正文，避免计划篇幅失控且难以评审。
| 资产/场景 | 风险等级 | 测试类型 | 验证方法 | 证据 | 负责人 |
|---|---|---|---|---|---|
| 订单查询接口 | 高 | 接口与业务安全测试 | 用不同用户账号交叉请求，核对返回数据归属 | 请求与响应记录、结论截图 | 测试执行人A |
| 管理后台角色配置 | 高 | 配置与权限核查 | 逐角色核对菜单与操作权限，验证最小权限 | 权限对照表、核查记录 | 测试执行人B |
| 第三方文件解析组件 | 中 | 组件与依赖检查 | 核对组件版本与已知问题清单 | 依赖清单、核查结论 | 研发负责人 |
| 日志中的敏感字段 | 中 | 静态检查 | 抽查日志输出字段，核对脱敏规则 | 抽查样本与规则对照 | 测试执行人A |
控制范围的方法是把清单条目数量与轮次容量对齐：高风险项必须进入本轮，中风险项按容量安排，低风险项可合并抽样。清单评审时由研发负责人确认技术可行性，由业务负责人确认风险优先级，评审通过即作为排期依据。
排期、准入准出与缺陷闭环怎么设计
测试项生成后，要按风险与迭代节奏排入轮次。常见做法是高风险项安排在功能提测后的第一轮，中低风险项安排在回归轮或独立安全轮；每轮预留回归窗口，用于修复后的复测。排期表要写明轮次、起止时间、覆盖的测试项编号和责任人。
准入条件决定一轮测试能否开始：环境可用且与生产配置接近、测试账号与角色就绪、测试数据准备完成、构建版本冻结。准入检查未通过时，测试轮次顺延并通知相关角色，避免在变动版本上执行测试导致结论失效。
准出标准要可判定：高风险测试项全部完成并通过；中风险项的未通过项有修复计划；遗留风险有书面接受人并记录接受理由与期限。准出由安全测试负责人汇总，业务或产品负责人确认上线决策。
缺陷闭环包括分级、修复时限与复测规则。缺陷按风险分级，高危缺陷设定更短的修复时限；修复后由原测试执行人复测，复测证据与初次证据一并留存；复测不通过的缺陷升级处理。计划变更时，例如范围调整或轮次顺延，由安全测试负责人更新排期表并通知研发、测试与业务负责人，变更记录保留在计划文档中。
当测试项、缺陷和证据需要在同一处流转时，ONES可以承载这一过程：测试项作为工作项排入轮次，缺陷从测试执行中提交并关联修复任务，复测结论与证据随状态更新留存，计划文档与排期表在文档中维护，便于评审和追溯。
| 检查点 | 判定内容 | 不满足时的处理 |
|---|---|---|
| 准入 | 环境、账号、数据、版本冻结四项就绪 | 轮次顺延并通知相关角色 |
| 准出 | 高风险项通过；遗留风险有书面接受人 | 不进入上线决策或补充测试 |
| 缺陷复测 | 修复证据齐全，复测通过 | 升级处理并重新排期 |
| 计划变更 | 变更记录与通知留痕 | 更新排期表后重新评审 |
角色分工与交付物
安全测试计划涉及五类角色，职责边界要在计划中写明，避免出现“测试项没人认领、风险没人接受”的情况。
- 安全测试负责人：编制计划、组织资产与威胁梳理、排序风险、汇总结果、发起准出评审。交付物为安全测试计划、测试项清单、轮次排期表和结果汇总。
- 研发负责人：确认测试项技术可行性、安排修复排期、提供修复证据。交付物为修复计划与修复说明。
- 测试执行人：按清单执行测试、留存证据、提交缺陷、完成复测。交付物为执行记录、证据材料和缺陷单。
- 业务或产品负责人：确认风险优先级、接受遗留风险、做出上线决策。交付物为风险接受记录与上线决策结论。
- 运维与环境负责人：提供测试环境、账号、日志与数据支持。交付物为环境就绪确认与账号清单。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 安全测试负责人 | 计划编制、风险排序、结果汇总 | 计划、测试项清单、排期表、结果汇总 | 计划评审前、每轮结束后 |
| 研发负责人 | 可行性确认、修复排期 | 修复计划、修复说明 | 清单评审时、缺陷提交后 |
| 测试执行人 | 执行测试、留存证据、提交缺陷 | 执行记录、证据、缺陷单 | 每轮执行期间与结束时 |
| 业务或产品负责人 | 风险接受、上线决策 | 风险接受记录、决策结论 | 准出评审时 |
| 运维与环境负责人 | 环境、账号、日志与数据支持 | 环境就绪确认、账号清单 | 准入检查前 |
示例：一个版本的安全测试计划片段
以下为演示情景，用于说明计划如何填写，不代表任何真实项目数据。
背景假设：某内部管理系统本版本新增订单导出功能，涉及对外接口和管理后台权限调整。范围包括导出接口、后台角色配置和新增的第三方文件组件；不包含历史模块的全面复测，原因是不在本版本变更范围内。
测试项清单片段：导出接口的越权访问列为高风险，测试类型为接口与业务安全测试，验证方法为用不同角色账号请求导出并核对数据范围，证据为请求响应记录，负责人为测试执行人A，安排在第一轮。后台角色配置列为高风险，测试类型为配置与权限核查，验证方法为逐角色核对导出权限，证据为权限对照表，负责人为测试执行人B，安排在第一轮。第三方文件组件列为中风险，测试类型为组件与依赖检查，验证方法为核对版本与已知问题清单，证据为依赖清单，负责人为研发负责人，安排在回归轮。
排期与准入准出片段：第一轮在提测后第2个工作日开始，准入条件为测试环境就绪、三个角色账号可用、导出测试数据准备完成、构建版本冻结。准出标准为两个高风险测试项通过，中风险项若未通过需有修复计划，遗留风险由产品负责人书面接受。
缺陷闭环片段：越权问题若发现，按高危缺陷处理，修复后由测试执行人A复测并留存前后对比证据；复测通过后更新测试项状态，结果汇总进入准出评审。这个片段体现了输入（架构与权限模型）、动作（梳理场景、执行测试）、输出（清单、排期、缺陷记录）和完成标志（准出评审通过）。
计划落地后的完成检查
计划编制完成或一轮测试结束后，用以下清单逐项核对，判断计划是否完整、可执行并已闭环。
- 范围与风险分级覆盖了关键资产、对外接口和权限模型，排除项有书面说明。
- 每个测试项都有负责人、测试类型、验证方法和证据要求，没有空白项。
- 准入与准出标准明确且可判定，准出评审有结论记录。
- 高风险缺陷已修复并复测通过，或遗留风险有书面接受人和接受期限。
- 计划变更、轮次顺延和复测记录均已留存，相关角色已收到通知。
- 测试证据按测试项归档，能够支撑准出结论和后续追溯。
核对中发现缺项时，回到对应章节补齐：范围问题回到要素表修订，测试项缺失回到清单补充，闭环问题检查缺陷状态与风险接受记录。完成检查通过后，计划即可作为下一轮次的模板复用。
常见问题
小团队没有专职安全测试人员，安全测试计划还能执行吗？
可以执行，但角色需要合并并写清边界。常见做法是由测试负责人兼任安全测试负责人，负责编制计划、排序风险和汇总结果；研发负责人承担组件与依赖检查、修复排期；业务负责人保留风险接受和上线决策。角色合并时，计划中仍要逐项写明谁执行、谁复核、谁接受风险，避免同一人既执行又接受遗留风险而失去制衡。测试项范围也可先聚焦高风险资产和对外接口，中低风险项按轮次容量抽样安排。
安全测试计划需要每个版本都重做一遍吗？
不必从零重做，可以复用上一版计划作为模板，再按本版本变更调整。调整重点是范围：新增或变更的接口、组件、权限配置进入清单，未变更模块可沿用历史结论并注明依据。风险分级和准入准出标准通常保持稳定，测试项清单和排期表按版本更新。复用时要检查历史遗留风险是否已关闭，未关闭的项继续带入本轮或明确接受期限，避免旧问题在模板复用中被遗漏。
测试环境与生产环境配置不一致时，安全测试结论还有效吗？
有效性会打折扣，需要在计划中说明差异及影响。配置与权限核查类测试项对环境的依赖较强，环境差异可能导致结论无法直接迁移到生产。可行做法是：准入检查时记录环境与生产的已知差异；对受差异影响的测试项标注结论适用范围；上线前在生产配置的预发环境补充关键项复核。若差异过大，应把环境整改列为准入条件，而不是带着已知偏差执行并直接用于准出判定。
遗留风险由谁接受，接受记录要写哪些内容？
遗留风险通常由业务或产品负责人接受，因为其承担上线后的业务后果；安全测试负责人提供风险描述和影响判断，研发负责人提供修复成本与替代方案。接受记录至少写明：风险内容与影响范围、未修复原因、接受人、接受期限、补偿措施（如监控、访问限制）和复审时点。接受记录要随准出结论一并留存，期限到期后重新评估，不能一次接受长期有效。
计划执行中途范围变更，排期和测试项怎么处理？
由安全测试负责人发起变更：先评估新增或删减对象对风险排序的影响，更新测试项清单；再调整轮次排期，确认新增高风险项能否进入当前轮，不能进入的说明顺延安排；最后通知研发、测试和业务负责人，变更记录保留在计划文档中。若变更影响准出标准，例如新增高风险项未完成，准出评审需重新进行。变更频繁时，可在计划中预设变更窗口，减少对执行轮次的反复打断。
