接口测试快速上手指南

大量线上BUG表明，对接口进行测试可以有效提升产品质量，暴露手工测试时难以发现的问题，同时也能缩短测试周期，提升测试效率。但在实际执行过程中，接口测试被很多同学打上了“上手难，门槛高”的标签。

本文旨在为接口测试工作提供一份按部就班的“说明书”，不仅可以打破门槛快速上手，还可以查漏补缺，提升接口测试质量和效率。

一、为什么要接口测试

在展开介绍接口测试工作之前，我们需要先了解一下“什么是接口测试”，“为什么需要进行接口测试”。

在游戏测试中，接口测试是指脱离游戏客户端的UI界面，通过直接测试服务器暴露给客户端的接口，来确定接口是否在正确性、安全性、性能、安全等方面达到预期的测试。

那么，为什么要进行接口测试？从产品的角度来说，最重要的目的是：避免玩家绕过客户端获利。

案例1：某游戏帮会仓库功能，玩家通过外挂手段绕过客户端，取出<1件装备，比如0.1个装备，则可复制多个一模一样的装备。

案例2：某游戏联动活动，玩家跳过“开始小游戏”接口，直接调用小游戏结算接口，不断刷代币，由于结算接口没有检查游戏次数，所以玩家可以不断调用接口获得代币，再在商店兑换道具。 ……

诸如此类，总有“贼”心不死的玩家，试图利用各种手段窃取其他玩家或游戏本身的利益，接口测试则是一道重要的防火墙。

而对于QA本身的角度来说，接口测试带来的好处就更多了：可以提前介入测试，缩短测试周期；接口有保障的情况下，客户端业务的测试效率也会大幅提升；接口测试是学习白盒/灰盒测试的敲门砖等。因此开展接口测试是提升产品质量、提升QA测试能力的重要手段。

在这我为大家准备了一份软件测试视频教程（含面试、接口、自动化、性能测试等），就在下方，需要的可以直接去观看，也可以直接点击文末小卡片免费领取资料文档

软件测试视频教程观看处：

软件测试工程师大忌！盲目自学软件测试真的会毁终生，能救一个是一个......

二、如何进行接口测试

1、制订测试计划

制订测试计划时需要明确：

1. 业务的重要程度、优先级、复杂程度、是否需要其他同学协助；

2. 测试排期，何时介入测试，留给测试同学的时间有多少；

3. 是否规划接口自动化，是否需要接口测试用例review等。

2、分析测试内容

前提准备：

准备好客户端与服务端的通信协议文件（rpc文件）；

主要内容：

分析客户端与服务端的通信协议，整理出需要进行测试的接口，并找服务端程序同学确认是否有遗漏；

分析原则：

重要接口全覆盖，其他接口根据测试时间和功能复杂度决定；

重要接口的定义：

涉及到货币变动（包括数值积分），涉及到物品变动（新增、删除、合成、强化、洗炼等一切编辑行为），涉及到高价值荣誉（称号、排行榜、全服公告等）；

产出结果：

得到需要测试的接口清单，及其参数信息。

3、设计测试用例

接口测试的用例设计大体分为两块内容：输入参数测试用例和处理逻辑测试用例。有一点需要特别注意的是，该阶段设计测试用例时，并不要求必须有用例的“预期结果”（该步骤会在下一步完成）。

1. 输入参数测试用例

调用接口时，都需要附带零个或多个参数，针对接口附带的参数设计用例遵循以下规则：

（1）区分必填参数和可选（可以为空）的参数，每一条用例都应该覆盖所有必填参数，且对可选参数进行组合。对于多参数接口，需要关注参数是否区分顺序，一次调用同一个参数填写多次，某些参数被遗漏等常见情况。

（2）判断每一个参数的数据类型，确认数据类型符合预期，不满足该类型的参数输入后的表现。

（3）对于参数类型为数字的参数，需要注意各种情况下该数值的边界值，这里的边界值不仅包括正常用例设计上的边界值（0，下限，上限，负数，小数等），也包含实际业务类型中的边界（例如某类型积分存在周获取上限，则获取时该上限值也成为边界情况）。

（4）对于数值类型为字符串的参数，需要注意字符串的长度和合法性，例如对于接受“玩家全局id”作为参数的接口，不仅要测试长度为空和输入非法的情况，还要测试传入一个“语法规则合法，但传入的玩家全局ID属于其他玩家”的情况。

（5）对于数据类型为自定义列表（table，dict，list等格式）的参数，则可以将其当做嵌套的接口，对于列表内的每一个元素进行上述的分析，除此之外，还要关注列表内元素的数量，元素的顺序，重复元素，矛盾元素（同样的标识key内容却不一致）等情况。

（6）关注参数之间是否存在关联，包括单个接口的多个参数之间存在关联的情况，也包括多个接口之间，A接口的回调可能用作了B接口的参数的情况。

2. 处理逻辑测试用例

接口输入参数虽然合法，但是在接口实现中，也会出现异常，因为内部的异常不一定是输入的数据造成的，而有可能是其他逻辑造成的，程序需要对任何异常都进行处理。

以下对常见的处理处理逻辑测试进行简单的说明，实际测试过程中，可以结合具体情况选择编写用例：

（1）大数据量测试：指数据量大，事务复杂时，接口内部处理事务可能会因为开销过大，耗时过长等失败或无响应。

举例：某游戏批量分解99999个某道具时，业务响应时间会超过3s。

（2）幂等测试：一个“幂等接口”，指的是可以使用相同参数重复执行，并能获得相同结果的接口。对一个通过幂等测试的接口的重复执行不会影响系统状态，也不用担心重复执行会对系统造成改变。

举例：某活动结算后，需要玩家手动去领取奖励，此时连续调用两次接口，预期结果为玩家不会领取到两份奖励。

（3）环境异常测试：指业务环境异常时，原本正常工作的接口需要能正确应对和处理突发情况。

举例：活动相关的接口在非活动时间是否需要可以被访问；需要顺序执行的接口如果打乱顺序是否会造成状态异常；接口相关联的服务器开关被关闭时接口如何响应；玩家处于跨服镜像模式下是否会导致数据丢失等。

（4）并发测试：指多用户在短时间内对同一个接口进行调用，可能会导致部分用户的请求响应失败。这类测试用例如果需要执行，一般情况需要单独设计压力测试场景和用例。

（5）安全测试：少部分情况下，别有用心的用户可能会利用接口对游戏服务进行攻击，从而对产品进行破坏或期待恶意获利，虽然RPC协议框架本身可以对这一类攻击加以限制，但在接口测试时也需要注意该方面的问题。

举例：部分接口会以玩家的全局ID作为参数，玩家调用时本应传入自己或者队友的ID，个别玩家为了骚扰其他玩家，向接口恶意传入其他玩家的ID，如果接口没有校验ID的合法性就处理业务逻辑，就会对被传入ID的玩家造成骚扰。

4、执行测试用例

接口测试用例的执行相比较普通游戏业务测试而言较为复杂，执行门槛也比较高，原因主要是因为随着测试左移的不断推进，QA介入接口测试的时机越来越早，执行接口测试时多数情况下并没有完整的客户端逻辑，如果想要确认用例的执行结果，不仅需要对整体业务逻辑有较高的敏感度，从而可以合理地推测“如果这一步会出错，可能会出怎样的错”，还可能需要阅读业务逻辑代码，访问服务器后台内存池，访问数据库等多种复杂操作。

在执行接口测试时，对于每一组测试用例，可遵循以下的处理步骤：

1. 确认用例的预期结果

之所以要将“确认用例的预期结果”作为单独的测试步骤来说明，是因为接口测试本身是具有“破坏性”的测试，并且脱离了客户端与服务端的正常交互逻辑，也就意味着传统的用例设计中的一些交互逻辑在接口测试中不适用。

例如：“发送聊天信息”的操作，假设某游戏对玩家在世界频道的发言次数存在限制，某玩家用光次数后仍然尝试发言，此时客户端必须给出“发言次数不足，发言失败”的系统反馈，如果该反馈缺失导致点击发送按钮无响应，则可以认为是一个测试不通过的用例；但如果该玩家尝试通过直接调用接口进行发言，那么只要服务端没有通过该次操作，无论是否给出接口回调反馈，都可以被认为是一个测试通过的用例。

因此，对于特定的某一组测试用例，如果是一组合法的用例，那么可以按照正常的业务逻辑进行用例设计；如果是一组非法的用例，只要测试执行过程中满足如下条件，大多数情况下就可以被认定为测试通过了。