八、自动化应该立即见效，见效后应该慎重评估

　　来源：自动化测试推广

　　有时候如果我们对目的不够清晰，不能抓好本质问题解决，就很容易走极端，有人说录制不好，我们就反对录制，有时候我们抓到一个录制工具就以为遇到了神器，孰知后面是一个一个的大坑；而我觉得，录制不是不好，而是如何将它用在合适的地方，录制的好处是无需编程技能即可快速上，但是他的缺点是相对脆弱，一旦UI或者接口变化测试就会受到影响，分散的脚本不可重用且难以维护，而且系统在测试前必须可用（也就意味着无法使用A-TDD方法）。因此这种方法并不适合大型自动化测试。而关键字驱动，将数据与关键字结合来描述如何使用数据执行测试，这种方法是具备数据驱动的优势，同时非编程人员也能建立新类型测试。所有测试由同一个框架来执行，无需不同的驱动脚本。然而初始成本很大，但是可以使用开源方案，因此非常适合大型项目。所以，我们刚开始的时候，选择合适的项目，可以采用脚本录制这种方式，让自动化测试立即见效，小范围推动项目进度，然后，就严格控制，开始设计框架，把握可测性。

　　九、不要指望用自动化测试平台一下子解决所有的问题

　　来源：自动化测试平台建设

　　当年在作自动化测试过程中，遇到瓶颈，就想当然的认为要开发业内所说的自动化测试平台，即先弄出一个线，然后再想办法去线上发展每个点，后来历时几个月，加班加点的，总算基于STAF开发出了一套分布式的自动化测试平台，但是后来用着用着就不了了之了，分析出原因是问题本身和目的都没有明确，单纯的开发出了一个架子，然后再去找衣服强塞进去是不可行的，架子本身是为放衣服服务的，所以平台本身是为让自动化更有序的进行而服务的，之后我们大力发展点，而平台是等点都满足需求后，开始将点串起来，自然而然的形成了一条线，然后再加以修饰，就成为了平台。所以说，不要舍本求末，追求花哨，而要踏踏实实的做好每一个点，以需求为导向，自然而然的才能把架子搭好。

　　在这里也推荐几个用来搭建平台的较好的工具和框架：STAF， Jenkins，selenium grid可以用来做分布式测试执行和测试节点管理，sonar可以用来做质量管理平台，更多的是面向白盒测试分析。Toast也是一款不错的自动化测试平台，我觉得它的理念更多的像项目管理+jenkins。

　　十、将所有的测试资源都版本控制起来

　　来源：自动化测试配置管理

　　这个很重要，在我们的自动化建设过程中，因为我们是多产品线的，每个产品线的有些功能模块是共用的，我们的方法是将每个模块的功能抽象成关键字接口，所有产品线共用接口，只是实现上不一样，而这种方式前期的问题是版本管理的问题，因为一个产品线开发出一个模块后，各个产品线开始互相迁移，导致迁移混乱，还有一个问题是产品功能模块也在不断的更新，不同的产品版本要对应不同的测试脚本，所以后来，加入版本管理，而最终的测试脚本版本用V1.0.0进行跟踪，第一位表示接口版本、第二位表示产品特性，第三位表示当前产品线的脚本维护。

　　版本控制中重要的两个概念就是分支与合并，随着开发的版本控制的不断深入，测试的版本管理也需要跟上，常用的版本控制工具是svn、cvs以及分布式版本控制git，和基于流的版本控制系统Clearcase，个人觉得，前期可以用手工的方式定义好版本，等到开发协作强大到一定程度后，可以采用这些版本控制系统。

　　十一、时刻反省自动化测试过程

　　来源：自动化测试推广

　　自动化测试是一个长期的过程，我们即要低头走路，也要不时抬头看路，也需要不时的休息一下，回顾自己走过的路程，整理之后才可继续向前，所以需要我们每隔一个阶段，就要好好反省自动化测试的开展和推广过程，大家的时间都是很宝贵的，珍惜自己的时间，更要珍惜大家的时间。

　　总结；因为时间仓促和水平有限，有些经验和教训不一定很全面，或者还有朋友在推广或者平时观察到有更好的自动化测试实践经验和教训，希望可以一起总结，总之，个人觉得，学习过程最有效的方式是理论和实践相结合，知行合一，在实践中发现问题，然后去推敲理论，解决问题，最终总结从而变成自己的东西。

版权声明：本文出自 散步的SUN 的51Testing软件测试博客：http://www.51testing.com/?382641

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。