测试分析发生在需求理解之后、测试用例编写之前，任务是把需求、设计说明和风险信息拆成可验证的测试条件，回答“测什么、为什么测、测到什么程度”。它的典型输出物包括测试范围与测试项清单、测试条件与场景、风险与优先级判断、测试数据与环境需求、待确认问题清单。测试用例设计以这些输出物为输入，把测试条件转化为可执行用例，并回溯每条用例覆盖的测试项，形成从分析到用例的可追踪链条。
要点总览（TL;DR）
- 测试分析位于需求评审之后、用例编写之前，核心任务是回答测什么、为什么测、测到什么程度，为用例设计确定方向和覆盖面。
- 典型输出物包括测试范围与测试项清单、测试条件与业务场景、风险与优先级判断、测试数据与环境需求、待确认问题与假设清单。
- 衔接方式是逐层拆分：测试项确定用例集结构，测试条件展开为前置条件、步骤和预期结果，风险优先级决定用例优先级与覆盖深度。
- 用双向追溯和两次评审保障衔接质量：分析完成后评审范围与条件，用例完成后评审覆盖度，分析变更时同步修订关联用例。
- 常见误解是把分析等同于写用例、把输出物当形式文档、要求分析一次做完；缺少分析直接写用例，容易漏掉业务规则组合和异常路径。
测试分析在测试设计流程中承担什么任务
测试分析是测试设计的前置分析环节。团队完成需求评审、拿到需求说明和设计说明后，先不急于写用例，而是把需求拆解为若干可验证的测试点，判断每个测试点对应的业务规则、输入边界、状态变化和异常路径。分析结论稳定后，再进入用例编写。这个顺序的价值在于：用例编写是相对机械的转化工作，分析决定了转化的方向和覆盖面，方向错了，用例写得再多也补不回来。
测试分析与前后环节的关系可以这样理解。需求评审解决“需求是否合理、是否可测”，测试分析解决“从测试角度要验证哪些内容”，用例编写解决“每条验证怎么执行”。三者依次衔接，前一步的输出是后一步的输入。需求评审中记录的问题会影响分析范围，分析中标记的待确认问题又会回流到需求方澄清，形成一个小循环。
分析阶段要回答四类核心问题。第一是范围：本次变更涉及哪些功能、模块、接口和业务链路，哪些不在本次测试范围内。第二是条件：每个测试项在什么输入、状态、权限、数据条件下才成立，边界在哪里。第三是风险：哪些测试项一旦出问题影响最大，哪些实现复杂度高、变更频繁、历史缺陷多。第四是优先级：在时间和人力有限时，先测什么、测到什么深度。这四类问题的答案，构成了后续所有输出物的骨架。
测试分析的输出物包括哪些内容
测试分析的输出物是一组决策依据，用来支撑用例设计和测试执行安排。它们可以记录在文档、表格或管理工具的工作项中，形式不限，内容完整才有意义。下面逐项说明主要输出物及其应包含的字段。
| 输出物 | 核心字段 | 作用 |
|---|---|---|
| 测试范围与测试项清单 | 测试项编号、所属模块、需求来源、是否本次范围、简要说明 | 界定测什么，作为用例拆分的顶层单元 |
| 测试条件与业务场景 | 条件编号、对应测试项、输入数据、前置状态、业务规则、预期行为 | 把测试项细化为可验证的条件 |
| 风险与优先级判断 | 风险描述、影响程度、发生可能性、优先级、判断依据 | 决定用例优先级和覆盖深度 |
| 测试数据与环境需求 | 数据类型、数据量、构造方式、环境配置、依赖系统、账号权限 | 保证用例可执行，提前暴露准备成本 |
| 待确认问题与假设清单 | 问题编号、关联测试项、问题描述、当前假设、责任人、期望答复时间 | 记录分析中的不确定点，避免带着猜测写用例 |
测试范围与测试项清单要写清“不测什么”。只列测试内容，评审时很难发现遗漏；明确排除项并说明理由，才能让相关方确认边界。测试项应颗粒度适中，一个测试项对应一组相关测试条件，过粗会导致用例难以追溯，过细会让清单膨胀到无法维护。
测试条件与业务场景是分析的核心产物。每条条件应描述清楚输入、前置状态和预期行为，例如“订单金额达到包邮门槛时，运费显示为零”。条件写成可判定的陈述，后续转化为预期结果时才不会含糊。业务场景则把多个条件按用户操作顺序串起来，用于覆盖跨功能的完整链路。
风险与优先级判断要给出依据，不能只标高、中、低。依据可以来自需求变更频率、实现复杂度、历史缺陷分布、业务影响面、合规要求等。测试数据与环境需求常被忽略，等到执行时才发现缺少测试账号或依赖系统不可用，会直接拖慢进度，分析阶段提前列出能显著降低这类阻塞。待确认问题清单则要指定责任人和期望答复时间，否则问题会一直悬置。
输出物如何转化为测试用例
从分析输出物到用例，核心动作是逐层拆分和逐条映射。测试项清单提供顶层结构，每个测试项下挂一组测试条件，每条测试条件再展开为一到多条用例。拆分时遵循一个原则：一条用例验证一个明确的预期结果，条件中的输入组合、边界值、异常路径分别成例，避免把多个验证点塞进一条用例导致失败时难以定位。
测试条件转化为用例时，需要补齐四个要素。前置条件来自条件中的前置状态和环境需求，例如“用户已登录且购物车中有商品”。操作步骤把条件中的输入和操作顺序写成可执行的动作。预期结果直接对应条件中描述的预期行为，要具体到界面提示、数据变化或状态流转。优先级继承风险判断的结论，高风险测试项下的用例优先级相应提高，覆盖深度也更大，例如补充边界组合和异常恢复场景。
| 分析输出物 | 在用例设计中的用途 | 映射方式 |
|---|---|---|
| 测试项清单 | 确定用例集的组织结构 | 一个测试项对应一个用例集或一组用例 |
| 测试条件 | 生成用例主体 | 每条条件展开为前置条件、步骤、预期结果 |
| 风险与优先级 | 决定用例优先级和覆盖深度 | 高风险项增加边界与异常用例，优先级同步标注 |
| 数据与环境需求 | 写入用例前置条件 | 数据构造方式、环境配置作为执行前提记录 |
| 待确认问题 | 标注用例的不确定处 | 在用例中标记关联问题编号，答复后回填并修订 |
待确认问题在用例中的处理需要特别说明。分析阶段尚未澄清的问题，不应阻止用例框架的搭建，但要在相关用例上标注问题编号和当前假设。问题澄清后，按编号找到受影响的用例统一修订，避免遗漏。这种做法让用例编写和需求澄清并行推进，同时保留修订线索。
衔接过程中的可追踪关系与评审节点
可追踪关系是分析到用例之间质量保障的基础。每条用例应记录它覆盖的测试项或测试条件编号，每个测试项也应能反查覆盖它的用例。正向追溯用于检查测试项是否都有用例覆盖，反向追溯用于确认每条用例都有分析依据，避免出现没有来源的“拍脑袋”用例。双向追溯建立后，需求变更时可以先定位受影响的测试项，再找到关联用例批量更新。
评审是检查衔接质量的关键节点，通常安排两次。第一次在分析输出物完成后，评审测试范围是否完整、测试条件是否覆盖主要业务规则和异常路径、风险判断是否有依据、待确认问题是否都有责任人。第二次在用例编写完成后，重点检查覆盖度：每个测试项是否至少有一条用例，高风险项是否达到约定的覆盖深度，用例的预期结果是否与分析条件一致。评审发现的问题应记录并跟踪关闭，而不是口头确认。
分析变更后的同步更新容易被忽视。需求澄清、范围调整或风险判断变化时，测试项和测试条件会随之修改，关联用例必须同步修订。实践中可以在测试项上记录变更说明，用例评审时抽查变更项对应的用例是否已更新。把测试项、测试条件和用例放在同一管理工具中维护关联关系，追溯和同步的成本会明显降低。ONES 支持在工作项之间建立关联关系，测试人员可以把测试项、测试条件与用例作为相互关联的工作项管理，在需求或分析变更时沿关联关系定位受影响的用例，并在评审中按关联视图检查覆盖情况。
测试分析与测试用例设计的区别及常见误解
两个环节的关注点不同。测试分析关注“测什么、为什么测”，产出的是范围、条件、风险和优先级判断；测试用例设计关注“怎么测”，产出的是可执行的前置条件、操作步骤和预期结果。分析决定覆盖的方向和深度，用例设计决定执行的具体方式。把两者混为一谈，往往导致用例数量不少但关键场景缺失。
常见误解之一是把分析等同于写用例，认为只要开始写用例就是在做分析。实际上，缺少分析直接写用例，测试人员只能凭经验逐条设想操作，容易漏掉业务规则组合、状态流转和异常路径，覆盖度依赖个人水平，难以评审和交接。误解之二是把输出物当成形式文档，为了填模板而填，测试项清单写得笼统，风险等级没有依据，待确认问题不指定责任人，这样的输出物无法支撑用例设计。误解之三是认为分析必须一次做完、完全确定后才能写用例。分析可以与需求澄清并行，未确定的部分以待确认问题和假设标注，后续回填修订，关键是保留线索而不是追求一次到位。
分析缺失的后果通常在测试执行或上线后暴露：边界条件没有覆盖导致缺陷漏出，高风险模块测试深度不足，用例之间大量重复而关键路径无人验证，需求变更后无法判断哪些用例需要更新。这些问题的根源都在分析环节，补用例只能缓解表面症状。
一个具体例子：从分析输出物到用例
假设某电商系统新增“满额包邮”规则：订单商品金额达到99元免运费，未达到收取10元运费，使用优惠券后按优惠后金额判断。以下为演示情景，用于说明分析到用例的转化过程。
分析阶段产出如下。测试项清单列出三项：包邮门槛判断、优惠券叠加后的金额计算、运费展示与订单金额一致性。测试条件包括：金额等于99元时免运费；金额为98.99元时收取10元；金额为0元的空订单处理；使用满减券后金额降至99元以下时恢复收运费；运费在订单确认页和支付页展示一致。风险判断将“优惠券叠加后的金额计算”标为高优先级，依据是该规则涉及多个金额计算环节、历史缺陷较多。数据与环境需求记录需要可配置的商品价格、可用的满减券和免邮券、测试环境运费规则开关。待确认问题列出：优惠券与运费减免同时适用时的优先级，责任人為产品经理。
用例设计阶段，测试条件逐条展开。以“使用满减券后金额降至99元以下时恢复收运费”为例，生成用例：前置条件为购物车商品金额105元、账户持有一张满100减10的优惠券；步骤为进入结算页、选择该优惠券、确认订单金额；预期结果为优惠后金额95元、运费显示10元、应付总额105元。高风险测试项下补充异常用例，例如优惠券使用后订单金额恰好为99元的边界情况。待确认问题在相关用例上标注编号，产品经理答复后回填预期结果并修订用例。
覆盖检查时，按测试项反查用例：三个测试项均有对应用例，高风险项除正常路径外包含边界和异常用例，待确认问题均有标注且已指定责任人。检查通过后进入用例评审，评审记录覆盖结论和遗留问题，作为本轮测试设计的完成标志。
常见问题
测试分析输出物需要写到多细才算够用？
判断标准是能否支撑用例设计和评审，而非篇幅。测试项应细到能作为用例集的顶层单元，一个测试项对应一组相关测试条件；测试条件应写成可判定的陈述，包含输入、前置状态和预期行为，让不同测试人员据此写出的用例预期结果一致。如果评审时相关方无法据此判断覆盖是否完整，或写用例时仍需反复猜测业务规则，说明颗粒度还不够。
需求还在澄清中，可以先开始写测试用例吗？
可以，前提是把不确定部分显式标注。分析阶段将未澄清的问题记入待确认问题清单，指定责任人和期望答复时间；用例中关联问题编号并写明当前假设。问题澄清后按编号定位受影响用例统一修订。这样用例编写与需求澄清并行推进，同时保留修订线索，避免带着未记录的猜测写用例。
测试项和用例的追溯关系维护成本高，有没有轻量做法？
轻量做法是只维护必要关联：每条用例记录覆盖的测试项编号，测试项上不重复维护用例列表，通过反查获得。追溯关系随用例创建时一并填写，避免事后补录。把测试项和用例放在同一管理工具中维护关联，变更时沿关联关系定位受影响用例，比在多个文档间人工比对更省成本。ONES 支持在工作项之间建立关联关系，可用于承载测试项与用例的追溯。
分析输出物和用例评审能否合并成一次？
可以合并，但检查重点要分开。合并评审时先确认测试范围、测试条件和风险判断是否完整，再检查用例覆盖度，两类问题分别记录。合并的代价是评审材料较多、单次时间较长；如果需求变更频繁或测试项数量大，分两次评审更容易聚焦。无论合并与否，评审发现的问题都应记录并跟踪关闭。
测试分析输出物应该由谁编写和确认？
通常由负责该需求测试设计的测试人员编写，测试负责人或资深测试人员评审，产品经理和开发人员确认待确认问题。风险与优先级判断需要结合业务影响和技术实现信息，编写时宜与产品、开发沟通后再定稿。确认环节的重点是范围边界和待确认问题，而非文档格式。
