黑盒测试：不用关心底层代码逻辑的具体实现

最常见的黑盒测试用例设计方法有：

黑盒测试用例设计：

一、等价类划分法（✨重点）

1、原理

• 把程序的输入域划分为若干部分，然后从每个部分中选取少数代表性数据作为测试用例。
• 每一类的代表性数据在测试中的作用等价于这一类中的其他值，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误
• 反之，如果某一类中的一个例子没有发现错误，这一类中的其他列子也不会查出错误

2、明确等价类划分法的原则（6条）

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

 🌰：文本框可输入数据 6~18位
   在这个范围之内→  一个有效等价类  eg：10
   在这个范围之外→  无效等价类   eg：4 、20

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

🌰 ：请输入手机号11位，必须为11位
    有效等价类→11位数据
    无效等价类→非11位数据

3️⃣ 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类，“真”就是有效，“假”就是无效

🌰：方框内选取：阅读并接受《百度用户协议》及《百度隐私权保护声明》
                      打勾为有效，不打勾为无效

4️⃣ 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类
5️⃣ 在规定了输入数据必须遵循的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类(从不同角度违反规则)

🌰：用户名要求6-18位，由字母、数字、下划线组成
     此时无效等价类可以有若干个

6️⃣ 在划分的等价类中，各元素在程序处理中的方式不同的情况下，则应在该等价类基础上进一步划分为更小的等价类就（由大化小）

⚡注意事项

注意：测试用例不允许重复、不能缺失，越详细越好

不允许这样设计：

🌰：61012219990230204X → 存在错误。因为2月只有28或者29天

身份证最后一位是校验码，0-9和X（10）

（一条用例只能违反一个规则）

【身份证号：18位，倒数第二位代表性别 （偶数→女生、奇数→男生）】

3.实例🌰：

百度注册页面用例设计（用户名:中英文均可，最长14个英文或7个汉字）

有效等价类	数据	无效等价类	数据
中英文混合	心min月	数字和特殊符号	123&%
14个英文	xinminyue	超过14位	xinminyuexinminyue
7个中文	心皿月	超过7个	心皿月心皿月心皿月
不能为空	心皿月	空
不能重复	皿月	用户名重复（已经注册过）	心皿月

二、边界值分析法（✨重点）

边界值是一个特定的数据。
例如，文本框需要输入6—18位字符，那么此时边界值为：6个字符、18个字符。
次边界：边界附近的值，按照系统规定的单位或计算方式，一般是一个数据的差异。

1、边界值的选择原则

• 如果输入条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超越这个范围边界的值作为测试的输入数据
• 如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少1，比最大个数多1的数作为测试数据
• 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
• 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例。

📑思考题：

（1）6≤X≤12，请问测试中x的边界值要选取哪几个进行测试？

    5.  6 .  7.   11,12,13    【边界值加减1】

（2）6<X<12，请问测试中x的边界值要选取哪几个进行测试？

    此时的6和12是无效数据，应当做无效数据进行测试、
     6  7  8      10,11,12 【边界值加减1】

（3）文本框输入字符的个数要求是不大于150字，测试时如何选择边界值。

     0≤x≤150     测： 空，1， 149,150,151

三、因果图法

1.什么是因果图法

• 因果图法是一种适合于描述对于多种输入条件组合的测试方法

• 根据输入条件的组合，约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法

• 它适用于检查程序输入条件设计的各种组合情况

  🌰：注册QQ
  

2.因果图

第1️⃣步：根据功能说明书中规定的原因和结果之间的关系画出因果图

恒等关系：原因a成立，结果b一定成立
非：原因a成立，原因b一定不成立
或：原因a,b,c三者只要有一个成立，结果d就成立
与：原因a,b,c都成立时，结果d才成立
第2️⃣步：根据功能说明在因果图中加上约束条件

🌟其中互斥，包含，唯一，要求是对原因的约束，屏蔽是对结果的约束。

互斥(exclusion)：表示不同时为1。即a,b,c中至多只有一个1
包含(include)：表示至少有一个1。即a,b,c中不同时为0
唯一(only)：表示a,b,c中有且仅有一个1
要求(request): 表示若a = 1,则b必须为1，即不可能a=1且b=0
屏蔽(mask)：表示若a=1,则b必须为0

3.实例🌰

阅读和分析功能说明书，识别出”原因”和”结果”，并加以编号
案例：有一个饮料自动售货机（处理单价为5角钱）的控制处理软件，它的软件规格说明书如下。
※ 若投入5角钱的硬币，按下”橙汁”或者”啤酒”的按钮，则相应的饮料就送出来。
※ 若投入1元钱的硬币，同样也是按”橙汁”或”啤酒”的按钮，则自动售货机在送出相应的饮料的同时退回5角钱的硬币。

第1步：先分析原因和结果的关系，画出他们之间的关系图（部分关系连线）；按照需求描述原因、结果间的约束。

第2步：列出所有原因和结果的列表，设计初步的测试用例步骤。（列表中的每一列都是一条测试用例）

通过分析发现：
1）只选择饮料，没有投币的时候，软件没有任何结果
2）只投币，没有选择饮料的时候，软件也没有任何结果
我们不能把软件的缺陷，设计成测试用例
因果图的优势在于能够发现测试用例设计中存在的不足。

这里就简单的写上两条测试用例：

4.缺陷

当原因和结果比较多时，他们之间的关系连线就会较多，导致因果图的可读性差。
因此适用于局部的小功能分析，原因结果关系不是很多的情况使用。

四、判定表驱动法

1.概念

判定表法是分析和表达多逻辑条件下执行不同操作的情况的工具，它由以下几个内容组成：

• 条件桩: 列出了问题的所有条件，通常认为列出的条件的次序无关紧要。
• 动作桩： 列出了问题规定可能采取的操作，这些操作的排列顺序没有约束。
• 条件项：列出针对它左列条件的取值，在所有可能情况下的真假值。
• 动作项:列出在条件项的各种取值情况下应该采取的动作。

2.使用场合和条件

使用场合：
主要适用于多条件的内容组合和条件分析。
使用条件：
所有的条件桩在表中的顺序和位置互不影响；
所有的动作桩内的顺序不会因为条件的顺序变化，而产生不同。

3.实现步骤

• 识别出操作条件（原因），和对应的动作（结果）
• 分析条件的条件项（组合数量）：如果有n个条件，每个条件有成立和不成立两种情况，那么最后一共会有2^n个组合数量
• 简化和优化结果，排除一些不可能存在的情况

4.实例🌰

需求：订购单的检查
a.如果金额超过500元，又未过期，则发出批准单和提货单
b.如果金额超过500元，但过期了，则不发批准单
c.如果金额低于500元，则不论是否过期都发出批准单和提货单，在过期的情况下还需要发出通知单

第1步：分析条件和动作

第2步：写入条件桩、动作桩、条件项、动作项

第3步：对判定表进行简化和优化。（对其中不合理或者重复的项进行取舍）
通过观察分析，不管金额是否超过500，只要未过期，就会发批准单和提货单
（在测试时间不充足的情况下，可以选二者中的一个情况进行测试），所以优化之后，条件项就减少为3个：

第4步：将判定表中的每一列（条件项和动作项）作为测试用例的数据和操作以及对应的预期结果

5.适合使用判定表设计测试用例的条件：

规格说明以判定表的形式给出，或很容易转换成判定表
条件的排列顺序不影响执行哪些操作
规则的排列顺序不影响执行哪些操作
当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则
如果某一规则要执行多个操作，这些操作的执行顺序无关紧要

6.优点

能够将复杂的问题按照各种可能的情况全部列举出来，简明并且可以避免遗漏。

五、场景法

1.原理

现在的软件几乎都是用事件触发控制流程的。测试时，可以生动地描绘出时间触发时的情景，有利于设计测试用例，同时使测试用例更容易理解和执行。

2.基本流、备选流

基本流：软件功能按照正确的事件流实现的一条正确流程。通常一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点。
备选流：除了基本流之外的各支流，包含多种不同的情况。

3.设计用例步骤

• 根据说明，描述出程序的基本流及各项备选流
• 根据基本流和各项备选流生成不同的场景
• 对每一个场景生成相应的测试用例
• 对生成的所有测试用例重新复审，去掉多余的测试用例
• 测试用例确定后，对每一个测试用例确定测试数据值

4.适用场景

用于解决业务流程清晰的系统或功能

5.实例🌰

ATM机取款流程
（1）基本流：

（2）包含了备选流的过程

备选流：
1 卡片不是银行卡
2 卡片不是银联的卡
3 密码输错一次
4 密码输错两次，第三次输入正确
5 密码输错三次，冻结账号或者吞卡
6 选择存款服务
7 选择查询服务
8 选择转账服务
9 选择修改密码服务
10 选择取款服务
11 账户取款金额达到取款机的当日取款上限

场景设计：
场景1： 基本流
场景2: 基本流 备选流5
场景3： 基本流 备选流4
场景4： 基本流 备选流1
场景5： 基本流 备选流2 备选流4

设计测试用例：
每一个场景都是一个测试用例
以场景5为例：设计步骤
假定ATM只能识别银联卡。（用一个学生卡插入）
1、插卡（先用学生卡）
2、换卡（银联卡），在进行插卡
3、输入密码（第一次输入错误）
4、再次输入密码（第二次输入错误）
5、第三次输入密码（输入正确）
6、选择服务——取款
7、选择取款金额——500
8、等待出钞
9、取卡

白盒测试用例设计方法

---

• 编写：天林

---

问题：

1. 白盒测试方法的概念及应用场景
2. 白盒测试方法
3. 用各种逻辑覆盖法来和设计白盒测试用例
4. 使用基本路径法来设计白盒测试用例

内容：

1. 白盒测试的基本介绍
2. 白盒测试用例设计方法
   1. 静态设计方法
   2. 动态设计方法

一、白盒测试的概念及特点

1、什么是白盒测试

代码逻辑的测试

• 白盒测试，又称结构测试、逻辑驱动测试或基于程序代码内部构成的测试。此时，测试工程师需深入考察程序代码的内部结构、逻辑设计等。
• 对于白盒测试工程师来说，软件产品内部构成是透明的。

• 下列代码是”图书添加“功能页面对象检查功能函数。从白盒测试角度而言，测试工程师仅需关注此段函数所能实现的功能，无须关注该函数的外部功能特性。

2、白盒测试的特点

1. 优点：代码覆盖率高
2. 缺点：
   1. 覆盖所有代码路径难度大
   2. 业务功能可能覆盖不全
   3. 测试开销大

二、白盒测试设计方法

1、静态设计方法

1. 桌面检查
2. 代码审查
3. 代码走查
4. 代码扫描工具

2、动态设计方法

1. 逻辑覆盖法
   1. 语句覆盖
   2. 判定覆盖
   3. 条件覆盖
   4. 判断条件覆盖
   5. 条件组合覆盖
   6. 路径覆盖
2. 基本路径测试法

三、逻辑覆盖法

• 逻辑覆盖法：是通过程序逻辑结构的便利实现程序的覆盖。
• 覆盖率：是用来度量测试完整性的一个手段

1、语句覆盖

1、语句覆盖设计用例

• 语句覆盖：设计测试用例，是对程序中每条语句至少被执行一次。
  

例如：

• 案例代码中共有4条可执行语句
• 设计测试用例执行了3条，语句覆盖率为3/4=75%

2、语句覆盖法的局限性

2、判定覆盖

1、判定覆盖法设计用例

• 判定覆盖：也叫分支覆盖，设计测试用例，使得程序中的每个判断的”真“和”假“都至少被执行一次。即：程序中的每个分支至少执行一次。

例如：

• 案例代码中有判定2个，判定结果4个
• 设计测试用例执行了3个分支，分支覆盖率为3/4=75%

2、判定覆盖法的局限性

• 只要满足了判定覆盖标准就一定满足语句覆盖标准。

3、条件覆盖

1、条件覆盖法设计测试用例

• 条件覆盖：设计测试用例，使得判定中的每个条件至少有一次取真值，有一次取假值。

例如：

• 案例代码中有判定2个，条件3个，条件结果6个
• 设计测试用例执行了5个条件结果，条件覆盖率为5/6=83%

2、条件覆盖法的局限性

4、判定条件覆盖

1、判定条件覆盖法设计测试用例

• 判定条件覆盖：设计测试用例，使得被测试程序中的每个判断本身的判定结果（真假）至少满足一次，同时，每个逻辑条件的可能值（真假）也至少被满足一次。即同时满足100%判定覆盖和100%条件覆盖的标准。

例如：

• 案例代码中有判定2个，条件3个，判定结果4个，条件结果6个
• 设计测试用例执行了3个判定结果，5个条件结果，判定条件覆盖率为：（3+5）/（4+6）=80%

2、判定条件覆盖法的局限性

5、条件组合覆盖

1、条件组合覆盖法设计用例

• 条件组合覆盖：设计测试用例，使得被测试程序中的每个判定中条件结果的所有可能组合至少执行一次。

例如：

• 案例代码中有判定2个，条件3个（判定1有2个条件，判定2有1一个条件），判定1的条件组合为4个，判定2的条件组合为2个
• 设计测试用例执行了5个条件组合，条件组合覆盖率为：5/（4+2）=83%

2、条件组合覆盖法的局限性

6、路径覆盖

1、路径覆盖法设计测试用例

• 路径覆盖：设计测试用例，覆盖程序中所有可能的路径。

例如：

• 案例代码中共有4条路径
• 设计测试用例执行了3条路径，路径覆盖率为3/4=75%

2、路径覆盖法的局限性

四、基本路径测试法

• 基本路径测试法：在程序控制流程图的基础上，通过分析程序的环路复杂性，导出基本可执行路径集合，从而设计测试用例
• 基本路径测试法步骤：

五、总结