标签：没有 ppt 全球 ase 选择 盛大 service 持续集成 反思
本文内容节选自第六届全球软件案例研究峰会，时任美团点评酒旅质量团队工具链负责人王鹏老师分享的《微服务架构下的自动化测试和持续集成工具链实践》实录，重点分享：微服务架构下解决自动化测试、开发联调、测试环境、持续集成方面遇到的问题及解决方案。（PPT+文稿）。
王鹏老师时任美团点评酒旅质量团队工具链负责人，在软件开发，自动化测试，研发流程改进，持续集成/交付基础设施，敏捷开发等领域有近10年的开发实施和推广经验。
编者按：2017年11月9-12日，第六届全球软件案例研究峰会在北京国家会议中心盛大开幕，现场解读2017年「壹佰案例榜单」。时任美团点评酒旅质量团队工具链负责人王鹏老师分享的《微服务架构下的自动化测试和持续集成工具链实践》实录的案例分享。
【内容简介】微服务化为自动化测试和持续集成工具链等基础设施带来了新难题，本案例通过在酒旅研发测试团队中实施持续集成，敏捷开发工具链和自动化测试的实践，分享工具团队如何实现高效的研发质量保证体系保驾护航，提供质量和效率方面的工具支持。希望能为“急速”增长中的研发团队在提升开发测试质量和工程效率方面提供一些启发和参考。
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，有团队的支持，另外做好前置扫描，禁止有问题的代码上线。只有解决问题才可以上线。
以上内容来自王鹏老师的分享。
标签：没有 ppt 全球 ase 选择 盛大 service 持续集成 反思
原文地址：https://www.cnblogs.com/msup/p/9436634.html
