测试风险分析的依据主要来自五类可追溯输入：测试目标与验收要求、需求与设计资料、历史缺陷与质量数据、变更与依赖信息、资源与进度约束。把这些输入逐条落到“风险描述—影响—可能性—依据来源—应对动作”的条目上，再由测试负责人组织产品、开发评审确认，就能形成一份可跟踪、可更新的测试风险清单。下面按收集、转换、评审、检查的顺序说明具体做法。
要点总览（TL;DR）
- 测试风险分析的依据分五类：目标与验收要求、需求与设计资料、历史缺陷与质量数据、变更与依赖信息、资源与进度约束，每类都要记录来源、版本或时间与可信度。
- 分析顺序固定为定范围→收集依据→识别风险→评估排序→定应对→评审确认，交付物是一份字段固定的测试风险清单。
- 依据转风险条目的关键是写明触发条件、影响对象和依据引用；评估用影响程度与发生可能性两维打分，打分口径要能指向具体资料。
- 风险分析由测试负责人牵头，产品、开发、运维分别提供验收标准、设计与依赖信息、线上问题与环境约束，评审固定在测试计划定稿前和重大变更后。
- 完成检查看五点：依据可回溯、高风险项有动作和责任人、排除项有记录、有更新机制、评审记录留存。
先明确：测试风险分析要产出什么
测试风险分析的核心交付物是一份测试风险清单。它承担两个作用：一是说明本次测试为什么重点测这些地方，二是让测试范围、深度和资源安排有据可查。清单以表格形式维护最便于评审和更新，每条风险占一行，字段固定，避免分析停留在口头讨论。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 风险描述 | 一句话说明可能出问题的对象和情形 | 支付回调在第三方超时后重复入账 |
| 触发条件 | 什么情况下风险会暴露 | 第三方接口响应超过约定超时时间 |
| 影响范围 | 受影响的用户、流程、系统 | 下单用户、财务对账流程 |
| 可能性 | 高/中/低，附判断依据 | 中，历史同类缺陷出现过两次 |
| 严重度 | 高/中/低，附判断依据 | 高，涉及资金准确性 |
| 依据来源 | 指向具体资料及版本或时间 | 需求变更单 CR-2024-031、缺陷库支付类记录 |
| 应对动作 | 增加什么测试、提前做什么准备 | 补充超时与重试场景用例，安排接口联调 |
| 责任人 | 跟进该风险测试动作的人 | 测试工程师 A，开发 B 配合 |
支撑这份清单的依据分为五类：目标与验收要求、需求与设计资料、历史缺陷与质量数据、变更与依赖信息、资源与进度约束。分析顺序建议固定为：定范围→收集依据→识别风险→评估排序→定应对→评审确认。顺序固定的好处是每一步都有明确输入和输出，评审时能逐段回溯。
第一步：从测试目标和验收要求确定分析范围
风险分析最容易失控的地方是范围不清，导致清单越写越长、重点反而模糊。范围的起点是需求文档中的验收标准、质量目标，以及合同或合规条款中的硬性要求。测试负责人需要把这些要求翻译成可分析的对象，再划定本次分析的边界。
具体动作分三步。第一，按功能模块、非功能维度（性能、安全、兼容性等）、测试层级（单元、集成、系统、验收）三个方向切分范围，列出本次版本涉及的部分。第二，对本次不覆盖的部分写明原因，例如“旧版报表模块本期无改动，仅做冒烟验证”，形成排除项记录。第三，根据验收标准的严格程度和业务影响，对范围内对象做优先级初判，为后续风险排序提供参照。
这一步的输出是一份范围说明，包含覆盖对象、排除项及理由、优先级初判。完成标志是范围经产品与测试双方确认，排除项有书面记录。范围确认后再收集资料，可以避免把大量无关文档拉进分析。
第二步：收集五类依据并标注来源
依据收集的目标不是资料越多越好，而是每类依据都能回答“这条风险判断从哪里来”。建议建立一份依据台账，逐条记录来源、版本或时间、可信度，后续风险条目直接引用台账编号，评审时即可回溯。
| 依据类别 | 从哪里取 | 取到什么程度可用 |
|---|---|---|
| 目标与验收要求 | 需求文档验收标准、质量门禁、合同或合规条款 | 要求可量化或有明确判定条件，版本为当前有效版本 |
| 需求与设计资料 | 需求条目、原型、接口文档、架构说明、非功能指标 | 与本次范围对应，接口与数据结构有明确约定 |
| 历史缺陷与质量数据 | 缺陷库分布、线上问题记录、回归失败记录、同类项目经验 | 能定位到模块或场景，时间范围与当前版本可比 |
| 变更与依赖信息 | 需求变更单、版本计划、第三方接口文档、上下游系统依赖清单 | 变更内容与影响面已确认，依赖方接口状态明确 |
| 资源与进度约束 | 人力安排、测试环境与数据可用性、发布窗口期 | 约束条件已与项目方对齐，时间点明确 |
收集时注意两个判断标准。一是相关性：资料必须落在第一步确认的范围内，范围外的资料只做背景参考，不进入台账。二是可信度：正式评审过的需求文档、有记录的历史缺陷可信度高；口头传达的变更、个人经验判断可信度低，需要在台账中标注并请相关方确认后再使用。台账中的每条记录写明来源名称、版本号或获取时间，便于版本变化后识别哪些依据已失效。
当需求、用例、缺陷和测试计划分散在不同工具中时，依据台账的维护成本会明显上升。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，风险条目引用的需求条目和缺陷记录可以在同一协作空间内追溯；测试报告与项目缺陷分布统计也能为历史数据类依据提供来源。是否采用工具承载取决于团队现有的协作方式，关键是台账中的引用关系保持有效。
第三步：把依据转成风险条目并评估排序
依据本身不是风险，转换的关键是写出“什么条件下、什么对象会出什么问题”。转换规则可以概括为：一条依据对应一条或多条风险，每条风险必须写明触发条件和影响对象，并回引依据台账编号。例如，接口文档中约定第三方超时时间为 3 秒，这条依据可以转成“第三方响应超过 3 秒时，系统重试逻辑可能导致重复提交”的风险条目。
评估采用影响程度与发生可能性两个维度，各自分高、中、低三档。打分不能凭印象，每一档都要说明依据来自哪份资料：影响程度参考验收标准中的业务重要性和影响范围；发生可能性参考历史缺陷分布、变更复杂度和依赖方稳定性。两维都高的风险排在最前，优先安排增加测试深度、提前介入联调或补充专项测试。影响高但可能性低的风险，至少保留验证用例并记录判断理由，便于后续复盘。
排序完成后形成带优先级和依据引用的风险清单。此时清单应能直接回答两个问题：本次测试的资源为什么这样分配，哪些场景必须有覆盖证据。清单中的应对动作要具体到测试类型、覆盖场景或准备工作，避免写成“加强关注”这类无法验证的表述。
角色分工与各环节交付物
风险分析由测试负责人牵头，但依据分散在产品、开发、运维等角色手中，需要明确谁在什么时点提供什么。分工不清时，常见结果是清单只反映测试团队的单方判断，技术风险和线上约束被遗漏。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 测试负责人 | 组织分析、汇总清单、维护更新、组织评审 | 范围说明、依据台账、风险清单、评审记录 |
| 产品与需求方 | 提供验收标准与需求变更信息，确认影响判断 | 验收标准说明、变更影响确认意见 |
| 开发 | 提供设计与依赖信息，参与技术风险识别 | 接口与架构说明、技术风险判断 |
| 运维或业务方 | 提供线上问题记录与运行环境约束 | 线上问题清单、环境与窗口期约束说明 |
评审时点建议固定在两处：测试计划定稿前，对风险清单的范围、排序和应对动作做一次确认；重大变更发生后，补充新依据并更新受影响的风险条目。评审结论和不同意见都要留存，未达成一致的风险项标注待定并指定跟进人。ONES 测试管理支持未通过的用例快速创建缺陷任务并在测试与研发团队间流转，风险应对中发现的缺陷可以顺着这条链路跟踪到关闭，评审记录也可与测试计划一并留存。
示例：一次版本迭代的风险分析怎么走
以下为演示情景，用于说明依据如何转成风险条目，不代表真实项目数据。某版本对支付流程做改造，新增第三方支付渠道，发布窗口为两周。
范围阶段确认本次覆盖支付下单、回调处理、退款三个功能点，以及接口超时、重复提交两个非功能场景；旧版对账报表本期不改动，仅做冒烟验证，排除项经产品确认。依据台账收录四类资料：需求变更单（说明回调逻辑调整）、历史缺陷记录（支付类缺陷集中在回调与重试环节）、第三方接口文档（约定超时时间与重试策略）、测试窗口约束（第三方联调环境仅第一周可用）。
转换后形成的主要风险条目包括：第三方回调超时后重复入账，影响资金准确性，可能性中、严重度高，依据为接口文档与历史缺陷记录，应对动作是补充超时与重试场景用例并安排第一周联调；退款状态与渠道侧不一致，可能性中、严重度中，应对动作是增加对账校验用例；联调环境窗口短导致异常场景验证不足，可能性高、严重度中，应对动作是提前准备模拟工具并在窗口期内优先执行高风险用例。
这份清单直接反映到测试计划：高风险用例排入第一周执行，回归范围从原定的支付模块扩大到关联的订单与对账模块，联调所需人力提前锁定。发布前若第三方接口再有变更，按更新机制补充依据并重评相关条目。
完成检查：风险分析是否可用的判断标准
风险分析做完后，用下面几项逐条核对，全部满足即可认为达到可用状态；存在未满足项时，明确补做责任人和时间。
- 每条风险都有明确的依据来源，能回溯到台账中的具体资料及版本或时间。
- 高风险项都有对应的测试动作和责任人，动作具体到测试类型或覆盖场景。
- 范围排除项有书面记录，并经产品与测试双方确认。
- 清单有更新机制，明确在测试计划定稿前和重大变更后由谁负责更新。
- 评审记录与结论已留存，未达成一致的事项有跟进人和期限。
- 风险排序与测试计划中的资源安排一致，能解释重点测试投入的理由。
检查通过后，风险清单随测试计划一同发布，并在执行过程中随缺陷发现和变更情况持续更新，使风险分析真正成为测试决策的依据，而非一次性的文档作业。
常见问题
需求文档不完整时，风险分析还能做吗？
可以做，但要把不完整本身当作一条风险处理。做法是：先用现有验收标准和原型确定范围，把缺失的需求条目列入依据台账并标注可信度低；对依赖缺失信息才能判断的部分，在风险清单中写明“待需求确认”，指定产品方补充的时限。评审时优先确认这些待定项，避免它们被默认成低风险。
风险清单需要多久更新一次？
按事件更新比按固定周期更新更实用。至少在两处必须更新：测试计划定稿前做一次整体确认；重大变更发生后补充新依据并重评受影响条目。执行过程中发现新的高风险缺陷、依赖方接口状态变化、测试环境或窗口期调整时，也应及时更新对应条目。更新由测试负责人负责，更新记录与评审结论一并留存。
影响程度和发生可能性打分出现分歧怎么办？
分歧通常来自打分依据不同。处理方式是让各方把判断依据摆到台账上：影响程度对照验收标准中的业务重要性和影响范围，发生可能性对照历史缺陷分布、变更复杂度和依赖方稳定性。依据一致后重新打分；依据本身缺失的，先补资料再评。仍无法达成一致的条目标注待定，指定跟进人和确认期限，不强行取平均值。
小团队没有专职测试负责人，风险分析怎么组织？
可以由承担测试职责的人牵头，但评审环节不能省。小团队可简化形式：范围说明和风险清单合并成一份文档，依据台账只记录关键几条，评审用一次短会完成并留下结论。角色上至少保证产品方确认验收标准和排除项、开发方确认技术依赖判断。分工可以合并，判断依据仍需可追溯。
风险清单和测试计划是什么关系？
风险清单是测试计划的输入之一。清单中的优先级和应对动作决定测试范围、用例深度和资源安排，测试计划则把这些安排落到时间、人力和环境上。两者应保持一致：计划中重点投入的部分，能在风险清单中找到对应的高风险条目和依据。计划变更时，同步检查风险清单是否需要更新。
