有赞线上拨测系统实践(一)
前言
一直以来,作为互联网软件工程师接触最多的事务之一便是持续集成(Continuous integration,简称 CI)。持续集成俨然已成为主流互联网软件开发流程中一个重要的环节。现今有赞内部在实践持续交付(Continuous delivery,简称 CD),它可以被看成是后持续集成时代的产物。需要强调的是,不管是 CI 还是 CD,更多的是强调作为软件开发交付过程中的实践,而一旦交付到生产环境 CI 和 CD 就无能为力了。有赞线上拨测系统正是为了弥补这一不足。现有的线上保障手段可分为运维层面、产品层面、安全层面、服务层面和测试层面等维度。本文重点介绍我们在测试层面的实践。
基于测试脚本的线上监控产生
我们做测试线上拨测系统的初衷有以下几点:
- 主动预警线上问题。有赞有很多个业务线,各个业务线有不同的开发测试同学对接,我们很难做到每次发布都把影响面评估得十分准确。运维层面的监控更多的是被动告警,即用户流量触发了线上 bug,我们才会收到报警,用户体验不够好。我们需要在线上 bug 预警方面变被动为主动,周期性地知晓各个业务线的健康状况。
- 小流量下敏捷发现线上问题。通常我们软件的发布都是在凌晨流量非常低的时候进行。发布完成后,回归时间长(靠手动),测试面有限(无法做到次次发布全量回归)。此时需要敏捷构造一波覆盖面全的流量,在小流量背景下,敏捷发现线上问题。
- 知晓紧急情况下业务的受影响范围以及后续收敛情况。例如当生产环境出现网络异常等非软件故障时,需要清楚业务层面的影响;当网络恢复后,需要知道业务影响是否都已经收敛。 在此之前这些场景都需要测试人员手工介入,灵活度敏捷度都非常差。有了这套系统后,测试人员可以增加自己关注的场景,场景可以通过主动触发和定时触发来执行,通过告警系统通知到有关人员,做到第一时间排查问题,减少故障影响,降低故障时长。
基础版
1.0 版本我们使用通用的 SpringWeb 搭建,有赞内部称为线上机器人检查。系统结构如下:
1.0 版系统架构图
系统主要为三个模块:
- 任务调度模块。该模块将用例执行封装成系统任务,使用 Spring Quartz 来定时触发。对外提供 API 对接有赞发布平台,每当系统发布上线完成后主动触发用例执行。
- 测试用例模块。包括业务访问,断言和告警。测试场景需要各个业务线的测试同学投入开发。
- 告警模块。对接有赞内部告警平台。
1.0版流程图
系统将用例分为基础用例和场景用例,支持场景并发或者顺序同步执行。具体执行策略由用例设计者结合具体情况在用例开发过程中设定。
存在的问题
基础版满足了最小可用,这种方式优点在于前期能够快速投入使用,且对于经常写集成用例的人来说成本不高,但对其他人(测试新人、开发、运维等)则不然。概括而言,其缺点主要集中在以下几点:
- 业务线一旦多起来,用例代码开发成本提高;
- 随着用例数量增加,后期用例维护成本很大;
- 用例上线不灵活,每次用例改动需要重新发布;
- 无法直观看到运行情况和业务覆盖情况;
- 每次执行不区分业务,全量执行;
- 用例代码存在冗余,效率比较低。
配置化和可视化
由于这些不可规避的问题,我们重新设计并发布了 2.0 版本。对应解决以上问题:
- 测试用例和测试场景支持配置化,可以从管理平台上配置;
- 用例配置标准化,给定标准用例结构和断言策略;
- 通过管理平台来管理自己的用例,用例改动实时生效,无需发布;
- 增加前端展示,通过图表直观展示运行情况和业务覆盖情况,方便不同人群查阅;
- 对接发布平台,按照指定的应用名来区分跑哪些用例;
- 设计用例执行框架,实现核心代码复用。
新版系统架构图如下:
2.0版系统架构图
用例模型如下:
字段 |
是否必填 |
说明 |
---|---|---|
用例名称 |
是 |
建议命名格式:“用例类型:服务:方法” |
用例类型 |
是 |
两种类型可选 http 或 dubbo |
用例描述 |
是 |
场景描述 |
所属业务 |
是 |
用例所属业务阈 |
请求url |
否 |
http 协议调用的 url |
请求头 |
否 |
http header |
请求参数 |
否 |
http 或 dubbo 的请求入参。支持动态参数注入实现用例间依赖 |
服务名称 |
否 |
对应请求 dubbo 协议的接口名(包名+类名) |
请求方法 |
是 |
http 协议:GET、POST、PUT 等;dubbo 协议:方法名 |
断言 |
是 |
支持多个 |
是否开启 |
否 |
控制开关,关闭后不再运行。默认开启 |
是否登录 |
否 |
开启后,使用默认账号进行登录操作。默认不开启 |
是否重试 |
否 |
开启后,⽤例失败重试1次。默认否 |
前/后置检查 |
否 |
执行⽤例前/后,先执行前/后置检查,失败则中断 |
*此处略去了部分有赞内部使用的字段
为了更直观展示线上业务的健康状况我们增加了丰富前端报表:
数据展示
新版本与老版本的主要区别在于:
- 将执行流和数据流进行了分离,测试用例设计无需编码,支持配置化,用例作为数据存放到 DB 中重复使用,用例的执行引擎管理用例的执行流。
- 对通用的事务进行了封装,比如登录、切换店铺等操作,通过统一的线程池进行管理。
- 支持动态参数注入,实现了用例间的相互依赖,后面再单独介绍这块内容。
任务执行流程图如下:
2.0版流程图
任务执行引擎通过不同的工作线程实现。不同业务用例并发执行,业务内部用例串行执行。系统根据不同的用例的类型(http/dubbo)分发到具体任务流中。
核心类设计
用例间依赖的实现
从用例的复杂度上讲,我们的用例主要分为两大类:单一场景的基础用例和复杂场景的组合用例。组合用例是在基础用例的基础上进行一定的集成,用例的输入输出存在一定的依赖。我们实现用例依赖的方式有两种:
- 通过配置用例的前置后置关系。
- 通过参数注入。
第一种方式,在配置用例的时候,给它一个前置用例,当然前置用例也是在平台中管理的。这样当执行到该用例的时候,执行引擎会先去执行前置用例。
第二种方式,针对 Json 格式的入参,我们定义如下格式进行参数注入:
$#a,b,c#$
各个字段分别代表的含义为:
a:被依赖用例的ID b:被依赖用例响应的字段(key值),比如:name c:可选字段,当被依赖值位于 array 里面时,取其 index 下标 举例: {"code":"$#8,data,0#$","type":"$#10,type#$"}
参数注入的流程如下:
参数注入流程图
断言模块设计
在新版系统里面,我们设计了四种类型的通用断言,几乎可以满足我们自己的所有应用场景。这四种类型分别是:
1. 是否包含。 响应内容包含指定内容为 true,反之为 false。
2. 非空/null。 响应内容非空/null为 true,为空/null为 false。
JSON 特定位置的值的“相等”判断。
这种情况系统首先会将响应内容转换成 json,添加断言时需要指定待比较对象在 json 串中的坐标。如果该坐标上的值与指定的值相等则为 true,反之为 false。
那么如何给一个 json 串的每个值设置一个独一无二的坐标呢?考虑到 json 存在嵌套关系且 key 可能重复,我们通过一种复合 key 的来表示这个坐标,例如有如下 json:
{
"data": {
"list": [
"1",
"2"
],
"info": {
"name": "张三",
"age": 18
}
},
"code": 200
}
对标红的值的断言可以这样表示: {"data":{"info":{"name":"张三"}}}
,如果返回的位置的值为"张三"则判断结果为 true,否则为 false。
3. 面向 JSON 的伪代码表达式判断
前面三种类型的断言仅满足了部分场景,对于一些复杂的断言仍然无法满足,比如上文 json 中 list size 的断言。为此,我们引入第四种断言方式---伪代码断言。针对 list size 的断言我们可以这样写:
getJSONObject("data")getJSONObject("list").size()>0
代码在处理的时候会将该表达式拼接在 json 对象后进行执行。整段代码执行的结果为真断言为 true,否则为 false。 伪代码的动态编译、加载和调用,采用 GroovyShell 来实现。该部分代码实现如下:
public Result compare(String response) {
Result result = new Result();
// 单例获取GroovyShell
GroovyShell shell = SingleGroovyUtil.getGroovyShell();
Binding binding = null;
JSONObject jsonObject = new JSONObject();
JSONArray jsonArray = new JSONArray();
Object value = null;
try {
if (response.startsWith("[")){
jsonArray = JSON.parseArray(response);
binding = new Binding();
binding.setVariable("data", jsonArray);
value = InvokerHelper.createScript(shell.getClass(), binding).evaluate("data." + textStatement);
}else {
jsonObject = JSON.parseObject(response);
binding = new Binding();
binding.setVariable("data", jsonObject);
value = InvokerHelper.createScript(shell.getClass(), binding).evaluate("data." + textStatement);
}
if((Boolean)value) {
result.setSuccess(true);
}else {
result.setSuccess(false);
String msg = JsonUtil.findErrMsgByJsonObject(jsonObject);
result.setMsg(String.format("断言失败。断言的内容[%s], 错误描述[%s]", this.textStatement, msg.length()>0?msg:response));
}
} catch (Exception e) {
result.setSuccess(false);
String msg = JsonUtil.findErrMsgByJsonObject(jsonObject);
result.setMsg(String.format("断言时发生异常。ErrMsg=[%s],actual=[%s]", e.getMessage(), msg.length()>0?msg:response));
} finally { // 处理完后,主动将对象置为null
binding = null;
}
return result;
}
插件化
新版系统满足了用例的可配置化以及可视化的要求,同时也牺牲了一部分的灵活性。例如一些复杂断言的伪代码会非常长,且可读性不高,一不留神就会出错;简单的用例依赖可以满足,复杂的用例依赖却很难满足。比如用例 A 在某些条件下依赖用例 B,其他条件下依赖用例 C,这种复杂依赖关系走配置化并不合适。基于以上考虑,我们在现有的系统的基础上又增加了插件化的特性,来支持复杂用例的接入。
3.0 版系统架构图
插件化的设计思想如下:
- 平台对外提供一套用例标准,测试同学开发符合标准的用例添加到平台即可运行。
- 用例与平台完全解耦,用例在平台可配置。
- 用例支持热插拔,平台无需重启。
用例标准通过接口的形式对外提供,封装成jar包暴露出来。用例设计者直接依赖该jar包并实现指定接口即可。用例接口定义如下:
public interface AbstractTestCase {
CaseResult before();
CaseResult run();
void after();
}
用例开发完成后打包成 jar 包上传到平台,一个 jar 包中可包含一个用例也可以包含多个用例。
jar 包上传后平台要做的事情如下:
- 动态把 jar load 进 JVM
- 解析实现了 AbstractTestCase 接口的类
- 按照指定策略调用类中的方法
- 上报并展示结果数据
获取 jar 包中实现了 AbstractTestCase 接口的代码如下:
/**
* 获取jar包中某接口的实现类
*/
public static List<Class<?>> getAllImplClassesByInterface(Class c) {
List<Class<?>> filteredList = new ArrayList<Class<?>>();
//判断是否是接口
if (c.isInterface()) {
try {
//获取jar包中的所有类
List<Class> allClass = getClassesByPackageName();
allClass.forEach(clazz -> {
if (c.isAssignableFrom(clazz)) {
if (!c.equals(clazz)) {
filteredList.add(clazz);
}
}
});
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
}
return filteredList;
}
- 利用Actor实现管道过滤器模式
- SpringBoot整合Quartz定时任务 的简单实例
- 从机器学习学python(一) ——numpy中的shape、tile、argsort
- 剖析响应式编程的本质
- 从机器学习学python(二) ——iteritems、itemgetter、sorted、sort
- 基于MVC理解React+Redux
- JavaScript的IIFE(即时执行方法)
- 从机器学习学python(三) ——数组冒号取值与extend
- 从机器学习学python(四) ——numpy矩阵基础
- 从map函数引发的讨论
- AngularJs中,如何在render完成之后,执行Js脚本
- PHP取得上周一、上周日,下周一
- 代码诊所
- 《编程之美》读书笔记(一)——中国象棋将帅有效位置
- JavaScript 教程
- JavaScript 编辑工具
- JavaScript 与HTML
- JavaScript 与Java
- JavaScript 数据结构
- JavaScript 基本数据类型
- JavaScript 特殊数据类型
- JavaScript 运算符
- JavaScript typeof 运算符
- JavaScript 表达式
- JavaScript 类型转换
- JavaScript 基本语法
- JavaScript 注释
- Javascript 基本处理流程
- Javascript 选择结构
- Javascript if 语句
- Javascript if 语句的嵌套
- Javascript switch 语句
- Javascript 循环结构
- Javascript 循环结构实例
- Javascript 跳转语句
- Javascript 控制语句总结
- Javascript 函数介绍
- Javascript 函数的定义
- Javascript 函数调用
- Javascript 几种特殊的函数
- JavaScript 内置函数简介
- Javascript eval() 函数
- Javascript isFinite() 函数
- Javascript isNaN() 函数
- parseInt() 与 parseFloat()
- escape() 与 unescape()
- Javascript 字符串介绍
- Javascript length属性
- javascript 字符串函数
- Javascript 日期对象简介
- Javascript 日期对象用途
- Date 对象属性和方法
- Javascript 数组是什么
- Javascript 创建数组
- Javascript 数组赋值与取值
- Javascript 数组属性和方法
- TRTC Android端开发接入学习之实现视频通话(五)
- 让WordPress默认用户无法进入后台
- 图像处理笔记(2)----OpenCV imread函数详解
- 面试官:来写个代码求一下两个数的最大公约数吧
- 聊聊BitCaskLock
- 自动化构建工具~Maven
- 聊聊BitCaskKeyDir
- 使用 Node.js 定制你的技术雷达:上篇
- css画div对角线
- redis学习笔记--redis过期机制学习
- 猿实战08——属性库实现之属性关系绑定
- 猿实战07——属性库之实现电商系统基石模块
- 栈与队列简介
- Confluence 6 邀请你的小组来使用应用 APP
- 这可能是你见过最好的Redis主从复制原理