宜信支付结算系统API自动化测试实践

API 测试的基本步骤

一般来说,API 测试的基本步骤主要包括如下三大步骤：

一、准备测试数据；

二、经过通用的或本身开发的API测试工具发起对被测API的request；

三、验证返回结果的response。

经常使用的API测试工具备命令行工具cURL、图形界面工具Postman或SoapUI，支持API性能测试的JMeter等。

API复杂场景举例

经过使用基础的测试工具，能够作简单场景的API测试；而项目进行过程当中，为了解决实际的一些问题，咱们会设计更加复杂的测试场景，下面列举几个实际项目中的典型场景。

场景一：API串联调用

以协议支付为例，咱们知道，三方公司接入网联后，用协议支付取代代扣，而协议支付的流程中须要用户输入银行返回的验证码完成绑卡。从接口层面上看，顺序是先调用协议签约API，返回状态成功且获取到短信验证码后，再使用此短信验证码做为输入参数调用代扣API。协议签约和代扣两个API是顺序调用，并且在两次调用中间有获取手机上的短信验证码，这些过程都须要经过程序自动化实现以提升效率。

场景二：API接口加密

为保证API接口安全，系统间和系统内模块间互相访问须要进行加密处理，经常使用的加密方式有DES、AES、RSA、MD5等，各系统的加密方式并不同（接口调用方和接口提供方约定好便可），意味着API测试须要支持多种自动化加密方式程。某些系统还会返回加密的响应报文，也须要识别并解密。

场景三：异步API测试

异步API指请求发出后后收到一个同步响应，但并非最终处理结果，最终结果经过回调或者主动查询得到。对于这样的API，同步响应的验证只是第一步，后续还得继续验证DB中的值、MQ中的值、以及异步回调是否成功等。对于异步回调，咱们能够模拟回调地址来验证成功与否；而对于主动查询，咱们就得经过查看DB中的状态值来验证了，可是查询到结果的时间点不肯定，几分钟到几小时都有可能，这就得有一个定时DB查询任务去验证。

场景四：API测试中的外部依赖

APIA调用APIB且B不可用，此时如何测试APIA须要考虑。好比支付系统对三方支付通道、对银行的依赖，并非全部的三方都支持测试环境，解决此问题的核心思路是搭建MockServer，并且尽可能作到通用性，咱们开发了一套Mock系统 -aMock，经过页面录入接口信息，保存在数据库内，经过Nginx访问配置好的Mock接口，后台统一处理请求信息，而后经过URL和报文特性去匹配特定的响应信息。

API测试平台

咱们的API测试平台是要基于业务场景的，即要支持各业务的共性需求，又要针对不一样业务的个性特色加以开发来丰富API测试能力；并且，对用例也要有很好的规划，结果有清楚的展现，测试平台架构以下图：

 

BIT：业务接口测试（BusinessInterfaceTest）

SUT：被测系统（SystemUnderTest）

TestCaseManagement：测试用例管理，包括从测试用例到测试用例集，再到测试任务的数据关系的创建和维护。测试用例是最小单位，测试用例集是从某一维度对用例进行的归集，测试任务即测试执行，可当即触发也可定时执行，只能执行测试用例集。

Util：工具类封装，主要提供数据加解密，数据类型转换，配置文件读写，数据字典的缓存服务等。

Validator：接口响应字段和数据库字段的验证封装。

RiskManagement：风控处理，由于会涉及支付真实资金，须要内置风控规则来保证资金安全，风险可控。

Timer：定时任务服务，包括

1）串联API用例中，前置用例的状态判断；

2）异步API的数据库校验；

3）超时API用例的失效状态判断；

4）定时执行的任务计划。

MockServer：用例依赖的外部系统Mock服务。

Portal：API测试平台门户网站，包括测试用例的录入，维护，测试任务的执行，结果查看，导出等都经过门户进行操做。

DB：存储测试用例数据以及相应的测试任务、测试报告数据，还有项目配置等。

目前API测试平台上各项目维护用例总结1200多条，以回归用例为主，且还在不断增长中，随着用例的不断添加，平台也历经了一系列优化，下面就谈谈这个过程当中的一些思考。

测试数据准备

对于大量API用例的执行，须要数据驱动测试，也就是说能够将测试数据和测试代码分离解耦，这样便于测试数据的维护同时也保证了数据的准确性，用例设计格式是这样

<accountName>${accountName}</accountName>

<accountNo>${accountNo}</accountNo>

<identNo>${identNo}</identNo>

几个关键数据节点由DataProvider提供，为了增长测试覆盖度，数据库类似的测试数据有多条，好比多条四要素（银行卡号、手机号、身份证号、姓名）数据，当大量用例须要读取时，可采用缓存方式存储并读取到cList里面，经过循环遍历，使每条测试数据均可以被均匀读取，下面是替换关键数据节点的一段代码，将cList数据依次赋给对应变量。

 

测试执行的逻辑控制

不少状况下的测试是场景化API测试，涉及用例的顺序调用。以下图，“签约-成功-kftn-协议”依赖于“签约-成功-kftn短信”的执行；在添加用例时配置好关联关系。

 

执行时，会根据用例属性将此两条依据有无前置条件划分为两类，分别存放于两个list里，无前置条件的用例能够立刻执行，有前置条件的用例，设置TestStatus为0，等待定时任务轮询触发执行。分类执行代码以下图

 

定时任务每分钟执行一次，下面一段是判断前置API的执行状态，只有“0000”表明成功，当前API才能执行，执行时，须要读取前置用例的结果数据并传入；若是前置API失败，则中止任务执行，多条API用例顺序执行也是一样的道理；即便有外部依赖的用例，好比短信验证码，咱们也能够经过写一段手机APP程序自动上传短信验证码到服务器，而后触发延迟获取验证码，获得后经过DB记录用例执行的状态和结果，并传给下一个API使用，就完成了多用例的顺序执行。此外，测试任务的执行封装成restful接口，能够更加灵活地和目前团队正在开发中的CICD系统结合一块儿。

 

测试结果的验证

经过分析业务，API的结果校验大体分为两种类型，响应校验和数据库校验。响应校验是针对response报文字段的校验，可精确匹配也可经过正则表达式模糊匹配；数据库校验是基于定时任务的，须要在用例里面根据约定格式设置校验方法，好比下面的sql检验条件，会在准生产环境经过指定单号以及其余条件去查询返回字段，并判断status是否为7，从而判断用例是否成功。

PreOnline.3|,|SELECTtb.outer_batch_no,tb.status,bs.send_statusFROM

bs_outpay.trans_batchtbleft joinbs_outpay.es_business_sendbsontb.business_batch_no=bs.entity_uuidandbs.entity_status<>2 WHEREtb.outer_batch_noin (?) order bytb.CREATED_TIMEDESC|,|{"status":"7"}

用例状态分为成功、失败、处理中、超时四种状态，分别经过配置相应SQL查询条件去映射，成功和失败是终态，处理中则是须要定时任务继续查询，超时，是咱们内部设定的一个状态，目前是超过一个小时未返回终态设为超时，此API用例失效并报警，须要人工参与查看。全部这些规则都是在用例创建和编辑的时候添加的，以下图，一条用例包括了响应校验（值校验、key校验）和数据库校验，经过这种比较灵活的设计，基本可以知足复杂API测试场景。须要指出一点是，不少应用不容许外部测试平台直接访问数据库，咱们的解决办法是写一个数据查询服务部署在系统环境中，只提供查询功能，而且有加密验证保证通信双方（测试平台和数据查询服务之间）可信。

 

一般来讲，测试平台或框架能够从某种层面上理解为工具链的串联，开发此平台的过程当中，咱们使用的技术栈有springmvc+herbinate作逻辑控制、amazingUI作用例管理、echart作结果展现，还使用Jenkins作任务调度等，用户就是各业务线测试人员，他们不须要了解具体代码的实现，可是须要对系统结构以及用例规则有很好的理解，这样才能设计出符合测试场景的用例。

任何测试平台的设计仍是要基于业务的，后续咱们对API平台的推动策略是，继续增长场景化功能以支持更多业务类型的测试，好比清结算系统中日终、日间的跑批任务，对帐文件的数据检验等，增长大并发能力并和性能测试工具相结合。

-END-

做者：孙鹰 来源：宜信技术学院：http://college.creditease.cn/#/index