从这篇文章开始，我会选择一些重要的质量策略进行详细讨论，而今天就先来聊聊测试用例。

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

01. 万物皆可测

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

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

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

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

纯看着：外观

拿起来：功能/效率/安全/易用

装东西：功能/效率/兼容/安全/易用/可靠

喝东西：功能/效率/兼容/安全/易用/可靠

放起来：效率/兼容/安全/可维护/可移植

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

从功能上考虑，要能够正常盛放被装物品（正确性），要能够装入开水、凉水、茶、碳酸饮料（完备性），并且容量足够（适合性）。

从安全上考虑，如果我装的是开水，杯体是否会烫手。

从可靠上考虑，长时间盛装液体，是否会漏水。

…

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

功能：是否满足用户需求，核心三要素：正确性、完备性、适合性。

效率：在软件中可以理解为性能，包括时间特性、资源占用。

兼容：与环境的共存、交互对象的互操作。

易用：用户理解、操作需要付出多少努力。

可靠：能够正常维持产品特性的程度或概率。

安全：输入输出安全、内容安全、交互安全。

可维护：因环境变化时需要做出调整的难易度。

可移植：从一个环境移到另一个环境的难易度。

通过复用这套方法论，我们就可以在面对不同的测试对象时，尽量找到更多的“隐性特性”（显性特性已经明明白白写给你啦）。此外，我们能够识别的“隐性特性”，还取决于我们对业务的深度理解。比如水杯的容量是否足够，要考虑水杯设计时面向的用户群体。茶杯、白酒杯、红酒杯、啤酒杯，它们的容量要求都是不一样的，我们不会希望一个白酒杯的容量能有 500ml。所以，在列举输入域时，一定要结合业务特性和用户群体。

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

02. 用例的本质

在做完交互分析之后，会面临一个问题：在绝大部分（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 就是它们的边界。同样，对于黑盒测试，也可以应用覆盖率分析，这就涉及到接下来的内容：业务建模和图论。

测试用例可以讲的内容实在是太多，由于时间关系（工作太忙，见谅），我拆成上下两篇文章来讲解，剩下的内容，我们下周再见。

现在我邀请你进入我们的软件测试学习交流群：【746506216】，备注“入群”， 大家可以一起探讨交流软件测试，共同学习软件测试技术、面试等软件测试方方面面，还会有免费直播课，收获更多测试技巧，我们一起进阶Python自动化测试/测试开发，走向高薪之路。

喜欢软件测试的小伙伴们，如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一 键三连哦！