【软件测试】第三章·软件测试基本方法（逻辑覆盖、路径覆盖）

🌈个人主页： 十二月的猫-CSDN博客

🔥 **系列专栏：**🏀软件测试与软件项目管理_十二月的猫的博客-CSDN博客

💪🏻 十二月的寒冬阻挡不了春天的脚步，十二点的黑夜遮蔽不住黎明的曙光

[1. 前言](#1. 前言)

[2. 回顾](#2. 回顾)

[3. 软件测试的基本方法](#3. 软件测试的基本方法)

[3.1 路径覆盖](#3.1 路径覆盖)

[3.1.1 基本路径覆盖](#3.1.1 基本路径覆盖)

[3.1.1.1 基本路径法示例](#3.1.1.1 基本路径法示例)

[3.2 逻辑覆盖](#3.2 逻辑覆盖)

[3.2.1 语句覆盖](#3.2.1 语句覆盖)

[3.2.2 判定覆盖](#3.2.2 判定覆盖)

[3.2.3 条件覆盖](#3.2.3 条件覆盖)

[3.2.4 判定条件覆盖](#3.2.4 判定条件覆盖)

[3.2.5 条件组合覆盖（强调条件组合都要满足）](#3.2.5 条件组合覆盖（强调条件组合都要满足）)

[3.2.6 路径覆盖与组合覆盖的区别与联系](#3.2.6 路径覆盖与组合覆盖的区别与联系)

[4. 总结](#4. 总结)

1. 前言

考试前猫猫又开始更新考试科目了（也就是开始学了bushi）。本学期更新的科目有：

软件测试
软件项目管理
爬虫和Web数据管理
数据可视化

本系列【软件测试】将针对软件测试的基础知识进行拆分讲解，既是对自己学习的一次巩固也想为后面学习的猫友们提供一些帮助。如果大家有空可以点个免费的赞和收藏呀~~你的鼓励真的对猫猫很重要。

2. 回顾

**软件缺陷是软件质量的对立面：**软件质量有好几个因素包括功能、可靠、易用、可移植、可维护等。软件缺陷就是其反义词。

软件缺陷是什么： 从产品内部看，软件缺陷是软件产品开发或维护 过程中所存在的错误、毛病 等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能 的失效或违背。

**软件测试的分类：**层次/对象（单元测试、集成测试、系统测试、验收测试）、类型（功能测试、安全性测试、可靠性测试等）、方法（静态测试和动态测试、黑盒测试和白盒测试等）

**静态测试和动态测试：**看是否运行可执行软件（静态仅仅看需求、设计文档和代码）

**主动测试和被动测试：**主动（测试人员主动操作被测对象，获得被测对象的响应情况）、被动（测试人员被动地监视在实际环境中运行的系统，从而获得系统数据）

**黑盒测试和白盒测试：**黑盒（不看具体代码，仅仅是输入数据看其输出数据是否正确）、白盒（允许看实际的代码）

**软件测试的流程：**测试需求分析、测试计划与设计、执行、结果评估

**基于需求的测试方法：**软件肯定是要满足用户的需求，因此基于需求出发去做软件测试肯定是最重要且必要的方法。具体方法有：等价类划分+边界值分析、判定表、因果图、Pairwise法、正交法。

3. 软件测试的基本方法

在上一篇文章中我们学习了基于需求的测试方法（黑盒测试），这是软件测试基本方法中很重要的一部分。这一篇文章，我们将来学其中很重要的另一部分------白盒测试的部分。今天的学习将分为两个部分展开：1、路径覆盖；2、逻辑覆盖

3.1 路径覆盖

在学习逻辑覆盖之前，我们先来看看另一个覆盖------路径覆盖。路径覆盖非常简单，就是把程序完整的所有可能路径全部都执行一边。画出程序的运行图，然后把所有路径都执行一遍。**基本思想：**设计测试用例，来覆盖程序中的所有可能执行的路径。

覆盖路径	覆盖组合
1-2-4	1,5
1-2-5	1,8
1-3-4	4,7
1-3-5	4,8

优点：这种测试方法可以对程序进行彻底的测试。
缺点：需要设计大量的，复杂的测试用例，使得工作量呈指数增长，不见得能把所有的条件组合（逻辑）都覆盖

3.1.1 基本路径覆盖

上图中包含的不同执行路径数达5的20次方条，假定对每一条路径进行测试需要1毫秒，一年工作365 × 24小时，要想把所有路径测试完，需3170年。由于完全的路径覆盖是无法实现的，为解决这一难题只得把覆盖的路径数压缩到一定限度内。

因此，我们提出了基本路径覆盖！！

基本路径覆盖的方法：

根据代码写出流程图
根据流程图写出控制流图
根据控制流图计算独立路径数量（区域数量）
根据独立路径数量找独立路径

3.1.1.1 基本路径法示例

由代码到流程图

2.由流程图到简化的控制流图

3.由控制流图找独立路径数量

4.根据独立路径数量确定独立路径集合

因此，我们提出了逻辑覆盖，一方面是为了减轻测试压力，另一方面也是补充路径测试并未考虑的逻辑问题。

逻辑覆盖就是找一个具体的逻辑支撑点，然后用这个逻辑支撑点去找更少的测试用例，尽可能拟合路径覆盖的效果。同时修补其在逻辑上（条件判断）的缺点。

3.2 逻辑覆盖

3.2.1 语句覆盖

设计若干测试用例，运行被测程序，使程序中的每个可执行语句至少被执行一次。

3.2.2 判定覆盖

上面的语句覆盖存在问题，就算每一个语句都执行到了，我们也无法保证判断中具体的判断内容是正确的。如果判断条件错误了，但是判断结果是一样的，语句同样能够被覆盖：

因此引入判断覆盖！

**判定覆盖：**设计若干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足。一个判定代表着程序的一个分支，所以判定覆盖也被称为分支覆盖。

3.2.3 条件覆盖

判定覆盖就一定都完全了吗？显然不是的，如果说每一个分支都走到了，但是本质上判断的条件有一点细微的变化，但由于这个变化并没有影响判断结果（如a or b，我用a就可以走到需要分支，但是b发生变化了，此时对结果判定覆盖和语句覆盖都不会造成影响，因为本质在判断中是a起作用）。因此我们还需要具体对每一个条件就行覆盖。

条件覆盖 的基本思想是设计若干测试用例，执行被测程序以后，要使每个判断中每个条件的可能取值至少满足一次。