自动化测试应该如何开展呢?当时在论坛上回复了一下，现在放到博客，稍微调整一下。 首先，敏捷开发并不是部分同学想象中的那样，没有文档没有需求，开发来了就干，干几个月就丢给客户一个版本让他们用去。我们公司一般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前能够对产品进行覆盖较为全面的回归测试 工作中*不断地*开发自动化测试工具，提高自己的生产率 以上两点的目的很简单，就是要在保持产品质量处于一个较高水平的情况下，帮助公司尽可能地快速交付新版本的产品。 Tags: 敏捷测试, 自动化测试
一.29, 2010 in 自动化测试, 软件测试 4 Comments
内部自动化测试交流有感 上周公司组织了一个交流会，主题是关于自动化测试，这个已经在公司引起高层们足够重视的话题，说是交流会，其实我更觉得是个成果展示会，本人代表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作为对象的识别并不是一个好的选择 总得来说大家都各有特色，并且都做得挺好，并且都有不少可以提高的空间。多点交流的确能带来不少灵感。
文章来源于领测软件测试网 https://www.ltesting.net/
