接口测试快速上手指南

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

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

01 为什么要接口测试

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

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

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

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

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

……

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

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

02 如何进行接口测试

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. 确认用例的预期结果

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

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

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

玩家未能利用接口成功绕过客户端限制；

服务器没有崩溃、卡顿等性能问题；

没有对服务器的其他数据造成污染。

2. 确认接口影响范围及检查执行结果的方法

不同的接口由于涉及到的业务和技术架构的不同，其执行结果影响范围也不同。这里针对一些常见的业务和技术架构，列出一些检查执行结果的大致方法：

（1）单个玩家——简单服务

例如：修改自己的个人信息，上传一张图片，查询自己在排行榜的名次等，不涉及敏感业务。

这类业务最为基础而相对简单，几乎只影响玩家自身数据，通常执行结果都会通过某个接口回调，也可以通过检查玩家自身的指定数据确认执行结果。

（2）单个玩家——复杂服务

例如：领取活动奖励，交易行买道具，充值等。

这类业务相对比较复杂，而且是玩家牟利的重灾区，执行接口测试用例时，不但要关注接口回调和玩家自身的数据，还应去检查对应服务的管理器是否能正常影响业务逻辑，对于异常业务逻辑是否能及时报警等。

（3）多个玩家——简单服务

例如：多人聊天、组队、添加好友等。

对于MMORPG而言，这类业务数量最多，影响范围也最广，但是相对其他业务而言，出现问题时的破坏度较低。这类业务可以结合客户端表现进行接口测试，例如A客户端调用聊天接口发送给B，B通过客户端直接观察执行结果。

（4）多个玩家——复杂服务

例如：跨服PVP赛事，跨服匹配等。

这类业务建议请服务端同学协助梳理每个接口的影响范围及观察结果的手段，可以有效提升测试效率。举例：如果需要对跨服匹配进行接口测试，相比QA同学自己去看代码研究匹配逻辑，不如请服务端同学简单讲解下“管理玩家匹配的进程的业务处理逻辑及数据结构”，保存一些常用的代码片备用。

3. 执行测试用例并记录执行结果

此处的用例执行和普通业务的用例执行区别不大，需要注意的是，接口测试经常会对测试环境造成污染，要避免因为脏环境和脏数据带来的误报。

5.接口测试自动化

基于接口测试的各类特性，将其内嵌入自动化测试脚本中的性价比很高，不仅自动化测试代码的开发成本低，暴露的问题往往都还是关键问题。这一步需结合各项目的的自动化框架或协议测试平台开展，此处不再赘述。

 

总结：

感谢每一个认真阅读我文章的人！！！

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

 

          视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。