既然选择远方,便只顾风雨兼程……

测试覆盖率之二——测试覆盖率有什么用?

上一篇 / 下一篇  2008-12-09 22:35:43 / 个人分类:测试覆盖率系列

     在上一篇文章里面我们介绍了测试覆盖率的分类,举例揭示了需求覆盖率,语句覆盖率,分支覆盖率很条件覆盖率这些问题,在这篇文章里面,则主要介绍为什么要千方百计来找“测试覆盖率”。(关于上一篇文章,参见测试覆盖率之一——测试覆盖率分类)
KD8fP5@ QRv8Hk/x+t0    关于测试覆盖率讲的最多的地方应该实在测试停止标准里面。在测试停止标准里面经常出现这样的语句“测试覆盖率达到或超过95%”之类的概念。其实,如果你看了我前一篇文章中提到的测试覆盖率分类的话,就知道这是一个不准确的描述。关于更准确的描述,我认为应该是“性能测试需求覆盖率达到100%,功能需求测试覆盖率达到100%,语句覆盖率达到85%”这样的句子。“测试覆盖率”本来就包含了很多子部分,所以提测试覆盖率是不明智的一种做法。而我所说的语句覆盖率85%相对于性能测试需求覆盖率这个数据来讲似乎更难获得准确数值,不过现在已经有了很多工具用于测试“语句覆盖率”,而不用我们自己去计算已执行的测试用例覆盖到了数万或者更多代码中百分之多少,也有一些工具可以帮助我们得到代码覆盖率中“分支覆盖率”等其它数据。关于覆盖率检测工具,我将在本系列的后续文章中给予介绍。51Testing软件测试网Ky&`J5B"O1N^c
    测试覆盖率是测试结束标准中的一部分,这显然不是我们今天讨论的重点——测试覆盖率有什么用?直观上讲,我们可以这样理解:
.JA,e!vV L(j0    -> 性能测试覆盖率如果没达到100%,表示我们有些性能测试点没有覆盖到,这在一个对于性能有所要求系统显然是不可取的,这表示我们应该增加用例来覆盖到所需要的性能测试点。51Testing软件测试网!gZVXH
    -> 重要模块的语句覆盖率和条件覆盖率很低,表示我们测试用例过少,我们应当增加用例;如果我们已经写了很多用例(相对于代码行数来讲),但是这两项数据还是很低,那我们得检查一下我们的用例了,是否有重复的用例?是否应该重新设计用例结构?
x9Sg/On CY0    对于测试覆盖率,我们有这样一个简单的算式,如果A模块的条件覆盖率为80%,B模块也为80%,C模块也为80%,那么我们的总覆盖率则是51.2%,而不是我们想当然的80%。至于为什么这样,我就不解释了。因此在我们审查覆盖率报告时候,我们关注的是覆盖率低的模块,我们要检查为什么低,我们要思考怎么提高,对于覆盖率低的地方,是不是有一个等价类被我们忽略了?
~8fRt;|S{}_0    测试覆盖率的意义在瀑布式的开发模式里面可能显得没那么重要,但是如果在螺旋式开发模式中,如果我们没有控制好我们上一个迭代中的测试覆盖率,当一个版本一个版本累加下来后,你就很难确定我们哪些模块在开发过程中没有给予足够的测试;在近些年兴起的持续集成浪潮中,由于要求短迭代(有人建议3-5天一个迭代),如果没有很好的测试覆盖率保证,很难在这么快的代码变迁中保证测试的质量。在持续集成工作中,代码提交频繁,我们可以通过测试覆盖率来了快速对应新写的,没有对应测试的代码。
u;fL,yG{0    总之,测试覆盖率可以提供给我们两个方面的信息:测试覆盖率低的模块 和 重要模块的测试覆盖率。这些数据可以帮助我们快速定位需要更多测试的模块,可以帮助我们了解重要模块的测试情况,以此来衡量我们测试用例的质量乃至测试的质量。51Testing软件测试网A,l%Uz%vi(p$uc%U
    个人观点,仅供参考~~(如有问题请联系unique.wuchaodong@hotmail.com)在下一篇文章(测试覆盖率之三——测试覆盖率100%相关的问题)中,我将介绍关于测试覆盖率应该达到的数据,是不是需要100%呢?51Testing软件测试网-n]SH:a+?9r/^8h

w5z-vQe5z K0

TAG: 测试覆盖率 测试职业历程 测试覆盖率系列

一步一脚印 引用 删除 hjjlearning   /   2008-12-16 17:08:09
看了后面系列文章,第三篇写得不错,赞一个
一步一脚印 引用 删除 hjjlearning   /   2008-12-16 17:07:00
LZ回答很不错,谢了。以前我也和LZ说的那样做,但是有几点问题,1、有时候开发人员也不太确定需求。2、集中力量进行检查,效果很不好,不同的人理解不一样,有时候会议会成为扯皮状态,很多要PM确定,但PM也不一定全部知道。3、会议一两次还好,多了就,,,
现在我真是对测试需求覆盖率不奢望了,这块很难走通,所以想直接从代码入手,最起码可以保证代码正确,呵呵,谢谢LZ哈,加你为好友了
Aaron的测试生活小说 引用 删除 UniqueStudioWCD   /   2008-12-12 22:07:16
很抱歉没有及时回复你,因为最近出差的缘故。关于测试需求覆盖率,确实是一个很难确定的数据,这在我的本系列文章中的第三篇有提到过。在需求定义不完善的时候,更多的需要我们自己去找功能需求,在这种情况下,要达到需求覆盖率比较高,比较可行的办法是由测试人员按照功能模块将测试组已考虑到的功能点列出来,整理成文档并发送给PM以及开发人员,测试人员,集中整个组的力量来检查需求的覆盖。
对于单个开发人员,由于代码是他们写的,所以他们最清楚自己模块的功能情况,因此他(她)在检查刚才提到的列表时候,只需要了解自己所属模块相关内容即可。
上面提到的办法只是一种临时方法,在实践中这种方法对于流程不规范的组来讲还是有用的。
希望能对你的问题有所帮助~~
一步一脚印 引用 删除 hjjlearning   /   2008-12-12 09:20:55
谢谢LZ的回答,那请问下如果保证用户需求的粒度,通过测试需求文档?一般情况下产品需求都不是很完善,而且测试需求并不一定能分解出所有的需求,包括显性,隐性的,这样的话,测试用例根本就不太可能精确计算出覆盖了多少需求?
Aaron的测试生活小说 引用 删除 UniqueStudioWCD   /   2008-12-10 10:15:00
代码覆盖率一般通过工具获得。代码覆盖率是很难通过手工的方式来获取的,我们可以想一下手工检查哪些用例覆盖哪些语句这种“壮观的”景象。
     需求覆盖率则需要通过一些算式得到。一般情况下,需求覆盖率更直观的讲是考察我们的测试用例是否覆盖到了所有的用户需求,包括功能测试用例和性能测试用例。
一步一脚印 引用 删除 hjjlearning   /   2008-12-10 09:34:57
请LZ指教下,如何计算覆盖率这块的东西?白盒与黑盒计算的方法是否不一样,,
 

评分:0

我来说两句

Open Toolbar