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

1元 10元 50元





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



  求知 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
     
   
 订阅
  捐助
美团点评:打造微服务自动化测试与持续集成工具链实践
 
515 次浏览     评价:  
 2018-9-17
 

 

编辑推荐:

本文来自于网络,文章主要介绍了微服务架构下解决自动化测试、开发联调、测试环境、持续集成方面遇到的问题及解决方案等。

1 从Monolithic到Microservices

在2008年时,市场软件形式大多为CS架构。当时存在的问题在于,开发耗时1-2年且内部的解耦度低;而优点在于对测试团队十分友好。

后来软件形式又经历了从SOA分布式架构到现在的微服务架构。

对于微服务架构来说,它并非像开发者们想象中的井井有条。下图是一个微服务架构化的典型示例,从绿色的线可以看出服务之间的关系错综复杂。

由于微服务架构把系统功能细分,团队会在各个方面都碰到了挑战。那么微服务架构下工程质量面对的问题,该如何解决?接下来我们将会从四个方面讲述。

2 问题的发现与解决

自动化测试

1.存在的问题

服务数量多,以HTTP和RPC接口为主:链路长依赖多。

服务交付周期变短:从以前的大模块开发,花费几个月时间交付。到现在的一到两周交付上线,但自动化测试开发速度跟不上交付的速度。

框架使用不规范,多种方式并存。

自动化测试代码的扩展性和可维护性不够

2.解决方案

通过提供相应的自动化测试框架工具,可以实现标准化、规范化、快速交付测试代码。具体操作如下。

统一的框架archetype自动生成整个项目框架。

数据、配置、代码分离进行数据的驱动。

单接口+场景化,确保做到无参数传递。

把一些常用的Lib库打包,在POM文件里面引用。

HTTP和Thrift接口封装,提高代码的复用率。

API-Lib

下图是自动化测试框架图示。

在数据校验时,自动化设计框架会自顶层生成测试项目结构,测试环境动态配置。

在测试数据,会由数据驱动来完成,只需要维护里面的数据即可,无需改变代码;

在Testcase层,引入了Json Schema、Json Path做数据校验;

把HTPP和Thrift做了相应的封装,方便调用;

最底层使用了Thrift,封装相应的Lib库。

自动化示例

如下图,左边是之前的Test代码,右边是通过统一测试框架自动生成后的代码。

分为data和内部环境数据,子文件里是单接口和多场景,在内可以复用API接口。

如何做到无参数

对于代码而言,多一个参数含义,整体复杂度和冗余度都会提升。

团队从框架引用,生成框架,到case的编写,生成Thrift写法;在数据维护上自动生成数据格式。做到了测试框架+测试代码+测试数据,实现了自动化。

自动化之后可以做到相应的专项代码测试,大量的数据变化和验证会在文件里直接做相应的要求。

开发联调

1.存在的问题

多个服务同时开发, 联调耗时日益增长:从内部看联调的占比大概在20%-50%之间。这种情况主要有两方面。一是,联调自测环境不稳定,服务多。另一方面是,多人开发,从一开始的简单接口约定到中间PM需求改变,导致接口互相之间数据格式上有变化,双方难做同步。

联调测试环境不稳定:需要找合作方调试,浪费时间。

自测时需要部署和维护多个依赖方服务。

2.解决方案

开发未动,Mock先行,随时联调。

在开发开始时,多方定义好相应的接口,接口文件,数据格式和规则。通过Mock工具生成服务,发布到联调测试环境中。

使用Moka工具自动生成Mock Server,指定相应的Thrift定义,根据相应规则,生成Mock Server,在内配置联调服务,指向Mock Server,再配置相应的数据规则和匹配规则。

通过Moka能够做到开发刚开始时就可以提供相应的联调服务,流程基本如下。

一键生成独立Mock优于平台的点在于,适用性好。也支持Thrift的注解方式使用和Mock数据管理。

测试环境

1.存在的问题

由于服务数量增多,链路变长,调用依赖增多,整个环境的搭建会十分吃力。

多人共用一套环境,互相影响,容易影响测试结果。

稳定性差。

2.解决方案

解决的问题主要集中在,资源的申请,申请后的环境隔离与数据隔离,测试环境的维护,恢复测试环境等。

环境搭建可以从三个方面考虑,环境隔离、按需创建、描述依赖。

美团团队选择了通过HULK+泳道提供环境隔离,Cargo按需创建测试环境。骨干+泳道复制全新的环境,随后打通发布系统和代码仓库,发布大的测试环境,做稳定性与可控性的监控和三个9稳定性测试环境。

环境监控:

原则:泳道可以调骨干,骨干不可调泳道。

环境建好后,要保证随时可以使用。在稳定性监控下,只要提供服务,列表就可以进行监控,定时部署最新的分值代码。

整个环境都处于监控之中,每半个小时发送一次环境整体概况。如果某个服务稳定性降低,团队会直接@负责人查看原因。

持续集成

1.存在的问题

一次提测服务增多,提测了多个仓库,使得CI Job经历了爆炸性增长。

提测质量无法得到保证,测试不过关;缺乏前置测试,无效沟通太多。

2.解决方案

微服务环境中两个关键点:Merge到主分支前,提测前自动检测。

关键节点1:

代码提交和Merge到主分支,拉分支会自动创建CI Job,Push代码触发扫描,PR Merge到主分支触发扫描,PR更新触发再次扫描,通过允许Merge到主分支。

这样可以做到不把问题带到线上分支,并且前置的方式约束RD在上线前就解决问题。

关键节点2:

提测前还要再次自动检测。当需求提测的时候,根据提供的发布信息自动创建对应的Pipeline,点击提测之后会自动出发Pipeline的执行,自动部署,并做冒烟测试。Pipeline会明确的显示冒烟测试结果是什么,问题在哪里。

大大减少了无效的沟通。

工具链流程:

通过后台的CI服务,工具链从RD拉分支开始,拉分支会创建一个Pipeline Job,做Push代码的时候同时做Sonar扫描,由大象通知结果。

在工具链上共提供四个服务:

单测覆盖率CI服务。在Pom无侵入修改引入Jar包;一键接入单测覆盖率服务。

静态代码扫描CI服务,Sonar服务器进行线上监测。

自动部署,做冒烟测试。

内存扫描分析CI服务。Valgrind提供了Pipeline插件 开发,通过修改了插件,可以解决了许多相关的问题。在Pipeline上使用,可以一步分析,自动推送。

美团点评:打造微服务自动化测试与持续集成工具链实践

3 经验总结与反思

启示

理解用户需求的完整场景:源头,原因和原理。

坚持工具设计的主线和愿景,短期服从长期。

只有在用户需要时才出现。

从工具和服务做起,不要一开始就做平台。

跨团队合作,互补长短。

总结

我们在自动化测试方面,开发了规范化、标准化的LIPS自动化测试框架;开发联调方面,开发了Moka;Cargo来创建测试环境,做三个9的稳定性和可用性服务的测试环境;在持续集成方面,使用Pipeline,提供相应的CI服务且不做任何配置;PUSH代码会自动获取相应的信息,帮助大家做持续集成。

Q&A

Q:手工测试和自动化测试占比是怎么样的?

A:目前来讲,在工具应用之前,手工测试占比非常高,应该在60%以上,自动化测试应用的很不好,主要原因是整个标准化程度不够,维护起来很麻烦。根本的原因在于没有一个很好的框架工具支持它。

Q:Sonar扫描历史债怎么处理呢?

A:Sonar扫描每个团队都积累了很多关于怎样解决这个问题的经验。我们的解决方法一方面是依靠团队技术leader,有团队的支持,另外做好前置扫描,禁止有问题的代码上线。只有解决问题才可以上线。

   
515 次浏览  评价: 差  订阅 捐助
相关文章

性能测试十问:测试经理篇
web前端性能优化进阶路
性能测试综述
VS2010中自动化测试—Web性能测试
相关文档

性能测试
性能测试执行之测试脚本录制
性能测试进阶1-流程篇
性能测试进阶2-方案篇
相关课程

性能测试方法与技术
使用LoadRunner进行性能测试
Android应用的性能测试
基于Android的单元、性能测试
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号