微服务测试探索

微服务测试探索

随着微服务的流行,越来越多的系统采用微服务架构开发;软件架构的变化也给微服务下的软件测试带来了新的挑战。

关于微服务

1

关于微服务的介绍以及数不胜数,本文就不再赘述了,列出几个微服务的几个主要特点:

解耦

服务之间不耦合,可以随时加入和剔除服务

独立

每个服务能够独立被部署并运行在一个进程内,可以灵活扩展

轻量

通信

微服务之间通常通过一些轻量级交互机制来通信,例如 RPC、HTTP 等

自治

开发人员和团队可以相对独立工作,从而提高开发效率

微服务下测试的挑战

2

微服务的这些特点给项目开发过程带来诸多好处的同时,也给测试带来了新的挑战:

成本增大:随着微服务数量的膨胀,如果不能有效降低每个微服务的测试成本,项目成本会不断增大。

微服务之间的依赖关系复杂,如果想单独测试某一个服务,或者服务中的某个模块,就必须剥离它们对于其他环节的依赖关系。

不同的服务可能会在不同的系统平台中运行,给测试环境的搭建、部署、管理都带来了诸多不便。

微服务下的测试思路

3

那么在微服务架构下,该如何进行测试呢?主要思路如下:

采用分层测试由细到粗,由小到大,划分为单元测试、组件测试、契约测试、集成测试、端到端测试

对于单个服务而言,主要进行单元测试,重点验证服务组件内部功能的正确性。

对于两个服务之间的通信,主要进行契约测试,验证服务之间连接的正确性。

对于多个服务组成的子系统或者服务群而言,主要进行集成测试,验证子系统或者微服务群流程的正确性。

对于整个系统而言,主要进行端到端测试,关注用户场景,从头端到尾端验证完整业务流程的正确性。

微服务的测试探索

4

将开发过程划分为3个构建阶段,分别是:开发自构建、集成构建和系统构建,每个构建阶段都包含多个构建迭代,每个迭代包括代码的提交、编译、环境部署、自动化测试等任务。一个迭代完成后进行缺陷修复,而后进行下一个迭代,直至达到下一阶段构建的准入标准后,进入下一阶段构建。

在现在的开发过程中,大家谈论得最多就是效率,微服务下更是如此,那么如何提高效率实现快速迭代呢?

在所有的构建阶段中,除了编码和手工测试外,其余的任务皆自动化实现,甚至可以并发执行。

mock的使用在微服务的测试中至关重要,测试过程中可以使用必要mock来屏蔽对其他服务的依赖,减少不必要的等待,提前开始测试。

可以使用docker等工具实现服务、环境的容器化,从而实现快速搭建、快速部署。

测试前移的思想由来已久,在微服务的解耦、独立、自治等特点,更适合测试前移的落地。

开发人员完成单个微服务编码->提交配置库->自动编译构建->自动部署->自动化测试(单元测试、组件测试、契约测试)->下一轮迭代。

自动

编译

构建

需要将编译完成后的微服务打包为docker镜像

自动

部署

由统一资源管理平台分配测试主机资源,自动部署docker镜像

单元

测试

对代码中的可测单元进行测试,校验其正确性

• 不必追求100%的代码覆盖率。

• 使用mock。

• 使用到的工具主要有DevOps平台、testng、mock工具、统一资源管理平台等。

组件

测试

以单个微服务作为对象,把微服务依赖的所有其他服务或者资源全部模拟化,来检查其功能是否符合预期要求

•mock一切可mock的外部资源。

•在mock条件下,验证单个微服务的功能是否符合预期。

•使用到的工具主要有DevOps平台、testng、mock工具、API测试工具、统一资源管理平台等。

契约

测试

检查各个微服务的通信和交易是否符合预期

• 选择合适的场景,定义消费者的请求和期望的响应。

• 使用mock机制,为消费者提供模拟的提供者以及期望的响应。

• 记录消费者发送的请求、提供者提供的响应以及关于场景的其它元数据,并将其记录为当前场景的契约。

• 模拟消费者,向真正的提供者模拟发送请求。

• 验证提供者提供的契约是否和之前记录的契约一样。

• 使用到的工具主要有DevOps平台、testng、mock工具、契约管理工具、统一资源管理平台等。

经过了开发自构建阶段的多轮迭代,大部分程序逻辑和服务服务之间连接问题已被发现并修复,并且因为在开发阶段发现,缺陷的修复成本较低。之后就进入集成构建阶段。

组成子系统或者服务群的各微服务完成开发自构建阶段->从配置库拉取对应代码->自动编译构建->自动部署->自动化测试(集成测试)->下一轮迭代。

自动

编译

构建

与开发自构建类似,需要将编译完成后的微服务打包为docker镜像

自动

部署

由统一资源管理平台分配测试主机资源,自动部署所需的docker镜像

集成

测试

检查各服务与其它服务的资源、通信以及相关的业务逻辑是否符合预期

• 目的是把一些微服务组合到一起,以子系统或者服务群的方式工作,确保它们能够以预期的方式协作,并检查不同模块之间的通信和交互,核实接口上是否存在问题。

• 检查微服务对外的模块与外部服务的通信,以及与外部数据库的交互。

• 验证子系统或者服务群的功能是否符合预期。

• 使用到的工具主要有DevOps平台、mock工具、契约管理工具、统一资源管理平台、UI自动化测试工具等。

所有服务完成集成构建阶段->从配置库拉取对应代码->自动编译构建->自动部署->自动化测试(端到端测试)->手工测试->下一轮迭代。

自动

编译

构建

与集成类似,需要将编译完成后的微服务打包为docker镜像

自动

部署

由统一资源管理平台分配测试主机资源,自动部署所需的docker镜像

端到端

测试

关注用户场景

从头端到尾端验证应用的正确性

• 以用户的角度验证业务场景。

• 尽量简洁,应当覆盖用户使用功能的核心路径,少量重要的分支路径,力求 UI 自动化测试的轻量化,降低维护成本

• 使用新数据,避免脏数据影响。

• 使用到的工具主要有DevOps平台、mock工具、契约管理工具、统一资源管理平台、UI自动化测试工具等。

手工

测试

• 以用户视角,重点关注端到端以外的用户场景功能。

• 非功能的其他特性的测试,如性能测试、安全测试等。

微服务下的测试,不光是测试流程,工具技术上需要优化调整,角色分工也需要相应调整。

以上是对微服务测试的一些小探索,欢迎批评指正。

- THE END -

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20190201G0C6V400?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券