安全测试计划模板的核心是两张表：资产范围清单表用来圈定“测什么、测到哪”，风险分级表用影响程度和发生可能性两个维度定级，决定“测多深、复测几次”。模板还需配套依赖约束与退出准则字段，让计划既能执行，也能验收。以下提供可直接复制的空白表、字段说明、必填规则和一份完整填写示例。
要点总览（TL;DR）
- 模板以资产范围清单表和风险分级表为核心：前者逐行登记资产名称、类型、敏感级别、暴露面、责任人及纳入/排除理由，圈定测试边界。
- 风险分级按影响程度与发生可能性各1–3分打分，映射为高、中、低等级，再由等级推导测试深度与复测要求，判定规则需随表附上。
- 资产名称、类型、责任人、敏感级别、纳入/排除为必填；风险表的影响、可能性、等级、测试深度为必填，缺失即无法定级或纳入范围。
- 依赖约束（环境、账号数据、窗口期、外部配合方）与退出准则（高危项清零口径、遗留风险接受人、复测通过条件）需与两张表配套填写。
- 模板按项目规模裁剪，保留必填字段；资产或暴露面变化、发生安全事件时更新风险等级，模板按版本记录修订。
可复制空白模板：资产范围清单表
资产范围清单表逐行登记被测对象，一行一个资产或一组同质资产。填写时先列全量候选资产，再逐行标注纳入或排除，排除项必须写理由，避免范围在评审时反复拉扯。
| 序号 | 资产名称 | 资产类型 | 归属系统/模块 | 数据敏感级别 | 部署位置 | 对外暴露面 | 责任人 | 纳入/排除 | 范围理由 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | |||||||||
| 2 | |||||||||
| 3 | |||||||||
| 4 | |||||||||
| 5 |
资产类型建议使用固定枚举，便于筛选和统计：应用（Web、移动端、桌面端）、接口（对外API、内部服务间调用）、数据（数据库、数据文件、备份）、账号权限（登录认证、角色与授权配置）、基础设施（服务器、网络、中间件、云资源）、第三方依赖（外部服务、开源组件、SDK）。枚举可按项目实际情况增补，但同一份计划内保持统一。
范围边界通过“纳入/排除”列加“范围理由”列表达。纳入项写清测试覆盖的功能与接口边界；排除项写明排除原因，例如本期未上线、由外部供应商负责、已由其他专项覆盖。排除项同样需要责任人确认，防止出现无人认领的资产。
可复制空白模板：风险分级表
风险分级表以资产为行，按影响程度和发生可能性各打1–3分，两维得分组合后映射为高、中、低等级，再由等级推导测试深度和复测频次。判定规则直接写在表下方，保证不同人打分口径一致。
| 序号 | 关联资产 | 风险场景描述 | 影响程度（1–3） | 发生可能性（1–3） | 风险等级 | 测试深度 | 复测频次 | 备注 |
|---|---|---|---|---|---|---|---|---|
| 1 | ||||||||
| 2 | ||||||||
| 3 | ||||||||
| 4 | ||||||||
| 5 |
等级判定规则行（随表附上，填写时直接引用）：
| 影响程度 | 发生可能性 | 风险等级 | 测试深度 | 复测要求 |
|---|---|---|---|---|
| 3 | 2–3 | 高 | 完整测试，覆盖主要攻击路径与权限边界 | 修复后必须复测，复测通过方可关闭 |
| 3 | 1 | 中 | 重点场景测试 | 修复后抽测 |
| 2 | 2–3 | 中 | 重点场景测试 | 修复后抽测 |
| 2 | 1 | 低 | 基础检查 | 随版本回归验证 |
| 1 | 任意 | 低 | 基础检查 | 随版本回归验证 |
测试深度和复测频次两列在模板中预填默认值，项目可按自身节奏调整，但调整需在备注列说明原因，便于后续复盘时追溯定级依据。
字段说明：每个字段填什么、怎么判断
字段字典与S1、S2两张表一一对应。填写人按字典取值，评审人按字典核对，减少“同一字段各写各的”的情况。
| 所属表 | 字段 | 填写内容 | 判断依据与示例 |
|---|---|---|---|
| 资产表 | 资产名称 | 可唯一识别的名称 | 示例：订单服务对外API、用户中心数据库 |
| 资产表 | 资产类型 | 从枚举中选择 | 应用、接口、数据、账号权限、基础设施、第三方依赖 |
| 资产表 | 归属系统/模块 | 所属业务系统及模块 | 用于按系统汇总范围，避免资产散落 |
| 资产表 | 数据敏感级别 | 高/中/低 | 高：含个人身份、支付、凭证类数据；中：含内部业务数据；低：公开或可公开数据 |
| 资产表 | 部署位置 | 机房、云区域、内外网区域 | 影响测试环境搭建方式和访问路径 |
| 资产表 | 对外暴露面 | 公网/内网/仅本地 | 公网可访问的资产默认提高可能性评分 |
| 资产表 | 责任人 | 具体到人 | 负责确认范围、提供测试条件、确认修复 |
| 资产表 | 纳入/排除 | 二选一 | 排除项必须填写范围理由 |
| 风险表 | 影响程度 | 1–3分 | 3：导致数据泄露、资金损失或核心业务中断；2：局部功能受损或内部数据暴露；1：影响有限、可快速恢复 |
| 风险表 | 发生可能性 | 1–3分 | 3：公网暴露且认证薄弱；2：需特定条件触发；1：利用门槛高或暴露面小 |
| 风险表 | 风险等级 | 高/中/低 | 按S2判定规则行得出，不自行解释 |
| 风险表 | 测试深度 | 完整测试/重点场景/基础检查 | 由等级映射，可调整但需备注 |
| 风险表 | 复测频次 | 必测/抽测/回归验证 | 与退出准则中的复测通过条件对应 |
敏感数据级别与暴露面的判断口径需要提前对齐。敏感级别看数据本身，按“泄露后对用户或业务的影响”判断，与数据量无关；暴露面看访问路径，公网可达、无需登录即可触达的入口按最高暴露面处理。两个字段共同影响可能性评分，填写时先定敏感级别，再定暴露面，最后打可能性分。
必填与选填：哪些字段不能空
必填字段缺失时，该行资产不进入测试范围，计划不予评审通过。选填字段允许后补，但需在备注列注明补录时间与责任人。
| 表 | 必填字段 | 选填字段 | 缺失处理 |
|---|---|---|---|
| 资产表 | 资产名称、资产类型、责任人、数据敏感级别、纳入/排除 | 归属系统/模块、部署位置、对外暴露面、范围理由（排除项除外） | 必填缺失：该行退回补充，不纳入本期范围；选填缺失：备注列注明补录时间 |
| 风险表 | 关联资产、影响程度、发生可能性、风险等级、测试深度 | 风险场景描述、复测频次、备注 | 必填缺失：无法定级，不得进入执行；选填缺失：执行前补齐 |
排除项的“范围理由”按必填处理，这是范围边界可追溯的关键。风险表的“复测频次”虽列为选填，若该风险等级为高，则复测要求随等级自动带入，实际填写时不应留空。
依赖约束与退出准则字段
资产和风险定级完成后，计划还需要回答“能不能按时测”和“测到什么程度算结束”。这两类字段与资产表、风险表配套填写，不能等执行阶段再补。
| 类别 | 字段 | 填写内容 |
|---|---|---|
| 依赖约束 | 测试环境 | 环境地址、与生产环境的差异说明、可用时间 |
| 依赖约束 | 测试账号与数据 | 账号类型与权限、测试数据来源、脱敏要求 |
| 依赖约束 | 窗口期 | 可执行测试的时间段、对业务的影响与规避安排 |
| 依赖约束 | 外部配合方 | 供应商、运维、业务方联系人及响应时限 |
| 退出准则 | 高危项清零口径 | 高危项修复并复测通过的数量要求，未清零时的处理路径 |
| 退出准则 | 遗留风险接受人 | 中低风险遗留项的接受人、接受理由与跟踪期限 |
| 退出准则 | 复测通过条件 | 复测范围、通过标准、复测记录留存方式 |
| 阻断与暂停 | 阻断条件 | 环境不可用、账号权限不足、发现高危项需立即上报等触发条件 |
| 阻断与暂停 | 暂停与恢复 | 暂停的决策人、恢复条件与通知对象 |
退出准则要与风险等级挂钩：高危项按“清零口径”验收，中低风险遗留项由接受人书面确认后放行。阻断条件写清楚，执行中遇到环境或权限问题时按预设路径处理，不必临时找人拍板。
资产清单和风险项需要在执行过程中持续跟踪：谁负责、当前状态、复测结果。这类登记与流转可以放在ONES的工作项和文档中管理。ONES测试管理支持测试计划的规划和执行，并可多维度概览全部测试计划；测试用例可与需求、任务关联，测试计划与迭代关联；未通过的用例可快速创建缺陷任务，缺陷在测试与研发团队间流转；同时支持为用例库、测试计划单独配置权限。资产责任人与测试范围的对应关系、风险项的复测状态，可以借助这些能力保持与计划一致。
填写示例：一份完整的安全测试计划片段
以下片段演示资产表、风险表与退出准则如何联动。示例为演示情景，资产与评分均为示意。
资产表片段：
| 序号 | 资产名称 | 资产类型 | 归属系统 | 数据敏感级别 | 部署位置 | 对外暴露面 | 责任人 | 纳入/排除 | 范围理由 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 订单服务对外API | 接口 | 订单系统 | 高 | 公有云 | 公网 | 张工 | 纳入 | 对外提供下单与查询能力 |
| 2 | 用户中心数据库 | 数据 | 用户系统 | 高 | 私有云 | 内网 | 李工 | 纳入 | 存储用户身份信息 |
| 3 | 运营后台登录 | 账号权限 | 运营平台 | 中 | 内网 | 内网 | 王工 | 纳入 | 内部人员访问入口 |
| 4 | 旧版报表服务 | 应用 | 报表系统 | 低 | 内网 | 内网 | 赵工 | 排除 | 本期已下线，由下季度专项覆盖 |
风险表片段：
| 序号 | 关联资产 | 风险场景描述 | 影响程度 | 发生可能性 | 风险等级 | 测试深度 | 复测频次 |
|---|---|---|---|---|---|---|---|
| 1 | 订单服务对外API | 未授权访问订单数据 | 3 | 3 | 高 | 完整测试 | 修复后必测 |
| 2 | 用户中心数据库 | 越权查询用户信息 | 3 | 2 | 高 | 完整测试 | 修复后必测 |
| 3 | 运营后台登录 | 弱口令与暴力尝试 | 2 | 2 | 中 | 重点场景测试 | 修复后抽测 |
退出准则片段：高危项共2项，要求全部修复并复测通过后放行；中风险项1项，若修复未完成，由运营平台负责人书面接受遗留风险，跟踪期限为下个迭代结束前；复测通过条件为原风险场景复现失败且回归相关功能无异常，复测记录附在测试报告中。
这份片段中，资产表的敏感级别和暴露面支撑了风险表的可能性评分，风险等级又决定了测试深度和复测要求，退出准则直接引用高危项数量。三处字段互相引用，评审时可按此核对一致性。
调整与维护方法：模板如何随项目演进
模板按项目规模和资产数量裁剪。小型项目可合并“归属系统/模块”与“部署位置”，保留资产名称、类型、敏感级别、暴露面、责任人、纳入/排除等必填字段；大型项目可增加“关联需求”“合规要求”等列，但新增列需同步写入字段字典，避免模板与说明脱节。
资产与风险等级在以下情况需要更新：新增对外接口或上线新系统、数据敏感级别调整、部署位置或暴露面变化、发生安全事件或高危缺陷、业务方提出范围变更。每次更新在模板中记录变更行，并重新核对风险等级与测试深度是否仍然匹配。
模板本身建议按版本维护：文件头记录版本号、修订日期、修订人和主要变更；每次项目复盘后收集填写中的歧义字段，统一修订字段字典；旧版本归档保留，便于追溯历史计划的定级依据。裁剪时保留必填字段，选填字段可后补但需注明补录时间，这条规则同样适用于模板的长期维护。
常见问题
资产范围清单表填完后，评审时最常被追问的是什么？
通常是排除项的理由和责任人。纳入项容易达成一致，排除项却常出现“以为别人测了”的空档。建议在评审前逐行核对排除项的“范围理由”是否写明具体依据，例如本期未上线、由外部供应商负责、已由其他专项覆盖，并确认该行责任人已知晓并同意排除。排除项的责任人不能留空，否则范围边界无法追溯。
影响程度和发生可能性打分时，不同人给出的分数不一致怎么办？
先把判断口径写进字段字典，再打分。影响程度看后果：导致数据泄露、资金损失或核心业务中断记3分；局部功能受损或内部数据暴露记2分；影响有限、可快速恢复记1分。发生可能性看利用条件：公网暴露且认证薄弱记3分；需特定条件触发记2分；利用门槛高或暴露面小记1分。打分前由资产责任人先填敏感级别和暴露面，评分人据此打分，分歧在备注列写明理由，复盘时统一修订口径。
高危项在计划窗口内修不完，退出准则怎么处理？
退出准则需要提前写明未清零时的处理路径，不能等到验收时临时决定。常见做法是：高危项必须修复并复测通过才放行；确因客观条件无法在本期完成的，由指定接受人书面确认遗留风险、说明理由并约定跟踪期限，同时明确该风险项在下一期的复测安排。中低风险遗留项同样需要接受人确认。接受人和跟踪期限应在计划阶段就填入退出准则字段，避免验收时找不到决策人。
测试环境或账号权限在计划执行时才到位，模板里怎么体现？
把环境地址、与生产环境的差异、可用时间，以及账号类型、权限范围、测试数据来源和脱敏要求，作为依赖约束字段在计划阶段填写，并指定外部配合方联系人与响应时限。同时设置阻断条件：环境不可用、账号权限不足时按预设路径上报，明确暂停决策人和恢复条件。这样执行中遇到依赖未到位，按模板字段处理即可，不必临时找人拍板。
小型项目用这套模板会不会太重，可以裁掉哪些字段？
可以裁剪，但必填字段要保留。小型项目可将“归属系统/模块”与“部署位置”合并为一列，保留资产名称、类型、敏感级别、暴露面、责任人、纳入/排除；风险表保留影响程度、发生可能性、等级、测试深度。选填字段允许后补，但需在备注列注明补录时间与责任人。裁剪后同步更新字段字典，避免模板与说明脱节；大型项目新增“关联需求”“合规要求”等列时同样要写入字典。
