代码覆盖率 (Code Coverage)从简到繁 (一) (转)
此文章转载于其他园主,纯粹为了自我学习。
代码覆盖率(Code Coverage)是反映测试用例对被测软件覆盖程度的重要指标,也是衡量测试工作进展情况的重要指标。它也是对测试工作进行量化的重要指标之一,测试工作往往不如开发那样激动人心,一个重要原因之一就是测试难于量化,而代码覆盖率恰恰是解决着一问题的重要指标。
根据其覆盖内容的不同,又可以细分为:语句覆盖、判定覆盖、条件覆盖、路径覆盖以及循环覆盖等等,这里有一篇很好的博客《代码覆盖率浅谈》介绍了各种不同覆盖率的定义。有的理解起来还是蛮拗口的,但其实不难,用到了再看就成!在所有这些覆盖中语句覆盖(Statement coverage)是最简单的,但也是最常用的、最实际有效的覆盖率,Visual Studio采用的是语句覆盖中的基本块覆盖(Basic block coverage)。
对于敏捷开发团队而言,代码覆盖率是每个Sprint要完成的硬性质量标准(Exit Criteria)之一,覆盖率高低根据项目的不同而不同:75%,80%甚至100%都是可能的。代码覆盖率是一个白盒概念,应为毕竟它最后要落实到代码。既然代码覆盖率如此重要,那么什么时候该用它?该如何用它?
有人认为代码覆盖率重要,所以从项目的一开始就要进行代码覆盖率的检查和分析,即 获取覆盖率 –> 发现未覆盖的代码 –> 添加新测试用例。这样的使用方式,我把它命名为“代码覆盖率驱动的测试(CCDT,Code Coverage Driven Test)”。CCDT看起来很美,理论上无懈可击,但实际操作则完全不是那么回事儿。先不说这种方式是否正确,单就由此引入的开销来说,就够项目组喝一壶的,呵呵!之所这样说,是因为CCDT需要经历:获取覆盖率、分析覆盖率和添加测试用例这三步,每一步都存在着很多潜在“副产品”开销,尤其是前两步。要获取覆盖率,需要执行所有的测试用例,而你知道现在业界70%的测试仍然是手动的,仅为了覆盖率就频繁的执行测试用例,显然是不现实的;频繁分析覆盖率结果也是一件耗时的工作,无论开发人员还是测试人员做都是如此,尤其是对于采用敏捷开发方法的团队,短迭代不允许引入如此劳神的工作内容。胡凯在他的博客中称这种唯覆盖率论症状为“测试覆盖率强迫症”,其中有一句描述很精彩:
我认为对于测试团队而言,测试的过程应该是用户场景覆盖驱动的测试(USCDT,User Scenario Coverage Driven Test) ,即测试人员应该从用户真实使用场景出发,思考要测试的内容和设计测试用例。代码覆盖率是对USCDT的必要补充,以发现其中未覆盖的场景(Test Hole)。代码覆盖应该是在项目/迭代的中后期引入,不用很频繁,点到为止,例如对一个3-4周的迭代,3次的覆盖率检查就已经足够了。当然,如果你的自动化测试比例比较高,采用持续集成(Continuous Integration)的方式,例如:Visual Studio 2010中持续集成的构建功能,每次都能自动的进行代码覆盖率的统计,则可以更早,更频繁进行代码覆盖率,但前提一定是这不会带来过多的开销。
说了这么多,下面来点儿实际的吧,看看Visual Studio 2010中如何获取代码覆盖率数据!在Visual Studio的集成开发环境中获自动化测试用例的码覆盖率数据是最简单的(采用命令行方式则稍复杂一些,但它还可以用来获取手动测试用例的覆盖数据),只需要下面三步:
随着编程语言和开发工具的现代化和傻瓜化,现在获取和分析代码覆盖率工作越来越简单了,但人们对代码覆盖数据的使用却仍然停留在比较原始的阶段。其中还有很多值得去深入发掘的好东东,用于帮助测试团队优化测试过程和测试用例的设计!
参考资料
- Code Coverage Instrumentation
- How to: Configure Code Coverage Using Test Settings for Automated Tests
- Wikipedia's Code Coverage topic
- Team System “off-road” code coverage analysis and reporting experience
步骤三 :查看代码覆盖率结果
步骤二 :执行自动化测试用例
步骤一 :在Test Settings配置中选择Code Coverage