光の技术屋

在python开发期间，由于GIL的原因，不能直接采用并行的方式处理代码逻辑。在multiprocessing库的支持下，python程序能够启动子进程执行特定的任务，但子进程的管理也成为了问题。为了简化用户开发成本，python在concurrent.futures下内置了ProcessPoolExecutor这一数据结构，实现了简单的进程管理及任务调度。如果没有特别的需求，开发者只需要用ProcessPoolExecutor即可实现并行执行任务。因此，本文简单对ProcessPoolExecutor的实现进行分析，帮助大家更加了解python开发中进程/任务调度的一种方式。

首先来看ProcessPoolExecutor的用法，可以参考官方文档

• constructor：构造器
  • max_workers：最大worker数量
  • context：进程启动方式，比如spawn、fork等。可以参考这篇文章
  • initializer：初始化环境用的回调/钩子，会在传进去的任务执行之前调用（比如要import什么库，读取什么配置之类）
  • initargs：初始化回调的参数
• submit：提交特定任务，返回一个future实例（类似于js的promise）
• map：批量submit
• shutdown：关闭进程池并销毁资源

可以看到用法非常简单，用户一侧只需要这样操作即可得到任务执行结果：

golang的数据类型转换是困惑新gopher的一大问题之一。相对于python，golang的数据类型转换可要麻烦的多，而且还不走寻常路地诞生了些新的方法跟名词。因此本文讲解golang常见数据类型string、int、rune等数据类型相互之间的转换方法，给大伙儿避坑。

在讲述方法之前，首先非常有必要讲下go源码对这些数据类型的表述：

在先前的《游戏策划表格检查工具的一种设计》一文中，笔者分享了在一般游戏测试业务背景下设计策划表格检查工具的一种方式。本文基于先前文章的内容，将原先的表格检查工具升级为表格测试工具，涵盖更多的内容，并对其中部分技术实现进行分享。

测试工具架构设计

整个测试工具分为两个部分：

• 仓库管理服务：负责管理多个策划表格的svn/git仓库，并涵盖导入表格数据的功能
• 表格测试服务：负责接收用户的测试请求，向仓库管理服务请求特定版本的数据，执行表格测试任务

测试工具的整体架构如下图：

UE4在构建场景光照时，会启动swarm agent进行构建，但如果只用一台电脑会出现构建速度较慢的情况。为了加快编译的效率，需要配置联机渲染。

首先需要注意的是，在UE4中自动打开swarm agent和手动打开swarm agent会用到不同的配置。因此，建议的方法是手动打开swarm agent进行配置（对于所有机器），然后再开UE4。每个swarm agent以及调度器swarm coordinator的可执行文件位置，都在引擎的Engine\Binaries\DotNET下

在官方文档中，有Unreal Swarm配置的例子可以参考。假设你有一台性能强劲的机子，和一台你日常工作但性能一般般的机子。这样可以如下配置：

许多游戏，尤其是MMO，会包含“副本”这个概念，玩家通过打副本从而获得物品奖励及属性收益。通常来讲，单个游戏所涉及的副本数量/品种较多，因此在游戏测试过程当中，很难一次性全部遍历完所有副本的流程与玩法。为了解决这个问题，可以通过自动化测试的方式去冒烟副本玩法流程、检查奖励。为了让自动化测试用例执行更加稳定且易于维护，需要一套通用的逻辑模版去实现副本玩法自动化。自动化测试流程涉及多个部分，包括玩家账号的准备、副本的进入、副本流程、奖励检查，而本文主要考虑“副本流程”的实现。

副本玩法的机制可以如下描述：玩家在进入副本后，服务器会为玩家创建一个分线并让玩家执行切线操作切入副本内，而后下发副本信息，客户端则缓存信息，为玩家创建场景及指引，而后玩家根据指引游玩副本内的内容。每当玩家执行了特定的行为，比如走到指引的位置/干掉指引的怪物，就会触发这些指引绑定的触发器，触发器生效后，服务器就会同步触发出来的下一阶段的信息给到客户端，客户端便展示出下一阶段的指引，直到副本结束或者发生错误、意外退出为止。从副本机制可以看到，副本玩法的每一个步骤，在客户端中都有缓存相关的信息，在自动化的实现上，只需要每一个轮次读取副本信息，执行相关的行为即可（任务也是如此）。因此，我们可以设计如下的行为来自动跑副本：

excel-differ是游戏测试常用的测试工具。在有些业务场景下，excel-diff的结果可能需要通过web展示。Vue技术栈下的vxe-table表格组件能够支持大量数据的展示，因此可以用vxe-table展示excel-diff的结果。

excel-diff的算法本身，先前的文章已有讲解，在结果展示上会按file->sheet来分。为了让结果展示更加人性化，需要对表格的样式进行区分。在vxe-table的api列表中，我们可以通过cell-class-name的回调函数指定每个单元格的样式。针对excel-diff的结果可以这样设计样式：

在射击类游戏中，不可避免地需要对各种枪械武器进行测试。大多数情况下，枪械种类繁多，人工遍历测试会花非常多的时间，因此引入自动化测试替代人力执行部分冒烟用例，能够增加严重问题提早发现的可能性。枪械测试包括基础行为、伤害、弹道、后坐力等方面，从功能冒烟的角度考虑，基础行为和伤害是需要优先覆盖的部分。因此，本文以UE4引擎下的枪械测试为例，讲解基础行为跟伤害测试的一些设计。

后端的服务间通常采用固定的协议&rpc框架通信，当前主流的方案是以protobuf协议为基础，采用grpc进行通信，这种方式在Golang的开发中尤其突出。因此，笔者决定做一个小的golang应用来踩坑protobuf+grpc编码模式，上传到github分享——这便是protobuf-grpc-starter。

protobuf-grpc-starter主要受到了PasteBin的启发，用户post一段代码到服务器，得到一个短链接（shortLink），其它用户可以通过这个短链接取查看这个用户所发送的代码，实现代码文本分享。当存储文本量较大、且用户访问量较多时，数据库不一定能够承载的了查询的压力，这样就需要缓存来分担查询的任务。因此在protobuf-grpc-starter中，笔者编写了两个小server：WebSvr和CacheSvr，其中WebSvr用于处理用户的查询以及post文本请求，post的文本存储在单独的文件中；CacheSvr则在内部实现了一个驻留内存的LRU缓存，用来缓存短链接查询的结果（短链接only，保证强一致）。WebSvr和CacheSvr间基于protobuf协议采用grpc-go框架通信，处理获取/设定查询缓存的操作。为了保证新接触protobuf+grpc的同学能够专注于此，这个项目的prerequisities里也不会引入类似redis的中间件，而只有go、grpc、protobuf等相关的内容，包括：

• golang v1.16：有最新的库和特性
• protoc：用来编译protobuf协议文件，需要在protoc下载地址下载较新的版本（protobuf3）
• protoc-gen-go：用来生成golang的协议定义文件，可以在protobuf-go教程了解如何下载及生成文件
• protoc-gen-go-grpc：用来生成golang的协议grpc定义的文件，可以在grpc-go教程了解如何下载及生成文件
• make：项目里用了Makefile，因此需要支持make。Makefile里包含了文件生成（proto）以及服务器二进制文件生成（server）的指令

整个项目的结构如下：

策划表格数据检查是游戏测试工作的刚性需求。在游戏开发期中，有大量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的功能实例：