【白盒测试技术之-junit】

白盒测试

一、定义

白盒测试又称逻辑驱动测试或基于代码的测试。
白盒测试是一种测试用例设计方法，"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。

二、白盒测试方法

1.静态分析方法

1.1代码评审
1.2代码检查

2.动态分析方法

2.1基本路径覆盖
2.2循环覆盖
2.3逻辑覆盖

三、基本路径覆盖

路径测试就是设计足够多的测试用例，覆盖被测试对象中的所有可能路径。
圈复杂度是一种代码复杂度的衡量标准，圈复杂度大说明程序代码可能质量低且难于测试和维护。
圈复杂度V(G)，定义为V(G)=E-N+2，E是流图中边的数量，N是流图中结点的数量。

四、逻辑覆盖

逻辑覆盖按覆盖标准从低到高分别是语句覆盖、判定覆盖（分支覆盖）、条件覆盖、判定/条件覆盖、条件组合覆盖。

1. 语句覆盖

选择足够的测试用例，使得程序中每个语句至少都能被执行一次。

2. 判定覆盖（分支覆盖）

执行足够的测试用例，使得程序中的每一个分支至少都通过一次。

3. 条件覆盖

执行足够的测试用例，使程序中每个判断的每个条件的每个可能取值至少执行一次。

4. 判定/条件覆盖

执行足够的测试用例，使得判定中每个条件取到各种可能的值，并使每个判定取到各种可能的结果。

5. 条件组合覆盖

执行足够的例子，使得每个判定中条件的各种可能组合都至少出现一次。

举例说明：
示例代码如下：

流程图如下：

图中A、B、C、D、E分别表示路径；并且记第一个判断为P1，记第二个判断为P2；一共有4个条件，我们记为C1:a>1、C2:b=0、C3:a=5、C4:c>1

语句覆盖（使得程序中每个语句至少都能被执行一次）
测试数据 C1 C2 C3 C4 P1 P2 路径
a=5,b=0,c=7 T T A→C→E

判定覆盖（也叫分支覆盖，使得程序中的每一个分支至少都通过一次）
测试数据 C1 C2 C3 C4 P1 P2 路径
a=2,b=0,c=1 T F A→C→D
a=0,b=1,c=2 F T A→B→E

条件覆盖（使程序中每个判断的每个条件的每个可能取值至少执行一次）
测试数据 C1 C2 C3 C4 P1 P2 路径
a=5,b=0,c=1 T T T F A→C→E
a=1,b=3,c=6 F F F T A→B→E

判定-条件覆盖（也叫条件-分支覆盖，使得判定中每个条件取到各种可能的值，并使每个判定取到各种可能的结果）
测试数据 C1 C2 C3 C4 P1 P2 路径
a=2,b=0,c=1 T T F F T F A→C→D
a=5,b=1,c=2 F F T T F T A→B→E

条件组合覆盖（使得每个判定中条件的各种可能组合都至少出现一次）
测试数据 C1 C2 C3 C4 P1 P2 路径
a=5,b=0,c=1 T T T F A→C→E
a=5,b=1,c=7 T F T T A→B→E
a=0,b=0,c=2 F T F T A→B→E
a=-1,b=1,c=-1 F F F F A→B→D

路径覆盖（覆盖程序中所有可能的路径）
测试数据 C1 C2 C3 C4 P1 P2 路径
a=1,b=1,c=1 F F A→B→D
a=1,b=0,c=6 F T A→B→E
a=2,b=0,c=1 T F A→C→D
a=5,b=0,c=10 T T A→C→E

五、单元测试junit

1.Java开发环境：jdk1.8，工具idea，框架junit（junit-4.12.jar + hamcrest-core-1.3.jar）
2.代码演示。

六、单元测试的优势

1.优势

1.单元测试可以减少你后期找bug的次数和修复bug的时间
2.单元测试的代码量是很少的（除去测试数据的准备）
3.有单元测试的代码，在一定程度上是很有保障的代码，至少你不会有上线后才出现低级错误的尴尬
4.单元测试可以及早的暴露一些隐藏的问题，防止那种后期才发现问题后，大成本的去改代码的费神事了
5.单元测试，可以延长项目的生命期。因为一个项目的开发人员是经常变更的，我走了，你来了，在一个公司是很正常的。每个人都有自己的编程风格和习惯，有老手也有新手，没单元测试的话，大家就随便发挥了，只要结果出来了就好了，那么这个项目的代码将会越来越乱越来越烂。而单元测试可以在一定程度上约束这种事情的发生。

2.案例

在《单元测试的艺术》这本书提到一个案例：找了开发能力相近的两个团队，同时开发相近的需求。进行单测的团队在编码阶段时长增长了一倍，从7天到14天，但是，这个团队在集成测试阶段的表现非常顺畅，bug量小，定位bug迅速等。最终的效果，整体交付时间和缺陷数，均是单测团队最少。

3. TDD理念

“大军未动，粮草先行”，喜欢三国演义的朋友都比较熟悉。
“代码未动，测试先行”，喜欢极限编程的朋友都比较熟悉。

4.TDD测试驱动开发

1、简单的测试例子都不通过，整个系统不可能不出错。
2、各个组件的测试例子都通过了，那么整个系统的集成过程会变得很简单。
3、软件工程中绝大部分的工作量不在于编写业务逻辑的代码，而是在于BUG的修复、代码重构、功能测试、各个组件的集成。
测试驱动开发，是真正的敏捷开发，能够显著地提高开发效率，使得系统具备很强的健壮性。

七、友好建议

建议公司推行单元测试，实行‘无单测、不编码’原则，减少功能或集成测试阶段的bug量，减少后期维护产品的成本，较高质量的进行产品的发布。

（本文为本人在公司发布的原创文章，禁止转载）