转转交易全链路接口测试发展及扩展

Posted 2021-04-24 转转QA

1. 概述

1.1. 背景

1. 交易相关业务测试订单流很多、流程偏后测试与回归的重复工作量大，效率低；

2. 商品类型及订单状态多样，订单又包括红包、服务、活动等属性，全链路数据种类非常多，如被测需求发生在交易场景末端或者关联多种属性则数据构造需要操作很多步骤，效率很低。

3. 业务敏感，需求上线需要反复的对基础业务进行回归。

1.2. 目标

1. 测试前置。在联调或前端提测前完成业务流程测试，让功能测试尽可能的只关于与前端交互。

2. 抽离核心业务，作为环境检测、冒烟测试、上线前轻量级回归。

3. 用例可视化，提供分享执行、定时执行功能。

4. 提供数据构造，减少末端场景、复杂数据构造带来的效率损耗。

5. 性能数据收集，多线程场景下并发量可参数化，为性能测试提供便利。

6. 用例推荐，小需求自动提供用例，方便回归上线。

2. 发展过程

2.1. All In One

1. 接口测试最初应用阶段，没有成型的代码接口，为了快速响应需求，将所有代码集中在@Test方法中，包括服务初始化、测试数据构造、测试用例、测试结果校验。

 

2.2. 公共方法抽离

1. 随着测试用例的累积，服务初始化、数据初始化相同的代码块重复出现，甚至校验方式出现大同小异的方法块。一些请求参数封装，返回值的解析逻辑出现重复。

 

2. 当重复的代码和类似的逻辑重复出现时整个测试项目便可以进行集成和重构抽象出初步的框架结构。

 

3. 当抽离完成后用例编写更加高效用例对需求的覆盖程度提高，针对不同类型的项目或不同的被测主体出现几大类用例编写模式，如基于被测实体状态变化进行状态覆盖的状态类测试用例如订单流转与交易流程中商品的状态变化，基于业务流转进行分支覆盖的分支类测试用例如运营活动等等细分类别。

 

基于状态

 

基于流程

2.3. 项目分离与数据构造

    随着代码量增长，项目开始变得臃肿，但项目从代码逻辑来看可以清晰分为两层，一层为提供基础功能的代码，如服务于基础的工具类、服务接口调用方法等，另一层为测试用例；

再者接口测试已经发展一段时间，用于业务测试、回归测试的场景已经成熟，到了再往前走一步的阶段：比如在功能测试中QA往往直接通过写几行代码来辅助构造一些数据，项目合理的拆分似乎可以更便于将构造数据功能平台化。

基于以上原因对整个项目进行了分离，一个项目为zzserver-core，用于编写直接调用服务的代码以及通过一些组合可以用最少的参数构造出期望的数据，另外提供一些工具类，这样zzserver-core项目不仅可以为接口测试提供基本能力还可以作为公共jar包为其他项目提供接口调用能力或提供工具。 另一个项目为zzserver，用于维护接口测试用例；在项目分离的同时对测试用例进行了一次细分，分为项目测试用例用于需求和大项目测试、监控级别测试用例即checklist用于日常上线前回归等轻量级检测、性能测试用例用于基于testNG的性能测试。

zzserver-core中的数据构造是在项目中维护特定的builder方法，组织一部分接口构造一些常见数据，如发布不同类型商品的接口，发布商品并构造不同状态订单的接口等等。以上数据构造能力被用例展示平台引用后形成数据构造平台，方便除接口测试外码维护者外的用户方便的构造出想要的数据。比如通常来说功能测试需要校验一个已发货订单的详情页需要测试者在两台手机上登录App，一个发布商品一个购买商品，然后再做发货操作才能看到被测页面，有了数据构造功能后仅需要在页面上输入两个uid点下确认就可以在App上看到需要的订单。

 

提供数据构造后项目结构

2.4. checklist

1. 在持续的需求迭代、大小需求上线过程中保持交易核心流程的正确性，同时降低每次上线手动回归的时间成本，checklist便从繁重的业务接口测试中抽取出来，目标是高效的覆盖核心业务流程。

2. 当前checklist包括正向交易流程、退款仲裁等逆向流程、红包、活动等，同时对执行过程中的商品库存、订单状态、订单按钮、最终打款去向和财务平账进行校验，确保基本流程的正确性。

3. 后续checklist会继续细分，并引入推荐系统，协助轻量级上线。

2.5. 性能测试

随着交易业务发展，线上业务的性能瓶颈渐渐凸显性能测试需求开始出现；交易性能测试偏向于某个业务场景的性能指标评估。又因为现在接口测试用例比较完善另外有用例展示平台支持用例界面化生成和平台执行，在已有框架和平台最大化使用的前提下发展出基于TestNG加压、用例平台展示、新服务展示数据的性能测试框架；

比如要模拟一个比较真实的线上场景：线上用户都在随机的浏览可下单的商品，并出现一定比率的用户下单，一定比率的用户查看订单，一定比率的用户付款，一定比率的用户退款等操作，且以上操作都是混杂在一起随时都有可能出现，另外买家和卖家也在进行着不同的操作，且有可能同时操作试图将订单改向两个冲突的状态；

上段描述的测试场景看似复杂，但依托现有接口测试接口实现起来就简便了很多；

性能评估的一大要素是测试数据数据，主要包括qps、响应时间、服务器性能指标等，qps可用过服务端获取到，接口响应时间在SCF框架的代理外增加一层代理收集数据除此代课还可以收集返回值异常的请求和返回信息方便拍错，用例执行情况和抛出的异常通过testNG执行监听收集数据，服务器性能参数通过agent收集，以上数据均通过RMI服务同步至性能测试平台进行存储和分析。

 

数据收集策略

 

性能测试执行流转

3. 用例类型

无论用于接口测试的项目结构如何持续变更，配合提高效率的外部子系统如何多样和高效，用例永远是接口测试的核心内容。

交易接口用例大致分为五类：

1. 基于订单或商品状态流转的状态类测试用例。

a) 该类测试用例主要应用测试已配置好的状态机，校验订单在流转过程中的状态变化，通过订单状态为用例主线来覆盖所有业务。

2. 基于活动的分支覆盖类测试用例。

a) 该类用例主要出现在运营活动中，通过对活动中出现的不同分支进行覆盖达到需求测试点的覆盖。

3. 基于业务、财务分账的结算正确性验证的测试用例。

a) 该类用例主要出现在交易结束时对订单金钱流转进行校验，属于交易业务特有类型。即敏感有复杂。

b) 该类用例出现在交易末端，交易的前置流程复杂，数据多样，订单的附加属性又实时的影响着最终结算，通常从不同的分支过来的订单或夹带不同附加属性的订单最终的结算结果都不同，所以结算测试算是交易测试中敏感又复杂的业务，如采用功能测试则需要非常大的精力去构造各种类型输入，如遇到Bug修复或者需求变更需要全量回归，对整个项目的排期会带来很大的影响。

 

4. 基于交易核心能力的测试用例如状态机扩展的测试。

a) 状态机以及状态机扩展是交易的一种能力，可以使订单基于配置进行流转，如当前订单处于状态1，1状态订单仅仅可以触发handler A、B、C，其中handler A可使订单状态流转至B；状态机扩展即在状态机中加入扩展点，在命中扩展点之后可以在已有状态机的基础上执行扩展handler，同样也是一种能力。

b) 对于交易我们平时测试主要为已配置好的状态机以及编入业务逻辑的handler，但是如果在业务初期或基础能力改版、扩展时没有业务，仅有能力时，测试便是基于能力的测试而非业务，此时就需要测试者主动编入各种规则并通过订单流转来触发规则以证明基础能力是否可用。

 

5. 另外还有文案类，对列表页、详情页按钮、服务窗文案进行校验。

4. 整体结构与轻量级上线

1. 交易接口测试整体以服务调用方法、数据构造方法、工具类为基础，再此基础上拼装出满足不同业务测试的测试用例；

2. 另在测试用例的基础上添加不同子系统以发挥剩余价值或提高效率；

3. 用例持续提取和细分，整理出不同的checklist并配合diff数据主动推荐需求需要测试的checklist，并在测试后通过jacoco反馈diff代码的覆盖情况，做到小需求RD可自行通过checklist回归上线。

 

接口测试项目接口+后续扩展