微服务测试探索

微服务测试探索

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

关于微服务

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 -