微服务架构下的测试策略

微服务架构下的测试策略

微服务架构下的测试策略

源宝导读:最近几年,微服务架构越来越火爆,逐渐被企业所采用。随着软件架构的变化,对应的软件测试策略需要作何调整呢?本文将介绍云客在微服务架构下的测试策略。

一、云客测试策略模型

策略分析

行业内的测试策略是一个先底层再上层、从局部到整体的一个过程:

微服务架构下的测试策略

从行业内的演进过程可以看到,项目测试策略在不同阶段结合参考了不同的策略模型:金字塔->近似钻石->蜂巢。

基于行业经验,结合我们实际的架构特点,云客同样划分为不同的层级进行测试:客户端、BFF层、服务层,跟钻石型的过程是类似的。

微服务架构下的测试策略

各层测试侧重点

服务层不正常可能会影响BFF,BFF不正常可能会影响客户端,但每一层级各自验证的侧重点是不同的:

1

客户端

检查客户端(APP、小程序、WEB站点)操作以及操作后的界面呈现。

2

BFF层

不考虑服务层的实现规则和数据库存储,只关注用户在客户端的不同操作场景下,业务逻辑是否达到预期,确保衔接客户端和服务层是否正确。

3

服务层

对单个服务接口逐个测试,需要考虑入参和出参、数据库存储是否符合预期。

二、BFF层测试策略

BFF层测试面临的问题

由于BFF层的接口通常会调用到多个底层服务接口,由此暴露出一系列问题:

涉及业务场景多

涉及多种缓存    

自动化用例设计难度大

工具的缺失

BFF层测试策略分析

针对以上问题,考虑云客的BFF层测试策略需要达到以下效果:

  • 解决用例设计困难:能快速方便测试人员编写和维护测试用例;

  • 轻量级:减少消耗大量的人力在开发框架上;

  • 易操作:让测试同学都能简易使用,且保证持续集成;

  • 兼容性:能兼容Middleman或公司层面的其他工。

BFF层解决方案

1、录制:对接口进行录制。回归测试时,利用代理进行接口抓包。

2、清洗:清洗数据生成用例。清除掉重复接口、无用接口、补充漏掉接口并生成接口测试用例。

3、回放:利用其它框架运行接口用例。如robotframework ,postman , jemeter ,或自研框架。

4、持续集成:部署自动化。解决cookie等问题,自动化部署进行持续集成。

为了让大家能更清楚的理解我们的策略,结合刚刚介绍的BFF测试策略以及解决方案,这里以智能收款项目为例:

微服务架构下的测试策略

1、录制:通过启动本地代理,使用抓包工具抓取到用户操作的各种场景;

2、清洗:通过脚本过滤获取的接口,进行去重,按照规则筛选,最终生成接口用例;

3、回放:核对生成的接口用例,并运行;

4、持续集成:使用selenium模拟登录拿到登录态后,可以通过Jenkins进行持续集成,最终生成测试报告。

三、服务层测试策略

服务层测试面临的问题

覆盖率

测试用例覆盖率的不足会很大程度上影响测试的效果。

服务依赖   

在测试服务时,常常会遇到服务之间存在依赖的情况。此时无法单独对单个服务进行完整的测试,往往会依赖于其他关联的服务状态。

服务容错

我们对服务的测试,还需要考虑服务的容错和可用性,比如:当服务器的负载达到瓶颈或者当某个服务发布新的升级导致出现问题时,就会遇到服务的熔断、降级。

服务熔断:某个服务出现故障的时候,为了保证系统整体的可用性,会关闭出现故障的服务;

服务降级:当系统整体负荷过载的时候,关闭某些服务来保证系统的整体可用性。

服务层解决方案

服务覆盖率

    通过Middleman工具中测试覆盖率的数据指标,引导测试人员去完善用例,以达到接口的全覆盖。并且在代码提交时,需要保证用例全部通过才允许代码合入。

微服务架构下的测试策略

服务之间的依赖、连通性

    Middleman工具通过内置mock服务,解耦服务间的依赖,只测试那些真正被实际使用到的 API 调用,如果没有被使用到的,就不去测试,具体如下图。

微服务架构下的测试策略

多泳道测试

    核心解决的问题:多个开发并行,测试互不干扰,按分支需要创建,泳道完成环境隔离。

微服务架构下的测试策略

服务的容错性、可用性

    通过服务的熔断、降级的自动化预警工具,当慢SQL增多时,自动化脚本会自动Kill掉符合条件的慢SQL。同时可视化Kill记录、kill异常中断,既方便又直观。

微服务架构下的测试策略

四、云客测试策略

整体解决方案

微服务架构下的测试策略

在测试过程中,我们不难发现云客的产品测试现在正在面临的问题:

迭代频繁

测试时间短

测试评估不全面

测试人员少

随着功能的逐步增加,回归任务重

针对上面提到的微服务对测试的挑战,一方面为了保证在服务各个层级上对微服务进行全面的测试;另一方面又要确保测试执行的效率,这样才能保证持续集成/持续交付(CI/CD)。因此,云客总体的测试策略采用如下解决方法:

以增量测试为主,辅以自动化测试,探索性测试以及checklist检查微服务架构下的测试策略

测试策略的影响因素不是唯一的,技术架构并不是最关键的因素。业务价值始终是我们的终极目标。在这个终极目标的驱动下,测试策略不是制定完了就可以束之高阁的,需要在整个软件系统构建过程中不断的度量和改进,是演进式的。

------ END ------

作者简介

彭同学: 测试SM,目前负责云客相关的测试方案设计和执行工作。

也许您还想看

基于 Go 的微服务运行情况监控实践

在明源云客,一个全新的服务会经历什么?

“弱中心”化的分布式配置管理技术可行性探索

ERP平台的自动化测试技术实践

为什么容器内存占用居高不下,频频 OOM

微服务架构下的测试策略

微服务架构下的测试策略