返回 登录
0

DEVOPS之自动化测试

由普元&CSDN联合主办的PWorld 2016大会即将盛大召开!PWorld大会自2014年已经成功召开两届,共吸引近4000名CTO、CIO、架构师、技术经理、开发工程师等技术相关人员参与。2016年将首次在北、上、广三地共同召开,每场30位架构师将分别进行13个主题交流,更多开放,更多分享!
PWorld 2016面向企业软件开发领域,源于实践,旨在展示技术与架构的创新如何加速企业数字化变革。值得一提的是,本届PWorld大会将创新打造开放流动场地,不再被主题演讲束缚你的行动。
报名链接:http://pworld.csdn.net/m/topic/pworld/index
转载本文需注明出处:EAII企业架构创新研究院,违者必究。如需加入微信群参与微课堂、架构设计与讨论直播请直接回复公众号:“EAII企业架构创新研究院”。(微信号:eaworld)

图片描述

大家好,我是冀博,目前负责新一代数字化企业云平台 “The Platform” 的测试工作,很荣幸有这次机会和大家分享交流,今天向各位分享的主题是《DevOps之自动化测试》,主要包括以下几部分内容:

1.DevOps不可或缺的测试自动化

2.自动化测试过程与方法

3.云平台自动化测试实践

4.总结

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

图片描述

以上就是本次分享的全部内容,感谢大家。

关于作者

冀博

现任普元新一代产品部测试经理,多年来在普元一直从事测试工作,主要负责公司产品测试、客户项目测试咨询及实施,业余时间喜欢打羽毛球;
图片描述

关于EAII

EAII(Enterprise Architecture Innovation Institute)企业架构创新研究院,致力于软件架构创新与实践,加速企业数字化转型。

eaworld项目(微信号:eaworld,长按二维码关注)

eaworld是EAII的官方微信账号。

评论