上上周到杭州参加了第二届互联网测试交流大会（大会PPT下载），回来以后跟公司的同事分享了一下。分享什么，怎么分享，我想了好久，因为嘉宾们的演讲为了照顾大多数听众，所以不可能太深入。那怎么办呢？我如果拿着他们的PPT给同事讲，好像不太负责任，并且我的基础没他们那么稳固，经不起问。讲自动化测试吧，有点老生常谈，自己也没有太多新的内容。终于在第二周的时候有了灵感。我个人感觉吧，Agile和Testability在软件测试这个行业里面是比较热的两个点，最后加上个人的一点点对日常工作的感悟，完成了这个PPT，总体来说效果还是不错了，起到了抛砖引玉的作用，大家讨论的比较激烈 🙂
Category: 敏捷测试
敏捷开发中开展自动化测试的经验
上周在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前能够对产品进行覆盖较为全面的回归测试
- 工作中*不断地*开发自动化测试工具，提高自己的生产率
以上两点的目的很简单，就是要在保持产品质量处于一个较高水平的情况下，帮助公司尽可能地快速交付新版本的产品。
Magus Test Archive 