测试用例是每位测试人员都绕不开的话题,也是大家习以为常的事情。几乎所有测试相关的公众号、博客、专栏,都会提及测试用例,由此可见它的重要性。但是,有许多从业者,对测试用例的设计仍然依靠经验积累,即使知道用例要从功能、性能、安全等多方面考虑,也仅限于对字面的理解,未形成体系化的整理。所以,今天我更多会从系统的角度,来和大家一起看看用例设计背后的底层逻辑。
1、万物皆可测
曾经有一位小伙伴问我:接口要怎么测?当时他已经是一位很熟练的功能测试人员了,之所以在更换一种场景之后不知如何应对,还是因为未能掌握用例设计的通用逻辑。类似的问题还有:一个服务要怎么测、SDK 要怎么测等等。
首先,我要说一点:万物皆可测。在开始测试之前,我们需要深入去了解我们的测试对象,用互联网的话说,就是“业务分析”。通常,我们会根据 PRD(产品需求文档) 去构建测试用例,但这里面的问题是,业务的质量特性包含显性特性和隐性特性,而 PRD 往往只有最表层的显性特性(这很考验产品人员的能力,有些甚至连显性特性都不齐全)。一般而言,能通过各类文档中直接生成的用例,不到完整用例集的十分之一。所以这就需要我们通过其他的方法,来分析出更加全面的特性。
举个例子,过往的测试面经里有一个经典问题:要怎么测试一个水杯(不知道现在是否还有面试官问这个问题)。它的 “PRD” 只有一句:这是个水杯。这个问题考验的就是我们对测试对象的分析能力。我这里给出一条万能公式:交互分析->等价划分->边界测试->用例组合。接下来就以水杯为例,来具体看下如何运用这个公式。
我们要知道,所有的测试对象,都是可以被交互的。我们的测试用例设计,其实就是在寻找“交互点”,而后转化为输入域和输出域。比如,我们和水杯的交互点有:
- 纯看着:外观
- 拿起来:功能/效率/安全/易用
- 装东西:功能/效率/兼容/安全/易用/可靠
- 喝东西:功能/效率/兼容/安全/易用/可靠
- 放起来:效率/兼容/安全/可维护/可移植
通常我们说的“要从功能、性能、安全等多方面考虑”,其实指的就是单个交互输入域的完整性。比如,对于水杯“装东西”这个交互:
- 从功能上考虑,要能够正常盛放被装物品(正确性),要能够装入开水、凉水、茶、碳酸饮料(完备性),并且容量足够(适合性)。
- 从安全上考虑,如果我装的是开水,杯体是否会烫手。
- 从可靠上考虑,长时间盛装液体,是否会漏水。
- ......
当我们面临一个不熟悉的场景时,难免会无从下手。如果我们有一套方法论,就可以帮助我们提供更全面的思考,得到更完整的输入域。我引用一个我认为比较好的一种描述法,即产品质量的八个特性:
- 功能:是否满足用户需求,核心三要素:正确性、完备性、适合性。
- 效率:在软件中可以理解为性能,包括时间特性、资源占用。
- 兼容:与环境的共存、交互对象的互操