做得挺好的，我在学 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 个任务一共获得了多少资源，当前资源记录下，资源数检查点来源就是从数据库里面取导入的策划配置的数据）。

不过最近的技术发展是很快的，分享一些个人的研究心得吧。

1. OCR：结论是用开源的 PaddleOCR 就好了。探索过程比较坎坷，避免别人重新踩坑吧。下决心搭之前去官网的 demo 看看效果。
2. 脚本编排：只要是按顺序编排脚本的，不愿意用 sleep，就只能使用 wait_until_apear 等特定图片出现。不过现在有腾讯开源的 GameAISDK，其中 UIReg 那块儿就是另外的思路，这个框架很酷，他们有专门出一本工具书，买一本还是值得的。
3. 图片识别：大家可能真的有些误解，目前大部分能用于自然场景的图像算法用在游戏中算是绰绰有余的，比如 airtest 用的特征匹配只需要稍微过滤一下误匹配点就好了。之前帮友人用 python 翻译了用在自然场景里的处理方式，感兴趣的可以来看一下https://github.com/MishimaAsuka/svf 。另外的结论是：文字最好用 OCR，3d 模型最好自己用 yolov3 训练个分类器。
4. AI 自动化：结论是用 GameAISDK 吧。别想太多，非利益相关，咱自己有一套框架，而且因为整过这个活儿才得出这个结论。还有一个实际问题，缺游戏的数据集，非常缺。

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

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

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

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

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

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

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

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

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

感谢指点！

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

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

汉字方式不太推荐会有大坑，汉字等于理解为支持自然语言和模板的一种开发模式，互联网业务被验证，BDD 也只有一小部分可行。
游戏不太好搞。可以了解下命令设计模式。

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

从部门需求来讲，以下几个方面优先级最高，也是测试开发最需要研究的地方：

1. 服务器性能测试，比如模拟 3k -5k 个虚拟机器人 pvp pve login
2. 安全测试，基于协议的安全测试，任何和金钱 有关系的协议都是重点高危区域。
3. 客户端性能测试，一台安卓机器跑自动化不是难点，难点是 top30 top50 机器都能自动完成性能测试并完美收集数据。

测试开发并不是一门心思研究测试里面的开发技巧，部门期望的是用技术手段完成手动测试无法完成、但又不能不做的测试任务。

协议自动化这块我这里刚好在做，机器人搭建好后也可以做压力测试，我说说我这块的实现，不知道是不是你们想的哪种：
技术栈：docker(Jenkins+Gitee+Python(pytest+allure)+robot(websocket+pykka+sproto))
1.根据协议文档编写协议测试用例，基本是一条条用例写，多数用 Excel，复杂场景用 .py
2.用例编写完成之后 Git 提交推送
3.Jenkins 检查到更新/定时开始执行 shell 命令
4.shell 命令是执行机器人登录，然后 pytest 执行对应的测试用例
5.执行完毕之后生成测试报告
大概是这样

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

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

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

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

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

感谢！

用 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 查找控件来处理，经过操作之后，等待某个控件出现，只要出现了，就继续，否则就报错。

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

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

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

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

3. 图片识别 解燃眉之急可以，长期就算了，局限大，不稳定。

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

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

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

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

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

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

我们也是 protobuf，不知道写接口测试怎么去做

我回头开个帖子写，你说用什么语言的。。

wait 和 sleep 是啥原因不靠谱阿，不是等到元素出现么，然后最长等待大不了写 20s，那么无论是在 3s 还是 10s 的时候（不同性能下）只要元素出现了就继续。

目前还是在实习的实习生，有个问题想请教一下。如何实现通过自动化批量测试、不同机型，不同系统版本能否正常登录游戏这个需求呢，指出方法或工具足矣。目前还只是一个小游戏公司，公司里的测试人员都只是功能测试，但我想做得更多一点 向上发展。

非大佬，强答一波

既然提到 “帮助测试团队提升输出质量与效率”，那就不只自己所在测试组里面的事情了，做的东西得想到既能够应用到项目业务内容，又得考虑如何方便地让其他的项目应用，实现知识共享

首先自动化测试，看具体什么用途，如果是功能测试冒烟性质的，起码得保证运行时间多，反馈频率高（嗯，就是纳入日常冒烟测试环节），否则没法体现代替人力的作用。最好提炼一个脚本框架跟一个平台满足自动化用例的快速编写以及每周甚至每日运行的需求，UI、脚本等等的支持都可以搞上，打好基础之后就可以玩花的了（对，说的就是异常图像识别、AI 自动化之类的东东。。。）

协议、性能测试，涉猎不多，不敢多说。

表格等周边工具，这种就会是五花八门各扫门前雪的了，如果要做到通用性好，除了本身稳定性高之外，还要考虑接入规范跟灵活性（比如配置扫描是否支持自定义配置导出脚本与 non-code 的扫描规则、是否支持 docker image/helm 的接入方式，是否支持公司内部技术栈等等）。核心功能说白了就那样，但通过一系列包装能让工具更加易用，能让工具被更多人使用，工具的价值才会体现。

总之很多东西，细细挖掘就会发现一个人的力量难以完成，所以还有个很重要的点是能够创造机会让大家一起讨论交流，挖掘更多需求，沉淀技术产出。。

接口测试工具可以试用一下国产的接口测试和接口文档生产工具 apipost：https://www.apipost.cn/?dt=2020

想请问一下楼主，表检查工具是怎么实现的呢，检查的程度是？

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

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

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

国产不安全

现在有 perfdogService SDK 了，直接集成到 UI 自动化里面，生成 excel（聚合分析），json（生存 html 数据曲线）报告。我都搞了一套

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

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

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

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

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

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

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

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

好的，我去了解一下

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

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

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

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

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

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

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

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

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

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