bullsete在vs下的使用

BullseyeCoverage简介

Bullseye Coverage 是Bullseye 公司提供的一款C/C++代码覆盖率测试工具。

相对于Rational 的Pure Coverage，Bullseye Coverage 支持的C/C++的编译器更多。除了支持各种Unix 下的编译器之外，在Windows 下支持VC、Borland C++、Gnu C++、Inter C++。

提供的代码覆盖率是分支覆盖率而不是一般代码覆盖率，我个人认为分支覆盖率比代码覆盖率更好。

我这里有破解版本和key，如果有人需要，欢迎向我索取。

3.BullseyeCoverage的安装

因为有安装程序，所以安装整体来说比较简单。

不过，有几个地方还是要注意，相关的截图如下。

1）输入key，在license key输入框。

2）设置cov文件路径，可以设置到一个你比较容易记住的路径下。

这一步容易被忽略，导致最后都不知道cov文件在哪里。

cov文件的作用后面会讲到。

3）编译器选择，缺省会选择vc，但是建议把其他的几个主流的c++编译器也选上，这样可以识别更多类型的代码。

4.BullseyeCoverage的使用

4.1.在代码编译时如何使用？

BullseyeCoverage安装好后，会在vc编译器中以插件的方式出现。

在vc6的tools菜单中高亮显示部分，可以设置是否启用BullseyeCoverage。

如果启用，则会在编译的时候，把相应的代码符号记录到cov文件中。

可见设置cov文件路径的重要性，否则不好找。

在vc2005中。

特别提醒的是，BullseyeCoverage对业务代码逻辑无影响，只是在cov文件中记录了有关代码的函数、分支和条件判断等符号。

4.2.在测试时如何使用？

1）在测试机器上也必须安装BullseyeCoverage，安装方法跟上面介绍的一样。

测试的机器上是否安装vc编译器没有关系。

但是仍然要选择编译器类型，这样便于识别所选编译器产生的符号。

2）把编译产生的程序复制到测试机器。

3）用编译产生的cov文件覆盖测试机器上的cov文件。

4）启动测试程序，开始测试不同的测试用例（主要是功能测试）。

5）每测试完成一个功能case，都可以打开相应的cov文件，开始统计代码覆盖的情况。

当然，做了多少测试后开始统计，完全由测试人员自行决定。

打开一个cov文件如下。

6）cov文件打开后的样子。

7）其中打勾的表明该函数进入过，T表示ture，表示该条件分支被执行过，F表示false，表示该条件分支没有被执行过。

8）统计情况请看下图中的底部的状态栏。

其中有函数覆盖和未覆盖的百分比，条件或判断分支覆盖和未覆盖的百分比。

9）这个工具还有一个强大的地方是，在上图的左侧是代码目录结构，可以分级统计代码覆盖率的情况。

10）值得注意的地方是：如果仅仅统计代码覆盖率的多少，不用提供源码。

但是如果要查看某个函数或条件分支的执行情况，则必须把测试产生的

cov拿到有代码的机器上进行分析。

11）最好要注意的是：每次代码改动编译后，会产生新的cov文件，因此测试的版本和发布的版本必须一致。

12）还可以把统计结果导出成html或xml。

代码覆盖率（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的集成开发环境中获自动化测试用例的码覆盖率数