斗破28预测

模块级别自动化测试的经验与教训

时间:
2018-06-20 22:24:58

模块级别自动化测试的经验与教训

概述

搞了几个月的自动化测试,结果不甚理想,这里做一个简单的总结。

为什么要做自动化测试呢?因为手工测试效率低,找 case、执行 case 太费时间。

为什么自动化测试前面要加“模块级别”呢?因为一个系统依赖很多外部系统,如果不能有效屏蔽外部环境的差异,自动化测试会经常因为环境问题而失败。

原理

这里讲的自动化测试原理是,在线上环境录制测试 case,在线下测试环境利用录制的 case 进行回放测试。

如何录制 case?某个系统对一次请求的一次处理可以认为是一个 case,模块级别的自动化测试要求录制该系统在处理请求时的所有对外交互,包括但不限于:

  1. 该模块接收到的请求和对外响应信息。

  2. 该模块在处理请求过程中,产生的所有下游调用的请求和响应。常见的有:HTTP 请求、DB 请求、Redis 查询、MQ 输出、热更新配置等等。

以下图为例,有 A、B、C、D 四个系统模块,假设要对模块 A 做自动化测试,需要录制测试 case。该模块有一个接口,接收来自模块 D 的请求,在处理过程中会产生对模块 B、C 的下游调用。那么在录制 case 时,不仅要录制该接口的输入输出,也有录制两次下游调用的输入和输出。

示例1

在请求处理过程中,往往会出现各种线程的切换、异步调用,如何将一个请求的所有对外交互串起来呢?很多公司都有分布式链路跟踪系统,会有一个 traceID 能够把不同系统的请求串联起来,同理也可以利用该 traceID 把单个系统内部的请求处理过程串联起来,拥有同一个 traceID 的输入输出可以认为是属于同一个 case 的。

case 的录制思路比较简单,收集数据后存储到 DB 中即可。case 的回放测试分为两步:

  1. 运行测试 case。

  2. DIFF 测试结果,需要进行 DIFF 的数据包括测试接口的响应参数、下游调用的请求参数,也就是被测模块对外输出的数据。

经历的坑

本地缓存的 dump 问题

前面说了,录制 case 时,需要录制所有的下游调用的请求和响应。对于需要定期更新的本地缓存,也需要 dump 其数据,如何 dump 呢?dump 查缓存的方法即可,以下面代码为例,dump 方法 getXXXConfig 的输入输出即可。本质上是将 getXXXConfig 方法的调用当成了外部请求进行录制。