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

作者: 写完了没 | 来源:发表于2017-09-19 18:45 被阅读140次

微服务特点

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

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

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

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

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

微服务测试理论

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

来源网络

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

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

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

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

单元测试

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

集成测试

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

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

组件测试

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

契约测试

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

端到端测试

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

项目举例

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

项目测试分析

单元测试

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

集成测试

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

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

http协议:postman   

webservice协议:soapui  

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

压力测试

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

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

端到端测试

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

结束语

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

相关文章

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

    微服务特点 首先微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用...

  • Web测试原理与实践

    web测试原理与实践分为四部分: 一、软件测试阶段 二、web测试基础 三、web测试实践 四、然之登录测试点分析...

  • 软件测试,如何薪资破万

    测试理论实践 测试概论 测试流程 需求分析 测试计划 测试用例设计 缺陷管理 版本管理 测试执行 操作系统 虚拟机...

  • 微服务架构的测试思考和实践(二)

    微服务架构测试策略 微服务架构的测试思考和实践(一)里我们强调了测试的重要性,这一部分我们来聊聊微服务架构的测试策...

  • 吐血推荐:性能测试方案编写(一)

    前言 性能测试方案需包含测试测试需求分析、测试对象分析、测试重点分析、测试环境分析、测试场景构建几个关键点,其中:...

  • 微服务概述

    微服务概述 网易云容器服务微服务化实践—微服务测试及镜像化提测全流程实践 Microservices a defi...

  • 为什么你的产品开发好了,还需要专业的测试?

    测试的流程: 需求分析,系统分析,测试分析。测试方案设计,测试方案评审。测试用例编写及评审。测试执行。 测试回归及...

  • 测试分析不等于测试设计,测试点不等于测试用例

    测试分析不等于测试设计 一般测试分析与设计,最终以输出一个测试设计结束,容易忽略测试分析,将测试分析和测试设计混淆...

  • 测试需求分析

    一、测试需求分析 测试需求分析就是分析我们测试什么、如何测试的过程。通过完备的测试需求分析可以输出高质量的软件测试...

  • 软件测试流程

    测试准备-测试计划-测试需求-测试用例-测试执行-测试缺陷管理-测试报告总结 需求分析需求分析(Requirmen...

网友评论

    本文标题:微服务测试实践之测试分析

    本文链接:https://www.haomeiwen.com/subject/vzqgsxtx.html