安全测试计划要解决的问题，是把“这个版本要保证哪些安全目标”转化为一组可执行、可检查的测试活动。它需要写清被测对象、范围边界、测试类型与深度、负责人和时间窗，以及发现问题后的分级与准出规则。本文按编写顺序给出各章节的填写方法、对照表和检查清单，适合从零起草或修订现有计划时参考。
要点总览（TL;DR）
- 安全测试计划的核心是把安全目标落到可执行活动：被测对象、范围与排除项、测试类型与深度、角色排期、准入准出、交付物六项缺一不可。
- 范围划定从资产清单和暴露面出发，用“资产—威胁—测试点”的轻量对照确定优先级，排除项必须写明理由和替代安排。
- 深度按风险分档：高风险资产做深入测试，中低风险做快速核查，排期与提测、发布候选节点对齐，环境与脱敏数据列为准入条件。
- 缺陷分级综合影响范围、可利用性和数据敏感度，准出条件与例外审批在计划阶段写明，遗留风险书面登记。
- 计划完成后用检查清单核对：目标可验证、每项活动有负责人和时间窗、准出规则明确、记录可追溯。
安全测试计划先定哪几件事
一份可执行的安全测试计划，首先要回答六个问题：测什么、为什么测、测到什么程度、谁来测、什么时候测、什么条件下算通过。这六个问题分别对应被测对象与安全目标、范围与排除项、测试类型与深度、角色分工、排期与环境、准入准出与交付物。计划文档的章节结构可以按这六项展开，每一项都要落到具体条目，避免停留在原则性描述。
被测对象与安全目标的界定是起点。被测对象要具体到系统、模块、接口或版本，例如“订单服务 v2.3 的公网 API 与后台管理端”。安全目标则说明这次测试要验证的保护性质，例如身份认证不可绕过、用户数据在传输与存储中受保护、越权访问被拦截。目标写得越具体，后续的用例设计和准出判定越容易对齐。
范围与不测范围需要同时写明。只写“本次测试登录、支付、权限模块”并不够，还要列出明确排除的部分及理由，例如“第三方支付网关内部实现由供应商负责，本次仅验证回调签名校验”。排除项写清理由，可以避免评审时反复确认，也能在出现争议时提供依据。
测试类型与深度决定投入。常见类型包括认证与授权测试、输入校验与注入类测试、会话与传输安全测试、敏感数据暴露检查、配置与权限核查、依赖组件漏洞核查等。深度可分为快速核查与深入测试两档：前者用于低风险变更或例行发布，后者用于新增核心功能、涉及敏感数据或架构调整的版本。
准入准出与交付物是计划的收口。准入条件说明什么状态下可以开始测试，例如环境就绪、测试账号与数据准备完成、上一轮高危缺陷已关闭。准出条件说明什么状态下允许发布，例如无未关闭的高危缺陷、中危缺陷有明确处置结论。交付物则包括计划本身、测试用例或检查项、执行记录、缺陷清单和测试报告。
| 核心要素 | 必须回答的问题 | 填写产物 |
|---|---|---|
| 被测对象与安全目标 | 测哪个系统或版本，要验证哪些保护性质 | 对象清单、目标条目 |
| 范围与不测范围 | 覆盖哪些模块与接口，排除什么及理由 | 范围表、排除项说明 |
| 测试类型与深度 | 做哪些类型的测试，做到快速核查还是深入测试 | 类型清单、深度档位 |
| 角色与排期 | 谁负责执行、评审、修复，时间窗如何安排 | 职责表、排期表 |
| 准入准出 | 何时开始、何时允许发布、例外如何审批 | 准入准出条件 |
| 交付物 | 每个阶段产出什么记录，如何归档 | 交付物清单 |
从资产与威胁出发划定测试范围
范围划定建议从资产清单出发，而不是从功能菜单出发。资产清单的输入来源通常包括：系统架构图与部署说明、数据分类分级结果、接口清单、第三方依赖清单，以及历史缺陷和安全事件记录。把每个资产标注数据类型（如个人信息、支付信息、内部配置）和暴露面（公网、内网、仅管理端），就能初步判断哪些部分值得投入更深的测试。
威胁分析可以简化处理。完整威胁建模成本较高，日常计划中可采用“资产—威胁—测试点”的轻量做法：针对每类资产，列出可能被利用的弱点类型，再对应到具体测试活动。例如，公网登录接口对应“凭据爆破与认证绕过”，管理后台对应“越权访问与权限提升”，文件上传功能对应“恶意文件与路径处理”。这种对照不追求穷尽，重点是让高风险资产有对应的测试动作。
按风险排序确定优先级时，可综合三个维度：资产敏感度、暴露程度、近期变更幅度。涉及敏感数据且暴露在公网的模块优先；本次版本改动大的模块优先；历史缺陷集中的模块适当加权。排序结果直接决定测试深度和排期先后，也决定资源紧张时哪些项目可以降档而不至于失控。
排除项要写明理由和替代安排。常见排除包括：由供应商完全托管的组件、本次未变更且上轮已充分测试的模块、仅在特定离线环境使用的内部工具。排除不等于不关注，可以在计划中注明“由供应商提供安全声明”“下个版本安排复测”等替代措施，使排除项有据可查。
| 资产 | 数据与暴露面 | 主要威胁 | 对应测试 | 优先级 |
|---|---|---|---|---|
| 公网登录接口 | 账号凭据，公网 | 认证绕过、凭据爆破 | 认证测试、限流核查 | 高 |
| 后台管理端 | 运营数据，内网 | 越权访问、权限提升 | 授权测试、角色矩阵核查 | 高 |
| 文件上传服务 | 用户文件，公网 | 恶意文件、路径处理缺陷 | 输入校验测试 | 中 |
| 报表导出功能 | 聚合业务数据，内网 | 敏感数据超范围导出 | 数据暴露检查 | 中 |
| 第三方支付网关 | 支付信息，外部托管 | 回调伪造 | 仅验证回调签名，内部实现排除 | 低（排除项） |
测试类型、深度与执行窗口怎么排
把范围分析的结果转成排期，需要为每项测试确定类型、深度、环境、时间窗和负责人。测试类型的适用场景不同：认证与授权测试适合所有涉及登录和角色权限的系统；输入校验与注入类测试适合接收外部输入的表单、接口和文件处理；传输与会话安全测试适合公网服务；配置与权限核查适合部署变更频繁的环境；依赖组件漏洞核查适合引入新库或升级框架的版本。
深度档位建议按风险等级划分，而不是按测试类型统一规定。高风险资产采用深入测试：覆盖异常输入、边界条件、权限组合和错误处理路径，必要时安排交叉验证。中低风险资产采用快速核查：按检查项逐条确认已知控制是否生效，记录结果即可。同一版本内可以混合使用两档，把深入测试集中在少数关键对象上。
排期要与迭代节奏或发布窗口衔接。常见做法是把快速核查放在提测后、发布前完成，把深入测试安排在功能开发完成后的稳定期，避免在频繁变更的代码上反复测试。若版本节奏紧张，可把深入测试拆成两轮：第一轮覆盖核心路径，第二轮在发布候选版本上复测高危项。每项活动都要写明开始与结束时间窗，以及结果反馈给谁。
环境与测试数据需要提前准备。环境方面，确认测试环境与生产环境的配置差异，避免因环境差异导致结论失真；涉及权限测试时，需要准备不同角色的测试账号。数据方面，使用脱敏数据或专门构造的测试数据，避免在测试过程中接触真实个人信息。这些准备项应作为准入条件写入计划，未完成则不启动对应测试。
| 测试活动 | 深度 | 环境 | 时间窗 | 负责人 |
|---|---|---|---|---|
| 登录与认证测试 | 深入 | 测试环境，独立账号 | 提测后第 1–3 天 | 安全测试工程师 |
| 后台权限矩阵核查 | 深入 | 测试环境，多角色账号 | 提测后第 2–4 天 | 安全测试工程师 |
| 文件上传输入校验 | 快速核查 | 测试环境 | 提测后第 3 天 | 测试负责人 |
| 依赖组件漏洞核查 | 快速核查 | 构建产物清单 | 发布候选版本构建后 | 开发负责人 |
| 高危项复测 | 深入 | 发布候选环境 | 发布前 2 天 | 安全测试工程师 |
角色分工与各阶段交付物
安全测试涉及的角色通常包括：计划负责人（多为测试负责人或安全负责人）、安全测试执行人、开发负责人、产品负责人和发布审批人。职责边界要在计划中写清，尤其是缺陷判定争议时由谁裁决、例外发布由谁审批。执行人负责按计划完成测试并记录结果；开发负责人负责修复并说明修复方式；产品负责人确认业务影响与处置优先级；审批人对准出和例外做最终决定。
各阶段交付物建议与评审节点绑定。计划阶段产出安全测试计划，经评审确认范围、深度和准出条件；准备阶段产出测试用例或检查项清单、环境与账号准备记录；执行阶段产出执行记录和缺陷清单；收尾阶段产出测试报告与遗留风险说明。评审节点至少包括计划评审和准出评审，前者确认测什么，后者确认能否发布。
缺陷提交与跟踪的交接方式要事先约定。执行人发现问题后，按统一模板提交缺陷，包含复现步骤、影响对象、初步定级和建议处置；缺陷进入研发团队的跟踪流程，修复后回到执行人复测，复测结论记录在同一缺陷条目下。这样每个问题从发现到关闭都有连续记录，便于准出评审时逐条核对。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 计划负责人 | 组织编写计划、协调资源、主持评审 | 安全测试计划、评审记录 |
| 安全测试执行人 | 设计并执行测试、提交缺陷、复测 | 用例或检查项、执行记录、复测结论 |
| 开发负责人 | 修复缺陷、说明修复方式与影响范围 | 修复记录、变更说明 |
| 产品负责人 | 确认业务影响、参与风险接受决策 | 处置优先级确认、风险接受意见 |
| 发布审批人 | 依据准出条件决定发布或例外放行 | 准出结论、例外审批记录 |
当测试活动、缺陷和准出记录需要在同一处流转时，可以把测试计划与迭代关联，用例分配执行人，未通过的用例直接创建缺陷任务，让缺陷在测试与研发团队之间传递。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，并提供测试计划的多维度概览；缺陷可关联至迭代，测试报告可自动生成并支持自定义模板。这些能力适合承载计划中的排期、执行记录与准出材料，具体配置需结合实际版本核验。
缺陷分级、处置与准出判定
缺陷分级建议综合三个维度：影响范围（单用户、部分用户、全量用户）、可利用性（是否需要认证、是否需要特殊条件、是否已有公开利用方式）、数据敏感度（是否涉及个人信息、支付信息或核心配置）。三个维度都高的定为高危，例如未授权即可读取他人订单数据；影响范围有限但涉及敏感数据的定为中危；仅影响内部工具且利用条件苛刻的定为低危。分级标准要写成可对照的条目，减少逐条争论。
处置路径按级别区分。高危缺陷原则上修复后复测通过才允许发布；中危缺陷可以修复后复测，也可以在评估影响后由产品负责人和审批人共同决定是否带风险发布；低危缺陷可纳入后续版本修复，但需登记跟踪。风险接受要有书面记录，写明接受理由、影响范围和后续处理计划，避免口头放行。
准出条件在计划阶段就要写明，通常包括：高危缺陷全部关闭并复测通过；中危缺陷有明确处置结论；测试范围内计划的活动全部执行并有记录；遗留风险已登记并经审批。例外审批要规定审批人和适用情形，例如因外部依赖无法在本次修复时，由谁批准、需要哪些补偿措施。遗留风险记录应包含缺陷描述、当前状态、影响评估、责任人和计划处理时间。
| 级别 | 判定参考 | 处置要求 | 准出影响 |
|---|---|---|---|
| 高危 | 未授权访问敏感数据、认证可绕过、影响全量用户 | 修复并复测通过 | 未关闭则不允许发布 |
| 中危 | 需特定条件利用、影响部分用户或内部数据 | 修复复测或书面风险接受 | 需有明确处置结论 |
| 低危 | 利用条件苛刻、影响有限 | 登记并安排后续版本 | 登记后可发布 |
一份安全测试计划的填写示例
以下示例为演示情景，用于说明各字段如何填写，不代表任何真实系统。假设某内部管理平台发布 v3.2，新增了批量导出和角色自定义功能，计划安排一轮安全测试。
背景与对象栏填写：“被测对象为管理平台 v3.2 的批量导出接口与角色权限配置模块；安全目标为导出操作受权限约束、角色配置不可越权生效、导出文件不包含超出授权范围的数据。”范围栏填写覆盖项与排除项：覆盖导出接口的授权校验、角色配置的权限边界、导出文件的字段范围；排除平台登录模块（上轮已测试且本次未变更），理由为降低重复投入，替代安排为回归时执行快速核查。
类型与排期栏按活动逐行填写：导出接口授权测试定为深入，安排在提测后第 1–2 天；角色权限矩阵核查定为深入，安排在第 2–3 天；导出文件字段范围检查定为快速核查，安排在第 3 天；依赖组件核查安排在发布候选构建后。每行写明环境、账号准备和负责人。
角色与准出栏填写：计划负责人为测试负责人，执行人为安全测试工程师，开发负责人为对应模块开发，审批人为技术负责人。准出条件写为“高危缺陷关闭并复测通过；中危缺陷有处置结论；计划内活动全部执行并记录；遗留风险经审批人确认”。例外审批规则写为“因外部依赖无法本次修复的高危缺陷，需技术负责人与产品负责人共同批准，并附补偿措施”。
该示例的适用边界在于：它假设团队已有基本的安全测试能力和独立测试环境，适用于中等规模版本的功能级安全测试。若系统涉及支付、医疗等强监管场景，范围、分级和准出条件需要按相应合规要求补充，不能直接套用。
计划落地后的完成检查
计划写完后，用以下清单逐项核对，确认它可以被执行和检查。核对时以“能否据此判断做没做、做完没有”为标准，而不是看文档篇幅。
- 被测对象具体到系统、模块或版本，安全目标写成可验证的保护性质，而非“提升安全性”一类表述。
- 范围表列出覆盖模块与接口，排除项附有理由和替代安排。
- 每项测试活动都有类型、深度档位、环境、时间窗和负责人，时间窗与迭代或发布节点对得上。
- 环境与测试数据准备列为准入条件，账号和脱敏数据有明确来源。
- 角色职责表覆盖执行、修复、确认和审批，争议裁决人有名有实。
- 缺陷分级标准可对照，修复、复测、风险接受的路径清晰，例外审批人和适用情形已写明。
- 准出条件可逐条判定，遗留风险有登记字段和责任人。
- 交付物清单覆盖计划、用例或检查项、执行记录、缺陷清单和测试报告，且能追溯到具体版本和评审记录。
核对中发现缺项时，优先补齐影响准出判定的部分，例如分级标准和例外审批规则；范围与排期的细化可以在评审中逐步完善。计划通过评审并随版本执行后，把实际执行中的偏差记录在测试报告中，作为下一版计划调整的依据。
常见问题
安全测试计划需要每个版本都重新写一份吗？
不必每个版本从零起草。可以维护一份基线计划，写明角色职责、缺陷分级标准、准出规则和交付物清单，这些内容相对稳定；每个版本在此基础上更新被测对象、范围与排除项、测试类型与排期。版本变更幅度小时，基线加一份变更说明即可；涉及架构调整、新增敏感数据流程或外部依赖变化时，范围与深度部分需要重新评估，不能直接沿用上一版结论。
团队没有专职安全测试人员，计划怎么安排才可执行？
可以把测试活动按能力要求拆分：认证授权、输入校验等常规检查项由测试团队按检查清单执行；依赖组件漏洞核查、配置核查由开发负责人结合构建产物完成；涉及复杂权限组合或高风险资产的部分，安排外部支持或专项评估。计划中要写清每项活动的执行人和复核人，避免出现“都以为对方在做”的空档。准出评审仍需指定明确的审批人，风险接受由产品负责人和技术负责人共同确认。
测试时间被压缩时，哪些内容可以降档、哪些不能省？
可以降档的是覆盖广度：把部分中低风险资产的深入测试改为快速核查，把非核心模块的测试推到后续版本，但要在计划中记录降档理由和补偿安排。不宜省略的是高危项的验证与复测、准出条件的判定，以及遗留风险的登记。范围缩小后，准出结论要相应说明本次未覆盖的部分及其风险，避免把“没测”当成“没问题”。
发现中危缺陷但业务要求按时发布，应该怎么处理？
按计划中事先写明的处置路径走：由产品负责人评估业务影响，技术负责人确认修复成本与补偿措施，审批人依据准出规则决定是否带风险发布。决定放行时，要形成书面记录，写明缺陷描述、影响范围、补偿措施、责任人和计划修复时间，并纳入遗留风险清单跟踪。若计划中未规定这类情形由谁审批，应先补充规则再决策，避免临时口头放行导致后续无法追溯。
安全测试的执行记录和缺陷如何与研发流程衔接？
常见做法是把测试计划与迭代关联，用例分配执行人，未通过的用例直接创建缺陷任务，让缺陷在测试与研发团队之间流转，修复后回到执行人复测，结论记录在同一缺陷条目下。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务，缺陷可关联至迭代，测试报告支持自动生成与自定义模板；具体配置需结合实际版本核验。这样准出评审时可以按缺陷条目逐条核对，不必在多个文档间比对。
