安全测试计划里最容易在评审时被退回的两块内容，往往是依赖约束和退出准则：前者写得太笼统，执行时才发现环境、数据、审批没到位；后者写得太模糊，测试做完了却没人能判断能否结束。本文给出一套可直接复制的表格模板，用四张表把资产范围、风险分级、依赖约束和退出准则串起来，并说明每个字段怎么填、哪些不能空、风险等级如何影响退出严格程度，以及项目推进中如何更新维护。
要点总览（TL;DR）
- 模板用四张表串起计划：资产范围表、风险分级表、依赖与约束清单、退出准则表，按顺序填写即可。
- 依赖与约束清单逐条登记依赖对象、提供方、需要时间、约束类型、影响范围、应对措施和责任人，约束类型固定为环境、数据、人员、外部系统、审批、时间窗口六类。
- 退出准则表按测试项列出通过条件、证据、判定人和未达标处置，通过条件写成可判定的表述，证据与条件逐条对应。
- 风险等级决定退出严格程度：高风险测试项要求高危问题修复并复测、双人判定；中风险可放宽为高危修复、中危登记跟踪。
- 必填字段缺失有阻断规则：资产范围或风险分级缺必填不进评审，依赖缺必填不排执行，退出准则缺必填不得判定退出。
可复制空白模板：资产范围、风险分级、依赖约束与退出准则
四张表按顺序使用：先圈定资产范围，再对范围内资产做风险分级，然后根据测试项列出依赖与约束，最后为每个测试项设定退出准则。表格可直接粘贴到文档或在线表格工具中，列宽和行数按项目规模增减。
表1 资产范围表
| 资产编号 | 资产名称 | 资产类型 | 归属部门/负责人 | 敏感级别 | 测试方式 |
|---|---|---|---|---|---|
| A-01 | |||||
| A-02 | |||||
| A-03 |
表2 风险分级表
| 风险编号 | 关联资产 | 威胁场景 | 可能性 | 影响 | 风险等级 | 处置优先级 |
|---|---|---|---|---|---|---|
| R-01 | ||||||
| R-02 | ||||||
| R-03 |
表3 依赖与约束清单
| 依赖编号 | 依赖对象 | 提供方 | 需要时间 | 约束类型 | 影响范围 | 应对措施 | 责任人 |
|---|---|---|---|---|---|---|---|
| D-01 | |||||||
| D-02 | |||||||
| D-03 |
表4 退出准则表
| 准则编号 | 适用测试项 | 通过条件 | 证据 | 判定人 | 未达标处置 |
|---|---|---|---|---|---|
| E-01 | |||||
| E-02 | |||||
| E-03 |
字段说明：每个字段填什么、怎么判断
同一份模板由不同人填写时，最容易出现口径不一致。下面逐表说明字段含义和判断方法，填写时以本表为准。
资产范围表字段口径
| 字段 | 填写口径 |
|---|---|
| 资产编号 | 项目内唯一，建议按“A-序号”编排，后续风险表和退出准则引用此编号 |
| 资产名称 | 使用系统、服务或数据的正式名称，避免简称歧义 |
| 资产类型 | 按项目习惯分类，如应用系统、接口服务、数据库、配置文件、账号权限、日志数据 |
| 归属部门/负责人 | 填业务归属方和日常维护人，用于协调测试授权和数据准备 |
| 敏感级别 | 按数据敏感度和业务重要性判定，可分高、中、低三档：涉及个人敏感信息、核心交易或对外暴露面大的定为高；内部使用、影响有限的定为中；公开或测试专用资源定为低 |
| 测试方式 | 写明拟采用的方式，如渗透测试、配置核查、漏洞扫描、接口安全测试、人工验证，便于后续排期 |
风险分级表字段口径
| 字段 | 填写口径 |
|---|---|
| 风险编号 | 按“R-序号”编排，与关联资产编号对应 |
| 关联资产 | 引用资产范围表中的资产编号，一个风险可关联多个资产 |
| 威胁场景 | 描述可能发生的具体情形，如“未授权访问订单查询接口”“测试数据含真实手机号” |
| 可能性 | 取高、中、低三档，依据暴露面、已有防护和攻击难度判断 |
| 影响 | 取高、中、低三档，依据数据泄露范围、业务中断时长和合规后果判断 |
| 风险等级 | 由可能性与影响组合得出，常用规则：任一为高且另一为中以上定为高；两者均为中定为中；其余定为低。项目可自定矩阵，但需在模板中写明 |
| 处置优先级 | 按风险等级映射，高风险优先安排测试资源和退出判定，中风险按计划推进，低风险可合并批次 |
依赖与约束清单字段口径
约束类型建议固定为六类，便于统计和跟踪：环境（测试环境、网络策略、脱敏环境）、数据（测试账号、样本数据、数据脱敏授权）、人员（业务配合人、运维窗口人、外部测试人员）、外部系统（第三方接口、支付沙箱、短信通道）、审批（测试授权、渗透授权、数据使用审批）、时间窗口（业务低峰期、变更冻结期）。
| 字段 | 填写口径 |
|---|---|
| 依赖编号 | 按“D-序号”编排，一个依赖只描述一件事，便于单独关闭 |
| 依赖对象 | 写清具体对象，如“订单服务测试环境”“脱敏后的用户样本数据” |
| 提供方 | 填具体团队或角色，不写“相关部门”这类无法追责的表述 |
| 需要时间 | 填依赖到位的最晚时间，与测试排期对齐 |
| 约束类型 | 从上述六类中选择，一条依赖对应一个主类型 |
| 影响范围 | 说明该依赖缺失会阻塞哪些测试项或资产，引用资产编号或测试项名称 |
| 应对措施 | 写备选方案或缓解办法，如“申请临时只读账号”“改用模拟数据先行验证” |
| 责任人 | 填跟进该依赖到位的具体人，通常是测试负责人或对应协调人 |
退出准则表字段口径
| 字段 | 填写口径 |
|---|---|
| 准则编号 | 按“E-序号”编排，与适用测试项一一对应 |
| 适用测试项 | 写明覆盖的测试项或资产范围，如“A-01订单接口渗透测试” |
| 通过条件 | 写成可判定的条件，如“高危漏洞全部修复并复测通过”“中危漏洞有明确修复计划并经负责人确认” |
| 证据 | 与通过条件逐条对应，如复测报告、漏洞跟踪记录、修复截图、评审签字 |
| 判定人 | 填有权判定该项是否达标的角色，通常是测试负责人，涉及高风险时增加业务或安全负责人 |
| 未达标处置 | 写清未达标时的动作，如“延期退出并升级至项目负责人”“带风险上线需书面审批” |
必填与选填：哪些字段不能空
计划评审时，关键字段留空会直接导致无法判断测试能否开始或结束。建议在模板中把必填字段标为加粗或加底色，并在提交评审前做一次完整性检查。
| 表格 | 必填字段 | 选填字段及适用情形 |
|---|---|---|
| 资产范围表 | 资产编号、资产名称、资产类型、敏感级别、测试方式 | 归属部门/负责人：资产归属尚在确认时可暂填协调人，并在备注中说明 |
| 风险分级表 | 风险编号、关联资产、威胁场景、可能性、影响、风险等级 | 处置优先级：风险等级确定后可自动映射，允许留空由负责人统一填写 |
| 依赖与约束清单 | 依赖编号、依赖对象、提供方、需要时间、约束类型、责任人 | 影响范围、应对措施：低风险且不影响关键测试项时可暂不填写，但需在评审中口头确认 |
| 退出准则表 | 准则编号、适用测试项、通过条件、证据、判定人 | 未达标处置：项目已有统一升级流程时可引用流程名称，不逐条展开 |
留空写法统一用“待定”并附上计划确认时间，避免用空白或横线造成“已确认无此项”的误解。必填字段缺失时的阻断规则建议如下：资产范围表或风险分级表存在必填缺失，计划不进入评审；依赖与约束清单存在必填缺失，相关测试项不得排入执行；退出准则表存在必填缺失，该测试项不得判定退出。
填写示例：一份完整的安全测试计划片段
以下为演示情景，用于说明四张表如何联动，不代表任何真实项目。假设某内部订单系统计划开展一轮安全测试，敏感级别定为高，风险分级结果为高，因此依赖约束和退出准则都按较严格的口径填写。
资产范围与风险分级
| 资产编号 | 资产名称 | 资产类型 | 归属部门/负责人 | 敏感级别 | 测试方式 |
|---|---|---|---|---|---|
| A-01 | 订单查询接口 | 接口服务 | 交易平台组/张工 | 高 | 接口安全测试、渗透测试 |
| A-02 | 订单数据库 | 数据库 | 数据平台组/李工 | 高 | 配置核查、权限核查 |
| 风险编号 | 关联资产 | 威胁场景 | 可能性 | 影响 | 风险等级 | 处置优先级 |
|---|---|---|---|---|---|---|
| R-01 | A-01 | 未授权访问订单查询接口，越权读取他人订单 | 中 | 高 | 高 | 优先 |
| R-02 | A-02 | 测试环境使用未脱敏真实数据 | 高 | 高 | 高 | 优先 |
由风险等级推导的依赖约束
R-01 和 R-02 均为高风险，依赖清单相应增加授权审批和脱敏数据两项，并把时间要求提前到测试执行前。
| 依赖编号 | 依赖对象 | 提供方 | 需要时间 | 约束类型 | 影响范围 | 应对措施 | 责任人 |
|---|---|---|---|---|---|---|---|
| D-01 | 订单服务独立测试环境及网络策略开通 | 运维组/王工 | 测试开始前3个工作日 | 环境 | A-01 全部测试项 | 先在与生产隔离的预发环境做只读验证 | 测试负责人 |
| D-02 | 脱敏后的订单样本数据 | 数据平台组/李工 | 测试开始前2个工作日 | 数据 | A-01、A-02 | 未到位前使用构造数据，不接触真实数据 | 测试负责人 |
| D-03 | 渗透测试书面授权 | 安全合规/赵工 | 测试开始前5个工作日 | 审批 | A-01 渗透测试 | 授权未批前仅执行配置核查 | 安全接口人 |
对应的退出准则
高风险测试项的退出条件更严格：高危问题必须修复并复测，中危问题需有经确认的修复计划，证据要求可追溯。
| 准则编号 | 适用测试项 | 通过条件 | 证据 | 判定人 | 未达标处置 |
|---|---|---|---|---|---|
| E-01 | A-01 接口安全测试 | 越权与未授权访问类高危问题全部修复并复测通过；中危问题有修复计划并经业务负责人确认 | 复测报告、漏洞跟踪记录、确认邮件 | 测试负责人与业务负责人 | 延期退出，升级至项目负责人 |
| E-02 | A-02 配置与权限核查 | 数据库账号权限符合最小化要求，测试环境确认无未脱敏真实数据 | 权限核查表、数据脱敏确认单 | 测试负责人 | 整改后重新核查，未通过不得进入上线评审 |
对照可见，风险等级为高时，退出准则要求“修复并复测”和双人判定；若同一类测试项风险等级为中，通过条件可放宽为“高危修复、中危登记跟踪”，判定人可只保留测试负责人。这一差异应在模板使用说明中写明，避免不同项目随意套用。
调整与维护：模板随项目变化怎么改
模板的价值在于长期复用，需要明确裁剪原则、更新时点和版本记录，否则几轮项目之后表格会变得臃肿或失真。
按项目类型裁剪
小型内部系统可保留四张表但精简行数，风险分级可只保留高、中两档；涉及第三方接口或外部暴露面的项目，应在依赖清单中固定保留“外部系统”和“审批”两类；纯配置核查类项目可省略渗透测试相关的依赖条目，但退出准则中的证据字段不能删。裁剪时遵循一条原则：删字段不删表，表结构保持稳定，便于跨项目对比。
更新时点与责任人
| 更新对象 | 更新时点 | 责任人 |
|---|---|---|
| 依赖状态 | 每次测试例会后，或依赖到位/延期当天 | 各依赖条目责任人 |
| 退出判定 | 测试项执行完毕、复测完成后 | 准则判定人 |
| 资产范围与风险分级 | 需求变更、新增接口或数据范围调整时 | 测试负责人与业务负责人 |
版本记录与变更留痕
| 版本号 | 变更日期 | 变更内容 | 变更人 | 影响范围 |
|---|---|---|---|---|
| V1.0 | 初始版本 | |||
| V1.1 |
计划变更后，资产范围、风险分级、依赖约束和退出准则要同步更新：新增资产需补风险条目，风险等级上调需同步收紧对应退出准则，依赖延期需在影响范围中标注受阻塞的测试项。依赖跟踪和退出判定往往跨多轮会议推进，若团队使用 ONES，可把每条依赖登记为工作项并指定责任人与截止时间，退出准则作为测试任务的完成条件挂在同一需求或测试任务下，判定证据以文档形式关联，评审时按状态逐条核对，减少表格分散在多处导致的版本不一致。
常见问题
依赖迟迟不到位，测试计划该怎么调整？
先看该依赖在清单中的影响范围：如果只阻塞部分测试项，可以把未受影响的测试项按原排期推进，受阻塞项标注为“等待依赖”，并在例会上由责任人说明到位时间。如果依赖影响的是高风险测试项，且预计延期超过测试窗口，应启动清单中预先写好的应对措施，例如改用构造数据先行验证、在隔离环境做只读核查。延期本身要回写到依赖状态和计划变更记录中，避免退出判定时才发现关键测试项没有执行。
退出准则里的通过条件写到什么程度才算可判定？
判断标准是：另一个人拿着条件和证据能否独立得出“达标”或“未达标”的结论。像“安全问题基本修复”这类表述无法判定；写成“高危问题全部修复并复测通过，中危问题有经负责人确认的修复计划”就可以对照证据逐条核对。每条通过条件都应在证据字段有对应材料，例如复测报告、漏洞跟踪记录或确认邮件，条件与证据一一对应，判定时才不会出现有结论无依据的情况。
项目中途新增了接口或数据范围，模板要改哪些表？
新增资产先补进资产范围表并给出敏感级别，再为它补充风险分级条目；如果新资产带来新的环境、数据或审批需求，同步在依赖与约束清单中增加条目并指定责任人和需要时间；最后为受影响的测试项补充或调整退出准则。三处更新应在同一次变更中完成，并在版本记录表中登记变更内容和影响范围，防止资产已纳入而退出准则仍停留在旧范围。
低风险测试项能否简化退出准则？
可以简化严格程度，但结构不建议删减。低风险测试项可将通过条件写为“扫描或核查完成，发现的问题已登记并评估”，判定人保留测试负责人即可，未达标处置可引用项目统一的缺陷跟踪流程。需要保留的是证据字段，至少要能追溯到本次测试的执行记录，否则后续复盘或上线评审时无法说明该项测试确实做过。
依赖跟踪和退出判定分散在多个文档里，怎么保持同步？
常见做法是把依赖清单和退出准则作为计划文档的固定章节，每次例会只更新状态列，不改结构。若团队使用 ONES，可以把每条依赖登记为工作项并指定责任人与截止时间，退出准则作为测试任务的完成条件挂在同一需求或测试任务下，证据以文档形式关联，评审时按状态逐条核对，减少表格分散在多处造成的版本不一致。
