【白盒测试技术之-junit】

这篇具有很好参考价值的文章主要介绍了【白盒测试技术之-junit】。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

白盒测试

一、定义

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

二、白盒测试方法

1.静态分析方法

1.1代码评审
1.2代码检查

2.动态分析方法

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

三、基本路径覆盖

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

四、逻辑覆盖

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

1. 语句覆盖

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

2. 判定覆盖(分支覆盖)

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

3. 条件覆盖

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

4. 判定/条件覆盖

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

5. 条件组合覆盖

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

举例说明:
示例代码如下:
【白盒测试技术之-junit】

流程图如下:
【白盒测试技术之-junit】

图中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迅速等。最终的效果,整体交付时间和缺陷数,均是单测团队最少。
【白盒测试技术之-junit】

3. TDD理念

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

4.TDD测试驱动开发

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

七、友好建议

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

(本文为本人在公司发布的原创文章,禁止转载)文章来源地址https://www.toymoban.com/news/detail-484062.html

到了这里,关于【白盒测试技术之-junit】的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包