写点什么

有赞线上拨测系统实践(一)

  • 2020-03-11
  • 本文字数:4753 字

    阅读完需:约 16 分钟

有赞线上拨测系统实践(一)

前言

一直以来,作为互联网软件工程师接触最多的事务之一便是持续集成(Continuous integration,简称 CI)。持续集成俨然已成为主流互联网软件开发流程中一个重要的环节。现今有赞内部在实践持续交付(Continuous delivery,简称 CD),它可以被看成是后持续集成时代的产物。需要强调的是,不管是 CI 还是 CD,更多的是强调作为软件开发交付过程中的实践,而一旦交付到生产环境 CI 和 CD 就无能为力了。有赞线上拨测系统正是为了弥补这一不足。现有的线上保障手段可分为运维层面、产品层面、安全层面、服务层面和测试层面等维度。本文重点介绍我们在测试层面的实践。

基于测试脚本的线上监控产生

我们做测试线上拨测系统的初衷有以下几点:


  1. 主动预警线上问题。有赞有很多个业务线,各个业务线有不同的开发测试同学对接,我们很难做到每次发布都把影响面评估得十分准确。运维层面的监控更多的是被动告警,即用户流量触发了线上 bug,我们才会收到报警,用户体验不够好。我们需要在线上 bug 预警方面变被动为主动,周期性地知晓各个业务线的健康状况。

  2. 小流量下敏捷发现线上问题。通常我们软件的发布都是在凌晨流量非常低的时候进行。发布完成后,回归时间长(靠手动),测试面有限(无法做到次次发布全量回归)。此时需要敏捷构造一波覆盖面全的流量,在小流量背景下,敏捷发现线上问题。

  3. 知晓紧急情况下业务的受影响范围以及后续收敛情况。例如当生产环境出现网络异常等非软件故障时,需要清楚业务层面的影响;当网络恢复后,需要知道业务影响是否都已经收敛。 在此之前这些场景都需要测试人员手工介入,灵活度敏捷度都非常差。有了这套系统后,测试人员可以增加自己关注的场景,场景可以通过主动触发和定时触发来执行,通过告警系统通知到有关人员,做到第一时间排查问题,减少故障影响,降低故障时长。

基础版

1.0 版本我们使用通用的 SpringWeb 搭建,有赞内部称为线上机器人检查。系统结构如下:



1.0 版系统架构图


系统主要为三个模块:


  1. 任务调度模块。该模块将用例执行封装成系统任务,使用 Spring Quartz 来定时触发。对外提供 API 对接有赞发布平台,每当系统发布上线完成后主动触发用例执行。

  2. 测试用例模块。包括业务访问,断言和告警。测试场景需要各个业务线的测试同学投入开发。

  3. 告警模块。对接有赞内部告警平台。



1.0 版流程图


系统将用例分为基础用例和场景用例,支持场景并发或者顺序同步执行。具体执行策略由用例设计者结合具体情况在用例开发过程中设定。

存在的问题

基础版满足了最小可用,这种方式优点在于前期能够快速投入使用,且对于经常写集成用例的人来说成本不高,但对其他人(测试新人、开发、运维等)则不然。概括而言,其缺点主要集中在以下几点:


  1. 业务线一旦多起来,用例代码开发成本提高;

  2. 随着用例数量增加,后期用例维护成本很大;

  3. 用例上线不灵活,每次用例改动需要重新发布;

  4. 无法直观看到运行情况和业务覆盖情况;

  5. 每次执行不区分业务,全量执行;

  6. 用例代码存在冗余,效率比较低。

配置化和可视化

由于这些不可规避的问题,我们重新设计并发布了 2.0 版本。对应解决以上问题:


  1. 测试用例和测试场景支持配置化,可以从管理平台上配置;

  2. 用例配置标准化,给定标准用例结构和断言策略;

  3. 通过管理平台来管理自己的用例,用例改动实时生效,无需发布;

  4. 增加前端展示,通过图表直观展示运行情况和业务覆盖情况,方便不同人群查阅;

  5. 对接发布平台,按照指定的应用名来区分跑哪些用例;

  6. 设计用例执行框架,实现核心代码复用。


新版系统架构图如下:



2.0 版系统架构图


用例模型如下:


字段是否必填说明
用例名称建议命名格式:“用例类型:服务:方法”
用例类型两种类型可选 http 或 dubbo
用例描述场景描述
所属业务用例所属业务阈
请求urlhttp 协议调用的 url
请求头http header
请求参数http 或 dubbo 的请求入参。支持动态参数注入实现用例间依赖
服务名称对应请求 dubbo 协议的接口名(包名+类名)
请求方法http 协议:GET、POST、PUT 等;dubbo 协议:方法名
断言支持多个
是否开启控制开关,关闭后不再运行。默认开启
是否登录开启后,使用默认账号进行登录操作。默认不开启
是否重试开启后,⽤例失败重试1次。默认否
前/后置检查执行⽤例前/后,先执行前/后置检查,失败则中断


* 此处略去了部分有赞内部使用的字段


为了更直观展示线上业务的健康状况我们增加了丰富前端报表:



数据展示


新版本与老版本的主要区别在于:


  1. 将执行流和数据流进行了分离,测试用例设计无需编码,支持配置化,用例作为数据存放到 DB 中重复使用,用例的执行引擎管理用例的执行流。

  2. 对通用的事务进行了封装,比如登录、切换店铺等操作,通过统一的线程池进行管理。

  3. 支持动态参数注入,实现了用例间的相互依赖,后面再单独介绍这块内容。


任务执行流程图如下:



2.0 版流程图


任务执行引擎通过不同的工作线程实现。不同业务用例并发执行,业务内部用例串行执行。系统根据不同的用例的类型(http/dubbo)分发到具体任务流中。



核心类设计

用例间依赖的实现

从用例的复杂度上讲,我们的用例主要分为两大类:单一场景的基础用例和复杂场景的组合用例。组合用例是在基础用例的基础上进行一定的集成,用例的输入输出存在一定的依赖。我们实现用例依赖的方式有两种:


  1. 通过配置用例的前置后置关系。

  2. 通过参数注入。


第一种方式,在配置用例的时候,给它一个前置用例,当然前置用例也是在平台中管理的。这样当执行到该用例的时候,执行引擎会先去执行前置用例。


第二种方式,针对 Json 格式的入参,我们定义如下格式进行参数注入:


`#a,b,c#`


各个字段分别代表的含义为:


a:被依赖用例的 ID


b:被依赖用例响应的字段(key 值),比如:name


c:可选字段,当被依赖值位于 array 里面时,取其 index 下标


举例: {"code":"$#8,data,0#$","type":"$#10,type#$"}


参数注入的流程如下:



参数注入流程图

断言模块设计

在新版系统里面,我们设计了四种类型的通用断言,几乎可以满足我们自己的所有应用场景。这四种类型分别是:


  1. 是否包含。


响应内容包含指定内容为 true,反之为 false。


  1. 非空/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。


  1. 面向 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 版系统架构图


插件化的设计思想如下:


  1. 平台对外提供一套用例标准,测试同学开发符合标准的用例添加到平台即可运行。

  2. 用例与平台完全解耦,用例在平台可配置。

  3. 用例支持热插拔,平台无需重启。


用例标准通过接口的形式对外提供,封装成 jar 包暴露出来。用例设计者直接依赖该 jar 包并实现指定接口即可。用例接口定义如下:


public interface AbstractTestCase {
CaseResult before();
CaseResult run();
void after();}
复制代码


用例开发完成后打包成 jar 包上传到平台,一个 jar 包中可包含一个用例也可以包含多个用例。


jar 包上传后平台要做的事情如下:


  1. 动态把 jar load 进 JVM

  2. 解析实现了 AbstractTestCase 接口的类

  3. 按照指定策略调用类中的方法

  4. 上报并展示结果数据


获取 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;}
复制代码

未来

未来有赞线上拨测系统会提供更丰富的功能,例如更灵活的用例执行策略,核心用例执行频率更高,边缘业务执行频率降低;更全面的报警策略,各个业务方可以自由定制关心的用例,线上问题第一时间触达;支持多机房,目前该系统只在单机房进行部署,有赞核心业务已完成多机房部署,拨测系统也会随之调整;系统支持分布式,为了防范系统单点故障,未来还会考虑进行分布式部署。


目前这套系统可以保障测试同学第一时间知晓有赞线上核心业务异常,将来保障的业务广度和深度会进一步提高,成为有赞线上质量保障至关重要的一环。


2020-03-11 22:202004

评论

发布
暂无评论
发现更多内容

开源一夏 | Spring事务传播机制

六月的雨在InfoQ

开源 Spring事务 8月月更

10分钟快速入门RDS【华为云至简致远】

科技云未来

RDS

写给 Java 程序员的前端 Promise 教程

CRMEB

2022年中国全民健身发展白皮书

易观分析

行业分析 健身

湖北钠斯网络数字藏品交易系统

开源直播系统源码

NFT 数字藏品

LED显示屏在会议室如何应用

Dylan

LED显示屏 led显示屏厂家

【有奖征文 第13期】至简致远,“云”响世界,大胆秀出你的华为云技术主张,高额激励等你拿

科技怪咖

华为云分布式缓存服务Redis开通及使用规划教程【华为云至简致远】

科技云未来

redis'

一文读懂字节跳动“埋点验证平台”

字节跳动数据平台

字节跳动 数据治理 埋点治理 数据研发 埋点验证

秋招冲刺版!奉上[Java一线大厂高岗面试题解析合集]

冉然学Java

面试 面试题 大厂 java; 秋招

国产数据库的红利还能“吃”多久?

墨天轮

数据库 国产数据库

web前端培训班哪个好选择

小谷哥

带你玩转“超大杯”ECS特性及实验踩坑【华为云至简致远】

科技怪咖

华为云服务之弹性云服务器ECS的深度使用和云端实践【华为云至简致远】

科技云未来

弹性云服务器ECS

科创人·优锘科技COO孙岗:错误问题找不到正确答案,求索万物可视的大美未来

科创人

JavaScript 里三个点 ...,可不是省略号啊···

华为云开发者联盟

JavaScript 前端 运算符 函数

前端培训机构课程怎么样

小谷哥

干货:从零设计高并发架构

C++后台开发

高并发 架构师 C/C++后台开发 C/C++开发 高并发架构

基于DevCloud进行黑白棋实时对战游戏开发实践【华为云至简致远】

科技怪咖

Beetl使用记录

Geek_163f36

*打卡—>什么是云数据库&&沙箱实验如何用python和数据库来爬虫?【华为云至简致远】

科技云未来

云数据库

「Gitee篇」如何用Git平台账号登录建木CI

Jianmu

git 开源 DevOps 低代码 gitee

阿里巴巴最新分享Spring Cloud核心笔记,全程实例讲解,通俗易懂

Java工程师

Java spring spring-cloud

有了这个开源工具后,我五点就下班了!

IT学习日记

EasyExcel 签约计划第三季 seaweedfs文件系统 java excel导出导入 java csv导出导入

一起来学华为云数据库,RDS实践【华为云至简致远】

科技云未来

云数据库

如何选择ui设计机构

小谷哥

原来如此!谷歌架构师10年呕心沥血汇成的《23种设计模式》,这才是正解

冉然学Java

架构 23种设计模式 java; 编程、

面向云时代的龙蜥操作系统 是 CentOS 替代的最佳选择

OpenAnolis小助手

龙蜥操作系统 开放原子全球开源峰会 OpenAnolis 分论坛 CentOS 停服 CentOS 迁移最佳选择

腾讯云产品可观测最佳实践 (Function)

观测云

Java面试项目推荐,15个项目吃透两个offer拿到手软

冉然学Java

offer java; 技术栈 MAll java项目实战分享

携手数字创新 共筑国产生态 7月份AntDB与5款产品完成互认证

亚信AntDB数据库

AntDB 国产数据库 AISWare AIDB

有赞线上拨测系统实践(一)_文化 & 方法_有赞技术_InfoQ精选文章