自动化测试应该如何开展呢?

    首先，敏捷开发并不是部分同学想象中的那样，没有文档没有需求，开发来了就干，干几个月就丢给客户一个版本让他们用去。我们公司一般6个星期是一个release周期，在这6个星期里面，可以做的事情是非常多的。需求，需求通常来自于PM，在一个release周期的开始，TE通常没太多事情需要做，比较轻松，这个时候一个比较重要的工作就是跟PM沟通当前release里面的一些feature的情况。在这个时候，TE可以做一些自动化测试的准备。例如在某个release周期里，我知道在接下来的测试当中我需要频繁地比较CSV文件，那么作为TE就应该在项目还不是很紧张的时候，就开始准备自动化测试的脚本，例如刚才说的这个CSV文件比较工作。 开始开发，如果公司是实时TDD开发，那么这个时候TE可以做的事情大概有2个，帮助开发写单元测试用例，并且实施自动化测试(主要是单元测试)，另一个是review(虽然不是自动化测试的内容)。如果不是采用TDD开发，那么TE做的事情跟上一个阶段的做的差不多。正式提交测试，OK，这个时候是我们TE比较忙的时候，有可能出现几个情况，1. 跟我的预想一样，我真的需要一个CSV文件比较工作，并且只需要这一个工具，并且我已经完成了，那么就可以进行测试了。2. 可能有一些新的自动化测试需求跑出来了，例如每天晚上自动比较几万个CSV文件并且把测试结果发给相关的人，这时候作为TE，在考虑资源允许的情况下，应该尽早完成这个工具，而不是每天晚上爬起来看结果。 发布完毕以后，回过头来看工具，是否有值得改进的地方，是否能够改进一下就能够给整个Team使用。 以上算是一个release周期里面的一些微观的工作，宏观上来说需要做点什么事情呢? 现在提到的敏捷开发，都有一个很突出的特点，就是产品快速交付给客户，为了快速交付这个目的，公司里面每个团队都作出了努力，那么具体到TE团队，肯定就是要在保持测试质量得到保证的前提下，尽可能地缩减测试所需要的时间，使得产品按时按质交付。要达到这个目的，总靠一些AD-HOC的工作(例如刚才提到的突然写个CSV比较工具)是不可能达到要求的，那应该如何进行呢? 敏捷开发也是开发，产品不是孙悟空，不会某一天就从石头里面爆出来了。在产品开发的前期(例如0.1, 0.2版本之类)，尽可能地想办法搭建一个自动化回归测试的框架，这个框架的特点有：1. 快速完成回归测试; 2.能够快速地添加测试用例并且跑起来;3.能够随着产品的演化而不断改进(不能是那种用1~2个release就要扔的东西);4.维护的成本要低(在一个release周期里面如果自动化测试需求有变化，不应该需要超过1个星期的时间才能改好，当然翻天覆地的变化除外) 综上所述， 我认为在敏捷开发里面的自动化测试是有2条路线，并且这2条路是并行的，缺一不可 至少一个自动化回归测试框架，保证release前能够对产品进行覆盖较为全面的回归测试 工作中*不断地*开发自动化测试工具，提高自己的生产率以上两点的目的很简单，就是要在保持产品质量处于一个较高水平的情况下，帮助公司尽可能地快速交付新版本的产品。

　　一.29, 2010 in 自动化测试, 软件测试 4 Comments

　　内部自动化测试交流有感 上周公司组织了一个交流会，主题是关于自动化测试，这个已经在公司引起高层们足够重视的话题，说是交流会，其实我更觉得是个成果展示会，本人代表CORE TE跟大家分享了一下我们组内自动化测试的一些情况，并且在做的过程中的一些经验。我是第一个，下面是VI的自动化测试，VI主要是跟Video播放器结合的比较紧密，最后是UI同事的介绍。我从头到尾都参与，所以说说的我感受吧。 CORE这边测试的特点就是，针对MRM系统的后台进行测试，肩带来说就是模拟各种跟后台打交道的“程序”的工作，进行测试。我们测试有以下特点： 直接跟后台程序交互，基本没有现成的开源或者商业工具可以支持自动化测试快速开展测试验证结果大多数是后台的输入，也就是前台或者是第三方系统的输入，所以验证的方法不能简单地观察输出结果，同时需要知道后台的输出拿到别的系统能否正常工作 牵涉到数据迁移或者数据重处理的时候，TE需要直接读取生产环境的数据进行校验 由于以上特点，所以我们的自动化测试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作为自动化测试的主心骨，TE们可以在hudson上触发自动化测试的运行，运行完了以后可以看到测试结果，并且，利用了hudson的分布式结构，由多个测试机来执行测试，达到了很好的资源调配。对浏览器的控制方面，用了Selenium，会上没有问UI是否利用了Selenium的多浏览器支持，从演示上来看应该只做的Firefox的。他们的分工很明确，分了专门做功能测试的TE和专门做自动化测试工具开发的SDET，SDET主要是负责写RUBY代码，封装并且暴露了一些通用的方法给TE使用，并且同时使用了Cucumber作为一个DSL，TE是用Cucumber来做自动化测试的一些描述，Cucumber的作用就是对功能测试的TE屏蔽了底层RUBY脚本，对上就是“翻译”功能测试TE的意图，“翻译”成RUBY。说一下我觉得的优点： 分开了自动化测试工具开发和自动化测试实施 使用了大量开源工具，提高效率 而且都是业界常用工具，对以后跳槽帮助不小(嘿嘿) One click automation (只需要点一下hudson) 一些工具带来的制约 一次只能运行一批测试，不能重跑单个测试 个人觉得使用XPATH作为对象的识别并不是一个好的选择总得来说大家都各有特色，并且都做得挺好，并且都有不少可以提高的空间。多点交流的确能带来不少灵感。

转载：http://www.ltesting.net/html/22/n-201922.html

 已同步至 兰月儿的微博