测试用例是每位测试人员都绕不开的话题,也是大家习以为常的事情。几乎所有测试相关的公众号、博客、专栏,都会提及测试用例,由此可见它的重要性。但是,有许多从业者,对测试用例的设计仍然依靠经验积累,即使知道用例要从功能、性能、安全等多方面考虑,也仅限于对字面的理解,未形成体系化的整理。所以,今天我更多会从系统的角度,来和大家一起看看用例设计背后的底层逻辑。
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、结尾
测试用例设计是一个非常大的话题,以上这些内容还远远不能完整表达测试用例设计的精华,但由于时间的关系,暂时也不去做更多的展开讨论。随着测试理论和技术的发展,也许将来会出现更多、更智能的用例设计策略,就让我们“拭目以待”吧!
总结:
感谢每一个认真阅读我文章的人!!!
作为一位过来人也是希望大家少走一些弯路,如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助。
软件测试面试文档
我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。
视频文档获取方式:
这份文档和视频资料,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!以上均可以分享,点下方小卡片即可自行领取。