制定安全测试计划，核心是把“测什么、测到什么程度、谁来做、何时做、结果怎么处理”写成可执行、可验收的安排。先界定被测系统与风险范围，再确定测试类型与深度、时间窗口与准入条件，随后落实角色分工、环境与数据准备、缺陷处置与回归规则，最后用交付物和完成标志收口。本文按编制顺序给出步骤、角色交付物、填写示例与完成检查清单，适用于版本迭代中的安全测试规划，不展开具体攻击技术与源码审计方法。
要点总览（TL;DR）
- 安全测试计划先定五件事：被测对象与边界、风险范围与测试类型、时间窗口与准入条件、角色与责任、结果处置规则。
- 编制按五步推进：收集资产与合规要求、风险分级定范围、排定测试类型与环境数据、设定准入准出与缺陷规则、评审并基线化。
- 角色分工要落到人：安全测试负责人牵头，开发、运维、业务方与项目管理角色各有交付物，交接点明确接收人。
- 计划落地靠工作项承载：测试项关联需求与版本，缺陷按状态流转，按风险等级统计未关闭缺陷判断上线风险。
- 定稿前用完成检查清单核对范围、角色、准入准出、时间依赖、变更回归与结果汇总六项。
安全测试计划先定哪几件事
安全测试计划的第一版不需要写得很厚，但必须先把五件事定下来，否则后续步骤会反复返工。这五件事构成计划的骨架，也是评审时最先被追问的内容。
- 被测对象与边界：明确系统名称、版本号、部署形态、对外暴露的入口，以及本次不测的部分（如第三方托管服务、已下线模块）。边界写清楚，测试范围才不会在执行中被随意扩大或遗漏。
- 风险范围与测试类型：按业务重要性和暴露面做初步分级，据此选择测试类型。常见组合包括漏洞扫描、渗透测试、权限与越权核查、配置基线核查、依赖组件与接口安全检查。高风险模块安排深度测试，低风险模块以扫描和配置核查为主。
- 时间窗口与准入条件：确定测试在哪个阶段介入（提测后、上线前、变更后），以及进入测试的前置条件，例如版本已冻结、环境可访问、测试账号与数据就绪。
- 角色与责任：指定安全测试负责人，明确开发、运维、业务方各自配合的事项，避免出现“计划有人写、问题没人改”的情况。
- 结果处置规则：提前约定缺陷分级标准、修复时限、回归方式，以及哪些级别的问题构成上线阻断条件。
计划颗粒度随项目阶段调整。立项或架构设计阶段，计划可以只覆盖威胁识别与测试策略；进入提测阶段，需要细化到测试项、执行人和时间点；上线前的回归阶段，则聚焦缺陷验证与放行判断。同一套模板在不同阶段填写深度不同，比一次性写全更实用。
按步骤编制安全测试计划
把计划拆成五步，每步都有明确输入、动作、输出和完成标志。按顺序推进，前一步的输出就是后一步的输入，可以减少遗漏。
步骤一：收集资产、架构与合规要求
输入包括系统架构图、资产清单、数据分类分级说明、接口文档，以及适用的合规要求（如行业监管规定、等保要求、内部安全基线）。动作是梳理对外服务、数据存储位置、第三方依赖和信任边界，标注哪些资产承载敏感数据。输出是一份资产与边界清单。完成标志是清单经系统负责人确认，边界无争议。
步骤二：风险分级并确定范围与优先级
输入是上一步的资产清单和业务影响说明。动作是按“资产重要性 × 暴露程度 × 历史问题”做分级，把系统划分为高、中、低三档，并为每档匹配测试深度。输出是风险分级表与测试范围说明。完成标志是每个被测模块都有明确的风险等级和对应的测试类型，且范围外事项有书面说明。
步骤三：排定测试类型、工具类别、环境与数据
输入是风险分级结果和可用资源。动作是列出每类测试的执行方式（人工核查、工具扫描、渗透验证）、所需工具类别、测试环境地址与网络策略、测试账号与脱敏数据集。输出是测试项清单与环境准备清单。完成标志是环境可访问、账号可用、数据脱敏方案已确认，测试项与风险等级一一对应。
步骤四：设定准入准出、缺陷分级与回归规则
输入是测试项清单和团队对质量的要求。动作是写明进入测试的条件（版本冻结、冒烟通过、环境就绪），退出测试的条件（高危问题清零或已批准延期、回归通过率达标），并定义缺陷分级标准与各级修复时限。输出是准入准出条件表与缺陷处置规则。完成标志是规则经开发与业务方共同确认，无歧义条款。
步骤五：评审并基线化计划
输入是前四步的全部产物。动作是组织评审，记录评审意见与处理结论，修订后形成基线版本，并约定变更方式：范围、时间或测试深度发生变化时，由谁提出、谁审批、如何记录。输出是基线化的计划文档与变更记录规则。完成标志是评审通过、责任人签字确认、变更路径明确。
角色分工与各角色交付物
安全测试计划涉及多个角色，职责边界不清是计划落空的主要原因。下表按编制、执行、缺陷处置与验收四个环节列出职责与交付物，具体岗位名称可按团队实际调整。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 安全测试负责人 | 牵头编制计划、组织评审、跟踪执行进度、汇总结果 | 安全测试计划、测试项清单、测试报告与放行建议 |
| 开发负责人 | 提供架构与接口信息、确认修复方案、安排修复排期 | 架构说明、缺陷修复记录、修复自验说明 |
| 运维/环境负责人 | 提供测试环境、网络策略、账号与日志访问 | 环境就绪确认、账号清单、访问记录 |
| 业务方 | 确认业务影响与风险接受度、参与上线放行判断 | 风险接受记录、放行意见 |
| 项目管理角色 | 协调排期、跟踪里程碑、管理变更 | 排期表、变更记录、进度报告 |
评审与审批环节通常由安全测试负责人组织，开发负责人和业务方共同参与；涉及合规要求时，需合规或安全管理部门确认。跨团队协作的交接点集中在三处：环境与账号移交、缺陷提交与修复确认、回归验证与放行签字。每个交接点都应有明确的接收人和完成标志，避免任务停在“已通知”状态。
一份安全测试计划示例
以下为演示情景，用于说明字段如何填写，实际项目需按自身情况调整。
背景假设：某内部管理系统发布 2.3 版本，新增对外接口与角色权限调整，计划在提测后第二周执行安全测试，上线前完成回归。
| 计划字段 | 填写示例 |
|---|---|
| 测试范围 | 新增的 5 个对外接口、角色权限模块、登录与会话管理；不含已下线的报表导出模块 |
| 风险分级 | 接口与权限模块为高风险，登录会话为中风险，其余改动为低风险 |
| 测试类型 | 高风险：渗透测试与越权核查；中风险：漏洞扫描与配置核查；低风险：依赖组件扫描 |
| 时间窗口 | 提测后第 2 周执行，第 3 周完成修复回归，上线前 2 天出具放行建议 |
| 准入条件 | 版本冻结、冒烟用例通过、测试环境与脱敏数据就绪 |
| 准出条件 | 高危与中危问题全部修复并回归通过，低危问题有明确处理计划 |
| 缺陷分级 | 高危：可导致越权或敏感数据泄露，24 小时内响应；中危：7 个工作日内修复；低危：纳入下个迭代 |
| 回归安排 | 修复后由原测试执行人验证，高危问题需双人复核 |
示例的适用边界在于：它假设团队已有基本的环境与账号管理能力，且业务方能够参与放行判断。若项目处于早期架构阶段，测试类型应前移到威胁识别与设计核查；若涉及强合规要求，需补充合规条款对照与证据留存安排。缺陷分级的具体时限也应按团队响应能力设定，不宜直接照搬。
计划落地中的协作与跟踪
计划评审通过后，真正的难点是让测试项、缺陷和验收结论在团队之间持续流转。建议把计划中的每个测试项拆成可分配的工作项，关联到对应的需求与版本，使“计划里写了什么”和“实际执行到哪一步”能对上。
状态流转需要留下记录：测试项从待执行到执行中、已完成，缺陷从提交到修复、验证关闭，每个状态变化都应有责任人和时间点。评审与交接环节同样要留痕，例如环境移交确认、修复自验说明、放行意见，这些记录在复盘和合规检查时都是依据。进度与风险的可见性来自两处：测试项完成情况与缺陷分布。按风险等级统计未关闭缺陷，比只看总数更能反映上线风险。
ONES 测试管理可在这一环节承载上述动作：测试计划与迭代关联，测试用例与需求、任务关联，形成测试流程闭环；支持多维度概览测试计划并查看进度，将用例分配执行人；未通过的用例可快速创建缺陷任务，缺陷在测试与研发团队间流转，并可关联至迭代；同时支持自动生成测试报告与项目缺陷分布统计，便于汇总放行判断所需的信息。涉及多角色协作时，还可为不同用户组及用例库、测试计划单独配置权限。具体配置以产品实际能力为准；安全测试专项模板等能力，建议在选型或启用前向厂商核验。
完成检查：计划是否可执行
计划定稿前，用以下清单逐项核对。每一项都应能给出明确答案，答不上来的条目就是需要补的地方。
- 范围与风险对应：每个被测模块都有风险等级，每个风险等级都对应了测试类型和深度，范围外事项有书面说明。
- 角色落实到人：测试负责人、开发对接人、环境负责人、业务确认人都有具体姓名，各角色的交付物已列明。
- 准入准出明确：进入测试和退出测试的条件可判断，缺陷分级标准与修复时限无歧义，上线阻断条件已约定。
- 时间与依赖可行：测试窗口与版本排期不冲突，环境、账号、数据在计划开始前可就绪，外部依赖有备选方案。
- 变更与回归具备：范围或时间变化时有提出与审批路径，回归执行人、验证方式和复核要求已写明。
- 结果可汇总：测试项完成情况与缺陷分布能够按风险等级统计，放行建议有数据支撑。
清单全部通过，计划即达到可执行、可验收的程度；仍有空缺的条目，应在评审前补齐或明确标注为待确认事项，并指定跟进人。
常见问题
项目处于架构设计阶段，安全测试计划要写到多细？
早期阶段的计划可以只覆盖威胁识别与测试策略，重点写清系统边界、信任边界和需要重点关注的数据资产，测试类型以设计核查和威胁分析为主。进入提测阶段后再细化到测试项、执行人和时间点，上线前回归阶段聚焦缺陷验证与放行判断。同一套模板在不同阶段填写深度不同，比一次性写全更实用，也能避免早期计划因信息不足而反复返工。
安全测试发现的高危问题来不及修复，计划里应该怎么处理？
在计划阶段就应约定例外路径：高危问题无法在窗口内修复时，由谁提出延期申请、谁审批、需要哪些补偿措施（如临时访问限制、监控加强），以及风险接受记录由谁签署。业务方参与放行判断，安全测试负责人给出放行建议。例外处理结论要写入测试报告，作为上线决策和后续复盘的依据，避免问题在口头沟通中被默认放过。
测试环境或账号在计划开始时没有就绪，会带来什么影响？
环境与账号是准入条件的一部分，未就绪会直接压缩测试窗口，导致深度测试被降级为扫描。计划中应把环境移交列为独立交接点，明确运维或环境负责人的交付物和确认时间，并准备备选方案，例如使用预发环境或缩小测试范围。若环境延迟，应由项目管理角色评估是否调整排期或测试深度，并记录变更，避免执行阶段临时压缩造成覆盖不足。
安全测试的缺陷和普通功能缺陷要分开管理吗？
可以放在同一缺陷流程中管理，但需要按风险等级区分处置规则。计划中定义高危、中危、低危的判定标准和修复时限，高危问题设置更短的响应时间并要求双人复核回归。分开或合并取决于团队习惯，关键是统计口径一致：按风险等级统计未关闭缺陷，比只看缺陷总数更能反映上线风险。使用 ONES 测试管理时，未通过的用例可快速创建缺陷任务，缺陷在测试与研发团队间流转并可关联至迭代。
计划评审通过后，范围发生变化怎么办？
计划基线化时就应约定变更方式：范围、时间或测试深度变化由谁提出、谁审批、如何记录。常见做法是由安全测试负责人评估影响，项目管理角色协调排期，开发负责人和业务方确认，变更结论更新到计划版本并留痕。变更后要同步检查准入准出条件和回归安排是否仍然成立，避免范围扩大而测试深度和资源没有相应调整。
