测试用例设计背后的底层逻辑你肯定要知道

前言

测试用例是每位测试人员都绕不开的话题，也是大家习以为常的事情。几乎所有测试相关的公众号、博客、专栏，都会提及测试用例，由此可见它的告急性。但是，有许多从业者，对测试用例的设计仍然依靠经验积累，即使知道用例要从功能、性能、安全等多方面考虑，也仅限于对字面的理解，未形成体系化的整理。以是，今天我更多会从体系的角度，来和大家一起看看用例设计背后的底层逻辑。
1、万物皆可测

曾经有一位小伙伴问我：接口要怎么测？当时他已经是一位很熟练的功能测试人员了，之以是在更换一种场景之后不知如何应对，还是因为未能掌握用例设计的通用逻辑。雷同的问题还有：一个服务要怎么测、SDK 要怎么测等等。
首先，我要说一点：万物皆可测。在开始测试之前，我们需要深入去相识我们的测试对象，用互联网的话说，就是“业务分析”。通常，我们会根据 PRD（产品需求文档） 去构建测试用例，但这内里的问题是，业务的质量特性包含显性特性和隐性特性，而 PRD 每每只有最表层的显性特性（这很考验产品人员的本领，有些甚至连显性特性都不齐备）。一般而言，能通过各类文档中直接天生的用例，不到完整用例集的十分之一。以是这就需要我们通过其他的方法，来分析出更加全面的特性。
举个例子，过往的测试面经里有一个经典问题：要怎么测试一个水杯（不知道如今是否还有口试官问这个问题）。它的 “PRD” 只有一句：这是个水杯。这个问题考验的就是我们对测试对象的分析本领。我这里给出一条全能公式：交互分析->等价划分->边界测试->用例组合。接下来就以水杯为例，来详细看下如何运用这个公式。
我们要知道，所有的测试对象，都是可以被交互的。我们的测试用例设计，实在就是在寻找“交互点”，而后转化为输入域和输出域。比如，我们和水杯的交互点有：

• 纯看着：外观
  
• 拿起来：功能/效率/安全/易用
  
• 装东西：功能/效率/兼容/安全/易用/可靠
  
• 喝东西：功能/效率/兼容/安全/易用/可靠
  
• 放起来：效率/兼容/安全/可维护/可移植
  

通常我们说的“要从功能、性能、安全等多方面考虑”，实在指的就是单个交互输入域的完整性。比如，对于水杯“装东西”这个交互：

• 从功能上考虑，要能够正常盛放被装物品（精确性），要能够装入开水、凉水、茶、碳酸饮料（完备性），并且容量足够（得当性）。
  
• 从安全上考虑，如果我装的是开水，杯体是否会烫手。
  
• 从可靠上考虑，长时间艳服液体，是否会漏水。
  
• ......
  

 当我们面临一个不认识的场景时，难免会无从动手。如果我们有一套方法论，就可以帮助我们提供更全面的思索，得到更完整的输入域。我引用一个我认为比力好的一种描述法，即产品质量的八个特性：

• 功能：是否满足用户需求，核心三要素：精确性、完备性、得当性。
  
• 效率：在软件中可以理解为性能，包括时间特性、资源占用。
  
• 兼容：与环境的共存、交互对象的互操作。
  
• 易用：用户理解、操作需要付出多少积极。
  
• 可靠：能够正常维持产品特性的程度或概率。
  
• 安全：输入输出安全、内容安全、交互安全。
  
• 可维护：因环境变化时需要做出调整的难易度。
  
• 可移植：从一个环境移到另一个环境的难易度。
  

通过复用这套方法论，我们就可以在面对不同的测试对象时，只管找到更多的“隐性特性”（显性特性已经显着白白写给你啦）。此外，我们能够辨认的“隐性特性”，还取决于我们对业务的深度理解。比如水杯的容量是否足够，要考虑水杯设计时面向的用户群体。茶杯、白羽觞、红羽觞、啤羽觞，它们的容量要求都是不一样的，我们不会希望一个白羽觞的容量能有 500ml。以是，在列举输入域时，肯定要结合业务特性和用户群体。
回到之前的问题，接口要怎么测试？我们同样从与接口的交互考虑：我们可以发起接口调用，检查它返回内容的精确性；可以以雷同参数反复请求，检查它的幂等性；可以高频次的发起，检查它的性能；可以实验提交未经授权的请求，检查它的安全性等等
2、用例的本质

在做完交互分析之后，碰面临一个问题：在绝大部分（99.999..%）的环境下，输入域是无限的。比如，水杯中艳服的物品，大概是水、酒、可乐、饼干、草莓、浓酼酸...... （谁说只能装可饮用的液体？）我们穷尽一生，也不大概去实验所有的输入。因此，业内才有一句话叫做：完美的测试是不大概的。那是不是代表测试就是在碰运气呢？并否则。
之以是测试范畴会有这么多的用例设计方法论，原因就是我们需要把无限的输入域，酿成有限的、有代表性的输入集。测试的意义，不是找到全部的缺陷，而是找到对业务有代价的缺陷。比如一款定位是面向下沉市场的水杯，杯子不敷耐摔，就是有代价的缺陷，而杯体不敷透明，就是无代价（或低代价）的缺陷。对任何一款产品或一块业务而言，我们都得把握好质量自己的“度”。
好的用例设计，是能够以尽大概少的用例，找到尽大概多的有代价问题。因此，用例的本质，是对问题的抽象，而测试人员最核心的本领，是对问题的界说和抽象本领。我们再往返首这个公式：交互分析->等价划分->边界测试->用例组合，它实在就是一个 问题界说->问题抽象->问题简化->问题处置惩罚 的过程。
1）等价划分 是将输入域按某个维度进行的有效归并。比如可乐、雪碧、芬达，它们对于常规的水杯而言，都是同类物体，穷举测试并没有意义，我们可以把它们归为一类“碳酸饮料”。再比如，一个塑料杯，对于温度 10 度的可乐和 28 度的水，也没有分别，我们也可以把它们归为一类“常温液体”。注意这里在归类之后，会有输入重叠的征象，比如常温下的碳酸饮料，这个稍后很快会讲到。
2）边界测试 是提取单个输入域分类的有效代表值。对于单个输入域分类而言，可选的输入值仍然是无限多的，以是我们需要找到能够代表其他输入值的单值。而边界值每每就极具代表性。比如，对于水杯能够蒙受的液体温度，会有一个规定的上下限，而我们需要验证它是否能够真正到达这个限制（我们不会希望看到倒入开水之后杯子就爆开吧）。除了边界值外，还可以在非边界范围内随机挑选几个值做为代表。
3）用例组合 则是对这些代表值按分类做交叉考虑。像判断表、因果图、正交实验等，就是告诉我们如何做交叉考虑的方法论。前面提到的输入域重叠，便是不同分类的交叉点。比如，常温下的碳酸饮料、常温下的水、冰冻的碳酸饮料、冰冻的水、沸腾的碳酸饮料、沸腾的水......
很多测试教程，将等价划分和因果图等做为同一个维度的测试方法放在一块介绍，对测试新手会造成很大的干扰，以为它们相互并行，这实在是不精确的理解。前者是对问题的抽象，后者是对问题的处置惩罚。还有一个常见误区是，等价划分、边界测试仅用于黑盒测试，覆盖率分析仅用于白盒测试，这也是由于没有真正理解测试方法论造成的。比如对于如下代码：

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

复制代码

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

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

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

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

2. if (uname == null || pwd == null) {
4. return errorResult("账号名或密码不能为空");
6. }
8. UserDO user = userMapper.getUserByName(uname);
10. if (user.getPwd.equals(encry(password))) {
12. return succResult（"登录成功"）;
14. } else {
16. return errorResult（"登录失败"）;
18. }

复制代码

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

这个例子阐明了一件事情：为什么上篇文章里说，像等价划分、边界测试、覆盖率分析等常见的用例设计策略，不能说它只适用于黑盒或白盒，在绝大部分环境下（确实也存在少数特定方法），黑盒、灰盒、白盒只是分解程度上的不同，它们可以通用、甚至混用。比如上图就是将黑盒部分和白盒部分混合在一起。
整个业务体系，都可以按照这种方式进行不同程度的拆解。拆解的目标，是为了得到输入点、输出点以及它们之间的大概路径。所有输入点的可选项，就是输入域；所有输出点的可选项，就是输出域，而输入点到输出点之间走过的路径的重复度（覆盖率分析），就是等价划分的依据。因此，拆解的粒度越细，能够辨认的（子）节点和（子）路径越多，得到的输入域和输出域也就越完整，进行的等价划分也就越精确。
这个拆解的过程，我们就叫做业务建模。它核心依靠两张图：业务流程图和数据流程图。以一个简化过的购物下单流程为例，两张图分别如下（因绘图工具的限制，图形的样式不专业，但不影响对内容的阐明）：

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

由此可以看出，数据流程图对测试人员来说，有比力告急的“校验意义”，它可以帮助我们确认每个步调产生的结果的精确性和完整性。
此外，它还可以做为模块化测试的依据：我们可以从庞大、复杂的业务流中，选择一部分节点和路径，做为一个模块。只要包管输入点的所有数据状态一致，就可以认为每次测试都是“幂等”的，它所到达的输出点的数据状态也应该与预期一致。由此，将复杂的业务体系隔离成一个个小的子体系，低沉团体测试的复杂度。
那么，我们又该如何确认测试的完整性？假设有一个逻辑复杂的业务模块，它的流程图（实线部分）如下：

这时添加一条从竣事点到开始点的路径（虚线部分），这张图就酿成了一张有向环图（比如红色部分就是一个环）。从开始点到竣事点的路径分支数，就等同于有向图的圈数。使用图论中的公式：V(G) = E - N + P（V 代表圈复杂度，E 代表边数，N 代表节点数，P 代表连通组件数（因为上图所有节点都是连通的，以是 P 为 1）），计算出圈数 = 13 - 8 + 1 = 6。即如果我们想要实验所有的路径分支，至少需要 6 个测试用例，感兴趣的小伙伴可以自行数一数。在这张图中，边数最少的路径，我们一般将它做为关键路径（主路径），其他路径做为次要路径（辅路径）。边数越少，阐明路径越告急，据此可以做为用例等级判断的依据。
更多测试相关的图论知识，保举阅读机器工业出版社的《软件测试：一个软件工艺师的方法》（【美】保罗 C.乔根森（Paul C.Jorgensen) 著）。
4、其他一些测试法

除了以上讲授的“理性”的测试方法，还有一些“感性”的测试方法，同样可以给测试人员带来较大的帮助，末了我就选择部分常见的方法做个介绍。
脚色分析法
脚色分析法，是将自己作为目标用户来思索：如果我是用户，会以什么样的方式来使用产品。我们可以将用户划分为不同的脚色，并构建出这些脚色的使用场景，最终转化为测试用例。该方法的的作用是“以终为始”，跳出自身的视角限制，来发现用例设计中的盲点。
错误推断法
错误推断法，是根据测试人员的经验和直觉，列举出大概会出现问题的环境。我们可以在雷同头脑风暴或用例评审的场所中，使用它来收集群体的想法。它非常依靠使用者的感觉，因此只能做为常规用例设计方法的补充，或在紧急的环境下采用，而不应将它做为主要的用例设计方法。
汗青经验法
错误的发生每每会有一些“惯性”，以是在测试时，可以回首一下过去在雷同模块（或范畴）发生过的问题，对它进行重复校验，大概会有“意外惊喜”。同样，当出现测试遗漏时，肯定要及时补充我们的测试用例库，以免跌倒在同一个坑里。
现场验证法
测试人员设计出的用例通常是一种“测试数据”，我们很难确保它们能够覆盖到全部真实的数据环境。以是会采用一些方法来验证待发布产品在实际场景下的表现，比如预发测试、灰度测试、流量回放等等。
探索性测试
探索性测试严格上说不是一种测试技术，只是一种测试风格，它可以包含以上列出或未列出的各种测试方法。每次在探索性测试开始之前，可以定好这次测试的“主题”，或干脆就“自由发挥”，来增长发现深层缺陷的机会。这种方法如果结合众测，会有很好的结果。
末了感谢每一个认真阅读我文章的人，礼尚往来总是要有的，固然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

​

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战堆栈，这个堆栈也伴随上万个测试工程师们走过最艰难的路程，希望也能帮助到你！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。