自动化测试之祸

最近，组内测试进入D2P 集成测试阶段。由于Scrum模式下开发，regression的错误自是引入不少，所以一轮轮regression下来，测试人员难免心生倦殆。有些人动起了automation的主意，更有人先是做起来了。我真是欣赏proactive to do some improvement的精神，但我认为，automation 测试还是要慎重的。那些机器可以做的事情，也许聪明人不想自己做。

 

以我看来，Automation测试，并不是一个release cycle的事情。从设计它的architecture到建立fundamental的class，再到写test case script，最后是maintenance，这一步一步紧紧相连。测试方法在组里的应用，测试组长要好好把握，要考虑到项目规模对自动化实施的时间人员需求，人员分配，时间安排，架构设计都不是简单的事情。在整个一个release cycle如果都没有自动化测试计划，但是在最后阶段加入此项工作，那么就是祸了。我们知道测试忙时也就是发布前期了，regression test，final acceptance test， beta test，这都是挑战。当组员们发现新引入自动化测试时，都因为有了新的东西而兴奋，都因为一遍遍的regression没有兴趣而想要放弃。所以，全组就都乱了。也有人义正言辞的跟我说，我是在为组里面提高工作效率。也许我可以给他些时间让他尝试，并且让他给我一个commitment。但是，在这最后的阶段，资源如金，我也就只能霸权了。

 

因此，Automation test这个概念在我们这次开发周期中，是祸。

 

可是，通过我和几个非常想尝试automation的同事聊天之后，我知道了真正的祸在哪里。很多公司，尤其是所谓的大公司。面试的时候，automation test被认为是最大的亮点。有些公司居然因为做过自动化测试而判断测试人员的测试技术。无论是自动化测试还是手工测试都是保证质量的一种途径。各有其明显的优缺点。有些性能测试自动化是不可取代的。对于功能测试，虽然手工测试代价很高，且容易漏掉问题，但是一些逻辑复杂的繁琐的用例，自动化不一定可以做到。在资源允许的情况下，两者互相交替执行，将能达到最好效果。这需要周密的计划，和严格的执行。不是拍脑袋的事情。在者，我认为测试人员的测试技术如何要看其是否拥有测试人员需要的素质，要有测试的“慧根”。

 

我想，也希望，以后所有的测试都自动化起来，将人力解放出来，但是目前还是要基于现状，踏踏实实地保证高质量的产品如期发布。

 

 

 

 

明天，我会去面试一个重庆的学生，想要来这里做实习生。我想，我还会从没有毕业的大学生那里知道象牙塔里的后备军是如何看待自动化测试的些许见解。

以下是我们很容易搜集到的Automation test的优缺点。

 

Automaton 测试的优点

1.   通过手工测试无法做到覆盖所有代码路径。

2.   简单的功能性测试用例在每一轮测试中都不能少，而且具有一定的机械性、重复性，工作量往往较大。

3.   许多死锁、资源冲突、多线程等有关的错误，通过手工测试很难捕捉到。

4.   进行系统压力、性能测试时，需要模拟大量数据或大量并发用户等各种应用场合时，很难通过于工测试来进行。

5.   进行系统可靠性测试时，需要模拟系统长时间运行，以验证系统能否稳定运行，这也是手工测试无法模拟的。

6.   如果有大量（几千）的测试用例，需要在短时间内（1天）完成，手工测试几乎不可能做到。

Automation 测试的缺点

1.   功能测试，自动化不能取代手工测试，手工测试比自动测试发现的缺陷更多

2.   测试自动化不能提高有效性

3.   软件开发语言模型将制约自动化工具，自动化测试的普遍应用存在局限

4.   工具本身并无想象力，不能主动发现缺陷

5.   一种测试工具不完全适用于所有测试，要划分覆盖区域

6.   自动测试不一定减轻工作量，要有专门的测试小组专门负责此事

7.   测试进度可能不一定缩短

8.   如果项目还在开发阶段，脚本维护成本高