测试分析要以需求与验收标准、设计说明与接口约定、业务规则与数据约束、历史缺陷与线上问题、变更记录与版本范围、测试环境与数据条件为依据。这些依据需要版本一致、来源可查，才能支撑测试条件拆解和用例编写。下面给出依据清单、从依据到测试条件的操作步骤、角色分工、一个订单状态变更示例，以及判断依据是否充分的检查项。
要点总览（TL;DR）
- 测试分析的依据包括需求与验收标准、设计说明与接口约定、业务规则与数据约束、历史缺陷与线上问题、变更记录与版本范围、测试环境与数据条件六类，每类都要写清来源、负责人和确认状态。
- 把依据转成测试条件分五步：核对完整性与版本一致性、按等价类边界值决策表等方法拆条件、为每条条件标注依据来源、回问缺失或冲突项、输出分析清单并转成用例。
- 依据的提供和确认分散在产品、业务、开发、测试和环境负责人之间，确认动作要落到具体的人，评审要检查依据有效性和版本对应关系。
- 判断依据是否充分，可核对每条条件有来源、版本与当前迭代一致、关键约束已覆盖、缺失项有人跟进、评审留有记录、环境数据可支撑执行、条件与用例可双向追溯。
测试分析要收集哪些依据
测试分析的起点是一份可核对的依据清单。清单里每一类依据都要写清来源、负责人和确认状态，避免分析时凭印象补规则。以下六类依据覆盖了功能测试分析的主要输入。
| 依据类别 | 典型来源 | 在测试分析中的用途 | 确认负责人 |
|---|---|---|---|
| 需求文档与验收标准 | 需求说明、用户故事、验收条件、原型 | 确定测试范围、正常路径与验收口径 | 产品经理 |
| 设计说明、接口约定与数据字典 | 概要设计、接口文档、字段说明、数据字典 | 确定输入输出、字段取值、异常返回与数据边界 | 开发负责人 |
| 业务规则、状态流转与数据约束 | 业务规则说明、状态机、权限矩阵、校验规则 | 拆出规则组合、状态迁移路径与非法操作 | 业务负责人 |
| 历史缺陷、线上问题与用户反馈 | 缺陷库、线上工单、客服记录、复盘文档 | 识别高风险区域，补充回归与异常场景 | 测试负责人 |
| 变更记录、版本范围与发布计划 | 变更单、迭代计划、发布说明 | 界定本次分析范围，判断依据是否为当前版本 | 项目经理 |
| 测试环境、测试数据与依赖系统条件 | 环境说明、数据准备方案、依赖系统接口清单 | 判断测试条件是否可执行，识别外部依赖限制 | 测试环境负责人 |
收集时建议逐项标注确认状态，例如“已确认”“待确认”“缺失”。需求与验收标准决定测什么，设计与接口约定决定怎么测输入输出，业务规则决定组合与状态路径，历史问题提示风险集中区，变更记录约束范围，环境与数据条件决定条件能否落地。六类依据中任何一类缺失，都应在清单中显式记录，而不是在分析时默认某种规则成立。
依据清单本身是一份可维护的文档。每类依据记录文档名称、版本号或更新时间、提供人和确认日期，后续需求变更时能快速判断哪些测试条件需要重做。对于跨系统场景，依赖系统的接口约定和版本也要纳入清单，避免只分析本系统而忽略上下游行为。
从依据到测试条件的操作步骤
依据收集完成后，测试分析的核心动作是把依据拆成可验证的测试条件。测试条件描述“要验证什么”，用例描述“怎么执行”，两者分开可以让分析先聚焦覆盖，再考虑步骤细节。以下五步给出输入、动作、输出和完成标志。
第一步：核对依据完整性与版本一致性
输入是依据清单，动作是逐项检查每类依据是否齐全、版本是否与当前迭代一致、确认人是否已签字或回复。输出是一份标注了缺失项和版本冲突项的核对结果。完成标志是清单中不再有“来源不明”的条目，所有待确认项都有明确跟进人。
第二步：按方法拆解测试条件
输入是已确认的需求、规则和接口约定，动作是根据场景选择设计方法：输入域用等价类划分和边界值分析，多条件组合用决策表，状态变化用状态迁移分析，业务流程用场景法。输出是一组测试条件，每条写明验证对象和预期结果。完成标志是每个需求点至少对应一条测试条件，规则组合和边界取值都有覆盖。
第三步：为每条测试条件标注依据来源
输入是测试条件列表，动作是为每条条件回填依据来源，例如“需求第3.2节”“接口文档字段status”“缺陷单BUG-1042”。输出是带来源标注的测试分析清单。完成标志是清单中不存在无来源的条件，也不存在有依据却未拆出条件的明显遗漏。
第四步：识别依据缺失或冲突并回问
分析过程中常遇到需求未写清、接口文档与实现不一致、业务规则前后矛盾的情况。动作是把这些问题整理成具体问题清单，注明涉及的测试条件和影响范围，提交给对应负责人确认。输出是问题记录及确认结论。完成标志是每个问题都有答复或明确的处理决定，答复结果回写到依据清单和测试条件中。
第五步：输出测试分析清单并转成用例
输入是评审前的测试分析清单，动作是组织评审，确认覆盖范围和优先级，评审通过后按条件编写用例。输出是可追溯的测试分析清单和用例集。完成标志是清单通过评审、每条条件能对应到用例、优先级已排定。
测试分析清单建议包含这些字段：条件编号、测试条件描述、设计方法、依据来源、优先级、关联需求、待确认项、状态。字段不必多，但要保证从用例能反查到条件、从条件能反查到依据。对于迭代节奏较快的团队，可以把清单和用例放在同一协作空间中维护，让需求变更时关联关系保持可见。ONES 支持在工作项与文档之间建立关联并保留评审记录，适合承载测试分析清单、依据链接和评审结论，具体字段和流程可按团队现有模板配置。
角色分工与各环节交付物
测试分析不是测试角色单独完成的工作，依据的提供和确认分散在产品、开发、业务和测试之间。明确谁提供、谁分析、谁评审，可以减少分析中途因依据不明而返工。
| 角色 | 主要职责 | 交付物 | 参与环节 |
|---|---|---|---|
| 产品经理 | 提供需求文档、验收标准，确认需求歧义 | 已确认的需求与验收条件 | 依据收集、问题回问 |
| 业务负责人 | 提供业务规则、状态流转、权限与数据约束 | 业务规则说明及确认结论 | 依据收集、规则确认 |
| 开发负责人 | 提供设计说明、接口约定、数据字典，说明实现约束 | 接口文档、字段说明、异常返回约定 | 依据收集、冲突澄清 |
| 测试分析人员 | 核对依据、拆解测试条件、编写分析清单 | 测试分析清单 | 全流程 |
| 测试负责人 | 组织评审、确认覆盖与优先级、跟踪缺失依据 | 评审记录、问题跟踪表 | 评审、完成检查 |
| 环境与数据负责人 | 提供环境说明、测试数据与依赖系统条件 | 环境与数据准备说明 | 依据收集、可执行性确认 |
分工的关键在于确认动作落到人。需求由产品确认，规则由业务确认，接口由开发确认，测试条件覆盖由测试负责人组织评审。评审不只是看清单格式，更要检查每条条件的依据是否有效、版本是否对应当前迭代。评审记录应保留结论和遗留问题，便于后续迭代追溯。
示例：一个订单状态变更的测试分析
以一个订单从“待支付”变为“已支付”，并可能进入“已取消”的场景为例，说明依据如何对应到测试条件。以下为演示情景，用于展示分析方法。
依据来源
- 需求文档：订单支付成功后状态变为已支付，超时未支付自动取消。
- 业务规则：支付回调可能重复到达；取消操作仅允许在待支付状态执行；已支付订单退款走独立流程。
- 接口约定：支付回调接口返回码定义，重复回调的幂等处理说明。
- 历史缺陷：曾出现重复回调导致订单重复发货的问题记录。
- 变更记录：本迭代新增“支付超时时间可配置”能力。
拆出的测试条件
| 条件编号 | 测试条件 | 设计方法 | 依据来源 | 优先级 |
|---|---|---|---|---|
| TC-01 | 待支付订单支付成功后状态变为已支付 | 场景法 | 需求文档 | 高 |
| TC-02 | 支付回调重复到达时订单只处理一次 | 等价类、历史缺陷 | 接口约定、缺陷记录 | 高 |
| TC-03 | 超时时间取边界值（最小值、最大值、临界值）时自动取消行为正确 | 边界值分析 | 变更记录、业务规则 | 高 |
| TC-04 | 已支付订单执行取消操作被拒绝 | 状态迁移分析 | 业务规则 | 中 |
| TC-05 | 待支付订单取消后不可再支付 | 状态迁移分析 | 业务规则 | 中 |
待确认项
分析中可能发现：超时时间配置的最小值是否有下限约束、支付回调重复到达时返回码是否与首次一致。这两项在需求与接口文档中描述不完整，应列入待确认项，由产品与开发分别确认后再补充或调整测试条件。确认结论回写到清单，保证后续用例编写有据可依。
完成检查：依据是否支撑用例
测试分析是否可以转入用例编写，可以用以下检查项逐条核对。检查不通过时，先补齐依据或完成确认，再进入用例设计。
- 每条测试条件都有明确的依据来源，能指向具体文档章节、接口字段或缺陷记录。
- 依据版本与当前迭代一致，变更记录中涉及的调整已反映到测试条件。
- 需求、业务规则、接口约定中的关键约束都有对应测试条件，规则组合与边界取值已覆盖。
- 缺失依据和冲突项已记录，有明确跟进人和处理状态。
- 测试条件已通过覆盖评审，评审结论和遗留问题留有记录。
- 测试环境与数据条件能够支撑条件执行，外部依赖的限制已说明。
- 测试条件与用例之间可以双向追溯，用例变更时能回查依据。
这份检查表可以作为测试分析清单的收尾动作。清单通过检查后，测试条件按优先级转入用例编写；未通过的项目记录为遗留事项，在迭代内跟进闭环。把依据清单、分析清单和评审记录放在同一处维护，后续需求变更时能快速定位受影响的测试条件，减少重复分析。
常见问题
需求文档写得很粗，测试分析还能开展吗？
可以开展，但要把缺口显式记录。先按已有需求、原型和验收条件拆出能确定的部分，把描述不清的地方整理成具体问题，注明涉及的测试条件和影响范围，提交产品经理确认。确认结论回写到依据清单和测试条件中，再补齐对应条件。依据缺失时在清单中标注“待确认”，避免分析时默认某种规则成立。
接口文档和实际实现不一致时，以哪个为依据？
以确认后的结论为依据。发现不一致时，先把差异整理成问题，说明接口文档的描述、实际观察到的行为和受影响的测试条件，交给开发负责人确认哪一方是预期行为。若实现需要修正，测试条件按文档预期编写并跟踪修复；若文档需要更新，则以更新后的接口约定为准。无论哪种结论，都要回写到依据清单，保证后续用例编写有据可依。
迭代周期短，依据清单和分析清单需要做到多细？
细度以能支撑追溯为准，不必追求字段齐全。依据清单至少记录文档名称、版本或更新时间、提供人和确认状态；分析清单至少包含条件描述、设计方法、依据来源和优先级。迭代节奏快时，可以把清单和用例放在同一协作空间中维护，需求变更时关联关系保持可见。关键约束和边界取值要有对应条件，低风险区域可以合并条件，但合并后仍要能反查到依据。
历史缺陷和线上问题在测试分析中怎么用？
历史缺陷主要用于识别高风险区域和补充异常场景。分析时查阅缺陷库、线上工单和复盘文档，把反复出现或影响较大的问题转成回归条件和异常路径条件，并在依据来源中标注对应缺陷记录。历史问题不替代需求和规则分析，它提示的是风险集中区，测试条件仍要以当前版本的需求和规则为准。
测试分析清单通过评审后，需求又变更了怎么办？
先判断变更影响范围。对照变更记录找到受影响的依据条目，定位关联的测试条件，评估需要新增、修改或作废哪些条件，再更新分析清单并补充评审记录。依据清单中记录的版本号和确认日期能帮助快速判断哪些条件基于旧版本。变更涉及的确认结论要同步给用例编写人员，避免用例与分析清单脱节。
