架构出来之后，就是系统功能的自动化脚本编写，因为项目的原因，当时的自动测试团队已经解散，我面临的是只有一个人的自动测试团队，怎样将上千个测试案例自动化，成了我头疼的问题。至今仍然很感激我的老板和项目经理，调配给我足够的资源，真正的打开了项目的软件测试自动化之门。团队中的其它成员，都是没有自动化测试经验的同事，给他们足够的培训和技术支持很关键。他们所负责的功能，我都会写一个例子，他们可以参照例子按照我们自动测试架构编写规范写脚本，遇到技术问题或业务问题，我会协助解决，在整体的架构上，我会全局把握。那一段时间，特别忙，架构的扩展、业务的熟悉、问题的跟踪解决，有时候同时有好几个问题在等着我解决，但就是这么一段忙碌的日子，从对系统基本业务的理解到系统业务的全面理解，从原来的只有十几个测试案例的自动化测试脚本到上千个自动化测试脚本的实现。很感激我的这些同事，现在他们大部分都回到了他们原来的角色，我也将要开始担任新的角色，但那一段一起工作的日子，我会记在心里。也是因为大家一起的努力，老板原要求实现web页面自动测试或系统30%功能的自动化测试，我们最终实现的是几乎所有接口所有检查点的自动化测试，接近80%的测试覆盖率。

　　自动化脚本的编写，当然要注意全局的把握和review，不同的人会有不同的风格，稍不注意就会问题多多。

　　脚本编写完成之后，自然是使用。脚本在前期的使用是功能测试和数据准备，在项目稳定之后的最大价值就是回归测试。我将脚本分为了三个级别：基本流程测试脚本，用于每次出新built安装后做smoke test；关键功能测试脚本，每次出新built后对所有重要功能进行回归测试，确保改动不会对原有功能的造成影响；全面回归测试脚本，一般每周跑三次或者是系统经过比较大的修改后作回归测试。自动测试脚本在回归测试中发挥了出色的作用，特别是系统在上线前夕，为了适应客户的需求，功能不断修改，对于原有的功能，自然不可能都手工测试，脚本在这个时候的意义特别大。

　　同事或朋友经常问我，自动化测试应该在什么时候介入？如果系统的功能需求和接口定义都很清晰，系统开发完成并且基本功能手工测试成功后，就可以开始编写自动化测试脚本了，一方面可以利用脚本做功能测试和bug验证，另一方面也可以用来做回归测试。但如果系统的变化比较大或接口的定义不够清晰，最好还是先手工测试，待功能比较稳定之后再写脚本，因为如果功能的变化太大，维护脚本的付出可能远远小于脚本可以带来的效益。

　　当然，并不是所有的系统都适合做自动测试，如果只是一些短期的项目，或者是脚本不会被重复利用，就没有做自动化测试的必要，成本会远远大于收益，也就没有做自动化测试的必要了。反之，如果是产品的测试或长期的项目或是自动化测试脚本会被反复使用，自动化测试就显得很有必要了，做完一套脚本之后就会反复被使用，当然可以节省很多成本，也可以提供测试的效率。

　　这个架构，自己付出了很多心思，付出所得到的回报找到了自动测试的感觉，底气不足变成了胸有成竹。项目组的其它团队也看到了自动化测试的好处并打算参考我们的架构实现自动化测试，再做设计，扬长避短、一气呵成。

　　敲完这些文字，也就意味着我的自动化测试工作暂告一段落，下周开始，因为项目的需要，将会开始我的另一个全新的角色。这个架构，绝对不是完美的，肯定还存在可以改进的空间，希望接替我自动化测试工作的同事，也能像绣花一样用心去完善它。