测试分析要回答的是“测什么、为什么测、测到什么程度”，支撑这些判断的输入远不止一份需求文档。需求与验收标准、设计与接口说明、业务规则与数据约束、历史缺陷、变更记录、标准合规要求，以及可用的测试环境和数据，共同构成分析依据。把这些依据逐条落到测试项和覆盖判断上，形成可追溯、可评审的分析记录，才算完成测试分析，可以进入用例设计。
要点总览（TL;DR）
- 测试分析的依据分七类：需求与验收标准、设计与接口说明、业务规则与数据约束、历史缺陷与线上问题、变更与发布记录、标准合规与合同要求、环境与数据条件，每类回答不同的分析问题。
- 依据要经过收集登记、拆解测试条件、识别风险与优先级、输出测试项与覆盖说明四步，才能转化为用例设计的输入。
- 产品、开发、测试、运维和评审角色各自对某类依据负责，分工明确可以减少分析阶段的来回追问。
- 依据不全时标注“待确认”并指定责任人，把测试项保留在清单中，避免因信息缺失漏掉测试范围。
- 进入用例设计前，用可追溯、覆盖完整、版本对齐、未覆盖项有交代、评审留痕五项标准判断分析是否完成。
测试分析的依据分几类，各自回答什么问题
测试分析常见的偏差是只盯需求文档：需求写了什么就测什么，需求没写的边界、异常和运行条件被整体遗漏。把依据按“回答什么问题”分成七类，可以对照检查手头输入是否齐全，也能解释每类依据缺失时会带来什么风险。
| 类别 | 典型来源 | 回答的问题 | 缺失时的风险 |
|---|---|---|---|
| 需求与验收标准 | 需求文档、用户故事、验收条件、原型说明 | 系统该做什么，做到什么程度算通过 | 测试项与业务目标脱节，验收时争议“算不算完成” |
| 设计与接口说明 | 概要设计、详细设计、接口文档、数据模型、状态机 | 功能怎么实现，模块边界和交互点在哪 | 集成点、异常分支和边界条件漏测 |
| 业务规则与数据约束 | 业务规则说明、字段校验规则、字典与枚举、权限矩阵 | 规则在什么条件下成立，数据有哪些合法范围 | 组合条件、临界值和非法输入覆盖不足 |
| 历史缺陷与线上问题 | 缺陷库、线上故障记录、客服与工单反馈、监控告警 | 哪里容易出错，哪些场景反复出问题 | 高风险区域未被重点覆盖，同类问题重复发生 |
| 变更与发布记录 | 变更单、版本发布说明、代码提交记录、配置变更 | 这次改了什么，影响范围到哪里 | 回归范围判断失误，改动引入的新问题漏测 |
| 标准、合规与合同要求 | 行业标准、监管要求、合同条款、安全与隐私规范 | 哪些要求必须满足，需要什么证据 | 合规项缺失，交付验收或审计不通过 |
| 环境与数据条件 | 测试环境说明、测试数据、第三方依赖与桩、账号与权限 | 这些场景能不能实际验证 | 测试项无法执行，或执行结果不可信 |
七类依据的作用不同，使用方式也不同。需求与验收标准决定测试项的来源；设计与接口说明决定测试条件的深度；业务规则与数据约束决定用例的取值组合；历史缺陷用于调整优先级；变更记录用于圈定回归范围；标准与合规要求形成必须覆盖的硬性条目；环境与数据条件决定哪些测试项当前可执行。分析时逐类过一遍，比只读需求更容易发现空白。
从依据到测试项：四步操作流程
依据收集齐不等于分析完成。下面四步把分散的输入转化为可设计用例的测试项，每一步都有明确的输入、动作、输出和完成标志。
第一步：收集与登记依据
输入：需求文档、设计文档、接口说明、规则说明、缺陷记录、变更单、标准条款等原始材料。
动作：建立依据清单，每条记录名称、来源、提供人、版本或日期、获取位置。同一需求存在多个版本时，以评审通过的版本为准，并注明替代关系。
输出：带来源和版本的依据清单。
完成标志：清单中每条依据都能定位到具体文档或记录，版本与当前迭代一致。
第二步：拆解需求为可验证的测试条件
输入：依据清单中的需求条目、验收标准、业务规则和接口说明。
动作：把每条需求拆成若干可验证的测试条件，每个条件描述一个可观察的输入与预期结果，例如“订单金额为负时提交，系统拒绝并提示金额非法”。同时从设计说明中补充异常分支、边界值和状态转换条件。
输出：测试条件列表，每条标注对应的依据编号。
完成标志：每条需求至少对应一个测试条件，验收标准中的每个可判定条目都有条件承接。
第三步：识别风险与优先级，确定分析深度
输入：测试条件列表、历史缺陷分布、变更影响范围、业务重要性说明。
动作：按业务影响、出错概率、变更幅度和合规要求给测试条件定优先级。高频出错模块、本次改动涉及的核心链路、合规硬性条目列为高优先级，分析深度到异常路径和组合条件；低风险区域可做常规覆盖。
输出：带优先级的测试条件清单和风险说明。
完成标志：每个高优先级条件都有明确的覆盖理由，优先级判断有依据可查。
第四步：输出测试项清单与覆盖说明
输入：带优先级的测试条件、环境与数据条件说明。
动作：把测试条件归并为测试项，每个测试项写明验证目标、前置条件、依据来源和优先级。对当前无法覆盖的条目，标注原因（如环境未就绪、规则待确认、数据不可构造）和责任人，不直接删除。
输出：测试项清单和覆盖说明，作为用例设计的直接输入。
完成标志：每条测试项可追溯到具体依据，未覆盖项均有原因和责任人。
这四步的产物可以在文档或测试管理工具中承载。以ONES为例，测试用例支持与产品需求、研发任务关联，测试计划可与迭代关联，测试项和用例能够挂接到对应需求上，形成从依据到用例的追溯链条；用例属性可自定义，便于按业务场景补充优先级、依据来源等字段。分析记录和评审结论也可以随需求一并留存，方便后续核对。
角色分工与各环节交付物
依据不全往往不是没人收集，而是没人对某类输入负责。把提供、分析、评审三类职责落到具体角色，并约定各自交付什么，可以减少分析阶段的来回追问。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 产品/业务方 | 提供需求与验收标准，确认业务规则和优先级 | 评审通过的需求文档、可判定的验收条件、业务规则说明 |
| 开发 | 提供设计与接口说明，说明本次变更范围和影响点 | 设计文档、接口文档、变更说明、影响范围清单 |
| 测试分析人员 | 登记依据、拆解测试条件、判断覆盖程度、输出测试项 | 依据清单、测试条件列表、测试项清单与覆盖说明 |
| 运维或支持 | 提供线上问题、故障记录和日志线索 | 线上问题清单、典型故障场景说明 |
| 评审角色（测试负责人、产品、开发代表） | 确认覆盖充分性，识别遗漏风险，对未覆盖项给出处理意见 | 评审意见与结论记录 |
分工的关键是让每类依据都有明确提供人。需求与验收标准由产品负责，接口与变更影响由开发负责，线上问题由运维或支持负责，测试分析人员负责整合并做覆盖判断。评审环节重点看两件事：高优先级测试项是否有依据支撑，未覆盖项的原因是否成立。评审结论留痕，后续需求变更时可以据此判断分析记录是否需要更新。
示例：一个订单改价需求的分析依据与测试项
以下为演示用虚构场景，用于说明依据如何落到测试项，不代表真实项目。
需求概述：客服在订单支付前可对订单执行改价，改价金额需在限定范围内，改价后订单金额同步更新并记录操作日志。
依据条目：
- 需求文档与验收标准：改价入口仅对客服角色开放；改价后金额即时生效；操作留痕。
- 业务规则说明：改价幅度不超过原价的指定比例，改价后金额不得低于成本价。
- 接口说明：改价接口的入参、返回码及失败提示。
- 历史缺陷：以往版本出现过并发改价导致金额覆盖的问题。
- 变更记录：本次新增改价权限校验和日志字段。
- 环境与数据：测试环境具备客服账号和可改价订单数据。
拆出的测试条件：非客服角色调用改价入口被拒绝；改价幅度在范围内成功、超出范围被拒绝；改价后金额低于成本价被拒绝；两名客服同时对同一订单改价时结果一致且不丢失；改价成功后日志包含操作人、原金额、新金额和时间；改价后订单列表与详情金额一致。
形成的测试项与优先级：权限校验（高，对应本次变更）、幅度与成本价边界（高，对应业务规则）、并发改价（高，对应历史缺陷）、日志完整性（中，对应验收标准）、金额展示一致性（中，对应验收标准）。
待确认项：改价幅度的具体比例在需求中未写明，标注“待确认”，责任人为产品；并发场景的锁机制在接口说明中未描述，标注“待确认”，责任人为开发。两项均保留在测试项清单中，待确认后再补充具体取值和验证方式。
完成检查：分析依据是否够用
进入用例设计前，用下面这份清单逐项核对。全部满足或未满足项已有明确处理意见，才说明本次测试分析的依据足够支撑后续设计。
- 可追溯：每条测试项都能指向具体依据条目，依据清单中的关键条目都有测试项承接。
- 覆盖完整：关键业务规则、异常路径、边界条件和本次变更影响范围均已覆盖，高优先级项有覆盖理由。
- 版本对齐：依据清单中的文档版本与当前迭代一致，需求变更后分析记录已同步更新。
- 未覆盖项有交代：每条未覆盖项写明原因、责任人和计划处理时间，不以“暂不测试”简单带过。
- 评审留痕：评审已进行，参与角色和结论有记录，评审提出的补充项已回填到测试项清单。
检查中发现依据缺失时，处理方式是标注“待确认”并指定责任人，把该测试项保留在清单中，待依据补齐后再细化。这样既不会因为信息不全而漏掉测试范围，也能让分析进度和风险对相关角色可见。分析记录与需求、用例保持关联，后续回归和变更影响判断都可以直接复用。
常见问题
需求文档写得很简略，测试分析还能做吗？
可以做，但需要把缺失部分显式标注出来。需求简略时，先从设计与接口说明、业务规则、历史缺陷中补充可验证的条件，把能确定的部分拆成测试项；对无法判断的取值、边界和异常处理，在分析记录中标注“待确认”，写明责任人和需要补充的信息。这样测试范围不会因为文档简略而收缩，待需求补充后再细化对应测试项。
测试分析记录需要和需求、用例保持关联吗？
建议保持关联。测试项标注依据来源后，需求变更时能快速定位哪些测试项需要重新分析；用例设计完成后，也能从用例反查它覆盖了哪条依据。在文档中可以用编号建立对应关系，在测试管理工具中则可以把测试项和用例挂接到对应需求上。以 ONES 为例，测试用例支持与产品需求、研发任务关联，便于形成从依据到用例的追溯链条。
历史缺陷和线上问题应该怎么用在测试分析里？
主要用来调整优先级和分析深度。把缺陷库、线上故障记录、客服工单和监控告警按模块和场景归类，找出反复出问题的区域，对应测试条件列为高优先级，分析深度延伸到异常路径和组合条件。同类问题曾经发生过的场景，要在测试项中明确写出验证方式，避免只做常规覆盖。
依据版本和当前迭代不一致时怎么处理？
以评审通过的版本为准，并在依据清单中注明版本、日期和替代关系。发现文档版本落后于当前迭代时，先向提供人确认最新版本，再更新分析记录；确认前受影响的测试项标注“待确认”，不按旧版本直接设计用例。需求变更后，同步检查已拆出的测试条件是否仍然成立。
测试分析评审应该看什么，评审结论怎么留？
评审重点看两件事：高优先级测试项是否有依据支撑，未覆盖项的原因是否成立。参与角色通常包括测试负责人、产品和开发代表，评审提出的补充项要回填到测试项清单。评审结论记录参与角色、意见和处理结果，与需求、分析记录一并留存，后续需求变更时可以据此判断分析是否需要更新。
