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

本文链接：https://blog.csdn.net/Free355/article/details/129910609

本文探讨了测试用例设计的系统方法，强调万物皆可测，通过交互分析、等价划分、边界测试和用例组合来发掘测试对象的隐性特性。介绍了测试用例的本质是对问题的抽象，以及业务建模的重要性，如业务流程图和数据流程图在测试完整性中的作用。同时提到了其他辅助测试方法，如角色分析法、错误推断法和探索性测试。

摘要由CSDN通过智能技术生成

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

1、万物皆可测

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

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

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