携程微服务架构下的测试浅谈

携程微服务架构下的测试浅谈_第1张图片


一、前言

640

在现在这个互联网时代,多变的市场环境以及日益增长的客户需求,加速了产品的迭代和更新。传统的单体式应用已经因跟不上发展的步伐而逐渐退出历史的舞台,取而代之的是SOA的问世。
SOA的出现使系统架构发生了跳跃式的转变,它提出了面向服务的设计思想。而现今流行的微服务架构,和SOA虽是一脉相承,但不再强调传统SOA架构里的ESB(企业服务总线)。
使用微服务架构可以将系统划分成更细粒度的服务,每个微小服务实现单一业务功能,且可以根据自身特点选择更适用的编程语言和技术。每个微服务可以由不同的团队独立完成开发,互不影响,加速了产品的推出和迭代。
夸张一点说,如果将整个软件系统比作宇宙的话,那每个微服务就好比行星,它可以独立的运行在自己的进程中。各服务之间通过网络通信,看似独立,却又因业务联系关联在了一起,就像各个行星之间有着引力等物质将它们紧紧关联。一系列独立运行的微服务就共同构建起了整个系统。


二、微服务架构下测试的分类

640

以传统建筑行业为例,项目的完成需要设计院、施工方和监理单位协同合作。类比到软件系统中,架构师、开发和测试也是缺一不可。微服务架构下,更要求采用的测试策略能够为服务内部的完整性,以及每个服务之间的交互,提供全面的测试覆盖。
相比于常见的UI测试层、接口测试层、单元测试层,三层测试金字塔,在微服务架构,这个分类可以被扩展为5类。
下面将逐一介绍在微服务架构中主要采用的测试类型:
单元测试
单元测试是针对代码单元的测试,通常只测试一个函数和方法调用,验证其运行结果是否符合预期,是对代码质量最快速的反馈。高覆盖率、高质量的单元测试是保障代码质量的第一道保护伞。在掌握TDD(Test-Driven Design,测试驱动开发)的前提下,单元测试更是对代码重构起到了非常关键的作用。
集成测试
虽然单独测试模块非常重要,但是测试各个模块之间交互是否正常,同样也占据了重要的地位。在微服务架构下,集成测试的目的是把一些子模块组合在一起,测试其作为子系统是否存在缺陷,检查模块之间的通信和交互是否通畅且准确,是否以预期的方式协作。
组件测试
在微服务架构中,组件实际上就代表着微服务本身,所以组件测试就是检查服务内部功能实现是否完整,内部逻辑是否正确,异常处理是否正常等。
契约测试
契约测试称之为消费者驱动的契约(Consumer-Driven Contracts,简称CDC)测试。契约测试是为了测试服务之间连接的正确性,测试服务能否符合契约预期,即是否能真正满足服务消费者的需求。
端到端测试
端到端测试是从UI层开始执行,目的是检查整个软件系统是否符合用户的预期需求。一个常规页面功能展示的背后往往涉及多个服务,所以运行端到端测试需要部署多个服务。这样的测试能够达到更广的覆盖面,但是也面临测试不稳定,定位问题难等问题。
在微服务架构下,前端及后端各微服务之间都是分开研发及测试。保证每个微服务本身的质量成了测试中至关重要的一环。要想楼房造的高而稳,那基础必须扎实。微服务就好比那基石,高质量的微服务,是保障软件系统整体质量的关键。
相较于端到端测试在敏捷开发中的维护成本,服务在迭代研发过程中,和UI相比变化相对少,所以自动化更易维护,且能在迭代中不断复用。而且,服务测试自动化受外界因素的影响较少,不会受浏览器、手机型号及系统版本等影响。


三、基于微服务架构的服务测试工具

640

微服务架构带来了便利,随之也给测试工作增加了难度和新的挑战。测试人员必须跟上时代的步伐,调整自己的测试方法和工具。
怎样模拟多样的上层数据以及稳定的下层服务,高效、高覆盖的完成对服务的测试。此时,携程基于微服务架构的自动化比对工具就应运而生了。
该比对工具是以生产Log作为测试数据源,通过Mock、缓存等实现生产流量在测试环境的回放,以达到对服务进行全面测试的目的。
设计初衷
1)缩减测试数据维护成本、增加测试覆盖度
因是对服务的测试,首先要做的就是模拟上层应用或系统调用被测服务。常规服务测试自动化中,测试数据都是由自动化来完成构建,痛点:数据维护成本高,Case量级偏少。
解决方案:
拉取生产的Log数据作为数据源,这样原来5%左右测试数据的维护成本就缩减为了0%。数据每天定时拉取,增加了数据的新鲜度。且拉取的数据量大,这样就能保障数据的多样性,丰富的测试场景,以达到增加覆盖度的目的。
2)测试用例的持续运行成功
因测试环境的不稳定性,以及测试环境数据的缺失,且对于下层服务返回数据的强依赖性,做到Case持续运行成功并不是一件容易的事。
解决方案:
通过实现Mock,摆脱对底层服务的依赖,且能高效还原当前Case在生产环境的测试场景。
3)实现对被测服务所有输入输出流的验证
很多时候被测试的服务内部需要去调用其他服务,且有非常复杂的逻辑判断,对调用其他服务这块中间输出流的验证也是非常重要的,所以常规只对服务返回结果的验证远远不够。
解决方案:
实现对被测试服务所有输入输出流的比对验证。
具体实现
比对工具中最关键的是实现两个服务:
  • 比对服务:负责测试数据的拉取、被测服务的调用以及最后的比对;

  • Mock服务:负责被测服务需要的返回结果的高效匹配,以及对调用其他服务请求报文的收集及缓存。


比对工具工作流图:

携程微服务架构下的测试浅谈_第2张图片


工具优势
仿真生产流量。通过实现多线程,对生产上高QPS的服务,能够高效还原生产流量场景,并且通过模拟生产高并发时被测服务的负载量,使原本还有藏身之所的Bug更无所遁形。同时,每次运行Case的时间也有了量级上了缩减。
灵活Mock下层服务。以携程机票一个聚合层服务为例,它需要调用超过30个下层服务,常规测试用的打桩服务需要对指定下层服务进行预设返回,在多线程的情况下,这种方式匹配效率较低且容易出错。我们Mock服务中对打桩功能进行了改良,不仅摆脱对指定服务的Mock,并能快速准确的匹配返回结果。
多种比对方式。工具除支持两个测试环境进行比对外,更支持直接与生产数据比对。不同的比对方式,满足更多的测试需求,且对于被测服务中已知有变化的节点,也支持除外不比较,大大缩减测试结果的分析时间。


四、总结

640

技术的发展不会停步,学习的脚步不会停止。在微服务架构下,除了对微服务技术本身的研究外,对更适用于微服务架构测试的探究,是每个测试人未来努力发展的方向。
本文转载自公众号: 携程技术中心,点击查看原文。


Kubernetes线下实战培训

640?


Kubernetes应用实战培训将于2018年12月21日在北京开课,3天时间带你系统学习Kubernetes 本次培训包括:容器特性、镜像、网络;Docker特性、架构、组件、概念、Runtime;Docker安全;Docker实践;Kubernetes架构、核心组件、基本功能;Kubernetes设计理念、架构设计、基本功能、常用对象、设计原则;Kubernetes的实践、运行时、网络、插件已经落地经验;微服务架构、DevOps等,点击下方图片查看详情。

640?

你可能感兴趣的:(携程微服务架构下的测试浅谈)