如何快速上手接口测试？

点击文末小卡片免费获取软件测试全套资料资料在手涨薪更快大量线上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对于数据类型为自定义列表tabledictlist等格式的参数则可以将其当做嵌套的接口对于列表内的每一个元素进行上述的分析除此之外还要关注列表内元素的数量元素的顺序重复元素矛盾元素同样的标识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客户端调用聊天接口发送给BB通过客户端直接观察执行结果。4多个玩家——复杂服务例如跨服PVP赛事跨服匹配等。这类业务建议请服务端同学协助梳理每个接口的影响范围及观察结果的手段可以有效提升测试效率。举例如果需要对跨服匹配进行接口测试相比QA同学自己去看代码研究匹配逻辑不如请服务端同学简单讲解下“管理玩家匹配的进程的业务处理逻辑及数据结构”保存一些常用的代码片备用。例如跨服PVP赛事跨服匹配等。3. 执行测试用例并记录执行结果此处的用例执行和普通业务的用例执行区别不大需要注意的是接口测试经常会对测试环境造成污染要避免因为脏环境和脏数据带来的误报。5、接口测试自动化基于接口测试的各类特性将其内嵌入自动化测试脚本中的性价比很高不仅自动化测试代码的开发成本低暴露的问题往往都还是关键问题。这一步需结合各项目的的自动化框架或协议测试平台开展此处不再赘述。最后下方这份完整的软件测试 视频教程已经整理上传完成需要的朋友们可以自行领取【保证100%免费】​​​软件测试面试文档我们学习必然是为了找到高薪的工作下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料并且有字节大佬给出了权威的解答刷完这一套面试资料相信大家都能找到满意的工作。