测试条件是从需求中提炼出的、可验证的判断依据，回答“要验证什么”；测试用例则回答“怎么验证”。本文用一个假设的“电商订单满减优惠”情景，完整演示从需求描述提炼测试条件、再展开为可执行用例的过程，逐项解释条件来源、取值依据与覆盖取舍，并给出可迁移到其他需求的提炼规律与适用边界。
要点总览（TL;DR）
- 测试条件回答“要验证什么”，测试用例回答“怎么验证”；本文用假设的电商满减优惠情景演示从需求条款到条件表、用例表与覆盖矩阵的完整填写过程。
- 金额类规则取临界值及临界值两侧，分类输入（如会员与非会员）拆成独立等价类，多条件组合用决策表逐列确认预期动作。
- 提炼测试条件可按四步执行：拆规则条款、识别输入变量、划分等价类与边界、用决策表处理组合；条件描述需写明具体取值、可观察输出与判断方向。
- 一条条件可对应多条用例，但一条用例不宜跨越多条互不相关的条件，判断标准是用例失败时能否直接定位到未满足的条件。
- 该方法适用于规则明确、输入可枚举的需求；规则模糊、强状态依赖或并发时序场景需先澄清规则或补充状态迁移与时序分析。
示例目标：这份示例要演示什么
这份示例要交付的是一份填好的测试条件表与配套用例表，让读者看到测试条件从需求条款中长出来的完整过程，而不是只看到抽象定义。
示例情景设定为：某电商平台的订单满减优惠规则。需求包含优惠门槛金额、会员与非会员的差异化门槛、优惠与优惠券的叠加限制、订单退款后的优惠处理等条款。选择这个情景，是因为它同时具备数值边界、用户分类和规则组合三类典型设计要素，适合演示等价类、边界值与决策表三种方法的配合使用。
演示目标包括三项：
- 从一段需求原文中识别出输入变量与规则条款，提炼出可验证的测试条件；
- 把每条测试条件展开为包含前置数据、操作步骤与预期结果的用例；
- 用覆盖矩阵说明条件与用例的对应关系，让覆盖情况可检查。
需要明确的是，本文情景为假设示例，需求原文、金额取值与规则细节均为演示而设，非真实客户案例，也不代表任何具体平台的业务规则。示例不覆盖测试脚本实现，也不讨论跨项目的用例资产复用；这两部分属于工程实现与资产管理范畴，与条件提炼方法本身可以分开处理。
完整示例：满减优惠需求的测试条件与用例
下面先给出假设的需求原文，再依次给出测试条件表、用例表与覆盖矩阵。三张表构成一份自洽的示例，读者可以对照自己的需求逐栏填写。
需求原文摘录（假设）
条款 R1：订单商品金额满 200 元减 30 元，满 500 元减 80 元，满 1000 元减 200 元；金额按商品金额计算，不含运费。
条款 R2：会员在 200 元档的门槛降为 180 元，其余档位门槛不变。
条款 R3：满减优惠可与优惠券叠加，但同一订单最多使用一张优惠券；满减与优惠券合计抵扣金额不得超过商品金额。
条款 R4：订单发生部分退款后，若剩余商品金额低于已享受优惠的档位门槛，按剩余金额重新计算优惠，差额从退款金额中扣回。
测试条件表
| 条件编号 | 条件描述 | 来源条款 | 设计方法 |
|---|---|---|---|
| TC-01 | 非会员订单商品金额处于 200 元档：199.99 元不享优惠，200.00 元享 30 元 | R1 | 边界值 |
| TC-02 | 非会员订单商品金额处于 500 元档：499.99 元享 30 元，500.00 元享 80 元 | R1 | 边界值 |
| TC-03 | 非会员订单商品金额处于 1000 元档：999.99 元享 80 元，1000.00 元享 200 元 | R1 | 边界值 |
| TC-04 | 运费不计入满减门槛：商品金额 190 元加运费 20 元，不享 200 元档优惠 | R1 | 等价类 |
| TC-05 | 会员 200 元档门槛为 180 元：179.99 元不享优惠，180.00 元享 30 元 | R2 | 边界值 |
| TC-06 | 会员在 500 元与 1000 元档的门槛与非会员一致 | R2 | 等价类 |
| TC-07 | 满减与一张优惠券叠加时，合计抵扣不超过商品金额 | R3 | 决策表 |
| TC-08 | 同一订单使用两张及以上优惠券时，系统拒绝或仅允许一张生效 | R3 | 决策表 |
| TC-09 | 部分退款后剩余金额低于原档位门槛，按剩余金额重算优惠并扣回差额 | R4 | 决策表 |
| TC-10 | 部分退款后剩余金额仍满足原档位门槛，优惠保持不变 | R4 | 等价类 |
用例表
| 用例编号 | 对应条件 | 前置数据 | 操作步骤 | 预期结果 |
|---|---|---|---|---|
| UC-01 | TC-01 | 非会员账号；购物车商品金额 199.99 元 | 提交订单，进入结算页 | 不显示满减优惠，应付金额为 199.99 元加运费 |
| UC-02 | TC-01 | 非会员账号；购物车商品金额 200.00 元 | 提交订单，进入结算页 | 显示满减 30 元，应付金额为 170.00 元加运费 |
| UC-03 | TC-02 | 非会员账号；商品金额 499.99 元 | 提交订单 | 按 200 元档减 30 元 |
| UC-04 | TC-02 | 非会员账号；商品金额 500.00 元 | 提交订单 | 按 500 元档减 80 元 |
| UC-05 | TC-03 | 非会员账号；商品金额 999.99 元 | 提交订单 | 按 500 元档减 80 元 |
| UC-06 | TC-03 | 非会员账号；商品金额 1000.00 元 | 提交订单 | 按 1000 元档减 200 元 |
| UC-07 | TC-04 | 非会员账号；商品金额 190 元，运费 20 元 | 提交订单 | 不享满减，应付 210 元 |
| UC-08 | TC-05 | 会员账号；商品金额 179.99 元 | 提交订单 | 不享满减 |
| UC-09 | TC-05 | 会员账号；商品金额 180.00 元 | 提交订单 | 享 30 元优惠 |
| UC-10 | TC-06 | 会员账号；商品金额 500.00 元 | 提交订单 | 按 500 元档减 80 元，门槛与非会员一致 |
| UC-11 | TC-07 | 商品金额 200 元；持有一张 180 元优惠券 | 结算时勾选优惠券 | 合计抵扣不超过 200 元，超出部分不生效或按规则截断 |
| UC-12 | TC-08 | 商品金额 300 元；持有两张可用优惠券 | 结算时尝试同时勾选 | 系统仅允许一张生效或给出明确提示 |
| UC-13 | TC-09 | 订单商品金额 520 元，已减 80 元；申请退掉 330 元商品 | 提交部分退款 | 剩余 190 元低于 500 元档，按 200 元档重算减 30 元，退款中扣回 50 元差额 |
| UC-14 | TC-10 | 订单商品金额 520 元，已减 80 元；申请退掉 20 元商品 | 提交部分退款 | 剩余 500 元仍满足门槛，优惠保持 80 元 |
覆盖矩阵
| 条件编号 | 覆盖用例 | 覆盖状态 |
|---|---|---|
| TC-01 | UC-01、UC-02 | 临界值两侧均覆盖 |
| TC-02 | UC-03、UC-04 | 临界值两侧均覆盖 |
| TC-03 | UC-05、UC-06 | 临界值两侧均覆盖 |
| TC-04 | UC-07 | 已覆盖 |
| TC-05 | UC-08、UC-09 | 临界值两侧均覆盖 |
| TC-06 | UC-10 | 已覆盖 |
| TC-07 | UC-11 | 已覆盖 |
| TC-08 | UC-12 | 已覆盖 |
| TC-09 | UC-13 | 已覆盖 |
| TC-10 | UC-14 | 已覆盖 |
覆盖矩阵的作用是让“条件是否都有用例承接”变成可核对的清单。当需求变更新增条款时，先补条件编号，再补用例，矩阵随之更新，遗漏会直接暴露在空行上。
逐项解释：每个条件为什么这样提炼
条件表看起来只是几行文字，真正决定质量的是每一行背后的取值理由。下面按类型解释示例中的关键取舍。
金额边界为何取临界值及临界值两侧
满减规则的本质是分段函数，金额在门槛点前后会跳变到不同优惠档位，错误最常发生在跳变处。因此 TC-01 至 TC-03 都取“门槛减 0.01”与“门槛本身”两个点，而不是在档位中间随便取一个金额。中间值属于同一等价类，验证一次即可；临界值两侧才可能暴露比较运算符写错（大于写成大于等于）或金额精度处理不当的问题。TC-05 对会员门槛 180 元做同样处理，是因为 R2 单独改写了这一档门槛，属于独立规则，需要独立验证。
会员与非会员为何拆为两个等价类
会员身份改变了 200 元档的门槛取值，使同一金额在不同身份下产生不同结果，这是典型的分类输入。拆成两个等价类后，非会员验证 200 元门槛，会员验证 180 元门槛，同时用 TC-06 确认会员在其余档位与非会员一致，避免把“会员所有档位都降门槛”这种误读带进用例。如果只测会员或只测非会员，另一类用户的规则分支就处于未验证状态。
优惠叠加规则为何用决策表表达
R3 涉及“是否有满减”“是否用券”“券的数量”“合计是否超限”多个条件的组合，用文字逐条列举容易漏掉组合。决策表把条件桩与动作桩对齐，每一列是一种组合及其预期动作，TC-07 与 TC-08 分别对应“合计超限”和“多券”两类组合。相比等价类，决策表更适合表达“多个条件同时成立时系统应做什么”，也方便评审时逐列确认。
哪些条件被合并、哪些被拆开
三个金额档位的边界被拆成三条条件，因为每档的优惠金额不同，任一处写错都只影响该档，合并会降低定位精度。运费不计入门槛（TC-04）单独成条，因为它验证的是计算口径而非金额边界，失败原因与边界条件完全不同。退款场景拆为 TC-09 与 TC-10 两条，分别覆盖“跌破门槛”与“仍在门槛内”两个分支，这两条路径的预期结果方向相反，合并后无法判断系统走的是哪条逻辑。
当这些条件与用例需要在需求、设计与执行之间保持可追溯时，可以把条件编号与需求条款关联、用例挂接到对应条件下，并在执行记录中回填结果。ONES 的测试管理支持用例与需求工作项的关联，评审与执行状态可以在同一处查看，便于在需求变更时定位受影响的条件与用例。
可迁移规律：换一个需求如何照做
把上面的示例抽象出来，提炼测试条件可以按四步执行，每一步都有明确的产物和完成标志。
四步提炼法
- 拆规则条款：把需求按“一句规则一个编号”拆开，标出每条规则涉及的输入与输出。完成标志是每条条款都能对应至少一个待验证的判断。
- 识别输入变量：列出金额、身份、券数量、退款金额等可变输入，标注取值范围与是否分类。完成标志是变量清单没有遗漏需求中出现的名词性条件。
- 划分等价类与边界：对连续型变量取临界值及两侧，对分类变量按取值分组。完成标志是每个变量都有“有效类、无效类、边界点”的记录。
- 用决策表处理组合：当两条以上规则同时作用于同一结果时，列出条件桩与动作桩，逐列确认预期。完成标志是组合表中没有空白列或未定义动作。
条件描述的可验证性检查
一条合格的测试条件应当让不同的人读完后得出相同的预期结果。检查时看三点：是否写明了具体输入值或取值区间；是否写明了可观察的输出（页面显示、金额、状态）；是否包含判断方向（享优惠/不享优惠、允许/拒绝）。示例中“199.99 元不享优惠，200.00 元享 30 元”同时满足这三点，而“测试满减功能是否正常”则无法据此设计用例。
条件与用例的粒度对应
一条条件可以对应一条或多条用例，但一条用例不应跨越多条互不相关的条件。示例中 TC-01 对应 UC-01 与 UC-02 两条用例，因为临界值两侧需要分别验证；TC-07 对应一条用例，因为该组合的预期是单一动作。粒度判断的标准是：用例失败时，能否直接定位到是哪条条件未满足。
常见遗漏点
- 隐含前置条件：如“会员价是否在满减计算前生效”，需求未写但影响金额，需要澄清后补条件。
- 异常输入：金额为 0、负数、超出上限、券已过期等，示例未展开，实际设计时应补充无效等价类。
- 状态依赖：订单已支付、已发货、已完成后能否退款，属于状态迁移问题，单靠条件表无法覆盖，需要补充状态分析。
适用边界：这套示例方法何时需要调整
这套方法在规则明确、输入可枚举的需求上效率最高，例如计价、门槛、配额、权限分级等条款清晰的业务规则。此时条件表能较快收敛，覆盖矩阵也能给出可信的完成判断。
遇到以下情形需要调整做法：
- 规则模糊或需求缺失：如需求只写“给予老用户适当优惠”，没有门槛与额度，应先澄清业务规则再提炼条件，直接设计用例会把猜测固化成预期。
- 强状态依赖：订单、工单、审批等对象在生命周期不同阶段行为不同，需要在条件表之外补充状态迁移分析，明确每个状态下的合法操作与非法操作。
- 并发与时序场景：库存扣减、优惠券抢领等场景的结果依赖执行顺序，等价类与决策表不足以表达，需要补充时序或并发分析。
- 取值依据：示例中的 199.99、180.00 等数字仅为演示临界值写法，实际取值必须依据真实业务规则与金额精度约定，不能直接照搬。
方法本身解决的是“验证什么”的梳理问题，用例的执行组织、评审流程与变更追踪则依赖团队约定与工具承载。把条件编号、用例与需求条款建立关联，能让这套方法在需求频繁变更时保持可维护，这也是示例之外值得同步落实的一步。
常见问题
需求里只写了“给予老用户适当优惠”，没有门槛和额度，还能先提炼测试条件吗？
这种情况建议先澄清业务规则，再提炼条件。测试条件的价值在于把一条可判断的规则固定成预期结果；如果规则本身没有门槛、额度和适用范围，提炼出的条件只能建立在猜测上，用例通过与否都无法说明需求是否被正确实现。可以先把缺失项列成问题清单（优惠对象如何界定、门槛金额、优惠额度、是否可叠加），与需求方确认后再进入条件表填写。
一条测试条件对应几条用例比较合适？
没有固定数量，判断依据是用例失败时能否直接定位到未满足的条件。临界值两侧通常各需要一条用例，例如 199.99 元与 200.00 元分别验证；预期为单一动作的组合条件，一条用例即可。如果一条用例同时覆盖多个互不相关的条件，失败后需要反复排查，说明粒度偏粗；如果一条条件拆出大量重复用例，则要检查是否在重复验证同一等价类。
示例里的金额取值可以直接用到自己的项目里吗？
不能直接照搬。示例中的 199.99、180.00 等数字是为了演示临界值写法而设定的假设值，实际取值必须依据真实业务规则与金额精度约定。套用时需要替换为需求中的真实门槛，并确认系统对小数位、四舍五入和运费口径的处理方式，否则临界值可能取在错误的位置上。
订单退款、审批流转这类带状态的需求，条件表够用吗？
条件表适合表达输入与规则的对应关系，状态依赖场景还需要补充状态迁移分析。以部分退款为例，除了验证“剩余金额跌破门槛后重算优惠”这一条件，还要明确订单处于已支付、已发货、已完成等不同状态时是否允许退款、退款后优惠如何回退。把状态与合法操作列成迁移表，再与条件表配合使用，覆盖才完整。
条件编号和用例建立关联后，需求变更时怎么维护？
需求变更时先更新条件表：新增条款补条件编号，修改条款调整对应条件的取值与预期，删除条款则标记条件失效。随后检查覆盖矩阵中哪些用例需要新增或调整，再同步用例内容。把条件编号与需求条款、用例保持关联，可以在变更发生时快速定位受影响范围，避免只改了用例却漏掉条件，或条件已更新而用例仍按旧预期执行。
