关于python游戏协议自动化框架的一些思路

前言

　　游戏的协议测试，如果只是单协议的测试，只需要用socket/websocket进行协议收发即可。如果要以框架的形式实现，主要需要解决协议返回不确定这个问题，这里可以提供一个思路，当然，这只是我个人的见解，仅供参考，思路如下：

　　游戏的协议测试，其目的主要是为了防止出现后端逻辑处理不当被玩家通过修改发送协议手段进行刷货币、刷道具等操作的问题。所以我们的协议测试，主要是集中在货币变更、奖励获取等处，其中奖励发放的形式主要有两种，其一为直接进入背包，其二为通过邮件发放，因此，我们需要监控的协议有，

　　　　一、背包新增道具；

　　　　二、背包道具数量变更；

　　　　三、新邮件的获取；

　　　　四、玩家属性变化(大部分的游戏中，其玩家货币直接以属性的形式记录)；

　　　　五、发送协议的返回

　　例子1：发送协议，内容为货币充足购买次数充足情况下购买1个商城道具，我们的预期显而易见，收到的返回协议有：一、发送协议的返回；二、背包内道具的变化(新增或数量更改)；三、玩家属性的变化(对应货币减少)。

　　例子2：发送协议，内容为货币充足购买次数充足情况下购买0个商城道具，其返回内容为：无返回

　　上面已经监控了五个主要协议，程序在收到返回后，将返回状态记录为“服务器返回数据”并将收到的协议内容记录并显现出来，以方便我们查看返回内容是否符合预期；若无返回，则将返回状态记录为“服务器未返回数据”。这便是单协议的测试框架思路。

协议自动化

　　通过asyncio+socket/websoket实现后端逻辑，asyncio的异步、并发、协程对于自动化来说非常实用，可以在完成自动化的同时顺带实现模拟多用户同时在线的效果，具体的库代码可以自行去google上查阅

async def main(firstusr, lastusr):
    if isinstance(firstusr, int) and isinstance(lastuser, int):for i in range(firstusr, lastusr):
            # your program
            ...

if __name__ == '__main__':
    asyncio.run(main(firstusr, lastusr))

　　后端逻辑中的思路也很简单，便是收到协议A->发送协议B(或B+C多重协议组合)，因为每次测试角色登录是必不可以少的行为，可以直接将登录的协议收发写进框架里面

　　  

　　由于发送协议的内容是不定的，可能需要根据不同的标识发送不同的协议，也有可能是根据一个标识发送多个协议，如果将全部的标识和协议都设置为测试人员去创建，会显得太过于繁琐，违背了简捷的原则，因此需要将多条测试用例合并以提升用例创建的效率，以下，便是一个可以参考的思路

 

 

 

　　其中TESTPROJECT行，为整个自动化测试用例的用例名。

　　其子行为自动化测试的操作，即发送的协议，内容主要有收到的协议标识(协议号系统号)、发送的协议标识(协议号系统号)、具体的协议内容、等待时间。

　　子行的子行，为相同协议的合并，内容主要有具体的协议内容、等待时间。

　　举个例子，比如说玩家行走到某一地点后释放技能的自动化测试，首先在拿到服务器发给程序的协议标识时(如协议0,6)，需要在发送一个目的地坐标后(如协议10,2)，不停地发送当前坐标给后端进行坐标更新，这不停的定时发送新坐标，就可以在子行的子行中添加，在到达目的坐标时收到到达的协议(如协议10,3)，发送释放技能的协议(如11,1)，这样便省去了输入协议标识的时间，用例也内容也更简洁可观。

　　Creator中的5为等待时间，由于页面设计的缺陷，空间不足，只能先将等待时间放于此处，后续再进行改进

 

　　以上，便是关于游戏协议测试的自动化一部分见解，关于前后端如何交互的问题，便等后面有机会再写了，咕咕咕