微服务测试实践之测试分析

微服务特点

首先微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终服务。每个服务运行在其独立的进程中,服务与服务间采用各种协议通信,例如我厂使用华为DSF微服务架构的DSF协议。每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境、仿真环境、测试环境等。

每个服务都可以被独立部署意味着随着服务数量及调用关系复杂度的增加,如果依然使用传统的集成测试方式对服务协作进行验证,必然会面临成本呈指数级增长的挑战。具体体现在:

1.验证成本高 为了验证多个服务协作后的功能正确与否,需要为每个服务搭建基础设施(包括其依赖的数据库、缓存等),并执行部署、配置等步骤,以确保服务能正确运行。

2.结果不稳定 微服务构建的系统本质上是分布式系统,服务间通信通常都是跨网络调用的。当对服务间协作进行测试时,网络延迟、超时、带宽等因素都会影响到测试结果,极易导致结果不稳定。

3.反馈周期长 相比于传统的单体应用,微服务架构下的可独立部署单元多,因此集成测试的反馈周期比传统的方式更长,定位问题所花费的时间也更长。

微服务测试理论

          相比于常见的三层测试金字塔,在微服务场景下,这个层次可以被扩展为5层(如果将UI测试单独抽取出来,可以分为六层)。分别为单元测试、集成测试、组件测试、契约测试、端到端测试。


微服务测试实践之测试分析_第1张图片
来源网络


和测试金字塔的基本原则相同:

1.越往上,越接近业务/最终用户;越往下,越接近开发

2.越往上,测试用例越少

3.越往上,测试成本越高(越耗时,失败时的信息越模糊,越难跟踪)

单元测试

单元测试,即每个微服务内部,对于领域对象和领域逻辑的测试。它的隔离性比较高,去除其他依赖,执行速度较快。它和其他组件原则上没有依赖。即使要测试的对象对其他类有依赖,我们会Stub/Mock的手段来将这些依赖消除,比如使用mockito/PowerMock。

集成测试

系统内模块(一个模块对其周边的依赖项)间的集成,系统间的集成都可以归类为集成测试。比如数据库访问模块与数据库的集成和外部service依赖的测试。

集成测试强调模块和外部的交互的验证,在集成测试时,通常会涉及到外部的组件,比如数据库和第三方服务。这时候需要尽可能真实的模拟实现与外部组件进行交互,比如使用和真实环境相同类型的数据库。

组件测试

贯穿应用层和领域层的测试。不过通常来说,这部分的测试不会访问真实的外部数据源,而是使用同schema的内存数据库,而且对外部service的访问也会使用Mock的方式。

契约测试

在微服务场景中,服务之间会有很多依赖关系。根据消费者驱动契约,我们可以将服务分为消费者端和生产者端,通常消费者自己会定义需要的数据格式以及交互细节,并生成一个契约文件。然后生产者根据自己的契约来实现自己的逻辑,并在持续集成环境中持续验证。有兴趣研究下Pact框架。

端到端测试

端到端测试是整个微服务测试中最困难的,一个完整的环境的创建于维护可能需要花费很大的经历,特别是当有多个不同的团队在独立开发的场景下。另一方面,从传统的测试金字塔来看,端到端测试应该覆盖那些业务价值最高的Happy Path。也就是说,端到端测试并不关注异常场景,甚至大部分的业务场景都不考虑。在端到端测试中,最重要的反而不是测试本身,而是环境的自动化能力。实践docker为主的devops思想。

项目举例

XX项目为我厂使用微服务开发的一个产品类项目,系统调用关系图如下,项目开发实现了部分单元测试、联调与系统环境的人员集成测试和与外部系统的联调测试。

微服务测试实践之测试分析_第2张图片

项目测试分析

单元测试

单元测试需要实现在每个工程模块中,开发人员编写测试代码,主要包括dao层、biz层和service层方法的测试,采用mock机制去除外部依赖、同时采用内存数据库也可以去除数据库依赖。

集成测试

通过集成测试来完成测试各个模块能否正确交互,并测试其作为子系统的交互性以查看接口的缺陷。

项目集成测试需要解决公有协议栈(http协议、webservice协议)和私有协议(dubbo协议、dsf协议)测试问题,对此使用工具列表如下:

http协议:postman   

webservice协议:soapui  

dubbo协议和dsf协议:自研发simulator系统 

压力测试

压力测试由测试部门发起,提供测试报告,主要技术是通过MockService桩服务实现微服务调用链各级服务的性能测试结果。

为满足项目需求开发了统一的微服务mock系统实现桩服务,测试设计如下图:

微服务测试实践之测试分析_第3张图片

端到端测试

测试人员通过开发人员提供unifornt-web页面进行业务端到端测试,直接穿透后端众多服务获取测试结果验证测试是否正确,公司其他同事也在实现以docker为主的devops实践方案。

结束语

本文主要讨论了微服务测试关注点以及我厂服务化项目实践微服务测试的时间,一路走来还存在大量的坑,目前也在慢慢填。后续文章,我会持续描述如何具体落实微服务单元测试、接口集成测试和自动化测试,同时也会单独介绍微服务测试的自研发的测试工具simulator系统。敬请期待!

你可能感兴趣的:(微服务测试实践之测试分析)