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

1、万物皆可测

曾经有一位小伙伴问我：接口要怎么测？当时他已经是一位很熟练的功能测试人员了，之所以在更换一种场景之后不知如何应对，还是因为未能掌握用例设计的通用逻辑。类似的问题还有：一个服务要怎么测、SDK 要怎么测等等。

首先，我要说一点：万物皆可测。在开始测试之前，我们需要深入去了解我们的测试对象，用互联网的话说，就是“业务分析”。通常，我们会根据 PRD（产品需求文档） 去构建测试用例，但这里面的问题是，业务的质量特性包含显性特性和隐性特性，而 PRD 往往只有最表层的显性特性（这很考验产品人员的能力，有些甚至连显性特性都不齐全）。一般而言，能通过各类文档中直接生成的用例，不到完整用例集的十分之一。所以这就需要我们通过其他的方法，来分析出更加全面的特性。

举个例子，过往的测试面经里有一个经典问题：要怎么测试一个水杯（不知道现在是否还有面试官问这个问题）。它的 “PRD” 只有一句：这是个水杯。这个问题考验的就是我们对测试对象的分析能力。我这里给出一条万能公式：交互分析->等价划分->边界测试->用例组合。接下来就以水杯为例，来具体看下如何运用这个公式。

我们要知道，所有的测试对象，都是可以被交互的。我们的测试用例设计，其实就是在寻找“交互点”，而后转化为输入域和输出域。比如，我们和水杯的交互点有：

纯看着：外观
拿起来：功能/效率/安全/易用
装东西：功能/效率/兼容/安全/易用/可靠
喝东西：功能/效率/兼容/安全/易用/可靠
放起来：效率/兼容/安全/可维护/可移植
通常我们说的“要从功能、性能、安全等多方面考虑”，其实指的就是单个交互输入域的完整性。比如，对于水杯“装东西”这个交互：

从功能上考虑，要能够正常盛放被装物品（正确性），要能够装入开水、凉水、茶、碳酸饮料（完备性），并且容量足够（适合性）。
从安全上考虑，如果我装的是开水，杯体是否会烫手。
从可靠上考虑，长时间盛装液体，是否会漏水。
......
当我们面临一个不熟悉的场景时，难免会无从下手。如果我们有一套方法论，就可以帮助我们提供更全面的思考，得到更完整的输入域。我引用一个我认为比较好的一种描述法，即产品质量的八个特性：

功能：是否满足用户需求，核心三要素：正确性、完备性、适合性。
效率：在软件中可以理解为性能，包括时间特性、资源占用。
兼容：与环境的共存、交互对象的互操作。
易用：用户理解、操作需要付出多少努力。
可靠：能够正常维持产品特性的程度或概率。
安全：输入输出安全、内容安全、交互安全。
可维护：因环境变化时需要做出调整的难易度。
可移植：从一个环境移到另一个环境的难易度。
通过复用这套方法论，我们就可以在面对不同的测试对象时，尽量找到更多的“隐性特性”（显性特性已经明明白白写给你啦）。此外，我们能够识别的“隐性特性”，还取决于我们对业务的深度理解。比如水杯的容量是否足够，要考虑水杯设计时面向的用户群体。茶杯、白酒杯、红酒杯、啤酒杯，它们的容量要求都是不一样的，我们不会希望一个白酒杯的容量能有 500ml。所以，在列举输入域时，一定要结合业务特性和用户群体。

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

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、其他一些测试法

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

角色分析法

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

错误推断法

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

历史经验法

错误的发生往往会有一些“惯性”，所以在测试时，可以回顾一下过去在相同模块（或领域）发生过的问题，对它进行重复校验，也许会有“意外惊喜”。同样，当出现测试遗漏时，一定要及时补充我们的测试用例库，以免跌倒在同一个坑里。

现场验证法

测试人员设计出的用例通常是一种“测试数据”，我们很难确保它们能够覆盖到全部真实的数据情况。所以会采用一些方法来验证待发布产品在实际场景下的表现，比如预发测试、灰度测试、流量回放等等。

探索性测试

探索性测试严格上说不是一种测试技术，只是一种测试风格，它可以包含以上列出或未列出的各种测试方法。每次在探索性测试开始之前，可以定好这次测试的“主题”，或干脆就“自由发挥”，来增加发现深层缺陷的机会。这种方法如果结合众测，会有很好的效果。

5、结尾

测试用例设计是一个非常大的话题，以上这些内容还远远不能完整表达测试用例设计的精华，但由于时间的关系，暂时也不去做更多的展开讨论。随着测试理论和技术的发展，也许将来会出现更多、更智能的用例设计策略，就让我们“拭目以待”吧！

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

文档获取方式：

这份文档，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！

以上均可以分享，只需要你搜索vx公众号：程序员雨果，即可免费领取