游戏测试-接口测试

标签：游戏   sina   uid   href   更改   限制   ref   组件   输入   

接口测试原理

测试系统组件间接口的一种测试。

接口测试主要用于检测系统与系统之间以及内部各个子系统之间的交互点。测试的重点是检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

接口测试要点

针对游戏，在接口测试时需要注意的地方：

重复请求已完成的数据。 ——快速获得需要一定劳作才能获得的奖励。

更改请求状态。——获得当前不能获得的东西或状态。

更改UID（角色ID相关）。——移花接木。

更改ID，重复请求。——获得了后，再次请求不应获得的奖励等。

验证掉落。——掉落掉落表里没有的物品。

更改数量为负数。——验证是否处理负值。

并发请求实现。——并发会导致可能没有做相应处理的返回。

测试手段和方法

无论哪种方法去实现测试，其原理是通过一定手段和途径模拟客户端向服务端发送请求，服务器接收请求后把对应的处理返回给客户端，客户端实现响应的一个过程。

利用工具测试：

Charles是基于HTTP传输的XML、AMF、HTML的测试工具。

WPE是基于Sockets传输的TCP、UDP的网络封包编辑工具。

具体使用分析可参考：

http://wenku.baidu.com/view/2a790e61783e0912a2162a50.html

Loadrunner

Java + Fitnesse

具体使用分析可参考：

http://www.51testing.com/html/66/n-814766.html

手动测试方法。

测试依据：将客户端发送的请求视为“不合法”操作。根据数据存储原理，在处理存储数据的时候，对数据库数据进行修改，让客户端的数据请求“不合法”。即客户端的一切都是假像。

手动测试会用到游戏客户端，是从另一个角度去审视请求是否合法。

这里的测试方法涉及到，服务端、缓存、客户端之间的数据交互，需要排除缓存数据对测试结果的影响。通常来说，客户端发出的数据请求，先在缓存中寻找数据，如果缓存中没有，就去数据库取。在手动进行接口测试时，需要保证缓存数据和数据库数据一致。否则，测试操作往往会得到“错误的”测试结果。

在网页游戏测试过程中，如果某个数据有用到缓存机制，比如在未修改时，缓存数据=DB数据=2，客户端呈现的数据=2；如果直接修改DB数据=0，不修改缓存数据，那么在使用1个数据时，会先使用缓存数据，使用一个后，缓存和DB交互会使得DB数据=-1，从而不能达到测试目的。

一般网页游戏测试过程中，会提供清除缓存的途径，使得修改DB数据后，清除缓存使得直接取DB的数据，达到测试结果的准确性。

在测试过程中，往往不会知道缓存数据是否和数据库数据一致，但测试员一定要知道，什么数据是与缓存有关，什么数据是直接和数据库打交道。

介绍下手动测试的方法：

修改数据库数据。

进行测试操作时，需要注意修改数据库数据时，客户端要保持没有请求发送（那样返回的数据会刷新客户端显示，造成测试操作请求的“合法”）。例如修改数据后，不能再打开目标操作界面，打开操作界面会重新请求界面数据显示；不能关闭客户端再开启。

示例1：测试数值判断；比如物品价格=10币，角色身上有100币，修改数据的金钱数量=9币，然后执行购买，这时通过购买判断，正确的结果应该不能购买。

示例2：测试状态判断；比如完成一个任务A，没有领取奖励，这时数据任务状态=完成未领取奖励，修改数据库该任务状态=完成已领取奖励，然后客户端执行领取奖励操作，这时通过领取条件判断，正确的结果应该不能领取奖励。

示例3：测试负值；比如在购买时，输入负值（一般客户端会限制负值输入，但服务端的判断必不可少），输入负值后，执行购买，通过购买判断，正确的结果应该不能购买。（不然就送钱出去了）

示例4：更改ID；比如A玩家已穿戴的装备，修改数据库使得装备的userID=B，在客户端A卸下穿戴的装备，通过卸下判断，正确结果应该是卸下不成功。（因为服务端认定这件装备是B已穿戴的）

总结：通过示例，可以泛用这种测试手法到近似的地方。

程序提供工具。（测试员的幸福，具体原理是一样，就不细说了）

接口测试的重要性

不借助工具进行接口测试，不能覆盖到所有测试需求。因为工具可以完全绕过客户端，对服务端发送测试目的性强的请求，以此来判断程序逻辑是否有疏漏。

特别是并发请求的测试，单线程并发和多线程并发。这种情况不可能通过手工测试达到测试目的。

单线程并发，虽然手工测试可以覆盖状态判断，但是同一时间多次请求，如果没有相应的处理机制，也可能发生一劳多获的漏洞。

多线程并发，有个示例可以说明其严重性：

一次BOSS战中，BOSS快死了，假如HP=100。A、B2个玩家同时间杀到。A伤害>100，B伤害<100。悲剧发生了，A杀死了BOSS，B一刀下去BOSS没死；更悲剧的在后面，A杀死了BOSS，击杀奖励发！A击杀BOSS公告发！B的结果BOSS没死，然后路人C一刀下去BOSS死了，C杀死了BOSS，击杀奖励再发！C击杀BOSS公告发！——玩家就崩了~

还好，这种情况的发生往往需要巧合，发生后可以通过查看日志来分析产生原因。

接口方面产生的漏洞往往会导致刷物品、刷金钱、刷属性。并发性的漏洞，往往很难发现和重现，如果不能及时发现和修复，会一直是一颗隐藏的炸弹。

一句话：在发生悲剧前找出并修复漏洞，这才是测试存在最直接的价值。

 来源于:http://blog.sina.com.cn/s/blog_89998f670101kd16.html

游戏测试-接口测试

标签：游戏   sina   uid   href   更改   限制   ref   组件   输入   

原文地址：http://www.cnblogs.com/R-bear/p/7189414.html