测试方法

黑盒测试方法

黑盒测试使用范围比较广泛，
优点主要是站在用户的角度进行测试，测试人员不需要了解程序实现的细节，相对白盒测试而言，黑盒测试的测试数据很容易生成，但是要测试到每一个输入流几乎是不可能的。
缺点就是不能针对特定的程序段，这样很容易造成程序路径的漏测，当程序非常复杂时其隐藏的问题很难发现。在实际工作中，由于黑盒测试的测试人员编程能力相对薄弱，所以大部分测试人员现在研究的都是介于白盒和黑盒之间，就是灰盒测试，也是常说的接口测试。

一、等价类划分 --掌握

1.1、概念

等价类划分，指的是一种典型的、重要的黑盒测试方法。其就是解决如何选择适当的数据子集来代表整个数据集的问题，通过降低测试的数目去实现“合理的”覆盖，以此发现更多的软件缺陷。

等价类划分法是把程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果。

等价类划分可有两种不同的情况:有效等价类和无效等价类

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

无效等价类:与有效等价类的定义恰巧相反，不合理的、无效的输入数据构成的集合。

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

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

1.2、划分等价类的六大原则：

1. 在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。
   例：手机号码
2. 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类。
3. 在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类. 布尔量是一个二值枚举类型, 一个布尔量具有两种状态: true 和 false 。
4. 在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。
   例：输入条件说明输入字符为:中文、英文、数字三种之一，则分别取这三种这三个值作为三个有效等价类，另外把三种字符之外的任何字符作为无效等价类（特殊字符等，html标签等）。
5. 在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
   例：身份证号码
6. 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。

1.3、实例

假设要输入一个日期，日期限定在1990年1月~2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的"日期检查功能"。

1)划分等价类并编号,下表等价类划分的结果

2)设计测试用例，以便覆盖所有的有效等价类在表中列出了3个有效等价类，编号分别为①、⑤、⑧，设计的测试用例如下：

3)为每一个无效等价类设计一个测试用例，设计结果如下：

练习：

1. 对手机号用 等价类划分设计一下用例
2. 保险投保年龄 只允许18-60岁之内人投保

二、边界值 --掌握

2.1 概念

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

根据大量的测试统计数据，很多错误是发生在输入或输出范围的边界上，而不是发生在输入/输出范围的中间区域。因此针对各种边界情况设计测试用例，可以查出更多的错误。

使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

2.2、边界的确认

边界值分析使用与等价类划分法相同的划分，只是边界值分析假定错误更多地存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例。

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

3、如果规定了输入域的取值范围，则选取刚好在范围边界的点，以及刚好超过边界的点，作为测试的输入数据。
4、如果规定了输入值的个数，则用最大个数，最小个数，比最小个数少1，比最大个数多1的数作为测试数据。
5、如果规定了输入是一个有序的集合，则选取集合的第一个元素和最后一个元素作为测试数据。

通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。相应地，以上类型的边界值应该在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、 最短/最长、 空/满等情况下。利用边界值作为测试数据

2.3、案例分析

如某保险公司发布一个产品，规定投保年龄 只允许18-60岁之内的人投保

得出等价类

输入值	有效等价类	无效等价类
整数	18<= i <=60	i<18 or i >60
小数		全部
字符串		全部

由等价类抽取 设计边界值

边界	有效边界	无效边界
整数18	18、19	17
整数60	59、60	61
小数全部		0.5、18.5
字符串全部		啦啦

练习：

1.某登录界面逻辑 用户名输入,规定只允许8-15个字母+数字任意组合

2.学生信息系统中有一个“考试成绩”的输入项，成绩的取值范围是0~100之间的整数，考试成绩及格的分数线是60

三、判定表法 --熟悉

3.1、概念

判定表是把作为条件的所有输入的各种组合值以及对应输出值都罗列出来而形成的表格。它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。
因此，利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。

判定表分析法主要是分析和表达多种输入条件下系统执行不同动作的技术。在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了，它可以把复杂的逻辑关系和多种条件组合的情况表达得很明确。判定表由四个部分组成

简而言之：是根据判定条件列出所有可能的组合，当有n个条件时，就需要列出相应的2的n次方个测试用例。

3.2、案列解析一：

某登录逻辑只有当用户名和密码输入正确时 才登录成功

1. 先明确理解需求

2. 画出判定表

3. 列出条件桩和动作桩

4. 填写条件项，对条件进行全组合

5. 根据条件项的组合确定动作项 简化、合并相似规则（有相同的动作

分析组合

username	password	结果
正确	错误	失败
正确	正确	成功
错误	错误	失败
错误	正确	成功

条件桩：列出问题中的所有条件。列出条件的次序无关紧要。

​ 如案列里面的有两个条件，条件一：用户名 ，条件二：密码

动作桩：列出问题中可能采取的操作。操作的排列顺序没有约束。

所有操作的输出结果

条件项：列出条件对应的取值。所有可能情况下的真假值。

所有条件的组合

动作项：列出条件项的各种取值情况下应该采取的动作结果。

所有条件组合出现的结果

这样我们每一条组合就是一条用例数据

练习：判断一个某一年是不是闰年？其中闰年的判定条件为能被4整除但不能被100整除或者能被400整除。

四、场景法（流程分析法） --熟悉

4.1、概念

场景法又称流程分析法，主要是针对测试场景类型。它是从白盒测试设计方法中的路径覆盖分析法演变过来的一种重要的方法。在白盒测试中，路径就是指函数代码的某个分支组合，路径覆盖法需要构造足够的用例覆盖函数的所有代码路径。在黑盒测试中，若将软件系统的某个流程看成路径的话，则可以针对该路径使用路径分析的方法设计测试用例。

在测试一个软件的时候，在场景法中，测试流程是软件功能按照正确的事件流实现的一条正确流程，那么我们把这个称为该软件的基本流；而凡是出现故障或缺陷的过程，就用备选流加以标注，这样的话，备选流就可以是从基本流来的，或是由备选流中引出的。

在实际工作中，流程分析法是比较容易理解和执行的，它是主要通过流程对系统的功能点或业务流程进行描述，可以展示测试效果。流程分析法一般包含基本流和备选流，从一个流程开始，通过描述经过的路径来遍历所有的基本流和备选流。

• 基本流：是指程序的主流程，是实现业务流程最简单的路径。
• 备选流：是指实现业务流程时，因错误操作或者是异常操作，导致最终未达到目的流程。

流程1：基本流

流程2：基本流→备选流1

流程3：基本流→备选流1→备选流2

流程4：基本流→备选流3

流程5：基本流→备选流3→备选流1

流程6：基本流→备选流3→备选流1→备选流2

流程7：基本流→备选流4

流程8：基本流→备选流3→备选流4

直线表示基本流；其他曲线表示为备选流。由图可以看到，一个备选流可以从基本流开始；也可以从备选流开始。备选流的终点，可以是一个流程的出口，也可以是回到基本流，还可以是汇入其他的备选流。

4.2、案例解析

在银行ATM取款机的取款 流程进行测试。

分析得出流程

每一个流程 我们就可以转换为一条测试用例

练习：

一个需要输入用户名和密码的登陆并付款购物功能，其中如果密码错误3次会锁定用户

五、因果图法 --了解

5.1、概念

一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，以及输入与输出之间有依赖关系 因果图（逻辑模型）

因果图相辅 判定表 ，因为最后因果图 还是要转换成判断表用例

优点：

1、能够帮助我们按照一定步骤，高效的选择测试用例，设计多个输入条件组合用例。

2、因果图分析还能为我们指出，软件规格说明描述中存在的问题

缺点：

输入条件与输出结果的因果关系，有时难以从软件需求规格说明书得到。

即时得到了这些因果关系，也会因为因果关系复杂导致因果图非常庞大，测试用例数目及其庞大

其中

因果图的 “因” —输入条件

因果图的 “果” —输出结果

5.2、 因果图几种符合逻辑

因果符号有恒等、非、或、与四种表示方法，如图所示，其中c1表示输入的状态，即原因、e1表示输出的状态，即结果。

c1和e1均可取值0或1（0表示某状态不出现，1表示某状态出现）

5.3、约束符号

约束是指输入与输入之间存在的某些依赖关系，称为约束。约束符号有互斥、包含、唯一、要求、屏蔽五种表示方法，其中前面四种是针对输入条件的约束，最后一种强制只针对输出条件的约束。

如下图：其中a、b、c分别代表条件。条件的取值0或1（0表示某状态不出现，1表示某状态出现）。

• 互斥：在所有输入条件中，至多有一个可能发生。即a、b、c 最多只有一个为1，不能同时为1，但可以同时为0。

• 包含：在所有输入条件中，至少有一个发生。即a、b、c最少有一个为1，不能同时为0，但可以同时为1。

• 唯一：在所有输入条件中，有且只有一个发生。即a、b、c，只有一个为1，不能同时为1，也不能同时为0。

• 要求：在所有输入条件中，只要有一个发生，则要求其他条件也发生。即a和b，a为1时，要求b也为1。

• 屏蔽：是针对结果的约束关系，当一个结果发生，强制另一个结果不发生

5.4、构造测试用例

• ① 分析需求中描述的原因和结果，给每个原因和结果赋予一个编号。

• ② 根据这些关系画出因果图

• ③ 因果图上用一些记号表明约束条件或限制条件

• ④ 把因果图转换成判定表

• ⑤ 将判定表的每一列作为依据设计测试用例

5.5、案列解析

有一个单价为5毛的 饮料自动售货机允许投入5角和1元的硬币，用户可通过“橙汁”和“啤酒”按钮选择饮料，售货机中无零钱找时提示灯亮。默认零钱为5毛

当用户投入5角硬币并押下“橙汁”或“啤酒”按钮后，售货机送出相应的饮料。

当用户投入1元硬币并押下“橙汁”或“啤酒”按钮后，如果售货机有零钱找，则送出相应的饮料，并退还5角硬币；如果售货机没有零钱找，则饮料不送出，并且退还1元硬币。
分析规格说明，列出原因和结果
根据规格说明，反映原因的输入条件有：投入1元硬币，投入5角硬币，押下“橙汁”按钮，押下“啤酒”按钮。反映结果的输出条件有：退还1元硬币，退还5角硬币，送出“橙汁”饮料，送出“啤酒”饮料。由于“售货机有零钱找”是在投入1元硬币时判断是否能找零钱的依据，所以也可把它看作是一个输入条件，即原因。与之对应的结果是售货机指示灯亮（或暗）。

分析如下：

输入：
1——售货机有零钱找
2——投入1元硬币
3——投入5角硬币
4——押下橙汁按钮
5——押下啤酒按钮

输出：
21——售货机〖零钱找完〗灯亮
22——退还1元硬币
23——退还5角硬币
24——送出橙汁饮料
25——送出啤酒饮料

得出以下 因果图

其中中间结点的含义如下：
结点11表示投入1元硬币且押下饮料按钮。
结点12表示押下“橙汁”或“啤酒”按钮。
结点13表示应找5角硬币且售货机有零钱找。
结点14表示钱已付清。

由于原因2和3不能同时发生，原因4和5也不能同时发生，所以需加约束条件E，如上图。

在因果图中加上约束条件、根据因果图画出判定表

阴影部分表示因违反约束条件，不可能出现情况，故删去

第16 和第32列 因什么动作也没做 也删去

最后可根据剩下的16列作为确定测试用例

六、错误推测法 了解

错误推测方法是指基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。这个方法强调的是对被测试软件 的需求理解以及设计实现的细节把握，当然还有个人的能力。

错误推测法和目前非常流行的“探索式测试方法”的基本思想和理念是不谋而合的，这类方法在目前的敏捷开发模式下的投入产出比很高，因此被广泛应用。但是，这个方法的缺点也 显而易见，那就是难以系统化，并且过度依赖个人能力。