本文讲的是DevOps之自动化测试，DevOps概念从2009年提出已有近8个年头，每个人对DevOps的理解可能都不完全一样，下面是普元对DevOps的理解和定义。
我们认为DevOps不仅需要打通开发运维之间的部门墙，更多的需要从应用的全生命周期考虑，实现全生命周期的工具全链路打通与自动化、跨团队的线上协作能力；
DevOps也不能简单等同于一组自动化工具的运用，要实施DevOps需要考虑敏捷、持续、协作、系统性、自动化五个维度；
第一部分：DevOps不可或缺的测试自动化
从上面的DevOps实践模型中可以看到，其实很多东西大家都不陌生，或者一直都在践行，比如，持续集成（CI）、持续交付（CD），还有多年来提的很多但不易落地的持续测试（CT）；
如果没有持续测试，也就不能对持续集成进行及时验证，自然就无法做到有效的持续交付。作为持续测试必需的能力，测试自动化自然不可或缺，但它也不仅仅只是工具的运用，还需要过程、方法等多方面的支撑。
第二部分：自动化测试过程与方法
首先阐述一下我们的测试理念，同时也是DevOps实践模型中很重要的三点：测试一切、测试驱动开发、测试自动化；
1）测试一切
文档、配置、环境、发布包，一切皆代码，这个很好理解，我不再赘述；
2）测试驱动开发
测试提前，敏捷协作，测试用例同步开发；
3）测试自动化
多种测试技术能力、组件化开发、统一管理，不间断测试执行；
为了实现测试驱动开发、测试自动化，我们认为需要以下四个要素：
1）敏捷协作的过程
2）测试设计方法
3）全栈测试团队
4）自动化测试服务
普元多年来在产品研发过程中，一直践行敏捷协作的RDT过程，在新一代云平台项目中，我们分为若干RDT小团队，每个团队负责一个或多个领域系统，以实现不同的用户场景；在每个RDT小团队中，采用需求、开发、测试协同并行工作模式；
随着产品需要在公有云上部署运维，我们做了一些改进，变成了RDT+Ops过程，运维组参与分析用户场景、需求设计测试评审、反馈运维遇到的问题，而且，运维组自身也作为RDT团队直接负责统一监控中心的需求定义和设计开发；
那么为什么在敏捷协作的过程中，就能将测试尽量提前呢？
从上面过程中我们可以看到，在计划阶段，每个RDT团队对用户场景都有了统一认识，那么在接下来的每个迭代开发中，定义需求规格、设计概念模型/原型界面/API定义/数据模型的同时，测试可以并行进行测试对象分析、测试点分析、测试数据和测试组件设计，并且强调RDT的相互评审；
基于这些成果，开发进行编码的同时，测试就可以并行进行测试用例的开发，并且测试用例开始不间断的执行，自动化测试相比传统开发过程大大提前，通过测试尽量提前达到测试驱动开发的目标；
自动化测试毕竟不同于手工用例，我们从四个方面定义了自动化测试的设计原则与方法：
1）易管理性
统一规划、统一版本控制的规范要求；
2）易实现性
采用分层设计，测试基础服务层、测试能力支撑层、测试组件层、测试用例层，支持多种技术的测试能力，测试组件复用，用例专注业务逻辑；
3）易维护性
组件与用例分离、区分变化与不变、测试用例原则上不互相依赖、测试数据容易维护；
4）易定位性
测试用例独立、低复杂度、要求断言信息的准确性；
自动化测试分层设计对测试团队提出了更高的要求，也就是要求我们必须成为全栈测试团队，具备各层的能力：
测试架构师负责总体设计、测试基础服务层，提供统一管理、统一调度的能力；
领域技术专家负责测试能力支撑层，对各领域测试技术进行分析和选型，提供测试服务能力以及基础的技术组件；
测试专家负责指导测试开发工程师进行测试方案设计、测试组件和用例的实现；
除了过程、方法、团队，自动化测试的落地最终还是需要依赖各种自动化测试服务的实现，我们也一直在做这方面的努力，并形成了产品化的自动化测试服务能力；
除测试基础服务以外，我们没有选择从零开始，而是评估并引入好的开源技术和公司内部其他产品的可用技术，按照我们的自动化测试设计原则和方法进行相应的改造；
比如WebUI测试服务，我们选用了Selenium，为了适应我们的用例开发规范和易用性，我们对其接口进行了重新封装，形成我们的WebUI基础组件库；
比如CI工具Jenkins1.x，由于我们产品多、每个产品版本也多，使用时间久了之后其任务管理界面简直就是灾难，任务的调用关系也非常不直观、难以维护，所以我们扩展实现了持续集成项目管理、图形化的持续集成任务流管理，以适应我们的需要；
另外，像用例开发/调试，除了支持Java以外，我们还复用了普元的逻辑流图形化开发能力、组件库可视化管理能力，用例开发效率更高、更易维护；
综上所述，有了适合自己的过程、方法、团队、工具的保障，自动化测试的实践自然能够水到渠成；
第三部分：云平台自动化测试实践
新一代云平台采用了自己生产自己的方式，使用V0.1生产线进行V0.2的开发和交付，于是我们也将自动化测试服务搬到了平台上，作为微服务进行部署；
自动化测试用例同样作为微服务进行开发，和其他领域系统一样进行管理和构建部署；
我们目前的持续集成、持续测试过程大致如上图所示，主要分为以下步骤：
1）开发/测试人员提交代码后， 手工触发或者系统定时触发持续集成任务流；
2）持续集成任务流会调用SRM资源管理领域系统的服务能力，进行产品的构建部署，其中包括编译、配置、打包、部署，这个过程中也包括了单元测试的执行；
3）继续调用SRM的服务能力，进行自动化测试代码的构建部署；
4）调用测试基础服务，加载测试用例调度执行，生成报告进行反馈；
新一代云平台项目中实践的执行效果
使用在Jenkins上扩展的可视化的任务流编排，进行持续集成和持续测试的流程定义，支持子任务流，避免了Jenkins的任务调用关系不直观、难以维护的问题，这里使用的就是之前提到的自动化测试服务中的持续集成任务编排，后续将会根据新一代云平台的服务编排设计进行重新规划；
可视化测试管理控制台，可以直观的进行用例展示和统计、指定用例执行、查看测试报告、参数配置等等；
自动化测试执行报告可以了解每次执行的情况，查看错误信息，及时响应；
自动化测试执行趋势报告，可以了解一段时间内版本质量稳定趋势，再结合其他过程数据反馈，QA就能够进行质量的度量，比如单元测试覆盖率、自动化测试需求/功能覆盖率、测试用例密度、缺陷密度等等；
第四部分：总结
最后总结回顾一下，我们的测试理念，也是DevOps实践模型中很重要的三点：测试一切、测试驱动开发、测试自动化，以及为了实现这三点所需的四个要素：敏捷协作的过程、测试设计方法、全栈测试团队、自动化测试服务；
