光の技术屋

《Game Of AutoTest》的最后一篇文章，聊一下游戏自动化测试的价值。

一千个人心中有一千个哈姆雷特。仅以笔者的角度，游戏自动化测试的价值，可以体现在这几个方面：

• 效率提升
• 缺陷发现
• 质量监控
• 技术支持

做好自动化测试的价值分析，不仅能够自动化测试技术落地做足理论基础，而且也能在任意时候指引自动化技术落地者做好当下的决策，从而逐渐把自动化测试做出更大的规模跟成果。

近期装Ubuntu22.04虚拟机，发现侧边菜单栏多了个Floppy Disk图标。软驱这东西毕竟是上世纪的了，2022年也没什么用，但就是找不到入口去掉这个冗余的图标。

今天偶然之间发现去掉图标的方式，供大家参考：

• 右上角点电源/声音/网络按钮，选择Settings设置
• 选择Appearance，就是能调Light/Dark风格的页签
• 下拉，在Dock栏目下，点击Configure dock behavior
• 里面的Show Volumes and Devices下，有一个Include Unmounted Volumes项。反正软驱一般也不会挂载，所以取消点选这个项，Floppy Disk图标就没了。

正值十一假期，近期准备把自己的python笔记精编整理，做一个pdf电子书。在调研如何把多个markdown文档转化为单个pdf的时候，试了很多种方法。最后找到了最佳方案，也就是本文的主角，由phodal前辈整理的电子书生成项目ebook-boilerplate。这个项目不仅支持批量转markdown为pdf，而且还支持转成ebook等多种格式。

使用这个项目的时候，也踩了一些坑，需要做一些额外的配置。以笔者的场景为例，电子书生成环境是Ubuntu22，需要转化一堆中文的markdown。clone了这个项目之后，除了ebook-boilerplate本身README.md里描述的内容之外，实际还需要留意以下环节：

在游戏自动化测试技术落地过程当中，如何保证自动化测试的稳定性，是一个需要重点优先解决的困难问题。

以手机游戏客户端自动化测试为例，和一般服务架构的自动化单元测试或集成测试不同，自动化驱动的过程，其本质更加类似于网络爬虫，每次测试执行都是一个时间较长的过程，而流程一长，不稳定因素则随之而来。游戏自动化的整个过程，大致是这样的：

• 前置环境准备（setup）：设置用例运行环境、设备状态与玩家状态，保证用例运行的条件
• 用例脚本执行（run）：执行自动化用例脚本
• 后置恢复操作（teardown）：恢复测试环境、设备状态与玩家状态
• 测试报告输出（report）：整合跑测期间游戏的运行数据与用例脚本收集/导出的数据，生成测试报告

要分析如何保障整个自动化过程的稳定性，我们可以根据这几个步骤进行细节切分，对每一个环节影响稳定性的因素逐个理顺，从而最终，我们就可以得到一整套自动化稳定性保障的解决方案。在这四个步骤当中，前置环境准备和用例脚本执行这两步，对自动化流程稳定性的影响面最大，而最后面两步的影响程度，则相对较低。

近期笔者因工作原因，需要做一个安卓手机的文件浏览功能，集成在笔者以前用PyQt5做的一个的工具当中。文件浏览功能大概做成这样：

• 一个列表界面，列出某个目录下的所有文件名（不区分文件和文件夹）
• 双击某个文件名，尝试进入这个文件名代表的文件夹（文件的情况会失败）
• 右键某个文件名，弹出上下文菜单，可以进入这个文件名对应的文件夹，也可以复制路径到其他的输入框

其中，文件列表选型用了QListView组件，但在实现兼容双击进入文件夹+右键菜单功能时，稍微踩了下坑。为了解决这个问题，笔者在网上查阅了许多资料，最后找到一种解决方法，决定记录于本文当中。

首先需要了解，Qt对于QListView这类数据容器组件，是遵循MVC的设计模式的。QListView数据的初始化，方法是这样的：

在2年以前的一篇文章中，讲述了游戏UI自动化方案GAutomator的基础机理、使用方式和一些工具扩展的想法。今天，趁着Game Of AutoTest系列的连载，结合游戏自动化技术选型一文，笔者将深入剖析GAutomator作为UE4安卓游戏UI自动化方案的实现机理，以及自己在实际工作中对GAutomator的优化实践。

工作原理

GAutomator是这样的调用链路：

自动化在技术层面上，除了基础的技术选型之外，最终还是需要落实到具体的工具框架，才能够助力我们自动化脚本开发的过程。因此，本文将讲述一下如何对游戏自动化测试框架进行设计。

在上一篇文章讲到，自动化测试的方式可以有客户端、服务器、编辑器三种方式，除了编辑器需要强依赖引擎层面的特性之外，其他两种自动化方式在工具或者框架的技术实现上有这么几个特点：

• 框架模块设计具有共通性，只是最终执行自动化用例/脚本的方式不同
• 许多框架模块可以不依赖游戏本身的特性去实现，可以实现很多企业业务功能的集成
• 由于和产品没有太多的耦合，可以做成易于在不同项目测试之间迁移通用的形式

考虑到当前我国有许多游戏企业的工作习惯是，测试由中台dispatch到各个项目，不直接参与研发过程（Code Review？不存在的），项目产品以提测的方式交付测试，测试侧可以运用自己的测试手法和工具去完成任务。从这样的角度看，拥有一个功能性强且通用的自动化测试工具，不仅是对于项目所需要自动化测试的场景，更是对于测试组整体的技术基建提升而言，都显得非常重要。

以笔者工作经验为参考，要做到游戏自动化框架得以通用，设计上需要遵循如下准则：

今天这篇文章，聊一下python在web开发上的一些基础实现，阐述下自己理解中的WSGI、ASGI，以及拿uvicorn+FastAPI的组合举个ASGI应用的例子。

WSGI

python的web服务的诞生，其实追溯到一种机制，叫做WSGI，全称Web Server Gateway Interface。WSGI的提案来源于PEP-333，可以理解为一种python-web-server和python-web-app的接口通信标准。在这种场景下，python的web服务呈现以下的工作模式：

• python-web-app，也就是web应用层，实现WSGI接口，用作web请求的handler
• 用户向python-web-server发送web请求
• python-web-server，又称作WSGI Server，解析请求数据，整理当前session的环境信息
• python-web-server加载python-web-app，调用python-web-app实例的WSGI接口，处理请求
• python-web-app处理完请求，返回结果给到python-web-server
• python-web-server写回返回结果，给回用户

代码上是这样的表现，以官方提案的例子为例：

要做游戏自动化测试，首先需要了解游戏自动化技术。因此，本文详细讲解下游戏自动化测试领域可能用到的一些技术以及对应的场景，为自动化测试落地的技术选型提供参考。

游戏自动化测试的测试对象是游戏本身。对于游戏这个概念，可以有以下几种：

• 客户端：我们实际玩到的游戏本体，比如说PC程序，手机App，Web-App。
• 服务器：在多人网络游戏中，用以模拟游戏世界的本体。
• 编辑器：包含未烘焙到OS平台的游戏程序以及资源。

我们在技术层面上所要做到的，就是通过某些方式访问这些程序运行环境产生的内容，改变游戏呈现以及玩家行为，操作玩家或游戏程序本身，达到我们的测试目的。在笔者的工作经验当中，主要做的是UE安卓客户端的自动化，应用场景主要在业务功能测试方面，因此本文会对客户端自动化做稍微详尽的解析。其他自动化的方案和叙述，如果其中描述有所纰漏，恳请指正。

客户端自动化

针对游戏客户端的自动化，在游戏测试里是最为广泛应用的，不仅是因为客户端是一个游戏必须有的成分，而更加因为我们在手工测试游戏的时候，实际是拿着客户端来测的。因此，客户端自动化会最贴合游戏功能测试的需求。

要实现客户端自动化，有以下的方法：

2022年的8月，结束了很长一段时间的犹豫，笔者决定开启新的文章系列：《Game Of AutoTest》，向外界公开自己近两年来在游戏自动化测试方面所沉淀的工作经验，以及许多关于自动化测试本身的思考跟想法。在先前的测试人生栏目中，曾经分享过许多关于游戏自动化测试的技术，但并没有一个比较系统化的输出。因此借这个机会，笔者也决定好好分享一下，从一个更加纯粹的技术人的角度，对于游戏自动化测试这一细分领域的理解。

自动化测试本身已经不是一个新鲜的名词，不论是游戏还是传统互联网行业，我们都能够见到自动化测试落地的身影。但是，自动化测试基础技术到底需要往怎样的方向搭建，业务应用需要覆盖哪些场景，这些话题其实很少被讨论，并且实际沉淀下来的知识分享和业务产出，也不尽然特别引人注目。尤其在游戏测试领域，自动化测试如何被应用到实际测试工作当中，相关的沉淀是少之又少，可以算是一片待开垦的荒地。

游戏自动化测试——这个名词本身都没有一个确切的定义。有些人认为，只有像自动驱动客户端玩游戏，测试场景物件是否正常交互，这种能够实际测到和测试用例相关的内容，才算是自动化测试；也有些人认为，像一些纯粹收集性能数据的场景，比如驱动玩家在地图里跑图，收集前后台数据，也算是自动化测试。这说明了，只要是用了程序化的手段，去完成游戏测试的整个或一部分的流程，那么就有可能被定义为一种游戏自动化测试的方案。但遗憾的是，正因为如此，很多测试工作者为了让自己的工作有技术含量，都会尝试沾自动化测试技术的光，为了技术而技术，用一些现成的自动化工具去做了个demo规模的东西，然后很阿里味地包装成富有技术含量的测试工作，但实际上相对于原来反倒增加了学习、维护、执行成本，是毫无价值的负优化。其中原因，归根到底，还是自动化测试这个工作被很多人小看了。如果你是个测试工作者，但业务经验、技术能力以及良师指导三者都很缺乏，并且业务环境上没啥落地场景，组织氛围也没啥支持的话，要做好自动化测试，那是非常困难的。

因此，我们有必要去重新认识游戏自动化测试这个概念。有几个准则：