黑盒测试-用例设计(上)

黑盒测试

通过测试来检测每个功能是否都能正常使用。在测试中，把程序看当做一个黑盒子，在完全不考虑程序内部结构和内部特性的情况下进行测试，只检查程序功能是否预期且正常使用，是否能根据指定输入而产生正确的预期输出。黑盒测试着眼于程序外部功能，不考虑内部逻辑，主要针对软件程序界面和软件功能。

注意： 黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。

测试流程

• 测试计划
• 用例设计
• 测试开发
• 测试执行
• 缺陷分析
• 结果反馈

测试方法

• 等价类划分
• 边界值分析
• 错误推测法
• 因果图&&判定表
• 场景法
• 正交实验法
• Pairwise

后续将详细说明以上各类测试方法的使用

---

等价类划分

等价类划分法是把程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。其中分为有效等价和无效等价：

• 有效等价类: 是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
• 无效等价类: 与有效等价类的定义恰巧相反。

设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性。

划分等价类的六大原则：

1. 在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.

例：输入值是学生成绩，范围是0～100：有效等价类(0 <= 成绩 <= 100) 无效等价类(成绩 < 0 || 成绩 > 100)

2. 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.

例：只能输入数字。有效等价类(数字)， 无效等价类(非数字)

3. 在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类. 布尔量是一个二值枚举类型, 一个布尔量具有两种状态: true 和 false 。

有效等价类(True)、无效等价类(False)

4. 在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.

例：输入条件说明输入英文字母区间为A-F，则分别取这个区间所有的值作为有效等价类，其他以外的任何字母作为无效等价类。

5. 在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）

例：只能输入正整数。有效等价类(正整数)， 无效等价类(负数、0、小数、中文、特殊字符、英文等)

6. 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类

例：温度的三个区间变化，（-273° ~ -1°）、（0）°、（1°~100°）。可以将这三个部分进行拆分。

等价类转化成测试用例步骤

1. 按照[输入条件][有效等价类][无效等价类] 建立等价类表,列出所有划分出的等价类
2. 为每一个等价类规定一个唯一的编号.
3. 设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.
4. 设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.

经典三角形的测试用例设计案例

需求：

在三角形计算中，要求三角形的三个边长：A B C 。

1. 当三边不可能构成三角形时提示错误，可构成三角形时提示"是三角形"。
2. 若是等腰三角形打印“等腰三角形”， 若两个等腰的平方和等于第三边平方和，则打印“等腰直角三角形”。
3. 若是等边三角形，则打印：“等边三角形”。
4. 画出程序流程图并设计一个测试用例。

分析：

• 构成三角形的条件：任意两边之和大于第三边；
• 构成等腰三角形的条件：任意两边相等；
• 构成等腰直角三角形的条件：任意两边相等，而且两条边的平方和等于第三边的平方和；
• 构成等边三角形的条件：三条边都相等。

输入条件	有效等价类	无效等价类
是否三角形	1.(A>0) 2.(B>0) 3.(C>0) 4.(A+B>C) 5.(A+C>B) 6.(B+C>A)	7.(A<0) 8.(B<0) 9.(C<0) 10.(A+B<C) 11.(A+C<B) 12.(B+C<A)
是否等腰三角形	13.(A=B) 14.(A=C) 15.(B=C)	16.(A!=B && A!=C && B!=C)
是否等腰直角三角形	17.((A=B) && (A²+B²=C²)) 18.((A=C) && (A²+C²=B²)) 19.((C=B) && (C²+B²=A²))	20.(A=B or A=C or B=C) && (A²+B²!=C² or A²+C²!=B² or C²+B²!=A²)
是否等边三角形	21.(A=B && A=C && B=C)	22.(A!=B) 23.(A!=B) 24.(B!=C)

等价类转化用例 - >

序号	输入[A,B,C]	覆盖等价类	预期输出
1	[3,4,5]	1,2,3,4,5,6	是三角形
2	[0,1,2]	7	非三角形
3	[1,0,2]	8	非三角形
4	[1,2,0]	9	非三角形
5	[1,2,3]	10	非三角形
6	[1,3,2]	11	非三角形
7	[3,1,2]	12	非三角形
8	[3,3,4]	1,2,3,4,5,6,13	等腰三角形
9	[3,4,4]	1,2,3,4,5,6,14	等腰三角形
10	[3,4,3]	1,2,3,4,5,6,15	等腰三角形
11	[4,2,2]	1,2,3,4,5,6,17	等腰直角三角形
12	[2,4,2]	1,2,3,4,5,6,18	等腰直角三角形
13	[2,2,4]	1,2,3,4,5,6,19	等腰直角三角形
14	[3,4,5]	1,2,3,4,5,6,20,22,23,24	是三角形
15	[3,3,3]	1,2,3,4,5,6,21	等边三角形
16	[0,0,0]	无效等价	错误提示
17	[-3,4,5]	无效等价	错误提示
18	[a,3,@]	无效等价	错误提示
19	[3,4,0]	无效等价	错误提示

用例1和用例14很明显是重复覆盖了，所以可以直接保留14去掉1.从上面的用例可以看出转化后的用例数是比较多的。可以进一步结合下面将要介绍的边界值分析法进一步优化用例。

---

边界值分析法

边界值分析法：就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。往往大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件，边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

哪些情况需要做边界值分析？

1. 输入条件明确了值的范围
2. 输入条件明确了值的个数
3. 输入条件明确了是一个有序的集合

举例：

一个输入框只允许输入1-100区间的数字。

分析：

0 < number <= 100

这里的边界有两个0和100，这里边界情况取了5种，-1，0，66，100，101,这里的考虑是由于列表可能会存在开闭区间，所以除了边界值，还要考虑边界值过去一点点，然后因为 number 是个范围，还要在范围内补充一个测试点，这里取66。实际情况可能会根据列表的开闭区间去设计，才能尽可能设计出合理有效的用例。

边界值分析时结合等价类做到合理的取边界值，而不是盲目的取所有边界和临近边界的值。作为等价类划分方法的一种补充，使用的时候需要结合等价类划分合理的使用。

---

错误推测法

错误推测法是指：在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。

错误猜测主要是一项依赖直觉的非正规的工程方法，其基本思想是列举程序可能出现的错误或者容易产生错误的测试点来编写测试用例。另外还可以在熟悉业务或需求相关时联想开发的实现和用户场景假设来确定测试用例，比如需求与实际业务场景不匹配等。

错误猜测法并非是一项有章可循的工程设计方法，而是很大程度上依赖于测试人员的经验、能力以及态度。错误猜测法并非是一项有章可循的工程设计方法，而是很大程度上依赖于测试人员的经验、能力以及态度。

从个人测试经验角度来看，在考虑使用错误猜测法补充测试用例时，可以从如下维度考虑：

• 极限值设计：
  考虑数值最大、最小、为空、为0等情况。

• 特殊取值设计:
  年、月、日情况，必须考虑平年、闰年，2月，每月包含28天、29天、31天等情况。同时考虑跨年、跨月等情况.常见的YYY-MM-DD或时区等。其他取值，包括NULL、1024、FALSE（0）、TRUE（1）、特殊字符（！@#...）等。

• 基于业务设计：
  通常测试用例都是以特性为维度进行设计，或者测试人员在用例执行时都是分功能进行测试用例设计和执行，并未进行端到端测试用例设计。而端到端的测试用例更容易发现问题。

• 性能并发：
  测试场景补充设计时必须要考虑性能情况，特别是未针对核心特性进行性能场景验证的情况。

• 安全角度：
  是否考虑不同用户权限功能使用情况、日志中是否有明文显示用户隐私信息、用户登录是否安全校验机制（如密码连续3次输入错误锁账户、验证码）、
  是否允许越权、前后台校验是否一致等等。

• 用户体验：
  提示信息描述是否合理、搜索出现单条记录是否默认选中、交互次数是否太多、界面操作是否简洁、新增菜单风格是否与已知菜单保持一致。

• 历史数据兼容：
  要充分考虑历史数据兼容、新老版本兼容，刷数据脚本也需要关注验证。往往这里忽略将会造成很大损失。

• 针对人的角度：
  这一条情况比较特殊。版本的缺陷会因人而异，同样的特性会由于开发能力、开发态度、开发自验证程度的不同而产生不同的bug。特别注意新员工、自验证随意的开发人员，你会发现有很多"惊喜"。但这些"惊喜"没有在版本发布前发现，就会成为"惊吓"了。当然不仅仅局限于开发，产品也是因人而异，尽可能从源头去预防问题的发生。

使用场景： 先用其他方法设计测试用例，再使用错误猜测法补充或者优化用例。

注意点及建议

错误猜测法的使用在不同的测试人员手里威力大小会有很大的区别，有经验、有态度的测试人员利用错误猜测法可以发现很多常规工程方法难以发现的问题。因而提升效率和质量。而经验不足或者能力不足的测试人员是很难利用好这一方法。

同时，要注意的是，使用错误猜测法有点类似"探索性测试"，同时，在版本管理过程中，建立好版本常见或典型测试问题集(异常case库)，定期进行巡检和推广，可以快速提升测试人员发现问题的能力和经验。