脚本编写完成之后，自然是使用。脚本在前期的使用是功能测试和数据准备，在项目稳定之后的最大价值就是回归测试。我将脚本分为了三个级别：基本流程测试脚本，用于每次出新built安装后做smoke test；关键功能测试脚本，每次出新built后对所有重要功能进行回归测试，确保改动不会对原有功能的造成影响；全面回归测试脚本，一般每周跑三次或者是系统经过比较大的修改后作回归测试。自动测试脚本在回归测试中发挥了出色的作用，特别是系统在上线前夕，为了适应客户的需求，功能不断修改，对于原有的功能，自然不可能都手工测试，脚本在这个时候的意义特别大。
同事或朋友经常问我，自动化测试应该在什么时候介入？如果系统的功能需求和接口定义都很清晰，系统开发完成并且基本功能手工测试成功后，就可以开始编写自动化测试脚本了，一方面可以利用脚本做功能测试和bug验证，另一方面也可以用来做回归测试。但如果系统的变化比较大或接口的定义不够清晰，最好还是先手工测试，待功能比较稳定之后再写脚本，因为如果功能的变化太大，维护脚本的付出可能远远小于脚本可以带来的效益。
当然，并不是所有的系统都适合做自动测试，如果只是一些短期的项目，或者是脚本不会被重复利用，就没有做自动化测试的必要，成本会远远大于收益，也就没有做自动化测试的必要了。反之，如果是产品的测试或长期的项目或是自动化测试脚本会被反复使用，自动化测试就显得很有必要了，做完一套脚本之后就会反复被使用，当然可以节省很多成本，也可以提供测试的效率。
这个架构，自己付出了很多心思，付出所得到的回报找到了自动测试的感觉，底气不足变成了胸有成竹。项目组的其它团队也看到了自动化测试的好处并打算参考我们的架构实现自动化测试，再做设计，扬长避短、一气呵成。
敲完这些文字，也就意味着我的自动化测试工作暂告一段落，下周开始，因为项目的需要，将会开始我的另一个全新的角色。这个架构，绝对不是完美的，肯定还存在可以改进的空间，希望接替我自动化测试工作的同事，也能像绣花一样用心去完善它。
文章来源于领测软件测试网 https://www.ltesting.net/
