🌈 个人主页：十二月的猫-CSDN博客
🔥 系列专栏：🏀软件测试与软件项目管理_十二月的猫的博客-CSDN博客💪🏻 十二月的寒冬阻挡不了春天的脚步，十二点的黑夜遮蔽不住黎明的曙光
目录
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 基本路径法示例
1. 由代码到流程图
2.由流程图到简化的控制流图
3.由控制流图找独立路径数量
4.根据独立路径数量确定独立路径集合
因此，我们提出了逻辑覆盖，一方面是为了减轻测试压力，另一方面也是补充路径测试并未考虑的逻辑问题。
逻辑覆盖就是找一个具体的逻辑支撑点，然后用这个逻辑支撑点去找更少的测试用例，尽可能拟合路径覆盖的效果。同时修补其在逻辑上（条件判断）的缺点。
3.2 逻辑覆盖
3.2.1 语句覆盖
设计若干测试用例，运行被测程序，使程序中的每个可执行语句至少被执行一次。
3.2.2 判定覆盖
上面的语句覆盖存在问题，就算每一个语句都执行到了，我们也无法保证判断中具体的判断内容是正确的。如果判断条件错误了，但是判断结果是一样的，语句同样能够被覆盖：
因此引入判断覆盖！
判定覆盖：设计若干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足。一个判定代表着程序的一个分支，所以判定覆盖也被称为分支覆盖。
3.2.3 条件覆盖
判定覆盖就一定都完全了吗？显然不是的，如果说每一个分支都走到了，但是本质上判断的条件有一点细微的变化，但由于这个变化并没有影响判断结果（如a or b，我用a就可以走到需要分支，但是b发生变化了，此时对结果判定覆盖和语句覆盖都不会造成影响，因为本质在判断中是a起作用）。因此我们还需要具体对每一个条件就行覆盖。
条件覆盖的基本思想是设计若干测试用例，执行被测程序以后，要使每个判断中每个条件的可能取值至少满足一次。
关键点：写出所有条件的所有可能性取值
一个例子：
但是这个条件覆盖到了，所有分支又不一定覆盖到了。因此又有下面这个方法——判定条件覆盖。
3.2.4 判定条件覆盖
判定-条件覆盖是判定和条件覆盖设计方法的交集，即设计足够的测试用例使得判断条件中的所有条件可能取值至少执行一次，同时，所有判断的可能结果至少执行一次。
3.2.5 条件组合覆盖（强调条件组合都要满足）
条件组合覆盖的基本思想是设计足够的测试用例，使得判断中每个条件的所有可能至少出现一次，并且每个判断本身的判定结果也至少出现一次。
它与条件覆盖的差别是它不是简单地要求每个条件都出现“真”与“假”两种结果，而是要求让这些结果的所有可能组合都至少出现一次。
3.2.6 路径覆盖与组合覆盖的区别与联系
路径覆盖和组合覆盖是两个完全不同的思路，测试的偏向也不一样。路径覆盖会让所有路径都走过，组合覆盖（前面提到的所有逻辑覆盖方法）都只能尽可能拟合路径覆盖的效果，但是他们也增加了对逻辑的考虑：
测试完全性排行：
语句覆盖<条件覆盖<判定覆盖<条件-判定覆盖<组合覆盖<路径覆盖
4. 总结
本篇的内容就两个：基于逻辑覆盖的测试方法、基于路径覆盖的测试方法
逻辑覆盖的测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖
路径覆盖的测试方法：完全路径覆盖、基本路径覆盖
如果想持续关注【软件测试】和【软件项目管理】系列文章，可以订阅：
如果想学习计算机其他方面的核心知识（都是猫猫的优质好文哦），可以订阅：
- 计算机网络_十二月的猫的博客-CSDN博客
- 软件工程与面向对象_十二月的猫的博客-CSDN博客、
- 操作系统与数据库_十二月的猫的博客-CSDN博客
- 编译原理_十二月的猫的博客-CSDN博客
- 算法启示录_十二月的猫的博客-CSDN博客
如果觉得本文对你有帮助，友友们可以点个赞，收个藏呀~
