自动化测试与DevOps以及持续集成的关系。



自动化测试与DevOps以及持续集成的关系。            

最近参加了一个公司内部关于DevOps的培训。简单了解了什么是DevOps以及自动化测试在DevOps这种新的开发模式中的重要性。简单来说DevOps提倡的是加强开发团队与运维团队之间的合作，从而加快产品开发周期以及上线频率。快速的产品发布导致的必然结果就是加强自动化测试的覆盖率，因为传统的手动测试很难跟上高速产品发布的脚步。但是与此同时，频繁的发布产品也会导致自动化测试的开发成本加大。在没有以自动化测试为开发驱动的项目当中，任何的产品组件的升级都可能导致寄存的自动化脚本失效。这就导致自动化测试的开发人员需要不停地维护原有的测试脚本，从而延长自动化测试项目的生命周期。而维护成本的不断增加是当今自导致自动化项目失败的一个主要原因。另一方面，在传统的手动测试无法满足高速产品更新的同时，自动化测试是否就一定能满足这一需求？我们知道自动化测试也是一种开发，如果开发的自动化测试脚本所对应的测试用例只需要检测一次，而测试脚本的开发（或者更新）时间要远大于手动测试时，自动化测试就没有真正的提高测试效率。自动化测试的ROI也必然走向负面。如何在开发自动化测试的同时减少维护成本甚至开发成本，必然是自动化测试人员不可回避的一个话题。

相对于产品开发，自动化测试的开发模式以及框架都相对较少，毕竟自动化测试的起步要远远晚于产品开发。简单谈一下我所知道的自动化测试项目的模式：

1.现有的自动化测试项目往往是借助自动化测试工具来录制回放测试脚本，再加上大量的人力来执行。这样做所带来的最大弊端就是当产品升级时，原有通过工具录制的自动化脚本重用率极低，自动化测试人员不得不重新进行一轮新的脚本录制。一个简单的UI升级都可能给这样的自动化项目带来毁灭性的打击。

2.根据SA提供的产品设计，由自动化测试人员自主开发自动化测试脚本。相对于上一种模式，这种由具有开发能力的自动化测试人员来编写测试代码的模式明显要高级很多。有经验的自动化测试人员往往会基于项目来开发一些共用库，从而大大提高开发效率。在产品更新的时候也可以通过简单的修改外围代码来维护自动化脚本。

在产品更新发布频率低于两周一次的时候，上述的第二种模式已经基本可以满足用户的需求。但是在当今的业界里，某些宫色的产品的更新发布频率要远远高于此，有时甚至是以分钟为单位。在如此快速的频率下，在保证产品“质”的同时，必然会降低产品的“量”。也就是说每次更新的产品原始代码会相对减少，产品功能变化不大（改变产品核心功能的情况除外）。如果可以将自动化测试脚本与产品本身建立起关联关系，从而使自动化脚本在产品更新时自动更新，那必然会再次大大降低自动化项目的维护成本。

想要达到这一目的，讲自动化测试与持续集成紧密联系在一起是一个必然的前提。这里的持续集成，指的不仅仅是将自动化测试的代码放入持续集成工具，而是将产品代码，测试代码，以及产品模块与测试用例的对应关系全部结合起来并作为可持续性集成的一种新的模式。自动化测试人员不仅需要得到产品功能的规定，还需要得到开发部门的整套开发文档（API, swagger等等）。让自动化脚本先可以“读”懂产品的源代码，然后将自动化测试脚本与产品代码中的业务逻辑链接起来。