深入探究测试用例设计的底层逻辑_用例的完整度评价逻辑

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

回到之前的问题，接口要怎么测试？我们同样从与接口的交互考虑：我们可以发起接口调用，检查它返回内容的正确性；可以以相同参数反复请求，检查它的幂等性；可以高频次的发起，检查它的性能；可以尝试提交未经授权的请求，检查它的安全性等等。

2、用例的本质

在做完交互分析之后，会面临一个问题：在绝大部分（99.999…%）的情况下，输入域是无限的。比如，水杯中盛装的物品，可能是水、酒、可乐、饼干、草莓、浓酼酸… （谁说只能装可饮用的液体？）我们穷尽一生，也不可能去尝试所有的输入。因此，业内才有一句话叫做：完美的测试是不可能的。那是不是代表测试就是在碰运气呢？并不然。

之所以测试领域会有这么多的用例设计方法论，原因就是我们需要**把无限的输入域，变成有限的、有代表性的输入集。测试的意义，不是找到全部的缺陷，而是找到对业务有价值的缺陷。**比如一款定位是面向下沉市场的水杯，杯子不够耐摔，就是有价值的缺陷，而杯体不够透明，就是无价值（或低价值）的缺陷。对任何一款产品或一块业务而言，我们都得把握好质量本身的“度”。

**好的用例设计，是能够以尽可能少的用例，找到尽可能多的有价值问题。**因此，**用例的本质，是对问题的抽象，而测试人员最核心的能力，是对问题的定义和抽象能力。**我们再来回顾这个公式：交互分析->等价划分->边界测试->用例组合，它其实就是一个 问题定义->问题抽象->问题简化->问题处理 的过程。

1）等价划分 是将输入域按某个维度进行的有效归并。比如可乐、雪碧、芬达，它们对于常规的水杯而言，都是同类物体，穷举测试并没有意义，我们可以把它们归为一类“碳酸饮料”。再比如，一个塑料杯，对于温度 10 度的可乐和 28 度的水，也没有分别，我们也可以把它们归为一类“常温液体”。注意这里在归类之后，会有输入重叠的现象，比如常温下的碳酸饮料，这个稍后很快会讲到。

2）边界测试是提取单个输入域分类的有效代表值。对于单个输入域分类而言，可选的输入值仍然是无限多的，所以我们需要找到能够代表其他输入值的单值。而边界值往往就极具代表性。比如，对于水杯能够承受的液体温度，会有一个规定的上下限，而我们需要验证它是否能够真正达到这个限制（我们不会希望看到倒入开水之后杯子就爆开吧）。除了边界值外，还可以在非边界范围内随机挑选几个值做为代表。

3）用例组合则是对这些代表值按分类做交叉考虑。像判定表、因果图、正交实验等，就是告诉我们如何做交叉考虑的方法论。前面提到的输入域重叠，即是不同分类的交叉点。比如，常温下的碳酸饮料、常温下的水、冰冻的碳酸饮料、冰冻的水、沸腾的碳酸饮料、沸腾的水…

很多测试教程，将等价划分和因果图等做为同一个维度的测试方法放在一块介绍，对测试新手会造成很大的干扰，以为它们相互并行，这其实是不正确的理解。**前者是对问题的抽象，后者是对问题的处理。**还有一个常见误区是，等价划分、边界测试仅用于黑盒测试，覆盖率分析仅用于白盒测试，这也是由于没有真正理解测试方法论造成的。比如对于如下代码：

if (value >= 1 && value <= 10) {
System.out.println(“I have " + value + " cards.” );
}

等价划分和边界测试在这里仍然有用：20 和 30 是同一类，-5 和 -10 是同一类；0、1、2、9、10、11 就是它们的边界。同样，对于黑盒测试，也可以应用覆盖率分析，这就涉及到接下来的内容：业务建模和图论。

3、业务建模

先来看一个常见场景：登录。按照最粗略的设计，它可能会是这个样子：

当然，在真实情况下往往不会这么简单，比如忘记密码需要重置、在多次错误输入的情况下账号会被锁定等等。所以我们把场景中的红色部分做进一步的拓展：

注意这里其实并没有往流程中注入更多的东西，只是把“登录成功”和“登录失败”这两个部分（见虚线框）做了展开描述。然后，假设“校验通过”这个判断步骤的代码如下：

if (uname == null || pwd == null) {
return errorResult(“账号名或密码不能为空”);
}
UserDO user = userMapper.getUserByName(uname);
if (user.getPwd.equals(encry(password))) {
return succResult（“登录成功”）;
} else {
return errorResult（“登录失败”）;
}

可以将它转化为等同的图形（因为篇幅的关系，登录成功和失败的细节重新被折叠）：

这个例子阐明了一件事情：为什么上篇文章里说，像等价划分、边界测试、覆盖率分析等常见的用例设计策略，不能说它只适用于黑盒或白盒，**在绝大部分情况下（确实也存在少数特定方法），黑盒、灰盒、白盒只是分解程度上的不同，它们可以通用、甚至混用。**比如上图就是将黑盒部分和白盒部分混合在一起。

整个业务系统，都可以按照这种方式进行不同程度的拆解。拆解的目的，是为了得到输入点、输出点以及它们之间的可能路径。所有输入点的可选项，就是输入域；所有输出点的可选项，就是输出域，而输入点到输出点之间走过的路径的重复度（覆盖率分析），就是等价划分的依据。因此，拆解的粒度越细，能够识别的（子）节点和（子）路径越多，获得的输入域和输出域也就越完整，进行的等价划分也就越精确。

这个拆解的过程，我们就叫做业务建模。它核心依赖两张图：业务流程图和数据流程图。以一个简化过的购物下单流程为例，两张图分别如下（因画图工具的限制，图形的样式不专业，但不影响对内容的说明）：

业务流程图比较好理解，即前面所说的路径，那为什么还需要一张数据流程图呢。原因是第一张流程图中存在隐蔽的“陷阱”：当我们新发起一个订单支付和支付失败需要重新支付时，虽然在流程图里的节点看起来是同一个，但实际上二者不是等价的（订单状态不一样，流水记录也不一样），所以“严谨”一点说，完整的流程图应该是这样：

由此可以看出，数据流程图对测试人员来说，有比较重要的“校验意义”，它可以帮助我们确认每个步骤产生的结果的正确性和完整性。

此外，它还可以做为模块化测试的依据：我们可以从庞大、复杂的业务流中，选择一部分节点和路径，做为一个模块。只要保证输入点的所有数据状态一致，就可以认为每次测试都是“幂等”的，它所到达的输出点的数据状态也应该与预期一致。由此，将复杂的业务系统隔离成一个个小的子系统，降低整体测试的复杂度。

那么，我们又该如何确认测试的完整性？假设有一个逻辑复杂的业务模块，它的流程图（实线部分）如下：

这时添加一条从结束点到开始点的路径（虚线部分），这张图就变成了一张有向环图（比如红色部分就是一个环）。从开始点到结束点的路径分支数，就等同于有向图的圈数。使用图论中的公式：V(G) = E - N + P（V 代表圈复杂度，E 代表边数，N 代表节点数，P 代表连通组件数（因为上图所有节点都是连通的，所以 P 为 1）），计算出圈数 = 13 - 8 + 1 = 6。即如果我们想要尝试所有的路径分支，至少需要 6 个测试用例，感兴趣的小伙伴可以自行数一数。在这张图中，边数最少的路径，我们一般将它做为关键路径（主路径），其他路径做为次要路径（辅路径）。边数越少，说明路径越重要，据此可以做为用例等级判断的依据。

更多测试相关的图论知识，推荐阅读机械工业出版社的《软件测试：一个软件工艺师的方法》（【美】保罗 C.乔根森（Paul C.Jorgensen) 著）。

4、其他一些测试法

除了以上讲解的“理性”的测试方法，还有一些“感性”的测试方法，同样可以给测试人员带来较大的帮助，最后我就选择部分常见的方法做个介绍。

角色分析法

角色分析法，是将自己作为目标用户来思考：如果我是用户，会以什么样的方式来使用产品。我们可以将用户划分为不同的角色，并构建出这些角色的使用场景，最终转化为测试用例。该方法的的作用是“以终为始”，跳出自身的视角限制，来发现用例设计中的盲点。

错误推断法

错误推断法，是根据测试人员的经验和直觉，列举出可能会出现问题的情况。我们可以在类似头脑风暴或用例评审的场合中，使用它来收集群体的想法。它非常依赖使用者的感觉，因此只能做为常规用例设计方法的补充，或在紧急的情况下采用，而不应将它做为主要的用例设计方法。

历史经验法

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
24b （备注软件测试）**
[外链图片转存中…(img-I3NNxaAm-1713572788551)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！