游戏测试 游戏接口自动化的一些问题

ownSecurityGuard · 2022年09月11日 · 最后由 HiKari 回复于 2022年09月30日 · 12558 次阅读

开头

中秋节突发奇想,尝试说能不能搞出通用点的游戏协议测试的工具,撸了一天代码。 越写越感觉少了什么,由于本人工作经验较浅,所以希望大佬指教一波

这边在开发过程,产生了一些问题:
1、各位大佬,平常在做游戏接口测试是怎么做的呢?我在想要不直接走 jmeter,然后自己这边选择开发波插件会不会更加容易接入呢?大佬们,你们在选择这类工具中会注重的是什么呢?我这边的考虑就是说尽量避免增加开发的工作量,只要开发给 proto 文件和编解码方法,剩下的就让我们自生自灭即可
2、因为游戏接口除了方式不一样外,其实和 http 接口测试没啥差别,可能需要再考虑下服务端会主动推协议和预期协议的捕获这类的。写的工具也参考了 Python 那一块接口测试的东西
3、最后问一个非常实际的问题,有没有大佬在实际工作中开展过,游戏接口自动化测试,然后比较成功的那种。我怎么总觉得收益不大,游戏版本迭代太快了,真的有必要搞么?

游戏接口测试

  1. 正常情况,游戏接口测试都是走 TCP 协议,数据传输类型应该大多数都是 Protobuf 格式才对,应该只有些历史项目会用 JSON 或 xml 之类的吧 (没做过调查,单纯的猜测😂 ),自定义格式的话,应该只有极少极少数会这么搞吧就不考虑了。目前我这边目前就只考虑 Protobuf 格式,tcp 链接。
  2. 每个公司都会有自己的一个数据传输规范,但既然走 TCP 和 Protobuf,就一定逃不掉 TCP 的头部要带有请求协议的协议 ID(能够让服务端知道后边的这一条数据对应的 proto 消息是哪一条的 id),及包体长度,序列号等 (我想了很久,tcp 头部必须带请求协议的协议 id 这应该是绕不掉的,如果还有其他的特殊情况,大佬给告知一下)。除此之外,服务端需要对数据做相应编解码。

故综上所述,这款工具接入准备有:

  • proto 文件
  • 编解码方法
  • 请求协议和协议 id

github 地址:https://github.com/OwnSecurityGuard/gameProtoTest
目前只是个 demo,比较粗糙

先直接说一下,我这工具的两个设想:

  1. web 项目, 一开始是打输直接搞成 web 项目,在 web 页面操作,在浏览器上输入协议名,及其对应参数,后台去维护一条连接的方式,但后边实操下来,操作略微繁琐 (对前端要求较高,但这边也简单实现了一版,使用 postman 的 websocket 也搞一波,但操作起来比较难)
  2. 脚本形式 后边想了想就搞成了以 yaml 配置文件的方式来进行。可以通过在 Yaml 上做配置,依赖 goconvey 自带的 web 页面来实现接口测试和管理

工具的基本逻辑:
解析 yaml 文件的数据, 加载 Proto 文件,依据协议名,还有参数,先使用参数构造 json 数据,再将 json 数据转为 protobuf 格式,发送。以单测的形式运行,去生成对应的用例,不用编写单测,只需编写 yaml 即可构造用例,而且 goconvery 功能非常好用,可以以 web 的形式展示用例,和运行。目前这一块断言还没有完全完成,估计得到国企才有空 了。。。
实现方法 (永远的调包侠,yyds)

  1. 使用第三方库 github.com/jhump/protoreflect 对 proto 消息进行一个动态的解析,即把 json 数据和 proto 数据的一个互转,依据协议名称得到协议结构等等
  2. 使用第三方库 github.com/traefik/yaegi ,动态加载编解码方法,原本是打输用动态链接的方式实现,这样其他语言只要使用对应的方法格式,编译成对应的文件,golang 能够动态调用,但奈何 go 的这一块的东西目前还不完善,无法做到类似热更新的方式(我要是用 java 就好搞了。。。)。
  3. 编解码方法的格式我这边定为了

    Encode func(data [] byte, mesId int32, seqId int32,s ...string)([] byte,error) 编码方法
    Decode func(conn net.Conn)(tarData [] byte, seqId int32,msgId int32) 解码方法
    非常粗略,感觉抽象程度不够,还不够通用,之后还细化一下,但感觉应该能满足需求了😅

github 地址:

使用说明
安装 go 1.16
安装 goconvey
go get github.com/smartystreets/goconvey
项目根目录 go mod tidy 一下
一切就绪后,
1、修改 first.yaml 文件的文件路径,建议改成绝对路径,所需文件均在 service 目录下。
2、 修改 tcp.go 文件中的 YamlFilePath,改为项目中的 first.yaml 的绝对路径
3、 运行 service 下 testSec 的 main.go 文件,可直接在改文件目录下,go run main.go
4、 在目录下,直接运行 goconvey, 进入页面 127.0.0.1:8080.即会开始加载 yaml 进行测试
目前这边工具使用了 Go 语言开发

ProjectName: "firstTest" ## 项目名,目前什么用都没有,
ProtoPath: "testSec" ## proto文件存放目录路径  建议修改成绝对路径
MesIdPath: "data.csv" ## 协议名对应协议id
CodecPath: "debugCodec.txt" ## 编解码方法
ServerHost: "127.0.0.1:9791"  ## 服务器地址
Proto:
  -
      name: LoginReq  ## 测试协议的协议名
      param:
          name: "username1"   ## 参数 若是有嵌套关系,可 a.m: 23 == {"a":{"m":23}}
          password: "password2"
      asserts:            # 断言 ,目前未实现
          -
            ProtoName: LoginResp  # 响应的协议
            Check:
                -
                  key: greet
                  expectVal: 1234

最后还成功搞出个 Bug(看来得国庆再来修一波了。。。)

最佳回复

越写越感觉少了什么——少的其实是不知道这个工具实际会怎么用,用在什么测试场景
游戏协议测试有个重要的点是能够绕过客户端屏蔽,相当于是可以测试到服务器的协议参数判断,好比某个玩法你只玩了 1 关,你发了个进 99 关的协议,要是服务器没做前置关卡通关校验,你游戏里直接进 99 关,那还得了
建议跟业务测试深入聊聊,确定下工具要做到的功能跟效果,再继续着手开发

共收到 9 条回复 时间 点赞

首先呢,游戏既然是软件,就同样遵循软件的测试方法和流程。
1.平常在做游戏接口测试是怎么做的呢?我在想要不直接走 jmeter,然后自己这边选择开发波插件会不会更加容易接入呢?
直接使用 JMeter,不做别的开发。
2.因为游戏接口除了方式不一样外,其实和 http 接口测试没啥差别
是的,和 http 接口测试差别不大,除了协议可能不一样。
3.我怎么总觉得收益不大,游戏版本迭代太快了,真的有必要搞么?
游戏版本迭代快,只要是新需求引起的而不是已有需求频繁变更引起的,自动化测试可能收益更大 (迭代快则脚本执行轮数多)。是否有必要搞自动化,需要对软件所处阶段、团队自动化测试技术能力、预期收益及公司支持力度进行综合考虑。

protobuf 自带 json 转换的

问题 1:游戏接口测试 (我习惯喊协议测试) 一般都会在功能测试阶段进行,点点点的时候顺便把数据通过 GM 命令或序列化接口把数据序列化发给服务端;Jmeter 我用的少,没啥发言权;
问题 3:我和题主出发点不一样,我是基于压力测试的需求才写机器人,后续延伸的协议自动化,收益得结合投入成本来算,像我这里的情况多个项目都是用同一套框架,写一套多个项目通用,成本已经剩下很多,目前我觉得收益较大是项目版本迭代更新前后数据对比。

skottZy 回复

知道的。我就是这么搞的

A_Jian 回复

这里前后数据对比,指的是性能表现方面的么? 接口测试或者说协议测试,我想的是主要是对边界值之类的测试,通过一个工具,搞成自动化,方便回归这样。基于压力测试的话,基本关注点都是在跑正常流程,和协议测试的侧重点感觉不大一样,虽然可以用同套工具

但是协议压测还是挺大不同,协议测试、压测需要保持长连接,协议需要关注边界、业务逻辑,压测需要关注响应时间、cpu 占用等等,这里对 protobuf 的处理是类似,对压测来说,需要根据回调去处理对应 case,协议测试则不太需要关注这一点

skottZy 回复

压测一般 protobuf 都是用插件转成对应语言的接口,就是不知道 json 转 proto 效率咋样,不然这套逻辑可以干成压测用的逻辑,直接用 locust 起个 master,压测过程中区上报数据,感觉还行

pb 接口的话是 google 官方给的,json 的话明显效率上是不够的,越多机器人,效率越低下,一般是函数注册,locust 你还需要自己去改 socket 保持长连接,压测可不是只看高并发的时候,往往很多业务逻辑需要跑一段时间才能发现问题

越写越感觉少了什么——少的其实是不知道这个工具实际会怎么用,用在什么测试场景
游戏协议测试有个重要的点是能够绕过客户端屏蔽,相当于是可以测试到服务器的协议参数判断,好比某个玩法你只玩了 1 关,你发了个进 99 关的协议,要是服务器没做前置关卡通关校验,你游戏里直接进 99 关,那还得了
建议跟业务测试深入聊聊,确定下工具要做到的功能跟效果,再继续着手开发

ownSecurityGuard 关闭了讨论 11月27日 22:36
ownSecurityGuard 重新开启了讨论 02月24日 18:01
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册