接口测试总结

由于平台服务器是通过接口来与客户端交互数据提供各种服务，因此服务器测试工作首先需要进行的是接口测试工作。测试人员需要通过服务器接口功能测试来确保接口功能实现正确，那么其他测试人员进行客户端与服务器结合的系统测试过程中，就能够排除由于服务器接口缺陷所导致的客户端问题，便于开发人员定位问题。以下便是个人的平台服务器接口功能测试经验总结:

一、接口测试范围

根据服务器的测试需求，接口测试范围主要分为：1、新增接口的测试；2、新增业务功能接口测试；3、整个服务器的接口测试。所需测试测试接口依次增多，在测试时间足够的条件下，当然需要对所有接口进行测试用例的设计，但如果测试较短的情况下，则应该首先根据用户的典型操作对测试接口进行优先级划分，对调用频繁接口需要优先进行测试。

二、接口测试策略

   在进行平台服务器接口测试之前，首先需要整理服务器接口的测试方案，分析接口测试的要点，平台服务器的接口测试内容主要有：

接口设计检查

接口用于服务器与客户端的数据交互，客户端通过网络协议传递的数据为服务器接口的输入数据，因此应该首先通过服务器接口文档及客户端数据约束文档进行交互数据的有效性检查：

n 整数型数据位数

n 浮点型数据精度

n 字符串数据范围值

要求客户端的整数型、浮点型、字符串数据以及其最大值和最小值都能作为服务器接口的有效输入。这些工作在服务器设计评审时就可以进行，以便确保不会出现客户端上传数据被服务器自动进行截断或四舍五入的操作。

接口依赖关系检查

以上策略只谈到单个接口的测试方法，对于用户来说，一个操作可能会造成服务器调用多个接口来进行完成，因此还需要从业务处理的角度，对各种业务操作所涉及的多个接口之间依赖调用进行测试。接口依赖关系检查主要是通过接口的输出值为另一接口的输入值来实现的，因此在进行接口测试之前，需要分析所测试接口的输入值是通过客户端还是其他接口输出来获取的，在设计测试用例时，加入接口的依赖关系说明以便于测试。

接口输入/输出验证

服务器接口功能测试类似于单元测试，在设计测试用例时，侧重点在于接口模块输入/输出项的正确性验证，根据接服务器接口处理方式，对各种接口进行分类：

第一类：条件判断接口

   这类接口在接收到请求数据后，会根据输入参数进行条件判断，然后返回相应结果码，通常涉及条件判断的接口有：用户鉴权接口、升级状态上报、密码修改/重置等接口。因此输入/输出项验证的侧重点主要集中在：

1）判断条件的验证

要对判断条件进行验证，则需要知道接口是根据哪些输入项来进行判断的，以密码重置接口为例：

密码重置接口

『接口功能』：用户登录之后发起找回密码操作，用户输入邮箱信息后，游戏中心将向平台服务器发送请求，平台服务器将随机为用户生成新的密码，发到用户的邮箱中。

此接口根据输入的userID、email参数来进行数据正确性的判断（key是接口名称，如果错误服务器将不会处理，version是版本号，其值只是用于记录，不参与判断），设计接口测试用例时，应该首先对接口的判断参数进行验证，这些输入项不能为空，然后利用等价类划分、边界值方法来根据userID、email输入项设计各种合法的数据，验证接口是否可以正常处理。

此外必须要关注数据库的数据，所以加入数据库里数据的校验。比如修改/重置密码后，要去看下数据库的密码是否是修改后的数据

2）异常数据的响应

只考虑正常情况，而不考虑异常场景是无法保证接口功能运行正常，对于密码重置接口，用户ID不存在、不合法，邮箱输入格式错误、用户邮箱信息不存在或未激活就是测试时需要考虑的异常场景，设计这类输入值，并且检查接口返回的响应码，响应码的正确才能保证客户端根据异常情况来显示相应的提示信息。简而言之，条件判断的接口其测试策略就是根据判断条件来设计各种输入值来检验接口的功能。

第二类：数据查询接口

   这类接口接收到请求数据后，首先会验证请求是否合法，然后会根据请求项查询数据库相应表中数据返回给客户端，通常涉及数据查询的接口有：用户基本资料/经验值/赛事信息查询、游戏列表获取、在线人数查询等接口。以用户经验值查询接口为例：

用户经验值查询接口

『接口功能』：用户登录游戏中心后，可以查询自己每个游戏项目的经验值信息，包括此项目的经验值等级、等级称号、今日经验值上限等。

『接口方向』：游戏中心—>平台服务器

『遵循协议』：HTTP+XML，请求消息使用Post方式

此接口首先会根据webkey来判断请求是否合法，然后根据请求参数中的userID、isAll、sportItemID来查询数据表中相应数据。除了象条件判断接口一样根据判断项webkey、请求参数userID、isAll、sportItemID设计合法/不合法和正常/异常测试值之外，还需要结合数据库来对查询结果进行验证:

1）是否根据正确的关联数据表进行查询；

2）验证查询结果是否从数据表中正确项中获取，涉及到多表联合查询时，不同表中的相同项设计不同测试数据进行验证；

3）修改查询结果在数据表中对应项中的数据，使其为空值或客户端相应项的范围值的最大和最小值，查看接口输出是否正确。

第三类：逻辑运算接口

这类接口在收到请求数据之后，会进行一系列逻辑运算，然后根据处理结果更新数据库中的数据，通常涉及逻辑运算的接口有：比赛成绩同步、商品支付、各种数据报表等接口。

此接口比数据查询接口又更加复杂，除了用条件判断和数据查询类接口的策略对此接口进行测试用例设计之外，还需要验证对接口的算法规则进行检查，因为此接口涉及根据用户比赛成绩(record)进行排名然后返回其得分及排名情况(score、rank、upRankFlag、exp)，通过对相关数据表中的数据进行查看方式，接口算法规则验证包括：

1）用户胜利、失败、中途主动/被动退出、规定时间内未完成比赛情况下，此场比赛得分(scroe)是否正确；

2）用户比赛成绩比上次成绩花费时间短、长、持平情况下，排名情况(upRankFlag)是否正确；

3）用户比赛成绩处于第一名、最后一名、比上次成绩花费时间短/长/持平情况下，用户积分排名（rank）是否正确；

4）用户胜利、失败、中途主动/被动退出、规定时间内未完成比赛，并且用户经验值在各种经验等级范围下，经验值根据得分进行计算的公式是否正确。

逻辑运算接口由于还涉及插入或更新数据库操作，因此测试时还需要考虑数据库特性，如数据精度问题，在MySQL数据库中，如果是浮点型数据，存入时会有精度误差（131072.32插入float(10,2)类型的数据会变为131072.31），因此对于需要用于金额计算、数据统计、成绩比较的数据，最好使用定点型。最后服务器接口的测试如果有足够条件的话，还需要通过白盒测试来对接口代码做进一步的测试，通过编写关键代码的测试桩，可以有效查找将字符数组当成字符串使用造成的读越界这类不易通过黑盒测试发现的BUG。接下来的工作就是如何通过测试工具来执行服务器接口功能测试。

三、支付接口

一、支付流程

用户 | 商户系统 | 第三方支付
—|—|—
1.用户下单，发送到商户系统。

2.商户系统生产订单，构造支付请求；发送支付请求给第三方。

3.第三方向用户展示支付相关信息。

4.用户输入密码确认支付，发送给第三方。

5.第三方收到支付密码，确认完成支付

6.第三方向商户系统返回支付成功，同时后台通知支付结果。

7.商户系统返回给用户支付结果页面。

8.用户确认支付成功，发货。

二、接入流程

1.业务系统调用支付中心支付接口。

2.支付中心鉴权。失败：进入支付中心错误。成功：进入支付中心收银台页面。

3.选择支付方式，向支付机构发起支付。

4.支付机构通知支付中心支付结果。

5.支付中心回调业务系统通知支付结果。

三、接口规范

1.接口说明

2.调用URL

3.请求方法（get/post）

4.请求参数、参数类型、请求参数说明

5.返回参数说明

四、测试用例

1.通过性验证；参数组合；异常验证（必传／非必传、参数类型、参数长度、为空、边界值）；业务逻辑（如：登陆失败5次，需要等待15分钟再登录）

2.接口安全：

（1）绕过验证。如购买商品价格300元，提交时用Fiddler设置断点修改金额为3，看后端有没有做验证

（2）绕过身份授权。如只能是卖家才能修改商品信息接口，我传一个普通用户或其他商家是否能修改成功

（3）参数是否加密。不加密就能被拦截修改；加密规则是否容易破解

（4）密码安全规则。密码的复杂程度校验

五、测试模版

项目 模块 用例ID 接口名称 请求方式 请求URL 请求参数 请求报文 响应报文 前置条件 预期结果 测试结果 测试人员

六、接口参数

1.收款号；seller_email

2.商品名称；subject

3.金额；total_fee

4.商家名；

5.付款方式；

6.sign；key；

7.外部交易号（商品的ID，primarykey）；out_trade_no

8.合作身份者ID（签订合同后得到一个表示自己的唯一号）；partner

—后面将持续更新！