Python代码覆盖工具coverage.py介绍

最近是跟代码覆盖干上了,今天下午测试一个功能的时候,路过另一段代码,发现一个问题,由此想到既然C++都要搞代码覆盖,为什么不搞搞python的呢?很容易就找到了coverage.py ,这个工具比较简单,我用easy_install安装的,非常顺利。由于python不需要编译链接,所以这个工具使用非常简单。coverage run [options] your_cmd [cmd options]。

假如原来的运行的命令是:

fact_compare.py -d result

需要收集代码覆盖信息的话只需要这样运行

coverage run –branch fact_compare.py -d result

运行完了以后会在当前目录下生成一个.coverage文件,保存了代码覆盖信息,可以用简单的coverage report看来简单的结果,当然,有更好的html结果显示

coverage html -d your_result_folder

最左边是绿,也就是没有颜色的代码的就是完全覆盖(其实只是语句覆盖和分支覆盖),黄色的是部分分支覆盖,红色的语句覆盖都不是。

分享两个PPT,关于gcov和lcov,还有代码覆盖

两个PPT的主题其实都是关于代码覆盖的,那为什么分开了2个PPT呢?因为准备在两个会上讲,一个讲代码覆盖,尽量不涉及工具细节,另一个只介绍工具。

PPT写的很粗,主要靠讲,不过PPT本身的话我个人感觉一般般,但是又没有修改的动力了,就先放上来吧,有问题意见请及时给我反馈,多谢先啦。

Using gcov and lcov
Knowledge share on code coverage

解决gcov不能生成.gcda文件,以及其他错误

上一篇博客简单介绍了如何用lcov获取代码覆盖信息,今天回到公司动手做,还是遇到了些问题。

跟开发沟通了一下,我们的程序不是在每台开发机上都能成功编译的,因为需要很多第三方库,等等……所以就登陆到他的开发机上把程序编译好,然后拷贝到我自己的机器上运行。问题就出在这里,编译的时候在机器A上,路径是/home/qli/debug,我在机器B上运行的目录是 /home/jchen/work/,程序运行完毕生成.gcda文件失败,出现若干个提示如下:

profiling:/home/qli:Cannot create directory
profiling:/home/qli/debug/server/Selection.pb.gcda:Skip
在我的运行环境中没有相应的目录,所以不能生成.gcda文件,Google了一下发现,只要设一下GCOV_PREFIX和GCOV_PREFIX_STRIP这两个环境变量就好了。GCOV_PREFIX就是制定生成数据文件的前缀,GCOV_PREFIX_STRIP就是需要在原来的路径上去掉多少层目录,这2个变量配合使用就能把数据文件生成到我们想要的地方。假如我编译时候的路径是“/home/qli/debug/server/”,我现在的运行路径是“/home/jchen/work/ads/ads_server/server/”,那么执行如下命令即可
export GCOV_PREFIX=”/home/jchen/work/ads/ads_server/server/”
export GCOV_PREFIX_STRIP=4
执行完这两行命令,就可以开始运行被测程序,然后正常退出,就会看到.gcda文件生成出来了。
.gcda文件生成了就可以用lcov直接处理它们,但是我在处理的过程中遇到以下错误:“stamp mismatch with graph file”
Processing Ads_Request.gcda
/home/jchen/work/ads/ads_server/server/xxx.gcda:stamp mismatch with graph file
geninfo: WARNING: gcov did not create any files for /home/jchen/work/ads/ads_server/server/xxx.gcda!
导致出现这个错误的原因是.gcda和.gcno文件并不是同一次build出来的,它们2个文件的时间戳就不一样了,很简单,更新所有的.gcno文件即可。

C/C++代码覆盖工具gcov与lcov入门

gcov是一个可用于C/C++的代码覆盖工具,是gcc的内建工具。下面介绍一下如何利用gcov来收集代码覆盖信息。
想要用gcov收集代码覆盖信息,需要在gcc编译代码的时候加上这2个选项 “-fprofile-arcs -ftest-coverage”,把这个简单的程序编译一下

gcc -fprofile-arcs -ftest-coverage hello.c -o hello

编译后会得到一个可执行文件hello和hello.gcno文件,当用gcc编译文件的时候,如果带有“-ftest-coverage”参数,就会生成这个.gcno文件,它包含了程序块和行号等信息
接下来可以运行这个hello的程序

./hello 5
./hello 12

运行结束以后会生成一个hello.gcda文件,如果一个可执行文件带有“-fprofile-arcs”参数编译出来,并且运行过至少一次,就会生成。这个文件包含了程序基本块跳转的信息。接下来可以用gcov生成代码覆盖信息:

gcov hello.c

运行结束以后会生成2个文件hello.c.gcov和myfunc.c.gcov。打开看里面的信息:

-: 0:Source:myfunc.c
-: 0:Graph:hello.gcno
-: 0:Data:hello.gcda
-: 0:Runs:1
-: 0:Programs:1
-: 1:#include
-: 2:
-: 3:void test(int count)
1: 4:{
-: 5: int i;
10: 6: for (i = 1; i < count; i++)
-: 7: {
9: 8: if (i % 3 == 0)
3: 9: printf (“%d is divisible by 3 \n”, i);
9: 10: if (i % 11 == 0)
#####: 11: printf (“%d is divisible by 11 \n”, i);
9: 12: if (i % 13 == 0)
#####: 13: printf (“%d is divisible by 13 \n”, i);
-: 14: }
1: 15:}

被标记为#####的代码行就是没有被执行过的,代码覆盖的信息是正确的,但是让人去读这些文字,实在是一个杯具。不用担心,有另外一个工具叫lcov,可以用程序解析这些晦涩的字符,最终输出成html格式的报告,很好吧!

lcov -d . -t ‘Hello test’ -o ‘hello_test.info’ -b . -c

指定lcov在当前目录“.”去找代码覆盖的信息,输出为’hello_test.info’ ,这个hello_test.info是一个中间结果,需要把它用genhtml来处理一下,genhtml是lcov里面的一个工具。

genhtml -o result hello_test.info

指定输出目录是 result。一个完整的html报告就生成了,做一个连接,把这个目录连到随便一个web server的目录下,就可以看报告了。

Continue reading “C/C++代码覆盖工具gcov与lcov入门”

敏捷开发中开展自动化测试的经验

上周在51testing上看到一个问题,题目是在敏捷开发中,自动化测试应该如何开展呢?当时在论坛上回复了一下,现在放到博客,稍微调整一下。

首先,敏捷开发并不是部分同学想象中的那样,没有文档没有需求,开发来了就干,干几个月就丢给客户一个版本让他们用去。我们公司一般6个星期是一个release周期,在这6个星期里面,可以做的事情是非常多的。

  • 需求,需求通常来自于PM,在一个release周期的开始,QA通常没太多事情需要做,比较轻松,这个时候一个比较重要的工作就是跟PM沟通当前release里面的一些feature的情况。在这个时候,QA可以做一些自动化测试的准备。例如在某个release周期里,我知道在接下来的测试当中我需要频繁地比较CSV文件,那么作为QA就应该在项目还不是很紧张的时候,就开始准备自动化测试的脚本,例如刚才说的这个CSV文件比较工作。
  • 开始开发,如果公司是实时TDD开发,那么这个时候QA可以做的事情大概有2个,帮助开发写单元测试用例,并且实施自动化测试(主要是单元测试),另一个是review(虽然不是自动化测试的内容)。如果不是采用TDD开发,那么QA做的事情跟上一个阶段的做的差不多。
  • 正式提交测试,OK,这个时候是我们QA比较忙的时候,有可能出现几个情况,1. 跟我的预想一样,我真的需要一个CSV文件比较工作,并且只需要这一个工具,并且我已经完成了,那么就可以进行测试了。2. 可能有一些新的自动化测试需求跑出来了,例如每天晚上自动比较几万个CSV文件并且把测试结果发给相关的人,这时候作为QA,在考虑资源允许的情况下,应该尽早完成这个工具,而不是每天晚上爬起来看结果。
  • 发布完毕以后,回过头来看工具,是否有值得改进的地方,是否能够改进一下就能够给整个Team使用。

以上算是一个release周期里面的一些微观的工作,宏观上来说需要做点什么事情呢?

现在提到的敏捷开发,都有一个很突出的特点,就是产品快速交付给客户,为了快速交付这个目的,公司里面每个团队都作出了努力,那么具体到QA团队,肯定就是要在保持测试质量得到保证的前提下,尽可能地缩减测试所需要的时间,使得产品按时按质交付。要达到这个目的,总靠一些AD-HOC的工作(例如刚才提到的突然写个CSV比较工具)是不可能达到要求的,那应该如何进行呢?

敏捷开发也是开发,产品不是孙悟空,不会某一天就从石头里面爆出来了。在产品开发的前期(例如0.1, 0.2版本之类),尽可能地想办法搭建一个自动化回归测试的框架,这个框架的特点有:1. 快速完成回归测试; 2.能够快速地添加测试用例并且跑起来;3.能够随着产品的演化而不断改进(不能是那种用1~2个release就要扔的东西);4.维护的成本要低(在一个release周期里面如果自动化测试需求有变化,不应该需要超过1个星期的时间才能改好,当然翻天覆地的变化除外)

综上所述, 我认为在敏捷开发里面的自动化测试是有2条路线,并且这2条路是并行的,缺一不可

  • 至少一个自动化回归测试框架,保证release前能够对产品进行覆盖较为全面的回归测试
  • 工作中*不断地*开发自动化测试工具,提高自己的生产率

以上两点的目的很简单,就是要在保持产品质量处于一个较高水平的情况下,帮助公司尽可能地快速交付新版本的产品。