联系我：新浪微博@架构师Jack 或 dongjietest#163.com联系.(#换为@)

设计路径测试覆盖率与代码测试覆盖率

上一篇 / 下一篇  2011-05-29 18:24:23 / 个人分类：测试技术

查看( 2970 ) / 评论( 15 ) / 评分( 15 / 0 )
   100％代码测试覆盖率就代表了我们的软件100％测试完毕了吗？我们就能对测试放心了吗？代码测试覆盖率到底给了我们什么确定性的结论呢？ 节选自微软技术丛书《完美软件：缺陷预防最佳实践》软件测量与度量一章：“较高的代码覆盖率与较高质量的代码不存在相关性，较高的代码覆盖率反映了测试宽度，不是测试深度，Pareto原理客户关心的缺陷80％可能存在于20％的代码。”
     该书微软的作者提出了这样的一种观点：测试宽度和测试深度。我对测试宽度的理解是测试宽度代表实现软件的函数有多少比例被测试调用验证过，如果还有部分实现的函数从未被测试调用验证过，难免在这些函数中会有遗留的缺陷，这是我们追求单元测试覆盖率100％的原始动力。
       哪什么是测试深度呢？ 先举一个例子：某模块有A(),B(),C() ,D(),E()5个函数。正常的处理流程是A并行依赖B和C, B并行依赖D和E,C依赖E; 如果在实际业务中E()函数的调用失败了（原因有：CPU忙OS调用E超时或E依赖的某个资源不足），那么对原来的函数调用序列的影响是什么呢？则是我们传统的函数接口测试或函数单元测试中难反应的场景，这类函数间的多层次调用序列和相互间的调用交互关系这就是我们的测试深度。传统模式下我们一般在集成黑盒测试的条件下发现这类深层次的测试深度问题。
      这也是为什么一直以来单元测试代码做到了100％覆盖了，还是能在系统测试环节发现不少埋藏深难通过人脑静态检视而发现的bug。既然代码测试覆盖率不能代表测试对需求实现覆盖的完整性（包含测试宽度和测试深度），那么我们如何度量测试对需求实现覆盖的完整性呢？
      在此我提出了一个设计路径测试覆盖率的概念，鉴于blog表达机制的约束，我就先简单文字描写一下什么是设计路径测试覆盖率—— 任何原始需求的实现都有一个内部状态迁移图，这个迁移图中包含了所有软件运行的路径（成功路径和失效路径）。我们针对状态图的所有路径分段用不同的测试用例来覆盖，并以此目标来设计我们的用例（可以使用单元测试工具手段和可测试性手段来实现），这样我们的测试用例就一定是覆盖了所有的需求实现成功路径和失效路径，并且我们没有多余用例。
      当然以上做法的不足是：由于需要测试设计人员对模块实现的设计逻辑要100％清晰理解，耗时会比较多。因此可以只针对20％对客户所关注的高风险模块进行设计路径测试覆盖率的测试设计活动。

"I/t2vL%|0
最后总结2个建议：
      1、代码覆盖率可以作为需求实现测试完整度的宽度参考，但不能作为决定测试投入结束的标准。
     2、如果测试组织内测试人力和时间不够（大多数情况下），则参考Pareto原理在20％的高风险模块进行设计路径测试覆盖代替进行函数级的代码测试覆盖，用100％的设计路径覆盖用例代替代码测试覆盖率更具真正的测试深度完整性。
    
    

收藏 举报

TAG:

QTP 学习者 引用 删除 ratankoy   /   2012-03-22 13:53:01
当你投入的成本远远大于bug产出率时，这个时候你就要思考是否还需要进行覆盖率测试了
lydiaylh的个人空间 引用 删除 lydiaylh   /   2012-03-21 13:21:31
学习中
引用 删除 melanieQ   /   2011-10-29 21:15:36
学习了~
scott1012的个人空间 引用 删除 scott1012   /   2011-10-29 09:10:39
liujintao00的个人空间 引用 删除 liujintao00   /   2011-09-27 15:03:55
我在进行黑盒和灰盒测试设计时，也经常采用类似楼主说设计路径测试覆盖率的设计思路。通过这种方式能够快速的验证程序是不是做了该做的事情。通常在测试后台程序时会使用这种方法。
yinzedong的个人空间 引用 删除 yinzedong   /   2011-09-26 18:44:44
原帖由mexia于2011-05-29 21:14:23发表

黑盒与白盒结合的精髓。
xin_晴的个人空间 引用 删除 xin_晴   /   2011-06-08 12:00:32
您好，我是51Testing软件测试网的编辑，您的本篇博文被推荐至51Testing软件测试网首页发表：http://www.51testing.com/html/75/n-237775.html
感谢您关注并支持51Testing博客，期待您更多的优秀原创博文。
happy_wendi的个人空间 引用 删除 happy_wendi   /   2011-06-01 13:02:37
是的，代码覆盖率100%并不表示测试就100%了，因为还有各个代码块调用时序的问题，这个就要用楼主说的方法了。高手 啊！
dawei1208的个人空间 引用 删除 dawei1208   /   2011-05-31 15:48:40
还没大看懂,记号.
是不是即使路径覆盖了,也很难找出第三段描述的系统级的问题.况且路径覆盖的投入太大了.
但针对20%部分做路径覆盖估计可取
dawei1208的个人空间 引用 删除 dawei1208   /   2011-05-31 15:45:27
评 5 分
狂想的世界的测试之路 引用 删除 狂想的世界   /   2011-05-31 15:40:01
评 5 分
狂想的世界的测试之路 引用 删除 狂想的世界   /   2011-05-31 15:39:47
您好，我想问下，关于代码覆盖率的问题：之前也有听说过，说如果真的代码覆盖率达到100%也不是一个很好的现象，因为这样可能说明我们的程序没有容错方面的代码。这个问题分两个方面：1、以上观点是否正确？2、如果真的有容错代码，测试人员是否需要对其进行测试？
架构师Jack的个人空间 引用 删除 架构师Jack   /   2011-05-29 22:47:57
用黑盒用例关注 设计路径，而不用关心接口的实现形式。
测试人生 引用 删除 mexia   /   2011-05-29 21:14:23
评 5 分
测试人生 引用 删除 mexia   /   2011-05-29 21:13:22
,jack老师你好，看到你这篇文章，我想起了我测试工作流的路径法，同你这个关键路径法差不多，就是把所有的路径都走一边。但是当有接口的时候会更加复杂一点。
 

评分：0

我来说两句

Open Toolbar