测试：用例篇

上一章讲述的是测试的基本概念。在我们开始做了一段时间基础测试，熟悉了业务之后，往往会 分配来写测试用例，并且在日常测试中，有时也需要补充测试用例到现有的案例库中

在开始之前先讲讲测试中经典的测试方法：黑盒测试、白盒测试

按照是否需要知道程序内部是如何实现的，将测试分为黑盒测试与白盒测试。

需要知道程序内部是如何实现的——白盒测试 不需要知道程序内部是如何实现的——黑盒测试

白盒测试一般是内部人员即程序员进行测试黑盒测试一般是外部人员如专门的测试人员和用户来测试

这里将会介绍测试用例中经典的测试方法：黑盒测试

重点的黑白盒在下一章重点介绍。

本章的重点内容如下：

测试用例的基本要素测试用例的设计方法 基于需求的设计方法等价类边界值因果图正交排列场景设计法错误猜测法 测试用例的有效性测试用例的粒度和评价 什么是黑盒测试？

黑盒测试又称为功能测试，主要检测软件的每一个功能是否能够正常使用。在测试过程中，将程序看成不能打开的黑盒子，不考虑程序内部结构和特性的基础上通过程序接口进行测试，检查程序功能是否按照设计需求以及说明书的规定能够正常打开使用。

测试用例的要素

主要的用例要素主要有以下四个重要要素

测试环境：就拿我们这个浏览器来说，这是什么浏览器啊，什么版本啊等等；像这样的我们通常为测试环境。

操作步骤：在测试报告中必须要说清楚你的具体操作步骤，不然可能就你一个人这么操作除了问题，而其他人正常操作却没有发现问题。

测试数据：把本次或多次的具体数据写进测试报告。

预期结果：不论如何测试用例得有个结果吧，这个结果是你预期的到还好，不是就需要往前找出问题，是自己测试时操作出了问题，还是说前后端代码有问题。

我们为什么需要有这些测试用例，用例的好处是啥呢？

提高测试效率，节省测试时间（避免重复测试）测试用例是自动化测试用例的前提（未来具体是使用手动测试还是自动化测试，这得看公司的具体安排，我们两个都得学习）。 测试用例的设计方法 1. 基于需求的设计方法

具体的步骤如下：需求文档 -> 梳理需求（掌握需求）-> 针对文档设计测试用例（基于需求设计测试用例）

我们来举个栗子：

需求文档（每个项目都会有各自需求文档）；

梳理需求：假设我们要对这个微信升级（发红包功能）；现在起发红包最多能发 300 ，而红包领取限制为 36h 之内。

针对文档设计测试用例：超出了300 能不能发送成功呢，恰好300 能不能发送成功呢?等等，这些都是需要我们去测试的。

2. 等价类

什么是等价类测试？ 等价类是指某个输入域的子集合中各个数据对于揭露程序的错误都是等效的，或者进行相同的处理。测试某等价类的一组数据就等价于对这一类其他值得测试，因此在等价类中只需要取一组测试用例即可。等价类集合的划分，提供完备性、保证无冗余性。

比如：我们理科将 物理，化学，生物 分在一起，这些就是等价类。

在等价类中还有两个概念：

有效等价类：满足客户需求输入集合类

无效等价类：不满足客户需求输入集合类

这里再举个栗子：

我们男生对未来老婆都有个理想中的评判标准：好看，有车有房，有存款，勤快，温柔体贴。这些满足男孩子理想中的需求（也就是有效等价类）。

其他少一点，统称为无效等价类。

这栗子不是很恰当，能理解就行。

换个栗子：在注册时设计登录密码，要求 8 ~ 16 位密码

那么有效等价类就是：6 ~ 15 位

无效等价类： 小于 6 位或者大于 15 位

3. 边界值

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

我们边界值中还有边界点的概念：

上点：边界上的点离点：离上点最近的点。如果输入域是封闭的，则离点在域范围外；如果输入域是开区间，则离点在域的范围内。内点：在输入域内任意一个点

助记： 上点是有效数据时，离点是无效数据 上点是无效数据时，离点是有效数据

这实用于一闭一开区间

示例 区间 (10, 20) 12 是内点10、20 是上点11、19 是离点区间 [10, 20] 12 是内点10、20 是上点9、21 是离点区间 [10, 20) 12 是内点10、20 是上点9、19 是离点

上述来自：

(231条消息) 【软件测试】边界值术语——上点、离点、内点_上点离点内点_hazelnut_x的博客-CSDN博客

4. 因果图

等价类划分法和边界值分析方法都是着重考虑输入条件，如果程序输入之间没有什么联系，采用等价类划分和边界值分析是一种比较有效的方法。如果输入之间有关系，例如，约束关系、组合关系，这种关系用等价类划分和边界值分析是很难描述的，测试效果难以保障，因此必须考虑使用一种适合于描述对于多种条件的组合，产生多个相应动作的测试方法，因果图正是在此背景下提出的。因果图法着重测试规格说明中的输入与输出间的依赖关系。

我们这里就稍稍理解以下就行了，不必那么纠结

基本图形符号：

恒等。若原因出现，则结果出现；若原因不出现，则结果不出现。非。若原因出现，则结果不出现；若原因不出现，则结果出现。或。若几个原因中有一个出现，则结果出现；若几个原因均不出现，则结果不出现。与。若几个原因都出现，结果才出现；若几个原因中有一个不出现，则结果不出现。

为了表示因果图中的约束条件，可用一些符号在因果图中加以标识。

限制关系图形符号

限制关系图形要么在因（输入条件）之间，要么在果（输出结果）之间。

从原因方面考虑主要有4种约束条件：

E(互斥、排他)。a、b两个原因不会同时出现，最多只有一个出现。I(包含、或)。a、b、c三个原因至少有一个出现。O(唯一)。a、b两个原因必须有一个出现，且仅有一个出现。R(需求)。a出现时b必定出现。

从结果方面考虑主要有1种约束条件：

M(屏蔽)。a出现时，b必定不出现；a不出现时，b则不确定。

上述来自：《因果图法》-有这篇就够了 - 知乎 (zhihu.com)

5. 正交排列

因果法设计用例太多怎么办？

正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合  

能够使用最小的测试过程集合获得最大的测试覆盖率，从全面试验中挑选出有代表性的点进行测试。适用于配置类软件，组合比较多的情况。

正交表Ln(m^k):

特点：均匀分散、整齐可比、高效、快速、经济.

n 正交表的行数，也就是需要测试的组合的次数； k 正交表的列数，也就是控件的个数； m是每个控件包含的取值个数；

两个重要概念

因素：输入的变量

水平：每个输入变量的取值

如何通过正交表设计测试用例

充分理解需求 -> 确定因素，确定水平 -> 画正交表-> 将正交表转换为测试用例

继续以注册账号为例

就拿这个知乎注册为例，我们想要注册一个知乎的账号，必须要手机号，获取验证码，后面还会有密码，等等。

此时的需求就是注册账号

此时的 因素 为：手机号、验证码 等

水平：填写/不填写.

6. 场景设计法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。 典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向 还是以注册为例：

 7. 错误猜测法

这就得看测试人员的经验了，靠自己的经验写出测试用例，我们只能多看、多谢一些测试用例，积累经验。

测试用例的有效性

什么是测试用例的有效性呢？

以下举几个栗子：

测试用例对应的功能已删除，不可操作了

微信刚出来时与QQ可互发消息，下一个版本后就不可以发消息。

执行一条测试用例未发现BUG，实际该处有BUG

苹果7手机微信添加了mobile单车小程序，扫码不能开锁，只能使用mobile APP开锁，测试用例未涉及到苹果7微信小程序扫码开锁。

执行一条测试用例发现了BUG

苹果7手机微信添加了mobile单车小程序，用例已写到了苹果7微信添加mobile小程序扫码开锁，问题被发现

执行一条测试用例未发现BUG，实际该处BUG已修改

苹果7手机微信添加了mobile单车小程序扫码开锁，可以正常开锁

测试用例的粒度

好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试

粒度：指测试用例编写的详细程度。

测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每数据，期待的结果及检验的方法， 具体到界面元素的操作步骤，指定测试的方法和工具等。

(1)测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。 (2)测试用例写得过于简单，则可能失去了测试周例的意义。

详细与否主要考虑可以参考如下内容：

产品的质量要求项目对用例的要求测试时间和资源是否充分  

但是不管用例怎么简化，上述三步操作都不应该省略。