4. 结合研发过程的应用
上面介绍了一些自动化的实施过程，这边再介绍下实施之后在项目研发过程中的应用。
目前在项目中，主要有以下几方面的应用。
（1）提测后的自动化回归验收
下图是项目的一条持续集成pipeline。在开发提测后，我会自动化地完成以下事情：
●编译代码
●将服务部署到各个机器，并完成Jacocod Agent的部署
●执行静态代码检查
●执行接口测试
●完成覆盖率统计
●将覆盖率统计数据接入到CR平台
当自动化用例全部执行通过时，说明系统的核心功能回归没有问题，然后开始版本的细粒度功能的测试。
（2）Bug修复后的回归验收
在测试过程中，开发肯定会经常修复bug重新提交代码，每次有代码重新提交时，我都可以一键完成部署、测试、覆盖率统计。
（3）上线后的回归验证
目前，项目的上线验证已经完全由自动化验证来替代。
（4）作为开发冒烟的一部分（未完成）
目前已经跟开发达成一致，开发非常欢迎将自动化用例接入到开发环境，用于他们每次变更时的环境正确性验证，可以尽早帮助他们发现研发过程中出现的问题。并且在提测前，只有100%通过自动化测试才可以进行提测。
（5）线上监控
目前各个线上集群，都部署了自动化测试用例，这部分用例会每隔4小时执行一次。用于确保线上环境的稳定性。从效果上来看，线上监控的成效是非常明显的，提前发现了很多集群的延迟问题，环境问题等，让开发可以及时地收到报警，了解线上集群的情况。
（6）关于持续集成
可能有人会发现，上述的执行过程其实不是真正意义上的持续集成，真正意义上的持续集成应该是：每次开发提交代码，自动触发构建。
必须要承认的是，确实是如此。但是不管怎么样，我觉得可以先从优化测试工作量的角度慢慢去推开整个流程，其实业界目前也并没有确切的定论说只有持续集成才是最佳的实践。相反，一味地持续集成可能会增加我们的维护成本。只要我们能切实提升自己的工作效率，达到目的就可以了。
5. 成效
当自动化做的比较完善后，你真的会发现：生活原来可以变得如此简单美好。
自动编译部署：测试过程中开发修复bug提交代码是非常频繁的，每次的手动编译部署可能都会耗费十几分钟，并且测试人员的关注点还不能离开。
自动打包发布：从这个版本开始，所有集群的上线都会统一使用QA发布的包。这样减少了以前每次上线时，开发运维人员要花费大量的时间逐一去拉取各个集群的代码再进行编译、部署。一键的打包发布，可以在上线前就提前准备好各个集群的上线包，开发只需调用部署脚本去获取这些包，然后替换就可以完成上线。此外，自动打包发布的方式极大减少了运维上线时漏操作的风险。
自动化回归测试：以前一次回归测试，需要QA持续地投入超过30分钟。现在通过一键执行，程序会自动地执行，时间控制在5分钟以内。且QA可以将注意力放到其它事情上。
自动化完成稳定性测试结果的校验：从前执行完稳定性测试，需要对着数据库的一大片数据进行人肉地校验。会耗费一个下午大半天的时间，甚至还是有遗漏。通过脚本自动校验，1分钟内就可以出结果报告。
这里再提一下UI自动化。很多人会对UI自动化有看法，觉得投入产出比不明显、维护成本高。我认为UI自动化跟接口自动化其实没有区别，都是功能回归的一种形式而已，选择哪种自动化的类型应该取决于项目的实际情况需要。另外，UI自动化的维护成本目前一个季度做下来看，真的没有比接口自动化要高，关键还在于自动化的设计上是不是做的易于维护。
6. 展望
可以看到以上的自动化都是基于环境的稳定可用为前提的。之所以没有独立分配一套环境用于自动化测试，也是因为环境维护的成本较高。但是，基于测试人员的增加，测试类型的丰富（异常、性能），在一套环境上执行所有测试显然会出现相互影响的问题。因此，如果能将测试环境搭建docker化，通过维护docker镜像的方式，自动化地使用docker镜像快捷地部署一套新的完整测试环境可以极大地提高我们的测试效率。
