微信号:grzlwx

介绍:光荣之路官方资讯

用例多,工作量大,bug却少,测试中你会缺陷预估吗?

2015-12-19 22:59 光荣之路

吴老的《selenium webdriver 实战宝典》出版了!


缺陷
你会预估吗?
少,用例多,工作量大

目前存在的问题:

1、 用例设计完成后测试人员基本按照用例执行,测试人员主观发挥空间比较少,不利于测试人员的测试分析能力的提高

2、 目前基本上在集成测试阶段整个用例导入后90%以上的用例都能够正常pass掉,实际这部分的用例是能够减少测试的。执行发现不了bug的用例(特别是在测试人员在执行该用例的时候就能够分析到该用例不能够发现bug)基本上做的就是无用功,也浪费了我们很多的测试时间,对应的增加了整个版本的测试周期

缺陷预估方法:

在集成测试开始前(全面测试),首先分析该模块可能存在缺陷的地方(可以按照研发的千行代码bug率来进行分析),然后根据分析导入能够测试到这些缺陷的用例(如果分析可能有5个地方存在10个缺陷),那么第一天只导入大概20个用例左右(差不多一天就能够测试完成),这样如果我们分析的比较全面的话,第1天应该就能够发现该模块所有的bug(当然,现在可能还没有达到这样的程度,但是70-80%以上应该还是有可能的,后面通过我们分析技术的不断完善,基本上是能够达到90%以上的),然后我们再根据自己的测试结果进行进一步的分析,然后再导入部分可能存在风险的用例(大概20个也差不多够了,通过这20个用例发现剩余20%左右的bug),这样我们实际上该模块就测试了40个用例,比起以前测试100个用例能够节省60%的工作量,也能够让bug在前期就暴露出来(以前按照顺序执行用例发现bug的效率确实是比较低的)!而且随着测试质量分析技术越来越完善,我们实际上需要话费的测试时间就更少了!

下面,提供一些分析的方法和过程

1、 评估该模块的代码行数,结合千行bug率来评估下该模块的的bug数(这个要走悲观策略,比平均值要稍微高点)

2、 子模块划分法,根据该模块的逻辑划分出具体的子模块(具体方法可以查看测试分析技术1),然后将每个子模块的bug数分析出来(可以跟研发和该模块专家一起讨论)

3、分析出可能存在bug的逻辑(根据该逻辑的复杂程度和自己的经验),然后导入能够测试到这些逻辑的用例(可能发现有些逻辑没有用例覆盖到,需要补充测试用例),可以重点考虑研发的一些异常情况处理(这部分研发实际上已经有很大改进了)

4、分析每个逻辑是否会和其他哪些模块关联(可以参考模块的关联表),由于研发一般只关注自己的模块,这块是比较容易出现问题的地方,然后也针对性的导入用例和预分析出bug

5、内部头脑风暴,可以召集2-3个人一起分析下是否还有其他存在其他的风险,或者这个时候就可以引入ET测试技术,然后再导入对应的用例安排测试

6、经过上面方式后看下发现的bug情况,是否和预期差不多,然后再根据发现的bug做一些补充和发散测试,这点可以作为上面提到的第2部分补充测试方案(也可以结合起来),如果分析技术比较全面的话应该是能够达到目的的

(作者:pengyongbo 来源:http://www.51testing.com/html/25/181625-851815.html)

公益传播测试知识、技能与正能量!感谢作者!
分享测试生活,思考测试人生!欢迎投稿!
文章图片来自网络,如有侵权请见谅,请联系我们妥善处理。
735821166@qq.com


光荣之路
软件测试培训


官网:www.gloryroad.cn

微信公众号:gloryroadtrain

性能测试QQ群:415987441
测试招聘QQ群: 203715128
自动化3群QQ: 371211499

Python群:457561756


 
光荣之路 更多文章 今天晚上的 linux 公开课- Awk 编程 7月28日(今天)晚上的 linux 公开课- shell编程 8月4日(今天)晚上的 linux 公开课- shell编程 9月1日(本周一)晚8点半,光荣之路Web自动化系列基础课—javascript第二讲 推荐本好书《与机器赛跑》
猜您喜欢 Markdown公式指导手册,能用到的建议收藏。 只做一件事,并且把它做好! Spring基础知识汇总 Java开发必看 比尔·盖茨和乔布斯他们的编程水平如何? Android Studio 2.0,先睹为快吧