测试场景描述用户在特定条件下要完成的一件事及其预期结果，粒度较粗，用来界定“测什么”；测试用例则把某个场景下的前置条件、操作步骤、测试数据和预期结果写清楚，是可执行、可判定的最小验证单元，用来界定“怎么测、怎么判断通过”。一个场景通常拆成多条用例，场景负责覆盖方向，用例负责落地验证。
要点总览（TL;DR）
- 测试场景描述“谁在什么条件下要完成哪件事、预期得到什么结果”，粒度较粗，用来界定测试范围与覆盖方向。
- 测试用例把前置条件、操作步骤、测试数据和预期结果写清楚，是可执行、可判定的最小验证单元，用来界定怎么测、怎么判断通过。
- 两者是包含与细化关系：一个场景通常拆成多条用例，按正常流、异常流和边界条件拆分，再用场景清单核对覆盖。
- 场景评审关注范围是否完整、业务目标与异常情形是否遗漏；用例评审关注前置条件、步骤可复现性和预期结果可判定。
- 常见误解是把场景当用例、认为用例越细越好、跳过场景直接写用例，后果是覆盖情况说不清、维护成本上升。
一句话说清两者的区别
如果只记一句话：测试场景回答“要测哪件事”，测试用例回答“这件事怎么一步步测、结果怎么算通过”。场景是覆盖维度的描述，用例是可执行维度的描述，两者是包含与细化关系，不能互相替代。
举例来说，“用户使用优惠券提交订单”是一个场景，它说明了角色、业务目标和预期结果；而“优惠券已过期时提交订单，提示不可用并保留原价”则是一条用例，它把前置条件、操作和判定标准都固定下来。场景写得再清楚，也无法直接交给执行人员照着操作；用例写得再细，如果缺少场景层面的组织，也容易漏掉业务分支。
| 对比维度 | 测试场景 | 测试用例 |
|---|---|---|
| 定义与粒度 | 较粗，描述一件事及其预期结果 | 较细，描述一次可执行验证 |
| 组成要素 | 角色、业务目标、触发条件、预期结果 | 编号、前置条件、步骤、数据、预期结果、优先级 |
| 主要用途 | 界定测试范围与覆盖方向 | 支撑执行、判定通过与回归 |
| 可执行性 | 不直接执行，需要继续拆解 | 可直接执行并给出通过与否的结论 |
| 数量关系 | 一个场景对应多条用例 | 多条用例共同覆盖一个场景 |
测试场景的范围与边界
测试场景的组成可以归纳为四个要素：谁在什么条件下、为了什么目标、触发什么操作、得到什么预期结果。它站在业务或用户视角，把需求或用户故事翻译成一件可被验证的事。例如“新用户在注册后首次下单”这一场景，角色是新用户，触发条件是完成注册，业务目标是成功下单，预期结果是订单创建并进入待支付状态。
场景与需求、用户故事的衔接方式，是从需求中提取业务目标和关键路径，再补充异常与边界情形形成场景清单。需求文档里的“支持优惠券抵扣”是功能描述，转成场景则可能是“有可用优惠券的用户提交订单”“优惠券已过期的用户提交订单”“优惠券与活动价叠加时提交订单”等若干条。
场景的边界在于它不承担逐步操作与数据细节。它不写“点击结算按钮、输入验证码、等待三秒”，也不规定具体用哪张优惠券、金额多少。这些属于用例层的内容。场景同样不包含跨项目资产复用、具体测试脚本实现等工程性安排，这些是测试管理与自动化建设的话题，超出场景定义本身。
测试用例的组成与可执行要求
用例之所以必须可执行、可判定，是因为它承担着执行与回归的职责。一条合格的用例，换一个人照着做也能得到相同结论；如果预期结果写成“系统正常”“页面显示正确”，执行时就无法判断通过与否。
| 字段 | 作用 | 填写要求 |
|---|---|---|
| 用例编号 | 唯一标识，便于引用与追踪 | 项目内唯一，稳定不变 |
| 前置条件 | 执行前必须满足的环境与数据状态 | 具体到账号状态、数据准备、配置项 |
| 操作步骤 | 按顺序描述执行动作 | 每步一个动作，可被他人复现 |
| 测试数据 | 步骤中使用的输入值 | 明确取值，边界值单独列出 |
| 预期结果 | 判定通过的依据 | 可观察、可核对，避免模糊表述 |
| 优先级 | 决定执行顺序与回归范围 | 结合业务重要性与风险设定 |
用例与场景的对应关系体现在归属上：每条用例应能指向它服务的场景，便于统计某场景是否被完整覆盖。用例粒度以“一次可独立验证的验证点”为宜，过粗会导致失败原因难以定位，过细则会产生大量重复步骤、增加维护成本。设计质量可以从三个角度检查：覆盖是否完整，判定标准是否明确，后续需求变化时是否容易修改。
从场景到用例的拆解机制
拆解的基本路径是先分流程类型，再落数据与条件，最后核对覆盖。具体可按以下步骤进行：
- 识别场景中的正常流，写出主路径用例，确认业务目标能够达成。
- 列出异常流，例如支付失败、库存不足、权限缺失，每条异常流至少对应一条用例。
- 找出边界条件，例如金额上下限、时间临界点、数量为零或最大值，转化为带具体数据的用例。
- 为每条用例补齐前置条件与测试数据，使执行者无需再自行推断。
- 回看场景清单，确认每个场景都有用例覆盖，且没有两条用例验证同一件事。
覆盖度判断可以用一个简单口径：场景中描述的每个预期结果，都能在至少一条用例的预期结果中找到对应；场景涉及的每个分支，都能在用例列表中找到入口。拆解时的取舍在于，异常流不必穷举所有组合，优先覆盖高概率和高影响的分支，其余组合可通过风险判断决定是否补充。
当场景数量增多、用例分散在多人手中时，场景与用例的对应关系需要被显式记录，否则容易出现某场景无人认领或重复编写。在ONES中，需求与测试工作项可以建立关联，场景作为测试方向的描述挂在需求下，用例作为可执行条目逐条编写并关联到对应场景，评审时按场景逐个核对覆盖情况，执行结果也回写到同一处，便于判断哪些场景已经验证、哪些仍有缺口。
容易混淆的相邻概念
测试点、测试步骤、测试脚本常与场景、用例混用，区分它们有助于在评审时说清各自关注什么。
| 概念 | 含义 | 与场景、用例的关系 |
|---|---|---|
| 测试点 | 需要验证的一个关注项，如“优惠券过期校验” | 比场景更细、比用例更粗，是拆解过程中的中间产物 |
| 测试步骤 | 用例内部的操作序列 | 用例的组成部分，不能独立成为用例 |
| 测试脚本 | 可被工具执行的代码或配置 | 用例的一种实现形式，一条用例可能对应一段脚本 |
评审时的关注点也不同。场景评审看的是范围是否完整、业务目标是否遗漏、异常情形是否考虑到；用例评审看的是前置条件是否充分、步骤是否可复现、预期结果是否可判定、数据是否具体。把两者放在同一次评审里讨论，容易出现“范围没定就抠步骤”的情况，效率反而下降。
具体例子与常见误解
以一个电商下单场景为例。场景描述为：已登录用户在购物车中选中商品，使用一张满减优惠券提交订单，预期订单金额按优惠后计算并进入待支付状态。围绕这个场景，可以拆出以下用例：
- 用例一：优惠券在有效期内且满足门槛，提交订单后金额正确扣减，订单状态为待支付。
- 用例二：优惠券已过期，提交订单时提示不可用，订单金额为原价。
- 用例三：订单金额刚好等于优惠门槛，验证优惠可以生效。
- 用例四：订单金额比门槛少一元，验证优惠不可用并给出提示。
四条用例共同覆盖一个场景，分别对应正常流、异常流和两个边界条件。执行时按用例逐条判定，汇总后即可回答“这个场景是否验证通过”。
常见误解有三个。其一，把场景当用例，认为写清业务目标就可以直接执行，结果执行者各自理解不同，回归时结论不一致。其二，认为用例越细越好，把每个点击都拆成独立用例，导致用例数量膨胀、维护成本上升，需求一变就要大面积修改。其三，认为场景可以跳过，直接写用例，短期看节省了时间，长期则容易出现分支遗漏，尤其在需求频繁变更时，缺少场景层就难以判断新增用例该挂在哪里、旧用例是否还有效。
这三种误解的共同后果是覆盖情况说不清：要么执行了却不知道验证了哪些业务目标，要么以为覆盖完整、实际漏掉了关键分支。把场景作为组织单元、把用例作为执行单元，两者各司其职，测试设计的方向与落地才能同时得到保证。
常见问题
测试场景和测试用例可以只写一种吗？
两种都写更稳妥，但侧重点不同。只写场景，执行者需要自行推断步骤和数据，不同人执行可能得出不同结论，回归时难以对比；只写用例，短期能支撑执行，但缺少场景层组织，需求变更时不容易判断新增用例该挂在哪里、旧用例是否还有效。实践中可以把场景作为组织单元、用例作为执行单元，两者各司其职。
一个测试场景拆成多少条用例比较合适？
没有固定数量，取决于场景涉及的分支和数据条件。一般先保证正常流有一条主路径用例，每条异常流至少对应一条用例，边界条件按金额上下限、时间临界点、数量为零或最大值等转化为带具体数据的用例。异常组合不必穷举，优先覆盖高概率和高影响的分支，其余组合按风险判断决定是否补充。
用例写得越细，测试质量就越高吗？
粒度以“一次可独立验证的验证点”为宜。过粗会导致失败原因难以定位，过细则把每个点击都拆成独立用例，用例数量膨胀，需求一变就要大面积修改，维护成本上升。判断粒度是否合适，可以看执行者能否照着复现、失败时能否快速定位到具体环节、需求变化时修改范围是否可控。
场景和用例应该放在同一次评审里吗？
建议分开或分阶段评审。场景评审关注范围是否完整、业务目标是否遗漏、异常情形是否考虑到；用例评审关注前置条件是否充分、步骤是否可复现、预期结果是否可判定、数据是否具体。放在同一次评审里讨论，容易出现范围还没定就抠步骤的情况，效率反而下降。
需求变更后，场景和用例分别要做什么调整？
先看变更影响的是业务目标还是执行细节。如果业务目标或关键路径变化，先更新场景清单，再判断哪些用例需要新增、修改或废弃；如果只是数据取值或界面操作变化，通常只改用例层的前置条件和步骤。场景与用例的对应关系被显式记录时，这类影响分析会更快，也更容易发现某场景在变更后失去覆盖。
