光の技术屋

策划表格数据检查是游戏测试工作的刚性需求。在游戏开发期中，有大量bug的起因是策划同学在配置上不够规范到位。因此作为测试角度而言，需要更加便捷、更加精准的方法去定位到策划表格配置的问题。除了依靠业务人员自身对业务的熟悉程度之外，也更加依赖于一个强大有力的工具，辅助表格数据检查。

表格数据检查的目的有以下一些：给定某个数值策划案，检查实际配置与策划案是否有出入；给定某个配置规则，检查实际配置是否有不符合规则，造成风险的地方（除去程序导表检查的那一部分）。针对这些需求，简单粗暴的方法就是强行coding的方式，将读取表格（Excel）数据出来（或者将表格数据转化为程序文件），然后用编码的方式联表，继而通过coding逻辑，去导出不符合规则的数据。这一种方式虽然灵活，但对于业务侧同学，还存在壁垒以及需要突破的地方：

• 壁垒：业务侧同学的技术能力，通常难以hold住coding的技巧。从技术人员角度而言，涵盖大量代码的臃肿的表格检查规则，可读性很差且难以维护。
• 突破：相较于人肉检查表格数据而言，时间的消耗主要在“联表”这一操作上面。游戏内部逻辑相对复杂，策划表之间的数据也是紧密耦合，比如一个宝箱抽取，就有可能涉及4~5个表的相互关系。如果不能够解决联表耗时的问题，表格数据检查的效率会大打折扣。

因此总体来看，除了采用coding这一备选方案之外，另外一个较好的方法是采用声明式、配置化的方式描述表格检查规则，通过一系列数据处理规则的串联，导出来一份最终数据。这样一来相对减少了学习成本，从业务侧角度而言，从“学习coding”变成了“理解配置”；二来解决了联表效率的问题，业务侧只需要描述一个联表的数据处理规则，后台就可以自动按照规则描述的方式对数据处理，最终呈现到业务的，直截了当，就是最终的结果；三来解决了根本目的，不论是策划案比对（通常是另外的文档，不能按版本diff）还是检索不合规的数据，本质上都是数据导出，因此用数据处理规则的串联，就能解决大部分的需求。

在UE4游戏开发中，官方文档推荐了2套功能：Data Driven Gameplay Elements以及Programming Subsystems。我们可以结合这两者的功效，实现一个简单的表格配置数据管理模块。

Data Driven Gameplay Elements讲述了一套通过DataTable数据表的asset驱动gameplay的方式。在C++代码中，我们可以预先定义好表结构所对应的USTRUCT，然后通过导入CSV文件的方式，去创建以该USTRUCT为结构基础的DataTable。这样在游戏里，如果需要读取配置数据的话，就可以直接在蓝图中添加获取DataTable以及获取行数据的节点，填写对应的asset路径与rowname（表格主键，以---为标题的列），就能够获得对应行的数据了。注意这种方式如果在需要热更的手游中是不适用的，需要用其他的方式（比如将表格配置转化为lua）

Programming Subsystems讲述了UE的Subsystem编程模式。Subsystem重点解决了单例Manager在游戏中生命周期的问题，并且能够直接导出方法到蓝图中，供蓝图侧调用。因此，Subsystem一个很棒的用途，就是分担BlueprintFunctionLibrary的工作。

以下，我们观察一个利用Subsystem模式在C++侧创建一个DataTable Manager的功能实例：

2021，新的开始，曾经精心制作的轻量级web后端框架start-fastapi也经历了一次升级。这次升级，是基于这一年来使用start-fastapi开发以及应用与业务工作的经验，对已有框架进行的结构性的优化。

start-fastapi，甚至是FastAPI本身，其专注的方面都是在快速实现轻量级应用当中。在升级后2021版的结构中，针对如何更加效率地组成FastAPI应用，下了很多手笔。我们可以一探究竟：

呼吸不停，coding不止。代码艺廊新系列，将要用来陈列自己的大小作品；极客日常系列，则专门用于分享新的技术心得。开年第一作，介绍一个自制用于管理代码仓库的小工具repomaster。

代码仓库管理在许多场景能够用到，比如用作构建集群的文件缓存、构建配置的代码仓库服务、配置导出与检查等等，其中最后一种需求在游戏QA的工作场景（导表检查）会是一个比较重要的需求，而repomaster的设计方式也会更加贴合管理大量同一个repo不同checkout副本的情况。作为一个纯靠内存作为缓存，无需持久化数据的应用，repomaster在技术选型上，Golang一定是最合适的语言（共享内存+方便的并发控制）。只需要少量的代码，就能够搭起来架子。

当前的repomaster已经具备如下的功能：

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：