接口测试系列——转转交易业务场景接口测试实践

01 交易业务场景接口测试演进

1.1 业务概述

制定一个系统或者需求的接口测试方案或者测试方案。首先要了解业务特性、测试痛点，才能定制合理的测试方案，使得方案即可以满足当前业务形态的测试，又满足对未来可期需求的支持甚至对未来系统重构做提前打算。

转转交易系统的特性如上图所示，是一个流程清洗，逻辑标准化的系统，并且引入了状态机和切面机制满足业务灵活定制业务流。

但是响应的测试痛点也很明确，对接业务多，导致系统流程、计算逻辑复杂，又因为是交易系统，承载B2C、C2C等不同的流程、促销玩法、清结算规则，资金流向、资金计算逻辑复杂，资金风险高。

1.2 All In one的系统与接口用例

整个转转系统采用微服务架构进行服务拆分。

对于微服务架构的系统也有个比较初始的阶段，虽说不是all in one的系统架构，也是多业务耦合在一起的，主要因为业务初期团队规模较小、业务形态并未完全成型，业务间横向、纵向划分并不是特别明确。

但是简单的实现方式能尽可能快速的满足现有需求，同时降低眼前的维护成本。

初期的测试系统也是类似思想，按照当时的背景，接口测试、UI测试

刚刚起步，为了最求高性价比，自动化测试仅仅是解决当前问题、满足业务快速上线设计的，一步到位或者过于激进的设计往往会拖慢项目进度。

初期用例结构如上右图接口调用client初始化、测试数据初始化、接口调用、结果校验都在一个Test方法中，这样能快速响应当前需求、尽快达到测试效果。

1.3 系统与接口用例的初步抽象

随着业务发展，交易系统和交易的测试用例都有一系列的改版升级，对于交易系统是微服务的横向拆分、纵向拆分，原有的交易系统内部有了明显的业务隔离。单服务排队上线的情况明显减少，这是从QA角度上最直观感知到拆分服务带来的便利。

经过业务维度的拆分，也就有了上左图的交易系统，在原有系统上增加了一层带有运营属性的服务。促销玩法的出现和业务增长让原有交易系统的业务复杂度上升明显。

对于case原有的all in one的case不再满足快速支持业务的目标。

直观的感受，case的量也随着不停的增加、冗余代码量的增加，同一接口在不同的case中反复调用，同一类校验方法在不同的case中反复编写。

基于上面业务变动原有的接口模式已经无法满足现状，我们将case初步抽象复用、减少冗余，便有了右侧图的接口测试系统雏形。

统一的data provider提供数据，同一接口的调用抽象出Action Collection模块，每个接口通过参数区分调用接口要做的操作，做到接口调用的复用；抽象校验方法，独立出Assert模块，将类似的校验集中在一起，通过参数区分期望结果；

Case层仅调用接口组合操作并在操作后调用对应的校验方法。这样便解决了冗余的问题，大量接口和校验方法的复用让接口测试又高效起来，满足了与业务并行的要求。

1.4 系统切面化与接口测试的跟进

随着垂直业务的增加，又因为每个垂直业务的玩法不同，每个玩法所需要的交易流程不尽相同甚至差别巨大，给每个垂直业务单独开发、维护一套交易链路，会对系统复杂度和冗余度带来很大的挑战，维护的人力成本也是难以估计。

所以切面化的交易系统就产生了，交易维护核心交易链路，并将业务个性化内容以切面的形式托管给业务自定义处理。这样业务可以根据需要在现有的框架上定制业务流，满足了业务自定义诉求同时减轻了对中台人力的依赖。

根据切面化的思想我们在测试系统中通过动态代理构建出两层切面。一个在操作层，一个在请求发送的client层。

操作层的代理将校验单独独立出来，与操作分离，通过上下文进行衔接，用例不用再关心校验，只需要调用操作接口，如此更进一步降低了用例编写成本，当然校验系统的设计成本也有所提升。但是整体用例成本的降低也让RD可以在测试系统上编写测试用例，而且不需要关心具体的校验逻辑，因为用例操作和校验通过上下文链接，只要上下文设计得当，不管用例、入参如何组装校验系统均能处理并计算出期望值并通过查询业务系统接口或者数据库等进行校验。

另一层代理client层，可以做一些基于请求和返回的测试工具，比如 diff工具，满足重构类需求的测试。

1.5 状态机流转与切面

这里介绍下切面的运行机制，系统配置切面的进入条件，进入切面的锁定状态，切面的扩展操作信息。当进行某个操作后满足了进入切面的状态，系统则根据配置决定是否锁住状态的流转并执行扩展操作，如果锁定状态则将单据后续的操作托管给业务系统，直到业务系统解锁，单据的流转权限交回中台系统。

1.6 可扩展的交易系统与接口测试

随着业务发展与系统重构交易系统横向划分也越来越清晰，上层为业务系统、促销系统，中层为交易系统、支付中心，底层为清结算中心。

业务横向划分对交易系统来说业务结构更加清晰，系统维护更加便利，

但是对测试来说是一个挑战。上层业务小小的改动，或者底层业务小小的改动都会带来大量的回归工作。

基于以上问题，测试系统改进为可扩展化的测试系统，改进方案是在校验系统的上层抽象出一层计算系统，计算系统维护所有的状态流转数据、计算公式等，整体结构与上一版本并没有大的变化，主要是计算和校验剥离的更加清晰，计算更加可维护可扩展。如此上层业务的改动仅需要在抽离的公式中维护对应的变量就可以做到全业务回归。

1.7 测试系统数据流转

在执行接口调用操作执行后封装上下文，通过动态代理触发校验，校验发现本次操作影响到了其他上下文，如订单操作影响到红包、商品，需要再维护红包商品的上下文，上下文更新后再触发对应红包、商品的校验。

如此在整个其他业务的校验编写完整的情况下，当前业务在编写校验模块时只需要关心涉及到的上下文是否完整以及当前校验是否完整即可。

1.8 测试系统完整架构

经过多次升级，上图是最终测试系统的架构，两层代理和独立的上下文维护模块，独立的校验模块。

02 不同类型系统接口测试方法

2.1 状态机类系统测试

比如各类单据流转系统，都可以参考用例、操作、上下文、校验系统的测试方案，交易系统中的订单系统其实就是状态机系统的一个应用。

2.2 切面类系统测试

切面系统的测试点是切面能力。因为构建切面是为了将更多的自定义能力托管给业务，那么对于中台来说，更多的测试工作是对切面能力的保证。

因为切面的构造基于配置，所以对应的测试系统要验证配置能力、托管接口能力，测试方法如右图。数据构造模块插入各种配置，用例执行命中配置的操作，执行托管接口，校验配置的生效性和托管接口的生效性。

2.3 策略类系统测试

策略类和切面类的相似之处是基于配置，策略类业务场景包括风控、支付风控等业务场景。
配置策略，触发操作，测试策略引擎，验证配置。测试策略引擎是轻量的描述策略的集合。

03 接口测试周边方法

3.1 异常测试

异常分为服务内部异常，领域内部异常（服务间异常），与三方服务的异常。

服务间异常可以通过RPC mock、http mock ，服务内部异常可通过插桩方案注入异常。

3.2 精准测试

通过插桩收集被测系统的方法级调用关系，并还原出整个服务的内部调用关系。在接口测试时将用例信息通过trace信息或 rpc context传入被测系统，并在插桩的代码中提取方法与用例的关系。这样在有代码改动时，即可知道覆盖本次改动的接口用例，以及本次改动所影响的范围。

在这里还是要推荐下我自己建的软件测试学习Q群：746506216，群里都是学测试的，如果你想学或者正在学习测试，欢迎你加入，大家都是测试党，不定期分享干货（只有软件测试相关的），包括我自己整理的一份2022最新的Python自动化测试进阶资料和零基础教学，欢迎进阶中和对测试感兴趣的小伙伴加入！