软件测试用例设计与覆盖率闭环 - 第3节

等价类划分法：原理与定义

等价类划分，说白了就是「把输入数据分堆」。

你想想看，测试一个登录框，难道要把所有可能的用户名和密码都试一遍吗？那得试到猴年马月去。我刚开始做测试那会儿，就犯过这种傻——恨不得把每个字符都测一遍，结果累得半死，覆盖率还没上去。

后来我明白了，很多输入其实「等效」的。比如用户名长度在6-20位之间，那6位和7位，本质上属于同一类。我们只需要从每一类里挑一个代表去测，就能覆盖所有情况。

这就是等价类划分的核心思想：把无穷的输入，变成有限的几类。

等价类的两个基本类型

这里有个关键点，很多人一开始会搞混——等价类其实分两种。

• 有效等价类：符合需求规格说明的、合理的、有意义的输入数据
• 无效等价类：不符合需求规格说明的、不合理的、无意义的输入数据

为什么要分这两种？我遇到过不少测试新人，只盯着「正常情况」测，觉得用户不会乱输。结果上线第一天，就有人在密码框里输入了表情符号，系统直接崩了。嗯，这就是忽略了无效等价类的后果。

有效等价类与无效等价类

咱们拿一个具体的例子来说。假设有个年龄输入框，需求写的是「年龄必须在1到120之间的整数」。

那有效等价类是什么？很简单，就是1到120之间的任意整数。比如18、35、99，都属于这一类。

无效等价类呢？那就多了：

• 小于1的数：0、-5、-100
• 大于120的数：121、200、999
• 非整数：3.14、2.5、0.99
• 非数字：abc、你好、@#￥
• 空值：什么都不输入

你看，有效等价类就一个区间，但无效等价类能分出好几种。这就是为什么我总说，无效等价类的设计，才是测试用例设计的重头戏。

实战案例：登录模块

好了，理论说完了，咱们直接上手一个真实案例。登录模块，每个测试都测过，但你真的测全了吗？

需求描述

假设一个登录模块的规则如下：

字段	规则
用户名	6-20位字母或数字组合，区分大小写
密码	8-16位，必须包含字母和数字，区分大小写
验证码	4位数字，不区分大小写

第一步：划分等价类

咱们先对用户名做等价类划分：

输入项	有效等价类	无效等价类
用户名	6-20位纯字母（如 abcdef）	长度小于6位（如 abc）
	6-20位纯数字（如 123456）	长度大于20位（如 21个a）
	6-20位字母数字组合（如 test123）	包含特殊字符（如 test@123）

密码的等价类划分：

输入项	有效等价类	无效等价类
密码	8-16位字母+数字（如 pass1234）	长度小于8位
	8-16位数字+字母（如 1234pass）	长度大于16位
		纯字母（如 password）

第二步：设计测试用例

有了等价类，设计用例就简单了。每个等价类挑一个代表值就行。

我个人的做法是：先覆盖所有有效等价类，再逐个覆盖无效等价类。注意，无效等价类要一条用例只测一个无效项，这样才能准确定位问题。

// 有效等价类测试用例
用例1：用户名=testuser，密码=Pass1234，验证码=1234
预期：登录成功

// 无效等价类测试用例
用例2：用户名=abc（长度不足），密码=Pass1234，验证码=1234
预期：提示「用户名长度需为6-20位」

用例3：用户名=testuser，密码=pass（长度不足），验证码=1234
预期：提示「密码长度需为8-16位」

用例4：用户名=testuser，密码=Pass1234，验证码=12（长度不足）
预期：提示「验证码为4位数字」

用例5：用户名=test@user（含特殊字符），密码=Pass1234，验证码=1234
预期：提示「用户名只能包含字母和数字」

等价类划分的核心逻辑

为了让你更直观地理解，我画了一张流程图：

等价类划分的注意事项

最后，分享几个我这些年总结出来的要点：

• 边界值要单独处理：等价类划分通常和边界值分析法配合使用。比如6-20位，6和20这两个边界值，我建议单独拿出来测。
• 不要遗漏空值：很多系统在空值处理上都有bug。我遇到过最离谱的一次，空用户名直接导致数据库查询报错，页面白屏了。
• 组合情况要留意：等价类划分主要针对单个输入项。多个输入项的组合情况，需要用判定表或正交实验法来补充。

等价类划分法，说白了就是用最少的用例，覆盖最多的场景。它不复杂，但需要你养成「分类思维」的习惯。每次拿到需求，先问自己一句：这个输入，能分成几类？

养成这个习惯，你的测试设计能力会上一个台阶。