最近参加了一个公司内部关于DevOps的培训。简单了解了什么是DevOps以及自动化测试在DevOps这种新的开发模式中的重要性。简单来讲DevOps提倡的是增强开发团队与运维团队之间的合做，从而加快产品开发周期以及上线频率。快速的产品发布致使的必然结果就是增强自动化测试的覆盖率，由于传统的手动测试很难跟上高速产品发布的脚步。可是与此同时，频繁的发布产品也会致使自动化测试的开发成本加大。在没有以自动化测试为开发驱动的项目当中，任何的产品组件的升级均可能致使寄存的自动化脚本失效。这就致使自动化测试的开发人员须要不停地维护原有的测试脚本，从而延长自动化测试项目的生命周期。而维护成本的不断增长是当今自致使自动化项目失败的一个主要缘由。另外一方面，在传统的手动测试没法知足高速产品更新的同时，自动化测试是否就必定能知足这一需求？咱们知道自动化测试也是一种开发，若是开发的自动化测试脚本所对应的测试用例只须要检测一次，而测试脚本的开发（或者更新）时间要远大于手动测试时，自动化测试就没有真正的提升测试效率。自动化测试的ROI也必然走向负面。如何在开发自动化测试的同时减小维护成本甚至开发成本，必然是自动化测试人员不可回避的一个话题。框架
相对于产品开发，自动化测试的开发模式以及框架都相对较少，毕竟自动化测试的起步要远远晚于产品开发。简单谈一下我所知道的自动化测试项目的模式：运维
1.现有的自动化测试项目每每是借助自动化测试工具来录制回放测试脚本，再加上大量的人力来执行。这样作所带来的最大弊端就是当产品升级时，原有经过工具录制的自动化脚本重用率极低，自动化测试人员不得不从新进行一轮新的脚本录制。一个简单的UI升级均可能给这样的自动化项目带来毁灭性的打击。工具
2.根据SA提供的产品设计，由自动化测试人员自主开发自动化测试脚本。相对于上一种模式，这种由具备开发能力的自动化测试人员来编写测试代码的模式明显要高级不少。有经验的自动化测试人员每每会基于项目来开发一些共用库，从而大大提升开发效率。在产品更新的时候也能够经过简单的修改外围代码来维护自动化脚本。测试
在产品更新发布频率低于两周一次的时候，上述的第二种模式已经基本能够知足用户的需求。可是在当今的业界里，某些宫色的产品的更新发布频率要远远高于此，有时甚至是以分钟为单位。在如此快速的频率下，在保证产品“质”的同时，必然会下降产品的“量”。也就是说每次更新的产品原始代码会相对减小，产品功能变化不大（改变产品核心功能的状况除外）。若是能够将自动化测试脚本与产品自己创建起关联关系，从而使自动化脚本在产品更新时自动更新，那必然会再次大大下降自动化项目的维护成本。设计
想要达到这一目的，讲自动化测试与持续集成紧密联系在一块儿是一个必然的前提。这里的持续集成，指的不只仅是将自动化测试的代码放入持续集成工具，而是将产品代码，测试代码，以及产品模块与测试用例的对应关系所有结合起来并做为可持续性集成的一种新的模式。自动化测试人员不只须要获得产品功能的规定，还须要获得开发部门的整套开发文档（API, swagger等等）。让自动化脚本先能够“读”懂产品的源代码，而后将自动化测试脚本与产品代码中的业务逻辑连接起来。
生命周期