光の技术屋

UE4本身支持在前端会话中执行自动化测试功能。有了它，我们可以用C++编写对应的自动化脚本，在编辑器的生命周期中随时随地运行，测试整个研发系统的子功能。

要深入了解UE4自带的自动化测试功能，可以参考自动化系统概述文章系列。而本文则介绍最简单的接入UE4自带Automation自动化测试的方法，以UnrealAutomator插件为例，提供一个最小的插件+Automation的范例

python语言，一般适用于快速实现业务需求的用途，在大型架构方面其应用范围并没有Java、Golang以及C++那么丰富，因此相对来讲还没有形成非常统一的技术体系。在某些需求中可能需要开发多个服务，服务之间需要实现异步通信，甚至是调用对方的函数。celery就是一个典型的例子，它提供了以将python函数注册到消息队列的方式暴露服务的方法，并且支持RabbitMQ、Redis等多种Broker中间代理形式。

celery同时也支持多个python的web框架，在其介绍页中，也明确说明了Tornado、Django、web2py等框架都有自己的celery实现方法，当然要知道其他框架的实践，可以上github上探查一番。

celery简便易用，本文笔者以自己整理的start-fastapi为例，讲述接入celery的方法。

在日常python编程中，有很多遍历文件夹内文件的需求，而os.walk方法就是一个满足该需求的例子。不熟悉这个方法的同学，刚开始用os.walk的时候难免踩坑。因此本文采用源码分析的方式，讲述os.walk的机理，让大家对于这个方法有更加深入的理解。

以python3为例，os.walk方法的源码如下：

近期为了丰富UE4插件UnrealAutomator的基础功能，在ProfileService中增加了LLM数据获取的方法。LLM拥有抓取UE4底层模块内存使用情况的功能，各种Modules按照LLM的规范实现相应宏即可将内存使用数据实时更新到LLM系统中。如果从产品外部，是难以直接访问这些信息的。

以UE4.24为例，用C++在UE4插件实现LLM数据获取的方式如下：

UE4游戏/手游自动化测试有很多方案可以执行，不论是传统的UI测试方法还是具备前瞻性质的以图像识别+机器学习技术为主的方法，都能够满足不同的需求。适逢1024节日，受到GAutomator和PocoSDK的启发，笔者近期决定开始UE4专属自动化测试插件UnrealAutomator的研发。当前已经集成并扩展了GAutomator的UI信息检索功能，已经能够满足UI测试服务端的基本需求。

UnrealAutomator的核心愿景，是希望集成游戏QA同学日常测试需求相关的功能到统一的插件当中，并在稳定的通信协议基础上设计易于扩展/二次开发的SDK，让各个UE4手游测试组能够比较容易地根据自己的需求去进行定制。相比较原有在UE4上的解决方案，PocoSDK的UE4插件并不能够像GA一样，通过AndroidWindow获得安卓手游的控件的精确位置；而GAutomator的UE4仅仅是集成了UI检索的功能，剩余的功能都需要GAutomator Python Client Module实现，且由于GA Client Module直接在代码实现中耦合了UIAutomator跟WeTest的相关功能，二次开发极其不方便。因此，UnrealAutomator将采取如下的方案解决这些问题：

前些天在写UnrealAutomator的Web解析模块的时候，遇到了一些USTRUCT方面的问题，由于笔者以前并非UE4程序员，因此踩了一些坑，果断分享一下踩坑历程。

首先聊一下USTRUCT的生成。USTRUCT是UE4的特性之一，从非C++/UE4程序员的角度来讲，USTRUCT、UPROPERTY、GENERATED_BODY之类的概念类似于注释和装饰器的作用，可以在编译等时期将代码标识的内涵纳入自己的Runtime。举一个例子，UnrealAutomator中的UIModel.h：

Jetbrains家的IDE，默认安装之后，配置和插件都存储在系统特定的文件夹中，如果是Windows系统的话，就会在用户文件夹存储。这样就滋生了一个问题：随着插件等安装的越来越多，系统盘也会占掉一些空间，这个时候就有了转移默认插件与配置路径的需求。今天就以IDEA为例讲述一下如何操作。

很久以前写过一篇文章：《测试、策划与开发，谁来把控游戏的质量》，聊了一下测试、策划和开发三者的关系。时至今日回头来看，大方向还是差不多的。在某些地方，测试地位低，被策划跟开发冷眼相看，所以让他们开心就好；在某些地方，测试、策划和开发也可以在同一层次上讨论需求与研发过程的好坏。说白了，把控游戏质量，是三个部门一起的责任，而且测试并不是必须要为策划和程序收烂摊子。

游戏自动化该怎么做？这是一个值得探讨的问题。在中国，用手游自动化来描述，可能更为贴切。游戏自动化技术并不难以上手，有许多现成的工具提供使用。但是，要想做好游戏自动化，让其真正服务于游戏研发/运营期业务，并不是一件容易的事情。

大型的游戏项目包含许多错综复杂的业务逻辑，针对UE4游戏而言，如果纯粹采用C++编写的话，一方面会增加大量的劳动成本，影响效率，另一方面难以解决游戏热更的问题。lua作为胶水语言，能够与C/C++/C#等语言互通，简化业务逻辑编写，并且支持热更。针对UE4的游戏开发，UnLua以及sluaunreal都是采用lua编写逻辑的解决方案。

作为一个没有怎么接触过游戏开发技术栈的小白，本文主要上手UnLua的使用。