在中国的软件行业，如果工作时间稍微长一点的话，应该都是从瀑布开发模式成长起来的，包括现在，很多公司其实还是采用瀑布开发的模式。当然，敏捷转型也是软件行业一个很热的topic。

　　作为一个在传统的软件测试行业工作了8年多，在敏捷开发模式也工作了3年多的一个测试行业的老兵，很想从测试自动化的角度看两种开发模式的不同，以及测试自动化在其中的差异。

　　先从传统模式说起吧，传统模式下，软件开发和测试人员分属不同的team，之间其实是有很多隔阂的。特别当时我们和开发人员还属于不同的site，沟通上面更加不是那们遍利。

　　记得那时公司要推测试自动化，我给其中的一个基站测试部门介绍一个我们新开发出来的工具，可以模拟手机打电话，但当他们的测试经理听到我说这个工具只能在协议层面来看通话是否畅通，不能真正判断无线话路的畅通的时候，他马上打起了退堂鼓。

　　他的思路估计是这样的，这个工具其实又没办法真正帮助我们取代人的劳动，还是需要人去做手工测试。那反正人会做的事情，为什么要机器去做？他只对这个工具能够提供的部分很难由测试人员手工执行的功能比较感兴趣，比如做一些性能测试，做一些频繁的切换测试等。

　　至于用它来做功能测试，虽然也能帮助他cover很多的功能，但是并不能引起他太大的兴趣。特别是他有好几个月的时间来执行一个版本的测试，他手下又有这么多的人，足够来做测试，何必引入这么个东西呢？

　　的确，对于一个Test Manager而言，如果他的着眼点在于发现足够数量的软件bug的话，测试自动化的确不能帮助他太多。

　　有一种比较有意思的现象叫杀虫剂效应，是说如果同样的case反复执行，对于一个特定软件来说，发现问题的概率是越来越低的。

　　自动化case都是固定的测试过程，固定的检查方式和期望结果，当然也不能期望他能够持续不断发现新的问题。

　　那到底我们为什么要来做自动化测试呢？

　　在传统的模式下，其实我也一直没想清楚到底为什么？特别是一个自己也做过三年多手工测试，对自己发现问题的能力也颇有信心的人来说，我其实是挺能体会测试人员对推广自动化测试的抵触情绪的。

　　然后加入了现在的公司，我们公司在国内的敏捷开发阵营里面，应该也算是比较前沿的。我的任务主要是在部门里面推广自动化测试，提高自动化测试的成熟度。

　　当时部门碰到的情况主要是已经有很多的自动化case了，但是这些case一直很难跑起来。具体来说是一个case失败，往往后面很多case会失败。而且这个失败，往往也不是真正的软件bug导致的，很有可能还是一个自动化case自身的问题引起的。

　　有的team呢，则是碰到这样的问题，case执行得很顺利，但突然某天有几个case失败了，也不知道什么原因。测试人员又无法通过手工测试复现，所以也是搞得莫名其妙的。

　　还有是敏捷开发要求每天team需要把自己的case回归测试一遍，但是随着case的数量越来越多，team差不多要dedicate 0.5-1个人来跟踪这些测试结果，而且往往也不能找到特别有价值的问题。而team日常又有新功能要开发，人力资源也比较紧张。所以渐渐地team也有疑问，这个事情每天做，到底有多大的意义？投入产出比合理吗？

　　在上一家公司，我花了很多的时间来游说测试部门多投入人力来搞自动化测试，但是收效始终不大，管理层的支持也不是很多。以致于到后来，我们team一致认为自动化测试搞不起来，技术问题不是主要的原因，公司的管理层理念能不能跟得上来，支持的方法是否正确，力度是否够，才是主要的。

　　现在公司的管理层态度很明确地支持这个事情了，不过碰到了一些困难，我是很有兴趣进去看看，到底这些问题都是由于什么原因引起的，能不能解决。