微服务测试探索
随着微服务的流行,越来越多的系统采用微服务架构开发;软件架构的变化也给微服务下的软件测试带来了新的挑战。
关于微服务
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 -
领取专属 10元无门槛券
私享最新 技术干货