安全测试计划模板：依赖约束与退出准则怎么写

安全测试计划里最容易写空的两块，是依赖约束和退出准则。把它们做成两张可填写的表：依赖约束逐条写清依赖对象、提供方、需要时间、当前状态、缺失影响和应对方式；退出准则按风险等级与测试类型写明可量化条件、判定证据、确认人和未达标处理。下面给出四张空白表、逐字段填写口径、必填项清单和一份完整示例，可直接复制到项目文档中使用。

要点总览（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-01	用户登录服务	应用接口	统一认证平台	高（含账号凭证）	接口测试、认证绕过验证
A-02	订单数据库	数据	交易系统	高（含交易与个人信息）	权限核查、脱敏数据验证

风险编号	风险项	影响面	可能性	风险等级	对应测试深度	关联资产编号
R-01	登录接口被暴力破解	账号安全、全站访问	中	高	接口测试加限流与锁定策略核查	A-01
R-02	越权读取订单数据	交易数据与个人信息	中	高	多角色权限矩阵验证	A-02

约束编号	依赖对象	提供方	需要时间	当前状态	缺失影响	应对方式	责任人
D-01	测试环境多角色账号	运维组	测试开始前2个工作日	进行中	R-02权限矩阵验证无法执行，属硬依赖	未按时提供则升级至项目负责人协调，测试顺延并记录	测试负责人
D-02	订单脱敏数据集	数据组	测试第二周前	未开始	影响数据验证真实性，属可替代依赖	先用构造数据完成接口验证，脱敏数据到位后补测	数据组接口人

准则编号	适用风险等级	可量化条件	判定证据	确认人	未达标处理
E-01	高	R-01、R-02对应测试全部执行完毕，高危问题修复并复测通过	测试报告、缺陷清单、复测记录	测试负责人、安全负责人	延长测试周期；确需上线的，由业务负责人书面接受风险并缩小上线范围
E-02	中	中风险项测试覆盖率达到计划约定比例，遗留问题均有处理结论	测试报告、遗留问题清单	测试负责人	补充测试或转为下阶段跟踪，记录跟踪责任人

核对示例与字段说明：每条依赖都写了缺失影响和应对方式，D-01标注为硬依赖、D-02标注为可替代依赖；每条退出准则都区分了可量化条件与判定证据，并落实了确认人和未达标处理。示例中的比例、时限为演示取值，实际填写按项目约定替换。

调整与维护：模板怎么随项目变化更新

安全测试计划在项目推进中会变化，模板需要配套的更新规则，否则依赖状态和退出准则会停留在计划评审时的版本。

• 依赖状态更新：每周固定复核一次；出现提供方延期、依赖对象变更、测试范围调整时立即更新，并在备注中记录变更原因。
• 退出准则调整：风险等级变化或测试范围扩大时，由测试负责人提出调整，经原确认人确认后生效，调整前后的条件与证据要求一并留痕。
• 版本与留痕：模板文件标注版本号和修订日期，每次修改记录修改人、修改内容和影响范围，评审时使用最新版本。
• 复核节点：计划评审、测试启动、测试中期、退出评审四个节点各复核一次，重点检查硬依赖是否闭环、退出准则的判定证据是否可取得。

依赖约束和退出准则的确认动作需要可追踪。在 ONES 测试管理中，测试计划可与迭代关联，测试用例可与需求、任务关联，依赖约束的提供方确认、退出准则的确认人签字可以对应到具体工作项和文档状态上，形成从计划到执行的记录；测试报告模板支持按业务场景自定义组装，便于把退出准则的判定证据汇总到同一份报告中。团队规模、流程复杂度不同，承载方式可以简化，关键是每条依赖和每条退出准则都能找到责任人和当前状态。

常见问题

依赖约束表里，硬依赖和可替代依赖的判断标准是什么？

按缺失后果判断：依赖缺失后相关测试完全无法开展，属于硬依赖，应对方式写升级协调或调整计划；依赖缺失后可以降级执行、改用替代数据或替代环境，属于可替代依赖，应对方式写具体替代路径。这个区分决定评审时哪些依赖必须闭环、哪些可以带条件通过。判断时以具体测试项为参照，同一条依赖对不同测试项可能结论不同，需要分别注明。

退出准则里的可量化条件和判定证据有什么区别，为什么不能合并写？

可量化条件描述“达到什么状态”，例如高风险项对应测试全部执行完毕且无未修复的高危问题；判定证据描述“用什么材料证明”，例如测试报告、缺陷清单、复测记录。合并写容易出现“已测试完成”这类无法核验的表述，退出评审时无法判断是否真正达标。分开填写后，确认人可以逐条核对证据是否齐备，未达标处理也有明确触发点。

项目中途风险等级上调，退出准则和依赖约束要怎么跟着改？

风险等级上调后，先检查该风险关联的测试深度是否足够，再调整退出准则中适用该等级的量化条件与证据要求。调整由测试负责人提出，经原确认人确认后生效，调整前后的条件与证据要求一并留痕。依赖约束同步复核：新增测试项可能带来新的硬依赖，需要补充依赖对象、提供方和应对方式，并更新当前状态。变更记录写入模板的修订说明，评审时使用最新版本。

计划评审时发现部分必填字段确实填不出来，能直接提交吗？

必填字段缺失时计划不进入评审，退回补充。确因客观原因无法填写的，按风险接受流程记录审批人后再提交。硬依赖缺少应对方式的，计划不得进入执行；可替代依赖须写明替代路径。退出准则中确认人未落实的，该条准则不得作为退出依据。把缺失项标记为风险接受并留痕，比留空提交更便于后续复核。

依赖约束和退出准则的确认记录，用什么方式跟踪比较可靠？

关键是每条依赖和每条退出准则都能找到责任人和当前状态。可以用文档加表格维护，也可以放到研发管理工具里跟踪。在 ONES 测试管理中，测试计划可与迭代关联，测试用例可与需求、任务关联，依赖的提供方确认和退出准则的确认人签字可以对应到具体工作项和文档状态；测试报告模板支持按业务场景自定义组装，便于把退出准则的判定证据汇总到同一份报告中。团队规模不同，承载方式可以简化，记录可追踪即可。