游戏测试 想请问下游戏测试行业的大佬,游戏测试开发,除了我下面提到的,还可以做些什么来帮助测试团队提升输出质量与效率呢

水山 · August 30, 2020 · Last by 热狗 replied at October 27, 2020 · 9318 hits
本帖已被设为精华帖!

目前已经做了的事情:
1、基于AirTest的自动化测试,这个目前最大的用途是给已经上线稳定运营的游戏的写的一个回归测试,其他的用途暂时没有挖掘出来。

2、协议测试工具,修改客户端网络层收发协议的方法,基于Unity Editor形式,写了一个插件,作用是拦截复制客户端发送给服务器的协议,然后修改、重发协议,达到欺骗服务器的目的。大概长这个样子:

3、基于UWA的静态资源检查自定义规则,补充了一些规则,比如检查prefab中引用的图集是单图还是图集中的图

4、AirTest+PerfDog 实现性能测试自动化

5、表检查工具,检查策划的配置是否有常见错误

6、一些小工具,比如测试同学提的需求,基于python win32api的连点器

目前掌握的技能:
python、C#(这两个熟悉程度差不多,不敢说精通,很多时候写代码都是边查边写)

Unity(学这个主要是觉得Unity的编辑器扩展对于写嵌入在客户端的工具太方便了,比如上面提到的协议测试工具)

各种工具什么的就不说了。

想问的问题是:
我还可以做些什么来帮助测试团队提升输出质量与效率?

共收到 46 条回复 时间 点赞
水山 #1 · August 30, 2020 作者

不要劝我转游戏开发哈,我对于游戏业务开发没什么兴趣,对于能够帮助测试团队提升效率和质量的工具开发很感兴趣,非常认可测试开发这个岗位。

难得看到有游戏行业的测开发帖哦~
基于unity的话,unity的editor还是挺好使的(当然,还是看unity版本)。曾经自己也做过类似的小工具,用来做GM、简单的接口测试等。
就我了解的,目前行业内有公司在做基于Airtest搞的自动化测试框架,但方向我不太认可。那边主要是用Airtest来把尽可能多的黑盒用例写成自动化脚本来跑,而且暂时只有上线很久的项目会写,新项目因为得不到项目组支持(需要接poco sdk,还有部分二次开发)所以没做。而且那边基本都是卡牌项目,Airtest的话,纯UI的东西操作起来倒是没太大难度。

然后关于自动化这方面的东西,就我目前了解的内容,UI的方向我认为你已经做了大部分了,UI回归脚本、性能测试是主要方面。
如果还需要补充的话,就是根据不同的项目,做定制需求的自动化脚本。比如重复打开各个界面,看客户端的性能啊(主要是看是否有内存泄漏,当然,也是跟项目有关。)

接口方面其实能做的更多。当然了,不清楚你这边是什么项目,而且也没真正做过接口,所以不确定做的话会做成什么样子。但如果可以的话,根据协议文档,针对每个协议编写用例,然后执行用例,各版本在测试环境都能稳定回归,确保协议方面ok。协议这方面呢,暂时能想到的是参数的类型、个数、等价类、边界值。比如曾经的项目里遇到过把商城礼包的参数类型从1改成0.01,然后这样玩家就能无限刷这个礼包。

然后可能的话,最好能做成自动化集群。

然后协议这方面呢,如果能搞定一个自动化的协议框架,那么也就能搞后端的压力测试了。针对可能产生压力的场景,用写成一系列的协议机器人去压服务器。

暂时能想到这么多,有不对的地方还请大佬们指正~

水山 #3 · August 30, 2020 作者
JarvanRay 回复

我总结了下,你的建议大概是以下4点。我一一回复下:
1、根据不同的项目,做定制需求的自动化脚本
2、根据协议文档,针对每个协议编写用例,然后执行用例,各版本在测试环境都能稳定回归,确保协议方面ok
3、自动化集群。
4、搞定一个自动化的协议框架,那么也就能搞后端的压力测试了。

回复1:
这个目前没有接到过这样的需求,可以跟测试同学聊一下,看他们有没有类似的需求

回复2:
这个是一个很好的建议,应该跟传统https的接口测试是一个道理,只不过游戏换成了测试基于protoBuf的协议。这方面我花时间去探索下

回复3:
这个不太懂具体是描述什么,涉及到什么技术栈,能够解决什么问题,可以详细展开聊一下吗?谢谢

回复4:
你说的这个类似于机器人的东西,程序已经实现了一个,就是用于压测的,我也阅读过这个工程,确实有很多值得借鉴的地方。

最后,感谢老哥的耐心回复~

水山 回复

客气,难得看到有能交流的帖子。
其实集群这个我也没做过,但如果要搞自动化的话,集群肯定得搞的。
说白了,集群就是用一个系统来管理自动化要使用的各种设备,比如测试机什么的。
如果要搞自动化的话,集群是必不可少的。有了好用的集群,才能更好地应用自动化

可以尝试用TestRunner对一些重要的方法做单元测试

你们的UI自动化测试是基于单设备的么,那用例数量和回归时间是在什么量级呢

测试的目标不一直是模拟用户场景吗
比如你负责的游戏有个团战的场景,怎么模拟游戏角色,怎么验证各角色发出的指令的响应结果、UI展示以及响应延时。
先针对单一产品设计方案,然后沉淀下来看怎么扩展到其他产品成为通用解决方案。
协议测试工具如果能生效,是不是意味着有被攻击的风险?这里的安全怎么考虑呢。
另外不太明白为什么需要欺骗服务器,拦截、转发都是拦截器的功能,跟游戏产品无关,如果是为了增加测试覆盖度,通过参数化多设计一些用例会不会更好点。

水山 #8 · August 31, 2020 作者
活在当下 回复

好的,我去了解一下

水山 #9 · August 31, 2020 作者
喵喵喵 回复

因为目的不是测适配,所以没有搞集群多设备跑,就是几台设备跑回归,回归时间就是小版本迭代前,用例数量这个,能保证核心功能基本都能遍历到

水山 #10 · August 31, 2020 作者
MarvinWu 回复

关于你说的协议测试工具的作用这个,我举个例子说明吧,比如,商城里面购买商品的协议,我把购买数量从正常的数值10修改为-1,然后发送给服务器,如果服务器没有校验异常数据的话,就有可能处理错误。协议测试工具的作用就是为了找出一些服务器没有校验的安全BUG

盲猜你是游戏研发部门的测开?个人感觉还有两部分内容和研发测试比较相关的:
一个是测试环境治理,毕竟研发版本太多太杂了,测试环境的部署是一个问题;
另一个是保障回归测试的路径覆盖率,怎么从程序改的版本里筛选出需要测试和不需要测试的用例,这个对于测试来说还是挺头疼的,毕竟不能每次都全部测一遍,工作量还是太大了。

redcafe_wei 回复

你提到的两点,从个人的经历来看,
1.测试环境部署。这个我觉得有必要测试自己来搞定。当然了,肯定会需要花时间、人力跟程序沟通,但如果不让测试部署,那么版本控制就无从谈起。毕竟,我还是很认可《游戏测试精通》这本书里提到的“不要相信任何人”的原则。也经历过开发做版本控制,结果就是一团糟,而且开发认为自己做了不该他们做的事情。
2.回归测试的路径覆盖率,个人认为,首先是根据对项目的熟悉程度以及和开发沟通好,确认需要验证的内容(过程确实很头疼),所以如果版本稳定并且团队能力到位的话,可以适当的将自动化测试利用起来。但目前还没有哪个团队真正的能在项目中实践的。

JarvanRay 回复

嗯,环境治理当然需要测试自己搞,但测开的介入可以提高效率。关于第二点,鹅厂应该是已经在搞了。

1个人能做成这样已经蛮不错了 。。
如果你们公司只有游戏业务,那可以考虑下这些:

  • 接口测试平台 主要用于每个版本的接口测试回归。 你做的Untiy插件更适合一些新功能的测试,但是不太适合大规模的回归测试。 我们接口测试全量用例一个游戏得有1W多条
  • 项目组如果是主干开发,可以考虑帮忙搭建一套CI流程 ,每次提交会触发该流程,从策划表检查、美术资源检查 到客户端拉起检查、服务器起服检查 等等
  • 游戏配套的辅助工具,比如帮忙批量造号 模拟批量玩家战斗 移动 、抽卡概率检查工具 等等 ,具体得跟项目组QA同学沟通
  • 压测工具, 主要针对服务器端的压力测试

然后已有的工具可以不断调优 加入新功能,比如策划表检查 可以支持更多规则; Airtest可以给对自动化有兴趣的QA同学培训,赋能给向项目组QA一些简单的脚本开发能力 等等等

单数 回复

接口测试平台这个,确实是可以搞。但是对于能产生多大的作用,心里还有点没谱。
CI流程这个,我们目前采用的是瀑布敏捷式开发,打包、打表在jenkins上都有集成,可以做到一键出包。
压测工具这个,目前程序自己开发了一个机器人工程,可以做到这个事情,我最近打算把这个工程好好看一下。

水山 回复

测试开发风景很大,有些需要开发到后面和接入更多项目会找到不足。主要来回复,游戏压测其实还是测试团队做比较好,工作这些年也看到过很多各种不同经历的“风景”,目前来看开发自己做还是比较大问题的。

做得挺好的,我在学Python时也受过朋友帮助,尤其是煎饼,下面列3个可以完全用Python开发的浅见。

一.图片资源检查(长期项目):
作用:比对图片资源二个版本(包)更新差异,这个基础上先查出2次图片修改新增差异,后面配合其他的比如性能恶化,再去查图片素材导致花屏,性能影响点更合适;有IP公司可以用于,IPQA审核图片用。
美术素材的纹理文件类型检查,比如开发了软解功能,在部分区域的美术素材纹理是有固定检查标准,或者是升级了etc压缩格式等级,也是有固定检查标准的。
核心思想为unity和虚幻之外的,用unzip解包来做,比对2个包的素材位置的md5,如果素材有加密,需要用加密之前的包。
虚幻不了解,Untiy Assetbundle后无法看,所以要拿2次工程里面的图片打个压缩包来做。
残留资源检查:
读取lua中引用图片的地方,去抓取出来放到列表里,然后去遍历整个工程,就可以找到残留图片资源,这个优点是减少包体大小。

二.自动化前置组件(1-4)
最佳实践,不使用一个文件去驱动整个自动化,使用jenkins流水线调起根目录的各python文件(把自动化行为拆分为前置和中间部分,后置)可以一个功能一个文件,所以前置会有多个文件,去年我做了,最后可能也没时间去解释为为啥分文件,没用起来。
自动化流程前置(按顺序):
1.取包 包管理区域(比如挂载盘,jenkins,软件管理软件等等)获取包
2.解包扫描 代码自动备份包,解包为备份包。检查包内区域文本的敏感信息和文字信息是否可读,协议描述文件位置(protobuff)是否解开可读,资源如果是加密的是否后缀和前缀可识别等,这里如果有安全组件还可以添加这里,我司无。
3.图片资源检查 上面的,把信息记录下来。
4.安装手机处理弹框
5.启动应用,应用启动后标记 对应手机模拟器信息。如果这里有客户端埋单检查组件当然也可以加进去(比如畅游埋点就是客户端服务端都有,然后二则匹配。)

三.增强配置表检查工具 检查点(长期项目):
这个的确你自己也列过了,但是所说是一个增强部分。
公司方面是看你服务需要服务一个项目还是多个项目,多个项目就是要考虑用代理模式。项目组--->代理--->rule,从rule那边抽离共性给项目组用。上百个规则时,用这个可以让代码清爽。
如果是一个项目,可以考虑在检查规则时,顺带把策划配置表用代码把接口要的参数抽成几张表,导入数据库内(!需要每个版本都要导入)。可以服务辅助接口测试,接口测试细的来说,需要验证参数结果是否对(比如3个任务一共获得了多少资源,当前资源记录下,资源数检查点来源就是从数据库里面取导入的策划配置的数据)。

之前项目做过一款协议工具,实现思路是拦截客户端的包,根据文档去解析协议,修改协议值去做协议测试。后面有根据这个协议工具做了协议收发器,自动反射,做了一个压测工具。

skottZy 回复

挺好的,使用文档解析协议也是一种思路。收发器层是一种应答式的,会不会把线性写压测case进入收发器变成同步处理了(全局设置是异步到收发器需要等待还是可以变成同步的)。另外反射从描述文件那边取会不会有点不是很快。

陈子昂 回复

美术资源格式检查这一块,由于欠缺了一些材质、纹理、贴图相关的理论知识,所以之前没搞过这方面的东西,后面可以去学习下。
第二个关于包体静态检查自动化这部分,以前没有这么思考过,感觉确实可行,列入到我的计划里面去了。大佬666
配置表增强检查这个,自己思考过一些,比如数值不光检查类型,检查范围,超范围就给警告。

skottZy 回复

我也是这么干的,不过由于程序把压测工具已经做了,所以就没有继续深入了

单数 回复

大佬,能分享下接口测试平台的大致功能吗?现在能想到的问题:
1.接口测试环境如何维护,docker还是什么的?
2.接口的用例是如何生成、编写的?
3.接口测试平台,是否相当于是客户端的一个简化版本?只有收发协议、客户端发送心跳等
4.既然涉及到自动化,那结果如何验收呢?直接在用例里加上断言?
5.接口测试什么时候会执行?什么时候编写用例?
7.执行策略,每次都是全量验证,还是增量部分验证?

水山 回复

1.配置表下面还有一部分是说把配置表把接口测试,需要使用部分存储数据库。
2.美术相关的,可以看官方引擎推荐,加油。还有多余资源检查等,只要正则和提取数据能力。

JarvanRay 回复

1.游戏服务器由开发提供,接口测试平台我们自己Docker部署
2.用例是手写啊,根据功能用例和分析协议 自己写接口用例 ,异常参数的话可以膨胀生成
3.除了这些之外 ,剩下的都是平台功能,比如批量执行用例,生成报告,数据持久化等等
4.用例里需要写断言条件 ,主要是判断回包的协议和参数
5.每次新版本做回归测试的时候跑 ,
6.新功能的话来不及写就下次补上,一般都是跑全量。

单数 回复

感谢!

恒温 将本帖设为了精华贴 07 Sep 10:34

楼主想问下AirTest+PerfDog 实现性能测试自动化,是怎么实现的?
PerfDog没有提供API,只能手动运行起来,再跑自动化脚本😂

吴秋楠 回复

用Airtest先给PerfDog工具本身写一个自动化脚本(windows的),再给游戏写一个性能测试专用脚本,然后两个脚本别用IDE的方式执行,用命令行的方式分别执行。即可

水山 回复

Mac,没救了

吴秋楠 回复

airtest也可以用命令行跑吧?具体官方的博客啥的都讲很清楚了我记得。
而且先启动啥之类的手工操作,airtest也完全可以胜任啊。

请问下我们是多进程通过airtest测试的!怎么结合AirTest+PerfDog运行?
PerfDog多台手机能同时检测性能数据吗?

陈子昂 回复

不会,不是全局的,写的时候就有做预留,每个实例不共享。反射速度依然是可以接受的。

水山 回复

最近在做一个hook工具,拿网卡里面的数据,hook 对应进程的socket,实现发送,这样好处是代码量不会特别大。解析协议就够了。

4、AirTest+PerfDog 实现性能测试自动化

大佬能分享下这个的实现吗? 用airtest+perdog跑完之后,数据采集怎么做的,还是直接在腾讯的网站去看,还是爬到本地做个excel

水山 回复

你们是接入poco还是基于图像识别,怎么解决不同机型的等待时间问题呀,感觉这个脚本是最操蛋的,如果用图像识别,得考虑识别率和不同机型加载情况,下wait和sleep也不靠谱。。还有分辨率。。

接poco的话还没尝试过,项目不准侵入SDK。。。

项目不准接入sdk可还行……
我之前做过接入sdk的,用poco来实现控件查找。所以你遇到的问题,可以通过poco查找控件来处理,经过操作之后,等待某个控件出现,只要出现了,就继续,否则就报错。

JarvanRay 回复

我觉得大佬们可以写个文章普惠下游戏测试圈的小老弟们,这对他们会是很大的帮助,像上面几个人提到的问题就是,从搭建到实现,踩坑的点。

JarvanRay 回复

命令行跑airtest肯定可以呀。
但是airtest只能起Windows的应用,Mac不行,所以Mac下perfdog部分必须手动启动

吴秋楠 回复

感觉你的想法有点局限了。mac也能用命令行启动应用吧?没必要非得用airtest去启动perfdog吧?

能做的事情有很多,但都能用起来不一定,如果你有一定的话语权,可以把平台铺起来。

  1. 自动化测试平台 ,可以参考市面上的云测,只不过内容更加专项和细致,这里已经够喝一壶了,性能,回归 等一系列都是在这,前期可以拆成小功能来实现。
  2. 你们的测试都是用unity直接跑游戏还是打出来的PC,手机包?其实大部分最终的验收应该是在手机上,封包编辑器扩展可以脱离unity。参考大厂自己封装一个sdk 进行通讯,这样可以做的事情有很多。
  3. 图片识别 解燃眉之急可以,长期就算了,局限大,不稳定。

  4. 不要小看一些小工具,可以省很多事,问问测试平常的需求和流程,用工具解放大部分重复的劳动,做成工具链

如果你发现费尽心思做出来的东西使用率不高,推广不开,说明方向错了。

1、自动化方面,建议自己去深入理解Android和IOS的自动化原理,前期使用Airtest快速成型,后期以自主实现,别人家的始终是别人家的,自己的在需求方面可以有更多的扩展性,自定化除了回归及性能测试外,可以在稳定性和适配以及一些重复性的工作上有很好的应用
2、接口测试建议脱离unity,单个项目没什么问题,但是在有多个项目的情况下需要多次接入,浪费时间和人力成本,制作通用工具只需要在项目初期接入一次协议解包和组包接口即可,可以更高效的支持多项目需求
3、压测,接口测试和压测工具是相辅相成的,接口工具可以为压测提供协议录制功能,接入的协议解包和组包接口也可复用与压测工具,压测方面还是建议由测试来做,程序做的不保险经常出漏子,最快的实现方案是基于Jmeter做Socket插件开发
4、包体安全方面的测试,主要涉及反编译,这个比较高深,需要汇编知识,但也是非常重要的一项
5、研究性能测试原理和实现方法,自主实现,可以更好的集成于自有体系
6、前后端的单元测试、内存泄露检测等
7、持续集成
8、建议去了解下测试中台概念,往做平台方向考虑

要是这个讨论贴早一两年就有的话,我起码不会蹉跎岁月😂 ,到了今年才转专项测试。
1.UI自动化同样用了airtest,配套写了测试框架跟测试平台
2.协议测试目前用jmeter,想弄个协议测试工具还没头绪
3.性能测试是服务端写好的机器人+PerfDog监控客户端的数据,客户端数据监控上面的测试平台也能监控,奈何PerfDog比adb获取的频率高太多了,真香
4.写一写自动化脚本,处理大量复制粘贴的手工活
5.整理流程文档/培训教程,规范如何UI自动化、协议测试、性能测试
6.安全测试是后面学习的方向
最后,都是志同道合的点点点,何不拉群PY一下

Author only

请问lua中protobuf.encode的消息,如何在c#中decode呢? 纯小白提问 --已经解决

游戏自动化测试,我们公司也刚起步,大神有兴趣来带我们飞吗?目前我们主要在开展AI自动化,主要跟AI相结合,进行自动局内外检测~

JarvanRay 回复

你是不是没用过perfdog。。。启动应用是简单,启动后要操作perfdog的,这块perfdog那边没提供接口,只能走界面

其实一个月前就看到老哥的分享了,一直忘记也来参一脚回复一下。现在我做的工作也是类似的事情。你的观念我也一样很认同。测试是技术岗位,他也是需要发展进步的。我们不可能一直在这样的行业里面一直干重复的事情下去,整合现有的情况,做出能方便大家提高产出的事情确确实实是有必要的。面临要不要转开发的这种问法,更是来源于测试总是比较低端的固有思想,但是只要相信自己每天能有收获,做的事情具有意义,那便值得坚持。
空话说了一堆,实际上我想说的也因为大家都讨论过而没有多少。这里觉得只能提供一点思路,那就是接口层面的,一定比UI层面来的更具有定向针对性,也能更高效的发现问题,不管是利用unity或其他引擎中,让其提供插件接口来进行对应数据的调用验证,还是针对专项的各种服务接口,这些都比UI来的实用有价值一些。但UI也并非一无是处,部署、持续集成、与设备交互装包到冒烟,以及涉及各类渠道SDK,直至游戏主要流程冒烟测试实现,这些都可以是跟UI相关的。掌握更多的工具和方法,也是必要的。如果结合OCR,实现关键字驱动,点击每个界面上对应按钮识别出文字的位置,那就可以以写汉字的方式来驱动UI自动化脚本了,当然从目前来看技术还没有那么成熟,深度和广度也需要权衡,实际效果也需要观测。。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up