software testing buzzword

上上周到杭州参加了第二届互联网测试交流大会大会PPT下载),回来以后跟公司的同事分享了一下。分享什么,怎么分享,我想了好久,因为嘉宾们的演讲为了照顾大多数听众,所以不可能太深入。那怎么办呢?我如果拿着他们的PPT给同事讲,好像不太负责任,并且我的基础没他们那么稳固,经不起问。讲自动化测试吧,有点老生常谈,自己也没有太多新的内容。终于在第二周的时候有了灵感。我个人感觉吧,Agile和Testability在软件测试这个行业里面是比较热的两个点,最后加上个人的一点点对日常工作的感悟,完成了这个PPT,总体来说效果还是不错了,起到了抛砖引玉的作用,大家讨论的比较激烈 🙂

开发人员与测试人员比例

上周末去参加了第二届(杭州)互联网测试技术交流会,下午结束了以后有个小型的交流会,会中淘宝的郭芙在自我介绍的时候提出了一个问题,就是开发人员与测试人员比例多少才是合适的呢?这个话题引起了各位嘉宾们的踊跃讨论,infoQ的泰稳整理了这次讨论(推荐看1楼回复),我也想谈谈自己的一些看法。

其实算上实习,我已经在4个公司工作过了,回头来看看这些公司研发团队的开发测试比例,从一个小职员的角度。

第一个公司是一家年收入10亿美元的百年老店,传统软件企业,在那里,开发和测试的比例大概是3:1。作为一个传统的软件企业,这家公司的自动化测试在那时候(2006年)才是刚起步,公司内部有较为规范的流程,QA在公司里面的工作大概就是从需求文档开始到各种设计文档进行review,之后dev开始写code,这时候QA也开始写测试用例,当时用的是QC。写好以后QA会review用例,然后就开始执行用例(真的是step by step,不夸张)。一个人一天如果能执行完40个用例,那是相当的高效率。3:1这个比率,看上去挺正常,但是其实QA做的工作并不多,总的来说QA的工作效率不是很高。在自动化测试程度不高的情况下,要保持产品质量,所以需要更多的QA来达到这个要求。我个人认为3:1的比率有点高。

之后在一家做统计分析的美资企业实习过一段时间,这个公司现在已经被IBM收购鸟……在这个公司,开发和测试比大概是2:1。QA的工作主要是阅读设计文档,设计测试用例,执行测试。同样,我觉得这个公司跟之前那个公司有着相同的问题,自动化测试程度不高,但是产品的质量要求非常高,所以需要更多人力物力在QA团队,而且由于各种各样的问题,团队的效率好像不是非常高。所以2:1这个比率有点高,但是其中是有他的原因的。

在MySpace,我们的开发测试比大概是5:1,互联网公司,要的就是一个快字,所以对产品的质量不需要很高,有Bug没关系,只要改的快就行了,抢在竞争对手前把产品发布出去才是根本。那时候基本上是一个人负责一个项目,一个项目可能持续2~3个月,完了以后继续第二个项目,QA要做的事情是,在拿到产品的设计文档以后,跟开发一起开会做设计,做测试用例,测试,上线,回归。我做的是后台的测试,所以我这边其实是4个开发写的代码给我1个人测试,那些接口测试用例其实都是自动化的(VSTS的mstest)。所以工作基本能很好完成。在这个互联网公司,有互联网的血统(快),但是对产品的质量要求也不低,QA做的工作比较细(其实主要是要经常性地在IE6的样式上纠结)。在自动化测试开展的还可以的情况下,比率是5:1。

终于到FreeWheel了,首先说一下我们的开发测试比,1.2:1,具体说就是12个开发对10个测试。说一下那么多QA都是干嘛的呢?QA的工作主要是拿到PM的设计以后,参与开发的设计,之后设计用例,测试,把测试转化为自动化回归测试(其实很方便的);解答客户遇到的各种问题(为什么我的广告没出来,我想要XXX的数据,等等)。我个人觉得这套服务的特点是(相对于其他系统来说)商业逻辑非常复杂,软件本身的复杂度相对商业逻辑来说较低。据我的工作的体会,DEV很少会出现比较低级的bug,出现bug的地方大多数都是在商业逻辑上,说白了这是一套business driven的系统,客户需求是第一位,如果他说要一个算法,要1+1=7的,都是要实现的。所以QA在看需求的时候需要看的非常细,所以就需要更多的QA,并且会花比较多的时间去解决客户遇到的问题。

这个开发测试比,基本上每家公司都是不一样的。这个原因有很多,公司传统,领导风格,人员素质,工作内容,等等……如果离开了当前公司的这个Context去谈开发测试比,并没有太多的意义。就譬如说两家公司的开发测试比都是3:1,但是其中一家公司的可能很糟蹋,另一家很高效。谈这个开发测试比例,最好是在相同的类型的公司(创业型VS大公司),相同的行业(互联网VS传统),人员素质在同一个水平,等等。。。在这些前提条件下,如果发现自己的所在的组织的效率不如其他公司,可以参考同行有什么好的实践,取其精华去其糟粕。

开发测试比例只是浮云,整个组织的效率才是关键。

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前能够对产品进行覆盖较为全面的回归测试
  • 工作中*不断地*开发自动化测试工具,提高自己的生产率

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

内部自动化测试交流有感

上周公司组织了一个交流会,主题是关于自动化测试,这个已经在公司引起高层们足够重视的话题,说是交流会,其实我更觉得是个成果展示会,本人代表CORE QA跟大家分享了一下我们组内自动化测试的一些情况,并且在做的过程中的一些经验。我是第一个,下面是VI的自动化测试,VI主要是跟Video播放器结合的比较紧密,最后是UI同事的介绍。我从头到尾都参与,所以说说的我感受吧。

CORE这边测试的特点就是,针对MRM系统的后台进行测试,肩带来说就是模拟各种跟后台打交道的“程序”的工作,进行测试。我们测试有以下特点:

  1. 直接跟后台程序交互,基本没有现成的开源或者商业工具可以支持自动化测试快速开展
  2. 测试验证结果大多数是后台的输入,也就是前台或者是第三方系统的输入,所以验证的方法不能简单地观察输出结果,同时需要知道后台的输出拿到别的系统能否正常工作
  3. 牵涉到数据迁移或者数据重处理的时候,QA需要直接读取生产环境的数据进行校验

由于以上特点,所以我们的自动化测试85%都是自己开发工具来做,常用的脚本语言是Python,经常用到的一些模块包括读取MySQL的MySQLdb;csv模块;re模块;总得原则就是把重复性强,容易引入错误的工作都写成小工具。并且尽可能使用已有的成熟的库,而不是自己重复发明轮子。例如我们的前端页面使用了web.py轻量级框架,JSON库。到目前为止,我自己感觉我们的自动化测试还是做的不错的,主要是以下几点

  1. 简单。说起自动化测试,可能有部分人,或者说是外行的人吧,都觉得这个东西非常酷,人只要倒杯咖啡看着电脑执行测试就好了。但是其实实用有效的自动化测试并不是说看起来有多酷,而是这个东西能把人从重复劳动中解放出来。
  2. 强大。我刚到公司的时候,已经有600多个回归测试跑在自动化框架上,我当时就觉得已经挺不错的,因为这个自动化测试是由大概4~5个不同的人做的,我以前在MySpace的时候SOA大概有300个CASE,不过那都是我一个人做的,相比较而言FreeWheel应该是更好。
  3. 持续改进。虽然我刚到公司的时候自动化测试已经存在并且也算是行之有效,但是任何系统都是有可改进的空间的,我把前端UI改了一下,很高兴可以帮助大家缩短了找问题的时间
  4. 全面。基本上所有的模块都有自己的一堆自动化测试工具。

引用一句我非常喜欢的英语:So far so good。那下面我想做什么事情呢?

  1. 自动化测试其实不是测试,只是重复运行测试用例而已。真正的测试用的是脑,而不是工具,工具只是辅助我们的工作的
  2. 自动化测试是危险的,不要看到所有回归测试都通过了,就高枕无忧
  3. 手动测试才是根本
  4. 希望能给大家灌输一些思想,如果发现自己在重复做一件事情,那么应该停下来,想想有什么办法能够让自己停止重复,尽可能自己解决问题,培养自己的动手能力
  5. 看看有没有一些开源工作能让现在的工作做的更加好

下面说说对VI TEAM自动化测试介绍的一点感觉吧,VI和CORE有点儿相似,就是都是用的自己开发的自动化工具,而没用应用了太多开源工具,我个人觉得这里面原因有2个

  1. VI的测试面向Video播放器的SDK,也是一个后台,所以也没有太多现成的工具
  2. 用户怎么用我们的SDK?就是调用接口,跟CORE面对的问题相似

估计由于经常跟XML打交道,所以VI的自动化测试用到很多XML文件作为配置。由于隔行如隔山,所以没有看懂里面的一些玄机,总的来说就是跟我们CORE有点相似。

我们CORE和VI一样,这些工具如果跳出了这个公司,基本上就不能应用到其他地方,这也是对整个系统来说的底层部分做自动化测试的特点:高度定制化,通用性低,自己开发居多

最后就是UI的介绍,终于等到一个看得懂的啦。

UI那边就是大量使用开源工具,这个也是很有道理的

  1. UI的自动化测试实施难度比后台程序的自动化要大
  2. 现有的UI自动化测试非常丰富

那我们的UI是怎么做的呢?首先UI的同事用了一个持续集成的工具hudson作为一个颗粒度比较粗的测试用例管理工具,hudson作为自动化测试的主心骨,QA们可以在hudson上触发自动化测试的运行,运行完了以后可以看到测试结果,并且,利用了hudson的分布式结构,由多个测试机来执行测试,达到了很好的资源调配。对浏览器的控制方面,用了Selenium,会上没有问UI是否利用了Selenium的多浏览器支持,从演示上来看应该只做的Firefox的。他们的分工很明确,分了专门做功能测试的QA和专门做自动化测试工具开发的SDET,SDET主要是负责写RUBY代码,封装并且暴露了一些通用的方法给QA使用,并且同时使用了Cucumber作为一个DSL,QA是用Cucumber来做自动化测试的一些描述,Cucumber的作用就是对功能测试的QA屏蔽了底层RUBY脚本,对上就是“翻译”功能测试QA的意图,“翻译”成RUBY。说一下我觉得的优点:

  1. 分开了自动化测试工具开发和自动化测试实施
  2. 使用了大量开源工具,提高效率
  3. 而且都是业界常用工具,对以后跳槽帮助不小(嘿嘿)
  4. One click automation (只需要点一下hudson)

一些工具带来的制约

  1. 一次只能运行一批测试,不能重跑单个测试
  2. 个人觉得使用XPATH作为对象的识别并不是一个好的选择

总得来说大家都各有特色,并且都做得挺好,并且都有不少可以提高的空间。多点交流的确能带来不少灵感。

用Python对体积较大的CSV文件进行比较的经验

最近的工作总是跟数据打交道,需要经常比较一些CSV文件,这些CSV文件其实都需要被LOAD到数据库里面,所以也就是一堆堆的数据文件需要比较。暂时没有发现有比较好用的现成的CSV比较工具,自己动手用Python做了一个凑合能用的。思想比较简单,就是把CSV文件的内容读取出来,保存为一个list,然后把2个CSV文件所生成的list进行对比。有个特殊的需求,就是对于CSV文件中一些肯定不一样的列,例如process date这样的字段,是需要跳过的。由于本地生成的CSV文件比较小,刚开始没有注意到如果文件太大的话会占用很多的内存。最开始的版本是:

def readcsv2list(filename, rows):
    fileobj = open(filename, 'rb')
    csvreader = csv.reader(fileobj)
    retlist = []
    for row in csvreader:
        clist = []
        selected_rows = [ic for ic in range(len(row)) if ic not in rows]
        for c in selected_rows:
            clist.append(row[c])
        retlist.append(clist)

    fileobj.close()
    return retlist

后来用这个脚本比较生产环境数据的时候就遇到问题了,其中最大的一个数据文件大概是1.5GB,这只是文件大小,把文件转成list以后所占用的内存会翻几倍(这个很容易理解,整数1在文件里面站1个字节,放到list里面就要4个字节了)。一下子把机器的内存用光了。随后找了一下文档,csv.reader是没有一个方法可以指定一次读取若干行数据的。后来就利用file object有一个readline()方法,通过一个参数来控制一次读取多少行的记录,从而达到控制内存使用量的目的。需要的注意的点有:1. 在读完若干行数据以后,需要获取一下当前这个file object的位置,Python提供了.tell()方法来获取这个值;2. 读取文件的时候需要知道上一会读到什么地方了,并且从那里继续往下读,用到了.seek()方法;3. readline()方法在读到文件末尾的时候只会返回一个空字符,所以需要对这个空字符做一点处理。

def readcsv2list(filename, rows, last_position, max_line):
    fileobj = open(filename, 'rb')
    fileobj.seek(last_position)
    datalines = []
    for i in range(max_line):
        line_itme = fileobj.readline()
        if len(line_itme) > 0:
            datalines.append(line_itme)
        else:
            break

    csvreader = csv.reader(datalines)
    retlist = []
    for row in csvreader:
        clist = []
        selected_rows = [ic for ic in range(len(row)) if ic not in rows]
        for c in selected_rows:
            clist.append(row[c])
        retlist.append(clist)

    current_position = fileobj.tell()
    fileobj.close()
    return retlist, current_position

Python,尤其是低版本(例如我们用的2.4.3),对于在程序里面显式地del一些变量(通常是个大list之类),是不会立刻释放内存的,所以对于处理数据量比较大的case的时候就需要特别注意内存的使用。参考文章:
Python Memory Management
Why doesn’t Python release the memory when I delete a large object?

代码中的注释

我第一个实习的公司,是一个美资公司,在印度设立研发中心可能都已经有超过10年的经验了,那时候一些前辈们告诉我,印度人写的代码可能不如中国人那么聪明,但是他们的注释实在是非常详细,有时候甚至达到了1:1的比例,试想想,100行代码就有100行注释,这是多么的恐怖啊。

经常听到会有人抱怨道,怎么这段代码没有注释啊,这是为什么这样写的啊,如此云云。仿佛没有注释,这个世界就不转了。类似的事情也经常发生在QA们的身边,只不过注释换成了文档。

刚毕业的时候做白盒测试,现在回想起来,那时候的我测试的代码大部分都是不包含注释的,不过我测试起来并没有太大的困难,总结一下,应该有以下几点原因:

  1. 有意义的函数名、变量名。函数的命名让人一看就大概知道在做什么,例如PostBlog就是发布一篇博客,如果遇到一个叫SaveProfile的方法但做的却是加好友,那我想再多的注释我也会头晕
  2. 代码不会说谎。根据经验,如果一段代码理解起来很费劲,那么通常里面都会隐藏着问题。代码就是最好的注释,一些过时的注释,设置会对阅读代码的人产生误导
  3. 充分的沟通。虽然游走于几个项目组,跟不同的开发人员打交道,但是每当遇到问题的时候总会主动跟相关的人沟通,一个活生生的人坐在那里不问,却迷信什么文档,这真是本末倒置

注释,能不写就别写,实在要写,写WHY而不是WHAT。

联系一下最近在Team内写的一个新的回归测试工具,里面基本没有注释,希望过几个月以后,自己还能够看看代码就知道当时那段代码为什么这样写。