测试自动化框架的建立并不意味着测试后期可以不再进行修改和维护，我们只是在力求将变化的风险降到最低点，而且一个好的框架的建立，不仅仅是由技术来决定的，必须由有效的管理以及一定的资金来支撑。

　　软件测试作为保证软件质量和可靠性的关键技术，正日益受到广泛的重视。但随着软件工程的规模越来越大，客户对软件的质量要求越来越高，测试的工作量也越来越大，如何提高测试的质量和可靠性，就成为众多测试同行所考虑的问题，自动化测试也随之进入大家视野。大家都期望自动化测试能够在测试效率、测试时间测试和人力资源成本上有一个质的提高，但是现在大多数项目中却难以实施测试自动化。当然成功实施测试自动化涵盖很多方面，比如：公司的管理、制度、领导支持力度、资金的投入等等方面，但这不是本文所谈的重点，本文着重从技术的角度探讨测试自动化。

　　测试自动化失败的几个因素

　　谈这个话题前我们先看一个自动化测试脚本（基于ruby语言写的一个watir框架应用测试脚本）：

　　这是一个按照“pickaxe”关键字在google中搜索网页并进行结果校验的一段测试脚本。首先确认这是一个自动化测试脚本，但是也是一个维护性非常差的测试脚本，如果在一个大规模的测试项目中大量存在这种测试脚本，无疑将导致测试自动化的失败。在此，笔者结合上面的案例探讨一下失败的几个因素：

　　1、不适合实施自动化测试的项目

　　在文章的开始，笔者已经表述了在项目中实施自动化测试主要为了三个方面：提高测试效率、缩短测试时间以及降低测试人员投入。所以必须在这三个方面进行衡量后才能决定是否采用测试自动化技术。根据笔者的经验，建议在如下几种类型的项目中不实施自动化测试：

　　● 周期很短的项目。在周期非常短的项目中，往往只需要1个初级测试人员花2周进行测试，在实施测试自动化时却需要1个高级测试人员花3周进行脚本开发，而且还不涵盖测试脚本后期的维护。

　　● 定制性项目。在此类测试项目中，业界往往在测试自动化方面积累很少。

　　● 易用性测试项目。往往此类测试与人类感观有关，比如界面的美观、声音的体验等等。

　　● 业务非常复杂的测试项目。此种类型的测试自动化几乎就等于测试人员同时开发了一套同样的程序去和开发的程序进行测试对比，此时测试时间投入远远大于手工测试时间。

　　● 涉及到物理交涉的项目。比如说银行的刷卡测试等等。

　　任何一个技术都有它的局限性，就像我们不能拿着剪刀去劈柴，拿着斧头去裁减布料一样，测试自动化适合于周期长、需要经常地回归测试，有一定资金投入和测试人员投入的项目，比如：产品的研发测试等等。

　　2、测试脚本通用性差

　　在软件行业中流行这样的一句话“惟一保持不变的就是变化”，软件开发过程的不断地变化导致了项目中需要不断地进行回归测试，此时正是体现自动化测试的优势所在，如果测试脚本不能做到一定的通用性这将很难适应软件的变化，比如说上面的脚本，已经固化的测试执行流程，固化了所有的测试数据，如果哪天google查询时改用不是点击按钮进行查询了，那这个脚本就得重新修改。此时一旦软件出现任何变更将导致测试脚本的修改或者重写，这将直接导致测试时间、测试人力资源的成倍的投入，从而很大幅度地降低了测试效率。

　　3、测试脚本维护性差

　　测试维护性往往包含两个方面：测试数据的维护以及测试流程的维护。在后面我们将探讨这两个方面，在测试后期测试自动化方面往往大量时间都放在测试维护上，如果在测试脚本中没有很好涵盖这方面的类型也将同时导致测试的失效。比如说，测试数据框架设计上如果存在过多的固化成分，将导致脚本无法正确执行。