安全测试计划的价值在于把安全目标变成可执行、可验收的测试安排。编制时先依据业务场景和资产重要性确定目标与范围，再识别威胁、评估风险并排出优先级，据此选择测试类型与深度，明确环境、数据、工具和人员分工，最后落实准入准出、缺陷处置与证据留存。计划中每项活动都应写明输入、负责人、输出和完成标志，需求或架构变化时同步更新。
要点总览（TL;DR）
- 安全测试计划从业务场景和资产重要性出发，先确定目标与范围边界，再识别威胁、评估影响与可能性并排出优先级。
- 按风险配置测试类型与深度：高风险项全量验证并多轮回归，中风险重点覆盖，低风险抽样或静态检查。
- 计划表每项活动写明输入、负责人、输出和可核验的完成标志，环境、数据与授权提前落实。
- 角色职责覆盖业务、研发、测试、安全、运维，缺陷定级、修复确认、复测和例外审批路径在计划阶段约定。
- 执行中按准入准出条件跟踪，证据按版本归档，需求、架构或高风险场景变化时更新计划并记录变更。
先定目标与范围：安全测试计划要回答哪些问题
安全测试计划的起点是回答“为什么测、测什么、测到什么边界”。目标来自业务场景和资产重要性：涉及资金交易、身份认证、个人敏感信息的模块，安全目标应包含防越权、防数据泄露和操作可追溯；内部使用的低敏感工具，目标可以聚焦访问控制和依赖组件风险。目标写得越具体，后续测试类型和验收口径越容易对齐。
范围划分建议按四个维度列出清单：系统与模块、对外接口与集成点、数据对象与流转路径、第三方组件与服务。每个维度标注“纳入”或“不纳入”，并写明理由。例如本次迭代新增的支付回调接口纳入接口安全测试，历史遗留的后台管理模块本轮不纳入，待下轮专项安排。范围边界清单的作用是防止执行阶段临时扩大或遗漏。
计划中还需明确不纳入的内容，例如具体攻击脚本的编写、源码审计的逐行检查方法、渗透测试的技术操作细节。这些属于执行技术范畴，计划层面只需说明是否安排对应活动及其验收标准。目标与范围说明通常由产品负责人提出业务背景，测试负责人整理成文，安全负责人确认风险覆盖是否充分，在需求评审或迭代规划会上完成确认并形成基线。
识别风险并排优先级：威胁与资产如何对应
风险清单是把资产、威胁和影响对应起来的表。先做资产梳理与数据分级：列出系统模块、接口、数据表、账号权限和第三方依赖，按敏感程度分为高、中、低三档。高敏感资产包括身份凭证、支付信息、个人隐私数据和核心业务配置。
威胁来源可按滥用场景列举：未授权访问、越权操作、参数篡改、重放攻击、敏感信息泄露、依赖组件已知漏洞、异常高频调用等。列举时结合业务动作，例如“普通用户能否通过修改请求参数查看他人订单”比笼统写“越权风险”更容易转化为测试项。
影响与可能性采用统一口径评估。影响看数据泄露范围、资金损失、业务中断时长和合规后果；可能性看暴露面、攻击门槛和已有防护措施。两项各分高、中、低，组合后形成优先级：高影响且高可能性的项排在最前，低影响且低可能性的项可安排抽样验证或静态检查。
| 资产 | 敏感级别 | 威胁场景 | 影响 | 可能性 | 测试优先级 |
|---|---|---|---|---|---|
| 用户登录接口 | 高 | 撞库、弱口令、会话固定 | 高 | 高 | P0 |
| 订单查询接口 | 高 | 越权查看他人订单 | 高 | 中 | P0 |
| 文件上传功能 | 中 | 恶意文件上传、类型绕过 | 中 | 中 | P1 |
| 日志查询页面 | 低 | 信息泄露 | 低 | 低 | P2 |
风险清单到测试优先级的映射应保留评估依据，便于评审时复核。优先级数量建议控制在三档，避免分档过细导致执行时难以取舍。风险清单由测试负责人牵头整理，研发提供接口与依赖信息，安全负责人校准威胁场景，产品负责人确认业务影响判断。
选择测试类型与深度：按风险配置测试活动
测试类型的选择依据是风险项的性质。静态检查适合在编码阶段发现硬编码密钥、危险函数调用等问题，成本低、可提前介入；依赖与组件检查适合识别第三方库的已知漏洞和许可证风险，应在每次依赖变更后执行；接口与业务逻辑安全测试适合验证参数校验、流程绕过和异常输入处理；权限与越权验证适合多角色系统，重点检查横向和纵向权限边界。
测试层级分为组件级、接口级、系统级和验收级。组件级关注单个服务或库的安全配置；接口级关注服务间调用与对外暴露的接口；系统级关注端到端业务流程中的安全控制；验收级由业务方确认高风险场景的防护效果。轮次安排上，高风险项在开发自测、测试环境验证和上线前回归中各覆盖一次；中风险项至少在测试环境验证一次；低风险项可合并到版本回归中抽样执行。
深度取舍遵循“高风险全量、中风险重点覆盖、低风险抽样”的原则。全量验证适用于权限矩阵、支付流程和身份认证；抽样适用于日志脱敏、错误提示信息等影响面较小的项。回归范围根据变更影响分析确定：涉及权限模型或公共组件的变更，回归范围应扩大到所有依赖模块；局部功能调整可只回归相关接口。
安全测试与功能测试、性能测试存在衔接点。功能测试用例中的异常输入和边界值可作为安全测试的输入；性能测试中的高频请求场景可同步观察限流和防重放机制是否生效。计划中应标注这些衔接点，避免重复执行或遗漏交叉场景。
编制计划表：输入、动作、输出与完成标志
计划表是安全测试计划的执行载体。每行对应一项测试活动，字段至少包括：活动名称、测试目标、覆盖范围、环境、测试数据、负责人、时间窗、输出物和完成标志。完成标志要可核验，例如“权限矩阵全部角色验证完毕，越权用例通过率100%，未通过项已建缺陷并定级”，而不是“完成权限测试”。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 活动 | 具体测试动作 | 订单查询接口越权验证 |
| 目标 | 对应风险项 | 验证普通用户无法查看他人订单 |
| 范围 | 接口、角色、数据 | 订单查询接口，普通用户与客服角色 |
| 环境 | 环境名称与配置 | 测试环境，含两套角色账号 |
| 数据 | 数据来源与脱敏要求 | 脱敏订单数据，禁止使用生产个人信息 |
| 负责人 | 执行人与复核人 | 测试工程师执行，安全负责人复核 |
| 时间窗 | 开始与截止时间 | 迭代第3天至第5天 |
| 输出 | 记录与报告 | 测试记录、缺陷单、验证结论 |
| 完成标志 | 可核验的通过条件 | 越权用例全部执行，未通过项已修复并复测 |
环境与测试数据准备需要提前落实授权。使用测试环境时确认配置与生产环境的关键安全设置一致；使用脱敏数据时明确脱敏规则和责任人；涉及第三方接口联调时取得对方许可。工具与人员能力同样列入准备事项：静态检查工具、依赖扫描工具、接口测试工具的可用性和版本，执行人员是否具备相应测试经验，必要时安排培训或结对执行。
计划表编制完成后组织评审，参与方包括产品、研发、测试、安全和运维。评审重点是目标与风险是否对应、活动是否有明确完成标志、资源和时间窗是否可行。评审通过后形成基线，后续变更走记录流程。
角色与交付物分工：谁定目标、谁执行、谁验收
安全测试计划涉及多个角色，职责需要在计划阶段写清。业务或产品负责人确定业务场景和安全目标，提供资产重要性判断，交付目标与范围说明中的业务部分。研发负责人提供架构、接口和依赖信息，负责修复缺陷并交付修复说明。测试负责人编制计划表、组织执行、汇总结果，交付风险清单、计划表和测试报告。安全负责人提供威胁场景和评估口径，复核高风险项结论，交付风险评审意见。运维负责人保障环境与数据准备，交付环境配置说明和访问授权记录。
| 角色 | 主要职责 | 输入 | 输出交付物 |
|---|---|---|---|
| 业务/产品 | 确定业务场景与安全目标 | 需求文档、业务影响说明 | 目标与范围说明（业务部分） |
| 研发 | 提供技术信息、修复缺陷 | 架构与接口文档 | 修复说明、变更记录 |
| 测试 | 编制计划、组织执行、汇总结果 | 风险清单、测试环境 | 计划表、测试记录、测试报告 |
| 安全 | 校准威胁与评估口径、复核结论 | 风险清单、测试结果 | 风险评审意见、复核结论 |
| 运维 | 准备环境与数据、管理访问授权 | 环境需求、数据需求 | 环境配置说明、授权记录 |
缺陷定级由测试提出初步判断，安全负责人对高风险缺陷进行确认，研发负责人认可修复方案。修复确认由研发提交修复说明，测试执行复测，安全负责人对高风险项复测结论签字确认。例外审批路径需要提前约定：因时间或资源原因无法在本轮执行的测试项，由测试负责人提出申请，安全负责人评估残余风险，产品负责人确认是否接受，记录在计划变更中。
示例：一个迭代内安全测试计划的编排
以下为演示情景：某电商系统一个两周迭代，新增优惠券领取与核销功能，涉及用户端接口和运营后台配置。目标是验证优惠券领取的防刷机制、核销权限控制和配置操作的越权防护。范围包括领取接口、核销接口、后台配置页面和相关的用户身份校验；不纳入历史订单模块和第三方支付通道的内部实现。
风险清单示例：领取接口被脚本高频刷取（影响高、可能性高，P0）；普通运营账号修改他人配置（影响高、可能性中，P0）；核销接口参数篡改导致重复核销（影响中、可能性中，P1）；错误提示泄露内部字段名（影响低、可能性低，P2）。
测试类型与轮次安排：P0项安排接口安全测试和权限越权验证，在开发自测和测试环境各执行一轮，上线前回归一次；P1项在测试环境执行接口测试并做抽样回归；P2项合并到版本回归中抽样检查。静态检查和依赖组件检查在提测前完成。
计划表填写示例：活动“领取接口防刷验证”，目标“验证同一账号和同一设备在限定时间内无法超额领取”，范围“领取接口、用户端”，环境“测试环境”，数据“脱敏测试账号10个”，负责人“测试工程师A执行、安全负责人B复核”，时间窗“迭代第3至4天”，输出“测试记录与缺陷单”，完成标志“限流规则生效，超额请求被拒绝并记录日志，未通过项已修复复测”。角色分工按上一节矩阵执行，产品负责人确认防刷规则阈值，研发提供限流实现说明。
执行跟踪与计划更新：准入准出与证据留存
准入条件在测试活动开始前核对：环境可用且配置符合要求、测试数据准备完毕、账号权限开通、被测版本已提测且冒烟通过、相关接口文档更新。准出条件在活动结束时核对：计划内活动全部执行、完成标志逐项确认、未通过项已建缺陷并定级、高风险缺陷已修复并复测通过、测试记录和报告已归档。
执行进度按计划表逐项跟踪，阻塞项记录原因和影响范围，例如环境不可用、依赖接口未就绪、测试数据未脱敏。阻塞超过约定时限时按升级路径处理，由测试负责人协调资源或调整时间窗，调整结果记入计划变更。
缺陷处置遵循定级、修复、验证、复测的闭环。高风险缺陷修复后必须复测并保留记录；中低风险缺陷可与研发协商修复时间，但需在准出时说明残余风险。证据留存包括测试记录、缺陷单、复测结论、风险评审意见和环境授权记录，按版本归档，便于后续审计和复盘。
计划变更的触发条件包括需求范围调整、架构或依赖变更、发现新的高风险场景、环境或资源发生重大变化。变更时更新计划表版本，记录变更原因、影响范围和确认人，保持计划与实际执行一致。
当计划表、测试记录和缺陷需要在同一处流转时，可以借助研发管理工具承载。ONES 测试管理支持测试计划与迭代关联，测试用例与需求、任务关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转；测试计划支持多维度概览和进度查看，测试报告可自定义模板。将安全测试活动作为计划中的条目管理，把完成标志和证据挂在对应记录上，评审和复测时可以直接追溯。具体功能范围以实际产品配置为准。
完成检查：安全测试计划是否可执行的核对项
计划定稿前逐项核对以下清单，全部满足才进入执行。
- 目标与范围：每个安全目标都能对应到具体业务场景或资产；范围清单覆盖系统、接口、数据和第三方组件；不纳入的内容有明确说明。
- 风险与优先级：风险清单包含资产、威胁、影响和可能性；优先级有评估口径和复核记录；高风险项均有对应测试活动。
- 测试类型与深度：每类测试的选择有风险依据；层级和轮次安排明确；全量与抽样的取舍有说明；与功能测试、性能测试的衔接点已标注。
- 计划表字段：每项活动都有输入、负责人、输出和完成标志；完成标志可核验；时间窗与迭代节奏匹配。
- 环境、数据与授权：环境配置确认完毕；测试数据脱敏规则明确；第三方联调授权已取得；工具和人员能力满足执行要求。
- 角色与交付物：各角色职责无悬空；缺陷定级、修复确认和复测责任已划分；例外审批路径已约定。
- 准出与证据：准入准出条件逐条可核对；证据留存范围和归档方式明确；计划变更触发条件和记录规则已写入。
清单核对由测试负责人组织，安全负责人复核风险覆盖部分，产品负责人确认目标与业务一致性。核对中发现缺口时回到对应章节补充，补齐后重新确认基线。
常见问题
迭代周期很短，安全测试计划可以简化到什么程度？
周期短时可以减少文档篇幅，保留四项核心内容：本次迭代的安全目标与范围边界、按优先级排序的风险清单、每项测试活动的负责人和完成标志、准出条件。测试类型可以聚焦高风险项，低风险项合并到版本回归中抽样执行。计划表仍要逐项填写，避免只写活动名称而没有验收口径，否则执行阶段难以判断是否完成。
安全测试发现的高风险缺陷在发布前无法修复，应该怎么处理？
按计划中约定的例外审批路径处理：由测试负责人提出申请，安全负责人评估残余风险和可能的缓解措施，产品负责人确认是否接受并在计划变更中记录。可选的缓解措施包括限制功能入口、增加监控告警、缩短会话有效期等。记录中写明缺陷内容、影响范围、接受人和后续修复时间，便于复盘和审计时追溯。
安全测试计划与功能测试计划如何避免重复执行？
在计划阶段标注衔接点：功能测试用例中的异常输入、边界值和权限场景可作为安全测试的输入，安全测试结论也可反哺功能用例补充。计划表中注明哪些活动与功能测试共用环境、数据和执行时间窗，哪些需要独立安排。涉及权限模型或公共组件的变更，功能回归与安全回归的范围应同步扩大，避免各自按局部范围执行而遗漏交叉场景。
没有专职安全人员时，威胁场景和风险优先级由谁评估？
可以由测试负责人牵头组织评估，研发提供架构、接口和依赖信息，产品负责人确认业务影响判断。评估时使用统一口径：影响看数据泄露范围、资金损失和业务中断时长，可能性看暴露面、攻击门槛和已有防护。对高风险项结论把握不足时，可引入外部安全服务做专项评审。职责划分写入计划，评估依据保留在风险清单中，便于后续复核。
安全测试计划在工具中承载时，需要关注哪些管理动作？
关注三个动作：计划条目与迭代关联，便于按版本查看执行进度；未通过的用例能直接转为缺陷任务并在测试与研发之间流转；测试记录、缺陷单和复测结论按版本归档。ONES 测试管理支持测试计划与迭代关联、用例与需求任务关联，未通过用例可创建缺陷任务，测试报告支持自定义模板，可作为承载方式之一。具体功能范围以实际产品配置为准。
