software testing buzzword

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

http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=softwaretestingbuzzwords-101129090835-phpapp01&stripped_title=software-testing-buzzwords&userName=maguschen

开发人员与测试人员比例

上周末去参加了第二届（杭州）互联网测试技术交流会，下午结束了以后有个小型的交流会，会中淘宝的郭芙在自我介绍的时候提出了一个问题，就是开发人员与测试人员比例多少才是合适的呢？这个话题引起了各位嘉宾们的踊跃讨论，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传统），人员素质在同一个水平，等等。。。在这些前提条件下，如果发现自己的所在的组织的效率不如其他公司，可以参考同行有什么好的实践，取其精华去其糟粕。

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

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

上周在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系统的后台进行测试，肩带来说就是模拟各种跟后台打交道的“程序”的工作，进行测试。我们测试有以下特点：

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

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

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

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

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

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

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

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

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

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

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

UI的自动化测试实施难度比后台程序的自动化要大
现有的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。说一下我觉得的优点：

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

一些工具带来的制约

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

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

敏捷测试只是手段不是目的

首先我要声明：本人不懂敏捷测试。
敏捷开发在这两年一直很火，很多时候作为一个测试人员，经常会“被敏捷”。一些常见的现象有，当你所要文档的时候，相关人员可能会告诉你“我们是敏捷开发，没有文档”；当你索要进度表的时候，答案也是相似的。既然软件开发已经迈入了敏捷时代，那么软件测试还能原地踏步麽？那什么是敏捷测试？我不知道，不过我想说说我在“敏捷”组织里面进行软件测试的经历。
由于我不懂敏捷测试，所以我不知道它的定义，我只能通过“敏捷测试不是传统测试”这样的思路来开展工作。
首先，那种拿着各种需求文档设计文档来设计Test Case的日子是一去不复返了，因为敏捷开发强调的是能工作的软件比漂亮的文档要有用，人和人之间的沟通胜于文档。所以作为我，一个测试员，我对被测软件的知识的了解来源有2个方面，第一是代码，第二是开发人员。
其次，如果在测试过程中发现一个问题，第一件事情并不是把这个问题记录在Tracking system里面，而是找相关的开发和产品进行确认，究竟这是不是一个真的Defect。
然后，需要知道一个现在很流行的新玩意儿：探索性测试（Exploratory Testing）。每个人对Exploratory Testing的定义都不一样，最近两个大牛（James Bach, James Whittaker）也在掐架。我觉得如果简化这个定义的话，就是我们一边熟悉被测软件，一边进行测试，在测试进行的过程中，随着对软件的熟悉，继而设计出新的Test case来对被测软件进行测试，我个人觉得就像是一个小的迭代一样。
最后，忘记敏捷测试这个词。我觉得现在业界能说清楚这个概念的人很少，所以没有必要在这些定义上纠结。人们为什么要实施敏捷开发，是因为想交付更好的软件；我们为什么要实施敏捷测试，是想提高测试的质量以及生产力，从而帮助公司交付更加高质量的产品，至于是不是真正的敏捷，又有什么重要的呢