“自动化回归测试所面临的最大问题就是退化和过早消亡”，当自动化测试在如火如荼的进行过程中，一个突如其来的软件变更、重构、开发平台变更、开发工具变更、关键人员离职可能会导致整个自动化测试流程的夭折。听起来有些耸人听闻，但当现实摆在面前的时候，我们不得不思考这样一个问题，如何防止这类现象的发生，当这种现象即将到来时，我们又应该怎样做呢?

　　什么原因会导致自动化测试的退化和过早消亡?

　　1、未提前通知的软件变更：当我们已经积累了大量的自动化脚本，而且脚本中存在大量的被引用测试包，当发生的变更隐藏在某个或某些个被引用测试包的时候，测试人员并没有得到应得的提前通知，而是在发现自动化测试失效的时候才发现问题的严重性，随之带来的失效诊断、问题修复、脚本维护上的时间打断了我们目前的测试进程，为了不过多影响软件发布，项目组不得不采取手动替代的方案让大家继续测试，自动化测试被迫搁置一边；

　　2、软件重构：当产品进入市场，由于性能或其他问题并不被客户看好的时候，我们会考虑到软件的大规模重构，由此带来的未知的界面和业务变更会使得我们前期积累的大批量自动化测试脚本无法复用，除了一些文档、方法、策略，其他都成了明日黄花，同时，开发语言、开发工具、平台的变更同样会导致这类问题；

　　3、关键自动化测试人员的离职：当一些测试策略、文档、规范一直存放于一个或些个自动化测试人员的脑海、未被公布的测试机的某个路径下的时候，关键自动化测试人员的离职也会导致自动化测试的停滞不前、日益退化；

　　如何应对与避免?

　　1、软件架构与设计阶段就应当考虑到自动化测试：软件测试并不仅仅是软件测试工程师自己的事情，需要架构师、需求人员、系统工程师、开发人员的协助，比如，在软件被开发出来之前就可以在软件原型上进行自动化测试设计、脚本编制等，这就要求原型开发人员、需求人员的大力支持，需求文档尽量精确详细，尽量避免变更，软件开发过程中，及时对原型进行维护等；

　　2、时刻考虑到维护：安排专门的自动化脚本维护工程师在特定的时间对脚本进行及时维护，而不是在发现测试大量失效的情况下再亡羊补牢；

　　3、不要集权：自动化测试策略、自动化测试文档、资料等不要集中在一个人手中，要有特定的机器存放，自动化测试进行过程中积累的各种经验和教训要及时付诸文档，或者及时沟通与培训；

　　4、规范：有严格的自动化脚本编写规范、每个里程碑的自动化测试目标明确、每个里程碑的测试策略明确、脚本编制人、编制日期、测试功能点、期望结果等要清晰可辨，这些都是为了脚本的易维护性而考虑的；

　　5、摆脱被动：自动化测试不要做软件开发的附属物，而是要驱动和指引软件开发，当发现问题时决不手软，比如软件性能问题，不要到软件开发后期再考虑到性能测试，时刻积累数据，发现问题及时通知，而不是到了一定程度，忍无可忍时再去通知，当软件不得不进行重构时，发愁的不仅是开发，还有测试。

　　总之，制定严格的自动化测试流程、提前考虑到各种风险、保持顺畅的沟通、考虑到维护、八方支援、层层把关，才能真正发挥自动化测试的功用，而不至于让大家失望。