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

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

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.基于活动的分支覆盖类测试用例。