软件测试与质量 之白盒测试

目录

一、概述

1.1 关注对象

1.2 优劣势

二、常见白盒测试方法

2.1 控制流分析

2.1.1 常见的程序结构

2.1.2 控制流分析的内容

2.2 对判定的测试（逻辑覆盖）

2.2.1 语句覆盖(Statement Coverage)

2.2.2 判定覆盖(Branch Coverage)

2.2.3 条件覆盖(Condition Coverage)

2.2.4 判定/条件覆盖(Branch/Condition Coverage)

2.2.5 条件组合覆盖(Condition Combination Coverange)

2.2.6 修正的判定/条件覆盖(Modified Condition/Decision Coverage)

2.3 代码检查

2.3.1 同行评审方法

2.3.2 同行评审流程

2.3.3 评审结果

2.4 静态结构分析 

2.4.1 函数调用关系图

2.4.2 函数的控制流图

2.5 路径覆盖

2.5.1 基于等价路径的测试

2.5.2 基于独立路径的测试

2.5.3 区别

2.5.4 相关术语和概念

2.5.5 测试用例设计

2.5.6 不可行路径问题

2.5.7 场景爆炸问题

---

一、概述

软件测试不仅包括动态测试，还包括对系统的静态检查，这种检查通常不需要实际运行被测软件，而是直接对软件形式和结构进行分析。

1.1 关注对象

• 源代码

措施：阅读源代码，检验代码的规范性，并对照函数功能查找代码的逻辑缺陷、内存管理缺陷、数据定义和使用缺陷等。

• 程序结构

措施：使用与程序设计相关的图表，找到程序设计的缺陷，或评价程序的执行效率。

1.2 优劣势

优势

针对性强，便于快速定位缺陷。
在函数级别开始测试工作，缺陷修复成本低
有助于了解测试的覆盖程度
有助于代码优化和缺陷预防

不足和弊端
对测试人员要求高（测试人员需要具备一定的编程经验，白盒测试工程师需要具备广播的知识面）
成本高（白盒测试准备时间较长）

二、常见白盒测试方法

2.1 控制流分析

2.1.1 常见的程序结构

• 线性结构

• 条件判定结构

• while-do循环结构

•  do-while循环结构

 缺陷风险逐渐增大：串行结构<两分支的条件判断<多分支的条件判断<循环结构

2.1.2 控制流分析的内容

• 关注判定节点固有的复杂性
  • 焦点：判定表达式
  • 方法：逻辑覆盖测试
• 关注判定结构与循环结构对执行路径产生的影响
  • 焦点：路径
  • 方法：独立路径测试
• 关注循环结构本身的复杂性
  • 焦点：循环体
  • 方法：基于数据的静态分析

2.2 对判定的测试（逻辑覆盖）

基本测试原则：对程序代码中所有的逻辑值均需要测试真值和假值的情况

通过考察源代码中的复合判定表达式，或构成复合判定表达式的各个简单判定条件的所有取值来展开测试

2.2.1 语句覆盖(Statement Coverage)

设计测试用例时，需要保证程序中每一条可执行语句至少应执行一次

语句覆盖是最弱的一种覆盖标准，它主要存在两方面弊端：

• 关注语句，而非关注判定节点
• 对隐式分支无效（隐式分支：if条件判定中，缺少else的情况）
• 对策：优选测试数据
• 更强的覆盖准则：判定覆盖

2.2.2 判定覆盖(Branch Coverage)

判定覆盖（分支覆盖）：设计测试用例时，应保证程序中每个判定节点取得每种可能的结果至少一次，相当于对控制流图进行边覆盖

判定覆盖的局限性：
当判定节点中包含的是复合判定表达式，即由多个简单判定条件通过“与"、"或"关系连接而成的判定时，判定覆盖仅关心表达式的整体取值，并不关心表达式如何构成，不能覆盖到每个子条件的所有取值情况，由此导致测试漏洞

2.2.3 条件覆盖(Condition Coverage)

设计测试用例时，应保证程序中每个复合条件判定表达式中，每个简单判定条件的取真和取假情况至少执行一次。

条件覆盖并不能确保满足判定覆盖，它虽然进一步检查了判定节点中的每个子条件，但判定节点局部的完全覆盖并不能保证对判定节点整体的完全覆盖。

2.2.4 判定/条件覆盖(Branch/Condition Coverage)

测试用例的设计应满足判定节点的取真、取假分支至少执行一次，且每个简单判定条件的取真和取假情况也至少执行一次，即判定覆盖+条件覆盖。

弊端：设计难度大

2.2.5 条件组合覆盖(Condition Combination Coverange)

测试用例的设计应满足每个判定节点中，所有简单判定条件的所有可能的取值组合情况应至少执行一次。

本质：通过列出真值表的方式来得到完全的覆盖（用测试用例的冗余来换取方法的简单性）

优势：方法简单；只需要找到所有简单情况，并列出真值表，穷尽所有组合情况即可

弊端：测试用例太多，冗余严重

2.2.6 修正的判定/条件覆盖(Modified Condition/Decision Coverage)

基本思想：在判定/条件覆盖的基础上，每个简单判定条件都应独立地影响到整个判定表达式的取值

实质：利用简单判定条件的独立影响性来消除测试用例的冗余

修正的判定/条件覆盖指标被广泛应用于国防和航空航天领域

最后的测试用例为： 

测试用例设计的一般步骤：

• 列出所有的简单判定条件
• 构建真值表
• 对每个简单判定条件，找到能够对整个判断结果产生独立影响的测试用例集合(简称独立影响对)；注意独立影响对可能不止一组
• 具体措施是：抽取能体现所有简单判定条件独立影响性的最少独立影响对

优势：综合具备条件组合覆盖的优点，有效控制了测试用例的数量，消除了测试冗余

不足：测试用例设计较为困难

2.3 代码检查

• 代码检查主要是通过同行评审来发现缺陷
• 以评审会议为形式，通过多人对软件交付物进行检查；从而发现缺陷，或者获得改进优化的机会
• 同行评审往往需要大量投入时间和人力资源

背景：

• 开发早期无法提供可运行对象，导致无法执行测试
• 特定类型的缺陷，通过测试无法发现。例如：违反编码规范

同行评审的好处：

• 促使参与者在有监督压力下工作，提高责任心
• 有助于在开发早起发现需求和设计中的缺陷
• 有助于帮助程序员发现不足，提高工作质量

同行评审的核心：缺陷预防
目的：发现缺陷，改进开发过程

2.3.1 同行评审方法

• 审查(Inspection)
• 团队评审(Team Review)
• 走查(Walk Through)
• 结对编程(Pair Programming)
• 同行桌查(Peer Desk Check)
• 轮查(Pass Around)
• 特别检查(Ad hoc Review)

说明：

修复：评审会议结束后，作者是否需要对发现的缺陷进行修复
确认：对缺陷修复的结果是否需要指派专人进行确认，保证对缺陷进行了正确的修复，而且不会引入新的缺陷
持续：评审过程不限于一次会议过程，而是从产品模块开发开始一直持续到开发完成为止
可能：不确定是否需要举行会议，可在会议中由参与人员同时进行单独评审并汇总，也可由参与人员分别抽时间单独评审后由组织者对意见加以汇总

审查(Inspection)、团队评审(Team Review)、走查(Walk Through)特点：

结对编程(Pair Programming)、同行桌查(Peer Desk Check)、轮查(Pass Around)、特别检查(Ad hoc Review) 特点：

2.3.2 同行评审流程

同行评审的5种角色：

 

 

2.3.3 评审结果

2.4 静态结构分析 

通过引入不同形式的图表，帮助我们快速了解程序设计和结构，更好的理解源代码，有利于找到程序设计的缺陷和代码优化的方向。

2.4.1 函数调用关系图

通过树形方式展现被测系统中各函数之间的调用关系

1）函数调用层次：

• 层次太深，增大集成测试负担
• 对栈造成压力，容易导致溢出

应注意控制单个函数的复杂度：

• 控制函数的代码行
• 控制每行代码的最大字符数
• 控制函数的环复杂度等 

从函数调用层次，还可以找到高风险节点：

• 调用层次越深的节点，从该函数传递数据所涉及的接口数量越多，经过的路径越长，则该路径可以完全正确执行的概率变低，对应风险越大。
• 所以调用层次越深的函数，风险越高，应设置更高的测试优先级；但站在整个函数调用图的角度而言，这类函数所占比例应越低越好。
• 根节点是高风险节点，应设置更高的测试优先级

2）函数调用关系

函数调用关系：它可以用于标识高风险节点。
函数调用关系体现了接口的复杂程度，在调用图中，可以通过计算节点的入度和出度来评价：

• 入度或出度越大的节点，风险越大，测试优先级越高

入度：一个节点被其他上层节点所调用的数量，表现为调用图中从其他节点指向某个节点的有向线段的数量，该指标体现的是一个节点被其他节点调用情况。

出度：一个节点调用其他下层节点的数量，表现为从一个节点指向其他节点的有向线段的数量，该指标体现的是一个节点对其他节点调用情况。

3）查看是否存在递归调用

普通的函数调用在图中表现为判定结构，递归调用意味着对自身的调用，在图中形成指向自己的循环结构。

递归调用一般对内存的消耗较大，长时间运行很容易导致崩溃。因此应尽量考虑对函数结构的优化——将不必要的递归调用改为循环结构。

4）是否存在孤立节点

孤立的函数意味着不执行的场景或路径，代表编码或设计的不合理

2.4.2 函数的控制流图

由节点和边组成的有向图：

• 节点表示一条或多条语句
• 边表示节点之间的控制走向，即语句的执行

作用：

• 直观反映函数的内部逻辑结构
• 展示程序中明显的缺陷
• 揭示程序是否隐含缺陷

1）看孤立节点

2）看出口节点

理想的程序是单入口单出口的。多出口增加了程序的环复杂度

3）看环复杂度

通常环复杂度不应大于10，否则，我们认为程序结构过于复杂。
导致环复杂度过高的主要原因：

• 出口节点数量太多
• 判定节点树目太多
• 未采用结构化的程序设计等

4）是否存在非结构化设计

 

2.5 路径覆盖

路径测试：对程序路径的执行进行测试，保证路径执行是按照设计的预期进行的

2.5.1 基于等价路径的测试

基本思想：通过分析程序路径中的处理机制，找到合适的等价划分方法，将所有路径划分为有限个等价路径的集合。
方法关键：如何找到路径划分的规律，如何定义路径的有效等价类和无效等价类

2.5.2 基于独立路径的测试

若将向量空间视作向量组，则基就是向量组的极大线性无关组，维数就是向量组的秩。
该向量空间内的任意向量，都可以用这组向量基来线性表示。

要求：确保这些独立路径构成一组向量基，进而确保路径中任意一条非独立路径都可以用这组向量基来表示
方法关键：给定路径集合，如何确定该向量空间的维数，以及如何找到这组独立路径，以确保构成向量基。

2.5.3 区别

共同点：都是从原始的路径集合出发
区别：
1）基于等价路径：
思想：基于共性分析——>数据归类为不同子集。
过程：对全集划分子集——>子集中抽取个体。
2）基于独立路径：
思想：基于个性分析——>独立路径集合
过程：从全集抽取个体。

2.5.4 相关术语和概念

程序图：用来表示程序结构的一种有向图。由圆圈和有向线构成。

• 圆圈(节点)：执行语句
• 有向线段：程序直行方向

程序图是简化、压缩的流程图
作用：

• 体现程序基本结构
• 反应程序结构复杂度
• 不关心源代码细节

环复杂度(McCabe复杂性度量):是一种定量描述程序结构复杂度的度量模型。能够反映判定节点和循环的引入对程序结构以及执行路径数目带来的不利影响。

环复杂度的确定：

• 直观观察法：观察程序图将二维平面分割为封闭区域和开放区域的个数

4个封闭区域+一个外部开放区域 

• 公式计算法：利用程序图包含的边和顶点的数量来计算环复杂度

环复杂度V(G)=e-n+1，e表示边的数量，n表示节点的数量

前提条件：

• 程序图中没有孤立节点
• 程序图是强连通图。（双向联通）

• 判定节点法：利用程序图包含的边和顶点的数量来计算环复杂度

公式：V=P+1，P为判定节点的数量

前提条件：仅计算两分支的判定节点

2.5.5 测试用例设计

 

 

独立路径测试面临的问题及解决方案：

• 从源代码构建程序图，得到路径测试所需的地图
• 通过计算程序图的环复杂度，确定独立路径集合的规模
• 以包含判定节点最多的路径作为主路径，并以此为基础构建其他独立路径

2.5.6 不可行路径问题

不可行路径对测试带来的影响：

• 破坏了独立路径测试的完备性和无冗余性
• 增大了测试用例设计的难度

如何处理不可行路径：

• 结合源代码寻找独立路径
• 补充其他具有较高风险的路径进行测试

不可行路径产生原因：判定结构体之前存在关联。
表现为判定结构都具有相同的数据变量或输入条件之间的关联

2.5.7 场景爆炸问题