等价类划分是一种黑盒测试用例设计方法：把输入或输出数据按“处理逻辑相同、暴露缺陷的可能性相近”分成若干集合，每个集合就是一个等价类，再从每个类中选取代表性数据形成用例。有效等价类验证合法输入能否被正确处理，无效等价类验证非法输入能否被正确拒绝。本文说明它的定义、适用边界、划分规则，以及它与边界值分析、决策表的区别。
要点总览（TL;DR）
- 等价类划分是一种黑盒测试用例设计方法：按处理逻辑相同、暴露缺陷可能性相近的原则把输入或输出数据分成若干集合，再从每个类中取代表值设计用例。
- 有效等价类验证合法输入能否被正确处理，无效等价类验证非法输入能否被正确拒绝；两类要成对考虑，无效类通常一次只放一个非法条件。
- 划分以需求条款为锚，按取值范围、数据类型与格式、必填与选填、业务规则、枚举集合等依据分组，并用类编号、条件描述、代表值、预期结果登记成表。
- 等价类划分取类内代表值，边界值分析取交界点及邻近值，决策表处理多条件组合；实践中先划分等价类，再补边界值，条件组合复杂时用决策表。
- 常见误解包括随机取几个值当划分、只做有效类、划分后不登记、把多个非法条件塞进一条用例，纠正后直接影响用例评审与后续维护的质量。
等价类划分的直接定义
等价类划分（Equivalence Partitioning）可以复述为：依据需求规格，把被测对象的输入域或输出域切分成若干互不重叠的子集，使同一子集内的任意数据在被测对象看来具有相同的处理方式；随后从每个子集中挑选少量代表值设计用例，用有限用例覆盖原本近乎无限的取值空间。
它解决的核心问题是输入空间过大、用例无法穷举。一个接受整数的输入框，理论上可取值数以亿计，逐一举证既不可行也无必要。等价类划分给出的假设是：如果某个类中的一个代表值触发了缺陷，那么同类中的其他值大概率也会触发同类缺陷；反之，一个类通过验证，可以为该类内其他取值提供较强的信心。这个假设成立的前提是划分依据来自真实的需求规则，而非主观猜测。
三个术语需要先分清：
| 术语 | 中文解释 | 在用例中的角色 |
|---|---|---|
| 等价类 | 按相同处理逻辑归并而成的一组输入或输出数据集合 | 划分的基本单位，每个类至少需要被覆盖一次 |
| 有效等价类 | 符合需求规格、应当被系统正常接受的取值集合 | 验证合法输入能否被正确处理，输出是否符合预期 |
| 无效等价类 | 违反某条需求规则、应当被系统拒绝或提示的取值集合 | 验证非法输入能否被正确拦截，错误提示是否合理 |
有效类与无效类是一对互补视角：前者回答“该接受的有没有接受对”，后者回答“该拒绝的有没有拒绝住”。只做有效类的用例集，无法说明系统面对脏数据时的行为，这是后文常见误解之一。
它覆盖什么、不覆盖什么
等价类划分适用于一切可以按规则分组的数据对象，常见的有：输入框的取值范围（如数量、金额、年龄）、数据类型（整数、小数、字符串、日期格式）、必填与选填字段、枚举与下拉选项、文件类型与大小限制、业务状态集合（如订单从待支付到已完成的各个状态）、以及输出域（如不同金额区间对应的折扣结果）。只要需求中存在“满足某条件走某分支”的描述，就存在可划分的等价类。
它不负责判断类与类交界处的具体取值。以18至60周岁为例，等价类划分告诉你“18至60”是一个有效类、“小于18”和“大于60”是无效类，但17、18、60、61这些紧贴边界的值是否被正确处理，属于边界值分析的任务。两类方法关注点不同：等价类取类内代表值，边界值取交界点及其邻近值。
它也不涉及代码结构与内部逻辑覆盖。等价类划分从需求出发、只看外部可见的输入输出行为，属于黑盒方法；语句覆盖、分支覆盖、条件覆盖等白盒指标衡量的是代码被执行的程度，两者不能互相替代。一个划分良好的等价类表，不能证明代码中每个分支都被走到。
此外，等价类划分是用例设计环节的一种方法，产出是待执行的用例集合。用例评审、执行记录、缺陷跟踪、回归维护等后续环节各有其管理动作，划分本身不替代这些环节。划分表做得再细，若没有评审确认需求理解一致，也可能整批用例建立在错误的前提上。
等价类怎么划分：规则与步骤
划分的锚点是需求规格中的条款。逐条阅读需求，把每条可验证的规则转成一个或多个等价类，是较稳妥的做法。常见划分依据包括：
- 取值范围：需求写明“18至60”，则有效类为18至60，无效类为小于18和大于60，两个无效方向分别成类。
- 数据类型与格式：要求整数时，小数、字母、空值、特殊字符各自构成无效类；日期字段则按格式合法与各类格式错误分组。
- 必填与选填：必填项为空是一个无效类；选填项为空是有效类，选填项填入合法值也是一个有效类。
- 业务规则：如“会员折扣仅对已登录用户生效”，可拆出已登录会员、已登录非会员、未登录等条件类。
- 枚举与集合：下拉选项中的每个合法选项可归为一个有效类，集合外的值归为无效类。
有效类与无效类要成对考虑，且无效类通常一次只放一个非法条件。原因是当一条用例同时包含两个非法输入时，系统可能只报出第一个错误，第二个非法条件是否被正确处理无法观察，用例的定位能力被削弱。把非法条件拆开，每条用例只验证一个拒绝逻辑，缺陷定位更直接。
划分结果建议用表格登记，字段至少包含：类编号、所属需求条款、类类型（有效/无效）、条件描述、代表值、预期结果。这张表既是设计产物，也是评审对象和维护基线。下表是字段示例：
| 类编号 | 需求条款 | 类类型 | 条件描述 | 代表值 | 预期结果 |
|---|---|---|---|---|---|
| EC-01 | 年龄须为18至60周岁整数 | 有效 | 取值落在18至60之间 | 30 | 接受并进入下一步 |
| EC-02 | 年龄须为18至60周岁整数 | 无效 | 取值小于18 | 10 | 拒绝并提示年龄不符 |
| EC-03 | 年龄须为18至60周岁整数 | 无效 | 取值大于60 | 70 | 拒绝并提示年龄不符 |
| EC-04 | 年龄须为18至60周岁整数 | 无效 | 输入非整数 | “三十” | 拒绝并提示格式错误 |
划分粒度以需求条款为锚，过粗与过细都有代价。过粗表现为把“小于18”和“大于60”合并成一个“非法年龄”类，代表值只能取一个方向，另一个方向的拒绝逻辑就漏测了；过细表现为把每个可能的整数都列成一个类，等价类划分便退化为穷举，失去方法价值。判断标准是：两个取值如果会走不同的处理分支或产生不同的错误提示，就应分属不同类；如果处理方式完全一致，就应合并。
划分表完成后进入用例编写与评审。以 ONES TestCase 为例，用例库支持树状结构组织与拖拽排序，可把等价类表按需求模块分层登记；用例属性支持自定义，可增加“类编号”“类类型”等字段，便于后续按属性筛选核对覆盖情况；已有 Excel 形式的划分表也可批量导入，减少重复录入。评审时按类编号逐条核对需求条款，确认有效类与无效类均无遗漏，再进入执行。
与边界值分析、决策表的区别
三种方法常被并列提及，但回答的问题不同，混用会导致重复设计或覆盖缺口。
| 方法 | 关注对象 | 典型取值 | 主要作用 |
|---|---|---|---|
| 等价类划分 | 类内部的代表值 | 有效类取一个常规值，无效类各取一个典型非法值 | 用少量用例覆盖各类处理逻辑 |
| 边界值分析 | 类与类交界处的取值 | 边界点及其两侧邻近值，如17、18、60、61 | 捕捉边界判断错误，如大于写成大于等于 |
| 决策表 | 多个条件组合下的动作 | 条件桩与动作桩的规则组合 | 梳理复杂业务规则，保证组合无遗漏 |
等价类划分与边界值分析是互补关系。等价类回答“有哪些类、每类取什么代表值”，边界值回答“交界处是否判断正确”。实践中通常先划分等价类，再针对每个有明确边界的类补充边界值用例。以18至60为例，等价类给出代表值30和无效值10、70，边界值补充17、18、60、61，两组用例合起来才既覆盖类内又覆盖交界。
决策表处理的是条件组合。当业务规则涉及多个条件同时作用，例如“用户等级”“订单金额”“是否使用优惠券”三者共同决定折扣，等价类划分只能分别给出每个维度的取值分组，无法说明组合后的动作。此时用决策表列出条件桩与动作桩，逐条规则设计用例。等价类划分仍是决策表的前置工作：每个条件桩的取值本身就需要先做等价类归并，否则决策表的规则数会迅速膨胀。
组合使用时，用例登记要避免重复。一种做法是在用例属性中标注“设计方法”和“来源类编号”，边界值用例注明其补充的等价类编号，决策表用例注明对应的规则编号。这样在评审和回归时，可以按方法维度检查覆盖是否完整，也能在需求变更时快速定位受影响的用例范围，而不必凭记忆判断某条用例为何存在。
一个具体例子与常见误解
以年龄输入框为例，需求为“年龄须为18至60周岁的整数，必填”。按前述规则划分，可得到如下等价类表：
| 类编号 | 类类型 | 条件描述 | 代表值 | 预期结果 |
|---|---|---|---|---|
| EC-01 | 有效 | 18至60之间的整数 | 30 | 接受，进入下一步 |
| EC-02 | 无效 | 小于18的整数 | 10 | 拒绝，提示年龄不符 |
| EC-03 | 无效 | 大于60的整数 | 70 | 拒绝，提示年龄不符 |
| EC-04 | 无效 | 非整数输入 | “三十” | 拒绝，提示格式错误 |
| EC-05 | 无效 | 空值 | 不填 | 拒绝，提示必填 |
取用方式是：每个类至少一条用例，EC-01至EC-05各设计一条，共五条基础用例；无效类逐条单独验证，每条用例只包含一个非法条件，例如验证EC-04时年龄字段只填非整数，其余字段保持合法。若还需覆盖边界，再补充17、18、60、61四条边界值用例，与等价类用例分开登记、互相引用。
围绕这个方法，有几类误解反复出现：
- 把等价类划分等同于随机取几个值。随机取值没有划分依据，无法说明覆盖了哪些处理逻辑，也无法在需求变更时判断哪些用例失效。划分的价值恰恰在于每个代表值背后对应一条可追溯的需求规则。
- 只做有效类，不做无效类。只验证合法输入能通过，等于放弃了对拒绝逻辑的检验。非法输入的处理往往涉及参数校验、错误提示、日志记录等多处代码，是缺陷高发区。
- 划分后不登记，只留在个人笔记里。没有登记表，评审时无法逐条核对需求条款，覆盖缺口只能靠记忆发现；人员变动后，后续维护者不知道某条用例为何存在、能否删除。
- 把多个非法条件塞进一条用例。系统通常只报第一个错误，其余非法条件是否被正确处理无法观察，缺陷定位被削弱。
这些误解纠正后，直接改变的是用例评审与后续维护的质量。有了带类编号和需求条款的登记表，评审可以按条款逐项确认有效类与无效类是否齐全，而不是通读用例凭感觉判断；需求变更时，可依据条款定位受影响的类，增删对应用例，避免整批用例推倒重来。在 ONES TestCase 中，用例属性支持筛选，按“类类型”筛出全部无效类用例即可快速核对拒绝逻辑的覆盖情况；用例库的树状结构便于按需求模块分层存放，导入导出能力则让划分表在文档与用例库之间流转时不必手工重录。方法本身决定用例设计的质量，登记与管理方式决定这份质量能否被评审、被执行、被长期维护。
常见问题
等价类划分和随机测试有什么区别？
随机测试从输入空间中任意取值，等价类划分则先依据需求规则把取值空间切成若干处理逻辑相同的集合，再从每个集合中挑代表值。区别在于可追溯性：等价类划分的每个代表值背后对应一条需求条款，评审时可以逐条核对覆盖是否完整；随机取值无法说明覆盖了哪些处理逻辑，需求变更时也难以判断哪些用例失效。两者可以配合使用，但随机测试不能替代等价类划分。
无效等价类为什么要一条用例只放一个非法条件？
当一条用例同时包含两个非法输入时，系统通常只报出第一个错误，第二个非法条件是否被正确处理无法观察，用例的缺陷定位能力被削弱。把非法条件拆开，每条用例只验证一个拒绝逻辑，一旦失败就能直接定位到对应的校验点。代价是用例数量增加，但这部分数量换来的是可诊断性，通常值得保留。
需求条款很多时，等价类划分要做到多细？
判断标准是处理分支是否相同：两个取值如果会走不同的处理分支或产生不同的错误提示，就应分属不同类；如果处理方式完全一致，就应合并。过粗会把“小于18”和“大于60”合并成一个非法类，另一个方向的拒绝逻辑漏测；过细则退化为穷举，失去方法价值。划分粒度以需求条款为锚，条款本身模糊时先澄清需求，再确定类的边界。
等价类表做完之后，怎么保证评审和维护不流于形式？
关键是让划分表成为可检索、可筛选的登记对象，而不是留在个人笔记里。表内保留类编号、所属需求条款、类类型、代表值、预期结果，评审时按条款逐项确认有效类与无效类是否齐全。在 ONES TestCase 中，用例属性支持自定义，可增加“类编号”“类类型”等字段；用例库中所有用例属性都支持筛选，按“类类型”筛出全部无效类用例即可快速核对拒绝逻辑的覆盖情况；用例模块支持树状结构与拖拽排序，可按需求模块分层存放，Excel 形式的划分表也可批量导入。
等价类划分能直接保证测试充分吗？
不能单独保证。等价类划分覆盖的是类内代表值，交界处的取值需要边界值分析补充，多条件组合下的动作需要决策表梳理，代码内部的分支执行程度则需要白盒指标衡量。它解决的是输入空间过大、用例无法穷举的问题，是设计环节的一种方法。用例评审、执行记录、缺陷跟踪与回归维护各有其管理动作，划分表做得再细，也需要评审确认需求理解一致后才能作为执行基线。
