近段时间，一部分工作在进行自动化测试开发，一部分工作在于资源整合，一部分工作在自动化测试推广，而感触最深的就是推广了，自动化测试难点一在于应用，难点二则在于应用推广，再好的技术底蕴，再好的形式，没有一个好的推广过程，则也是不行的，根据这段时间和过去的一些教训，在此总结一下，希望不对的大家能指出。
一、现象分析
做过自动化测试推广的人员应该都会遇到这么几个现象：刚开始推广自动化测试时，测试人员都很好奇，都会积极的参与配合，但是测试人员的热情在一段时间之后会被自动化测试人员的不断变动性所打败，所以，作为一个测试人员，你应该把测试人员的信任值和热情度牢牢把握。
1、自动化测试人员总是不断的更新框架，从而导致测试脚本不断变更，造成测试人员不断去定位测试脚本和维护测试脚本，造成测试人员对自动化测试信任度降低。
2、测试脚本在还未规模化应用的时候，则去强行的开发大型的测试平台，这样带来的问题就是后期的变动性造成了平台架构的变动，从而导致测试脚本和测试平台的兼容性差。
3、测试开发人员犯的一个很大的错误就是不断推出一系列不成熟的工具，即只想着去开发一个工具，而把测试人员还是当成了“测试人员”，而不是用户，从而造成了测试人员对测试工具的使用的畏惧性。
4、不够双赢；很多时候，测试人员做的工作往往被忽略，例如：测试开发人员开发的脚本数量是一个绩效，造成对开发出的脚本质量往往不负责任，但是测试人员对别人开发的脚本和环境的维护则没法进行量化统计，这样测试人员还不如手工测试来的绩效高，这样，则造成了测试人员对自动化测试的积极性不高。
二、对现象的思考和实践分析
1、脚本的稳定性应该是放在第一位的，不管刚开始的设计和想法多么宏大，你也必须克制自己，不管线性脚本，不管封装也好，从最基础开始，让测试人员首先感觉到脚本的运行顺畅性，而不是频繁的维护。这也是一个前期自动化测试的一个先锋部对，不求一下攻克，只求快速获得情报和前线支持，为后面的大军进发做准备。
2、决定开发了一个框架的话，那么就要先考虑到可拓展架构，或者快速做一个原型，采取功能迭代增加的方式，一定记住的时，能抽像到底层的一定要抽象，千万不要把特性的东西写死在底层，而是要分离。不然你会发现：前期写死一个变量，也许会让你在后期的某一个拓展中造成你的所有脚本瘫痪。
3、测试平台、持续集成平台之类的都是架子，个人觉得，要保证的是：测试平台和测试脚本是分开的，即测试脚本可以脱离平台单独执行，而不是脚本需要依赖于平台执行，因为有时候移植工作其实是一个很大的工作量，你不能保证你的平台永远没有变化，平台好变，大量的脚本不好变。
4、预期开发一堆的全面化的复杂的测试工具，还不如在一个点上把一个工具做精了，让测试人员真正觉得好用，那么你的自动化测试才能慢慢被他们接受，从而配合你的工作。其实这种策略很常见：很多平台化的公司做大前都是从一个点开始，把一个点做精了，这样就可以以此为入口，从而建立起一个产品体系。少做即是多做，这真是真理啊。
5、分享一个我推广自动化测试的例子：在部门内部，以一个自动化测试活动为一个项目，测试人员做为项目负责人，我则可以作为项目协助人参与。例如：一个关键字测试驱动用例项目，测试人员来设计测试驱动设计文档，包括划分的关键字点、环境、参数等。由另外的手工测试执行人员来测试执行过程中，组装关键字，最终形成测试脚本用例。关键字、文档以及脚本便作为整个项目的输出，以项目为活动颗粒的好处是职责容易细分，进度容易把握，并且最重要的是能够让测试人员主动性更强。所以，在推广过程中，要采用各种策略让测试人员的能力提升和职业发展相结合，让他们的成果突出，这样你给他负责，他才对你负责。
总结：其实推广过程中，最大的经验就是一定要站在不同的角度上思考问题；学会以辅助的角度去做人做事；学会珍惜别人的时间和劳动成果，学会将别人的成果最大化，学会双赢；有时候学会自己宁愿多做点，不要告诉比人；也许，这样，你得到的将是你意想不到的。
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/
