转转电商交易系统基于动态代理的测试框架设计

2019-06-05 18:00:38

eb41122462111dfe26292266c0e3f20a

本文作者田西西,转转 QA 团队资深测试工程师,将于 MTSC2019 大会上分享《转转电商业务测试方案与实战落地》议题。文末有抽奖福利

前言

测试框架的设计需要适合被测试系统,要依据当前测试问题和系统后续的发展合理设计,避免过度设计导致维护成本徒增。同时被测系统也要依据测试方法提供适当的便利,以提高被测系统的可测性。

本文讲述的是基于动态代理的接口测试设计,在思考如何测试之前需要先了解下被测系统。

简单介绍两个被测系统 1. 交易订单系统

交易订单系统基于状态机实现,包括正向流程状态机、逆向流程状态机,下图为正向流程其中的一条链路:  

20e698aa229497072c8bc58afaeca0d3


  • 订单经由特定条件触发,通过执行某个动作由当前状态转移到下一状态。动作执行前由前置校验逻辑判断当前请求是否可执行,当条件为真才会触发后续操作。

  • 订单操作以订单上下文为纽带,订单上下文持有订单当前状态及所有信息,订单操作将上下文由 A 状态变更至 B 状态并最终落库,同时处理一些 UI 渲染、消息发送等事物。

2. 支付中心账户系统

f3fca768f1bd41415b28cb8ec36e32ef

支付中心账户系统中不存在状态变更,但所有的操作基本都是对账户余额的操作。所以账户系统可以理解为以账户上下文为纽带对账户金额进行操作的系统,如充值操作使账户可用余额增加,提现操作使账户可用余额减少。

上面两个系统有一个共性,被测系统都可以抽象为由某个特定条件下触发某个操作引起某个主体发生特定变化的系统,如订单操作引起订单状态变化,对账户的操作引起账户金额变更。

如何自动化测试类似系统呢?

我们早期接口用例实现方式:

a874a93ea906e747d8030487d7733a1c

早期我们编写了很多校验方法用于不同属性的校验,如校验订单状态的方法、校验订单按钮的方法、校验订单服务窗内容的方法。在每个订单操作后依次调用该操作对应的校验方法并传入期望值。早期单条用例可读性可接受,从用例即可知道当前做了什么操作,引起了什么变化,期望值是什么。但也存在一些问题,如:

  • 同样操作会出现在不同用例中,如不同种类的订单需要调用的校验方法基本相同,导致在不同的用例中重复调用相同校验方法,冗余且容易漏掉。

  • 当交易系统更新后,需要到各个用例中更新或替换这些校验方法。当系统复杂到一个操作下需要调用五个左右的校验方法且每个操作还会定制一些个性校验,用例编写和维护会十分痛苦。

那么如何解决这些问题呢?仅仅解决眼前的问题就能满足吗?

我们先看下订单系统的一个特点:一组明确的条件可以定义当前订单所处的状态、UI 展示等信息。

  • 如买家在已发货状态下操作确认收货,上述条件可以确定订单当前处于已收货状态、订单详情展示为已收货状态下的 UI。

  • 如订单处于发货状态且买家 N 天未操作订单导致离线触发,上述条件也可以确定订单同样变为已收货状态。

账户系统如何描述呢:操作充值,导致了余额增加,且条件和结果相对于订单要更加简单。

基于上面的描述,如何改进测试系统呢?

似乎只需要拦截操作并构建操作前后的上下文,校验模块通过上下文获取需要的条件匹配当前被测主体的状态、UI 进行校验即可。而如何拦截?这里就用到了拦截器,依赖 JDK 中的动态代理实现。

动态代理

在介绍改进后的测试系统结构之前,先介绍下动态代理。

d8c55932695369f9761de96e6e3437f4

上图是动态代理的 UML 图,代理类与真正的实现类都继承了抽象的主题类,这样代理类和实际类有相同的方法,可以保证对上层调用方使用的透明性。

写法:

  • 编写一个委托类的接口,即 Subject 接口

  • 实现一个真正的委托类,即 RealSubject 类

  • 创建一个动态代理类,实现 InvocationHandler 接口,并重写 invoke 方法

那么改进后的用例为

35be6aaa3f231bbdf670d55b6e585fcb

上图为单个上下文的用例写法,实际测试时往往有多个被测主体,就会有多个上下文维护,多个校验分发的 switch。

  • 以订单系统为例

订单操作后根据请求参数和返回信息更新订单上下文,动态代理拦截上下文的更新触发校验。将分散各处的校验方法集成为校验模块。 通过分发器分发到不同的校验方法中,校验方法通过上下文匹配到当前订单的状态、UI 等信息与被测系统返回的订单信息做校验。 校验模块又分为各校验子模块,可通过开关控制是否开启。

  • 以账户系统为例

账户创建时初始化账户上下文,操作账户更新上下文并触发校验,在校验模块使用用例中维护的上下文信息与真实系统中信息做校验。

该方案的优缺点如下:

优点

  1. 校验对用例不可见,用例编写者设计好校验模块后只需要罗列操作步骤即可。

  2. 更高的集成度,降低用例维护成本,系统迭代只需要维护对应校验模块即可。可扩展性高。

  3. 扩展分为两个维度,业务扩展性和框架能力扩展性。业务扩展性 如:在订单体系中引入一个新的变量,可以通过接入新的上下文快速将新的业务和校验应用于已有用例。接入商品上下文和商品校验子模块用于校验交易过程中商品状态、库存等变化。

缺点

  1. 编写用例增加了设计成本,提高了门槛。大需求或系统新增的扩展能力,在用例编写时需要设计上下文、校验子模块,还需要考虑用例的业务可扩展性。

  2. 代码维护同样有门槛,需要了解框架、调用链和被测业务。

动态代理在交易测试框架中应用

78f43172379b1498563a68a4ebd8e0ef

目前接口测试框架中有两个动态代理:

  1. 用于拦截 SCF 请求的 SCF Proxy,可以对请求参数和返回信息进行收集,用于新老环境 diff,收集接口响应时间,上报测试环境性能。

  2. 校验代理,在接口操作执行后通过更新不同的上下文 如订单、商品、红包等触发对应的校验。

动态代理整体的使用理念是拦截对目标类的操作并在目标类的基础上增加切面逻辑,在切面上添加扩展子系统。这就是上面没有展开说的框架能力扩展性。

总结

最后总结一下,设计模式只是抛转,引玉则是测试系统中的每个模块的设计。后续转转 QA 团队还将介绍如何在当前模式下设计可扩展的清结算校验模块,以应对业务高速发展。

在 MTSC2019 测试开发大会上,笔者将分享《转转电商业务测试方案与实战落地》议题,期待与各位测试同仁在现场一起交流探讨!

MTSC2019 预告|8 折倒计时

MTSC2019 第五届中国移动互联网测试开发大会将于 2019 年 6 月 28-29 日在北京国际会议中心举行,50+ 来自 Google、BAT、TMD 等一线互联网企业的测试大咖分享精彩议题,涵盖移动自动化测试、服务端测试、质量保障 QA、高新测试技术(AI+、大数据测试、IOT 测试),游戏测试,工程效率提升等专题。(目前确认 40+ 议题, 8 折门票限时优惠中!)

ea552865af3e12c2d9a48d85da4c9013

大会官网http://2019.test-china.org/

报名地址:https://www.bagevent.com/event/2202999?bag_track=YT


TesterHome 福利时间

转发文章到朋友圈,抽奖赠送 TesterHome 定制版精美礼物(卫衣/图书等)、MTSC2019 测试开发大会门票或优惠折扣,以及其他福利等!0a642ee1d3d8299e72c5f1d89049e152


  • Step1: 转发本文到朋友圈,扫描二维码加小助手微信;

  • Step2: 回复「福利」入群抽奖;

  • SteP3: 回复「组团」入群,以团购优惠价购买 MTSC2019 门票;

91c71b29cc573d921d7bd12637569f83

P.S. 对于 MTSC 往届参会者,可享受 7.5 折福利,请联系票务负责人,也可进群咨询;


扫描二维码,或点击“阅读原文,抢购 8 折门票!

淘大象

怎么查淘宝买家号被哪个商家降权

梦想家

淘宝代运营

淘宝帐号信誉查询

淘宝权重是什么