📚 课程目录第4章测试用例设计方法

4、测试用例设计方法：等价类划分、边界值分析、因果图法、场景法、正交实验法在集成测试中的应用

集成测试和单元测试最大的区别在哪？我个人觉得，不是测的模块变多了，而是输入组合爆炸了。你想想看，两个模块一对接，A模块的3个输出参数，配上B模块的4个状态，瞬间就是12种组合。要是全靠直觉去点，漏掉关键场景是迟早的事。

所以这一章，咱们就聊聊怎么用工程化的方法去设计集成测试用例。说白了，就是给你几把趁手的工具，让你在面对复杂接口时，心里有谱。

等价类划分的核心思想很简单：把输入数据按“效果相同”分组，每组只测一个代表值。这样就能用最少的用例，覆盖最广的范围。

我在项目中遇到过最典型的例子，是一个温控设备的温度输入接口。文档上写“支持-40℃ 到 +85℃”。如果每个整数都测一遍，得测126个用例，太傻了。

用等价类划分，我们只需要分三类：

三个用例，搞定。但这里有个坑——等价类划分只关注“输入”，不关注“输入之间的关系”。比如两个参数互相制约，它就管不了了。这时候，得请出下一把工具。

我的小技巧： 拿到需求文档后，先别急着写用例。花10分钟把所有输入参数列出来，给每个参数画一个“有效/无效”的边界框。这个动作做完，你的测试覆盖率至少提升30%。

为什么边界值分析这么重要？因为程序员的逻辑判断，99%的Bug都出在“等于”、“大于”、“小于”这些边界判断上。你想想看，写 if (temp >= 0) 和 if (temp > 0) 的区别，就差一个等号，但结果天差地别。

边界值分析的原则是：取每个等价类的边界值，以及边界两侧紧邻的值。

还是刚才那个温度接口的例子，边界值要测的点是：

一共6个用例。加上等价类的代表值0，总共7个用例，就能把整个输入域覆盖得死死的。

避坑指南： 我曾经在一个项目中，只测了边界值本身（-40和85），没测边界两侧的值。结果上线后，用户输入-40.1时系统直接崩溃。为什么？因为程序里写的是 if (temp < -40)，浮点数精度问题导致-40.1被判定为等于-40。从那以后，我每次都会把边界两侧的值也加上。

当多个输入条件互相影响时，等价类和边界值就有点力不从心了。这时候，因果图法就派上了用场。

因果图法的核心是：画出“因”（输入条件）和“果”（输出结果）之间的逻辑关系，然后根据这个关系生成测试用例。

举个例子，一个智能门禁系统：

逻辑关系是：（因1 且因2）或因3 → 果

根据这个因果图，我们可以生成以下测试用例：

你看，5个用例就把所有逻辑分支覆盖了。因果图法的好处是，它强迫你去思考“如果A成立但B不成立，结果会怎样？”——这种思考方式，是发现逻辑漏洞的关键。

前面几种方法都是从“输入”角度出发的。但集成测试最终要验证的是“业务流程”是否走得通。这时候，场景法就登场了。

场景法的核心是：模拟用户在实际使用中的操作路径。它分为基本流和备选流。

我记得有一次测试一个支付系统，基本流测了20遍都没问题。但当我用场景法去模拟“支付过程中网络中断，然后恢复”的场景时，系统直接卡死了。为什么？因为支付模块和网络模块之间的超时机制没处理好。

场景法的价值就在于此——它不关心单个接口的输入输出，而是关心多个模块串联起来后，业务流程是否健壮。

当输入参数很多，每个参数又有多个取值时，组合数会爆炸。比如3个参数，每个有4个取值，全组合就是64种。测不完，根本测不完。

正交实验法就是用来解决这个问题的。它通过正交表，从全组合中挑选出“最具代表性”的用例，保证任意两个参数的所有组合都被覆盖到。

举个例子，一个设备有3个配置参数：

全组合是 3×3×2 = 18种。但用正交表 L9(3^4)，只需要9个用例。

你看，9个用例就覆盖了所有“两两组合”。对于集成测试来说，这已经足够了。因为大部分Bug都是由两个参数的交互引起的，三个参数同时出问题的概率极低。

    核心总结： 这五种方法不是互斥的，而是互补的。我个人的习惯是：先用等价类和边界值搞定单个参数，再用因果图理清参数间的逻辑关系，然后用场景法串联业务流程，最后用正交实验法处理多参数组合。一套组合拳下来，测试用例的质量和效率都能上一个台阶。