如何引入代码覆盖率度量提高测试质量
我们面临的困境1) 开发编写的单元测试代码可信度
2) 功能测试或者自动化测试效果可信度
为了提高测试过程的质量,是一个复杂系统过程。国外好些年前就引入代码覆盖率工具,比如
EMMA/Clover。
呵呵,据了解ebay中国的开发采用EclEmma。
经过初步评估,针对java语言的EMMA 和针对 linux+ c/c++ +gcc的gcov/lcov都只能做到语句覆盖、函
数覆盖、类覆盖。对于路径覆盖、条件覆盖等无法做。要做到更加精细,可以考虑结合Jester。
代码覆盖率工具最让人震撼的是,无须单元测试代码,可以清楚看到执行过/未执行过的代码行,以及由
宏观到微观的度量结果。另外引入代码覆盖率工具,无须修改代码,成本极低。
这个结果对于开发而言,可以增加自己负责的模块的单元测试代码,或者去除死代码。
对于测试而言,可以增加测试用例提高覆盖率,提高测试结果的信心度。
尽管代码覆盖率工具有这样或者那样的不足,也极难做到100%覆盖,但综合权衡,引入工具还是有积极
的意义。
推广代码覆盖率的规划:
1) 选取一个小型WEB应用代码覆盖工具,结果供测试工程师,分析代码覆盖率效益
2) 大型项目应用代码覆盖工具
3) 在研发部门推广EclEmma插件 和gcov/lcov
4) 经过一段时间实践,在开发提交代码给测试时,要求一起提交代码覆盖率源文件。
难点:
1) 测试工程师面对未覆盖的代码行,要有阅读代码能力呼应到业务操作,以有针对性增加测试用例
1) 加入代码覆盖率结果,意味对上游输出把握更加严格,要求研发部门经理和开发的意识转变以及实质
性支持
欢迎这方面有实践的朋友多提建议,谢谢 难点1)
需要增加测试和开发的合作及沟通吧。 1) 测试工程师面对未覆盖的代码行,要有阅读代码能力呼应到业务操作,以有针对性增加测试用例
这条是增加一个单元测试用例,还是增加一个一般的黑盒功能测试用例? 回photon :
一方面要求测试工程师提升能力;另外一方面增加开发、测试的沟通成本
回 maguschen:
目前单元测试由开发写,故测试增加功能测试用例 哦,谢谢回复,明白!
你的博客写的真好,以后我多来学习,呵呵~~ 据了解,即使华为,也仅局限于开发使用代码覆盖率工具。
呵呵,但我自己相信对于一个复杂业务系统、没有详细设计文档的情况下,提高测试透明度、测试覆盖率还是有积极意义,并且其成本不是很高昂 据ebay的朋友介绍。如果项目测试中实施,代码覆盖率可能一直在70%~80%左右,根据业界的一些数据显示,这个覆盖率已经非常不错了 简单表达了我的一些看法,请参考
http://www.51testing.com/?10851/action_viewspace_itemid_90803.html
页:
[1]