软件测试用例设计的隐秘黑暗面：你从未听闻

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

1、万物皆可测

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

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

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

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

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

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

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

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

• 功能：是否满足用户需求，核心三要素：正确性、完备性、适合性。
• 效率：在软件中可以理解为性能，包括时间特性、资源占用。
• 兼容：与环境的共存、交互对象的互操作。
• 易用：用户理解、操作需要付出多少努力。