您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
DevOps之自动化测试
 
  8561  次浏览      16
 2019-6-26 
 
编辑推荐:
本文来自aliyun,本文主要介绍了自动化测试过程与方法以及云平台自动化测试的实践等相关内容。

本文讲的是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实践模型中很重要的三点:测试一切、测试驱动开发、测试自动化,以及为了实现这三点所需的四个要素:敏捷协作的过程、测试设计方法、全栈测试团队、自动化测试服务;

 
   
8561 次浏览       16
相关文章

微服务测试之单元测试
一篇图文带你了解白盒测试用例设计方法
全面的质量保障体系之回归测试策略
人工智能自动化测试探索
相关文档

自动化接口测试实践之路
jenkins持续集成测试
性能测试诊断分析与优化
性能测试实例
相关课程

持续集成测试最佳实践
自动化测试体系建设与最佳实践
测试架构的构建与应用实践
DevOps时代的测试技术与最佳实践