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

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

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

3 thoughts on “敏捷开发中开展自动化测试的经验”

  1. 你好,我想请教一个问题:你在文章里写到在需求阶段就开始写自动化测试脚本,那软件还没出来,怎么写自动化测试脚本呢?我是一个初级的软件测试员,有很多都不懂,希望能给予指教,谢谢~

    1. 这个自动化脚本其实不是单单针对被测软件进行自动化测试的脚本,还包括了一些其他的工作,例如准备数据脚本,数据比较脚本等等。这个得看实际的情况来做。

Leave a Reply

Your email address will not be published. Required fields are marked *