1、引言

目前多数手游组的自动化相关工作都是基于脚本实现，通过各种接口的调用实现与游戏客户端或者服务端的交互，再通过脚本内逻辑调用顺序的组织来实现多样化的测试需求。

相对而言，开发成本较低，初期进度快，改动方便。但随着脚本数量增多，测试逻辑不断复杂，对测试逻辑的维护成本逐渐提高，并且对新人而言，这样的脚本学习成本高昂，接手难度高。

如果可以将测试逻辑与功能实现分离，并且将测试逻辑可视化展现，势必可以解决这一问题。应用BT便是一种方法，它可以非常好的管理测试逻辑，通过树状结构进行展示和维护，极大的降低后期测试逻辑的维护成本。

本文主要对各种类型的手游项目移植经验进行汇总，旨在推广BT应用，为其他游戏接入提供参考。

2、BT简介

BT是Behavior Tree(行为树)的简称，按照深度优先的原则进行遍历，遍历结束后再重新开始，篇幅所限，文中不对BT进行详细说明，仅作一些简单介绍，方便后文的阅读。

BT由各种类型的节点组成，除root(根节点)外，常用的节点主要有四种：

Ø  顺序节点（Sequence）：组合节点，顺序执行子节点，只要碰到一个子节点返回FALSE，则返回FALSE；否则返回TRUE。

Ø  选择节点（Selector）：组合节点，顺序执行子节点，只要碰到一个子节点返回TRUE，则返回TRUE；否则返回FALSE。

Ø  条件节点（Condition）：叶节点，执行条件判断，返回判断结果。

Ø  执行节点（Action）：叶节点，执行设定的动作，一般返回TRUE。

从定义看可能不是很好理解，通俗一点讲，条件节点就是用于判断当前状态是否满足要求，执行节点就是用于执行一些操作或者指令，顺序节点和选择节点都是用来连接各种不同的条件节点和行为节点。通过各种节点之间的组合，来实现需求的逻辑，即在什么情况下执行什么样的操作。

举个例子，如果需要实现如下这样一个逻辑：

按照BT的方式，可以实现为下图所示：

当a<3时，BT的节点遍历顺序为：Root node → Selector → Sequence → if a < 3(此时该条件节点判定结果为真，所以执行右侧节点) → a = a + 1(该节点返回真，sequence所有节点均为真) → Sequence 返回真(此时Selector有一个节点返回真) → Selector 返回真 → Root node 结果为真，一轮结束。

当 a >=3时，BT的节点遍历顺序为：Root node → Selector → Sequence → if a < 3(此时该条件节点判定结果为假，所以sequence不执行右侧节点) → Sequence 返回假(此时Selector节点继续往右侧遍历) → print a(该节点返回真，此时Selector有一个节点返回真) → Selector 返回真 → Root node 结果为真，一轮结束。

使用BT进行测试时，大致的结构如下图所示：

3、BT在游戏中的应用

BT在A1项目中应用非常广泛，除了游戏内的怪物AI实现，副本流程控制外，服务器的压力测试和客户端的性能测试也都使用了BT。

服务器的压力测试实际上是启动了非常多的机器人，每个机器人模拟一个玩家，从而达到一个高量级的压测效果。机器人在运行时，就是通过BT进行控制，通过BT编辑器，可以非常清晰直观的看到机器人的运行逻辑，包括什么时候在世界频道喊话，有多大的概率去进入一个副本等等。

与普通的压测脚本方式相比，BT的形式无疑更加清爽美观，也更方便进行维护。但从了解到的情况看，移植服务端的BT需要游戏客户端引擎的支持，即条件节点和行为节点的实现依赖引擎提供的接口，成本较高，因此暂未考虑。

客户端的性能测试与服务器压力测试不同，并不需要依赖引擎的支持，直接调用脚本层接口即可进行。在游戏启动后，通过在调试窗口输入指令的方式可以启动BT，从而进行性能测试，同样也可以通过telnet连接客户端的方式进行BT的调用。

由于BT是在游戏客户端进程内运行，相当于另起一个线程，因此接口的调用相对比较方便和直接，在了解程序实现或者获得对应接口后，就可以进行行为节点和条件节点的编辑。客户端性能数据的记录和各种操作的进行(例如进入副本，开枪，移动等)都可以通过行为节点实现，完全满足测试需求。

因此，考虑将客户端相关这一套BT进行移植。

4、BT在手游的移植

移植BT需要考虑的主要有两点：

Ø  BT结构的移植
Ø  各类节点的实现

BT结构的移植非常方便，A1的BT实现是通过python的方式，只需要本地安装过python，就可以运行。

节点的实现主要指的是行为节点和条件节点。与端游不同，手游的测试不仅仅局限于PC端，绝大多数的性能测试需要在移动端进行，直接游戏客户端内另起线程的方式并不适用。如果可以独立的运行BT进程，与游戏客户端通过远程调用的方式进行交互，就可以很好的应用在手游中，无论PC端或是移动端。目前开展的各类移植工作，都是基于这一思路进行的。

（1）Neox+python(B1)

第一次尝试移植，就是在B1进行的，由于之前做过一些针对B1客户端逻辑的自动化测试开发工作，所以移植的过程比较顺利。

与其他neox项目一样，B1的客户端逻辑是用python写的，程序在游戏启动时，会运行一个RPyC的server。关于RPyC本身，此处不做介绍。如果有需要添加时务必注意以下几点：

Ø  启动RPyC Server需要另起线程，否则客户端逻辑会卡住；
Ø  在启动RPyC Server的时候，需要进行控制，一般是测试版本才运行，正式版本是不运行的；
Ø  启动的RPyC Server类型为SlaveServer，这样可以方便访问游戏客户端的接口。

拥有RPyC的基础后，与客户端的通信就简单多了，只需要建立好连接，然后在客户端中找到所需的方法，即可直接调用，无论是PC端还是移动端都适用。

时序图如下：

在BT初始化过程中，会增加一个建立RPyC连接的过程，连接建立完成后，连接对象会作为行为树对象的一个属性进行保存：

之后进行Action节点和Condition节点实现时，就可以轻松调用客户端接口了。以判断角色爱心值是否足够为例，节点可以这样写：

在完成各个所需节点的实现之后，就可以通过BT编辑器进行BT的编辑(BT编辑器也是直接用F组的。在移植过程中，遇到过不同BT编辑器编码格式不同的问题，会导致节点加载出现乱码，通过使用英文注释或者改变文件编码格式的方法即可处理，此处不详谈)。

同样以角色爱心值为例，我们进行情景扩展，变为如下两条逻辑需求：

Ø  若角色爱心值充足，则进入双陆坊，不断的投掷骰子；
Ø  若角色爱心值不足，则离开双陆坊，使用指令增加爱心值；

转换成BT的形式，如下：

可以看出，在进行Neox项目移植时，整体的BT运用思路和A1类似，只是在调用客户端逻辑的时候，一个是直接调用，另一个是通过RPyC远程调用。整体框架的移植成本小，使用方便，开发成本主要集中于节点实现。

（2）Cocos+js(B2)

与移植到B1不同，在B2项目的BT移植过程并不顺利。最主要的原因在于其脚本层是js实现的，而且cocos引擎版本为2.X，查阅网上各种资料后，仍未找到很好rpc协议来实现测试端与游戏客户端的通信。

在发现不能像python的RPyC那样方便的进行远程交互，甚至在游戏客户端内启动一个server都不容易之后，移植的工作一度被搁置。之后退而求其次，把要求降为只要能够建立连接就好了，无论是做服务端还是客户端，至少具备了通信基础。这个要求还是比较容易实现的，http连接就满足要求，虽然和预期相比差了些，但好歹能够进行通信了，发送字符串什么的自己解析一下就好了。

由于通信的部分结构发生了改变，整体的测试框架也需要适当进行调整。简易的时序图如下：

在这个测试框架中，BT不再作为整个测试流程的发起者，所有过程都可以理解为是游戏客户端在主动进行请求，包括连接的建立，命令的执行等。

由于游戏客户端需要一个线程循环来不断请求命令，而BT自身也需要一个循环来轮询整棵树，所以这里设计了一个命令池的概念，用作两个循环之间的交互。具体结构如下：

两个循环相对独立，对于客户端而言，每个循环要做的就是向BT端发送一下当前的客户端状态，然后向命令池请求一个命令，如果获取到命令，则对命令进行解析，然后在本地执行对应的操作。对于BT端而言，每个循环要做的就是获取一下客户端的状态，然后根据状态生成需要执行的命令，并把命令添加到命令池当中去。

这样一来，可以很好的处理两个循环的问题，保证两边都可以顺利运行，但同样存在问题。由于BT的循环和客户端的循环并不是同步的，所以对客户端而言，获取到的命令并不一定是最新的命令，而对BT而言，获取到的客户端状态并一定是最新的状态(这个其实不是问题，BT只是负责产生命令，只要客户端执行命令时与对应的状态一致，就可以了)。

为解决这个问题，特意对流程进行了优化：BT在发送命令时，附加客户端状态，客户端在执行操作时，对当前的状态进行一次校验，如果当前的状态与接受的状态不一致，则不执行该操作。

完成这些步骤之后，编写一些对应B2的条件节点和行为节点，BT的初步移植工作就差不多了，作为检测，走通了一个自动切换场景、自动抽取道具并补充钻石的用例。

和Neox引擎相比，无疑cocos+js项目的BT运行效果差了很多，最主要的问题还是在于缺少一个好的RPC协议。如果之后有相关进展，可以再对现有的结构进行调整。

（3）Cocos+lua(B3)

同样是cocos项目，B3项目组移植BT的过程要顺利很多，一方面是脚本语言的不同，另一方面要归功于之前奠定的自动化测试基础(在移植到B2时，可以说是零基础)。

先上一份时序图：

除web外，其他的流程和Neox非常类似，只是把RPyC替换成了unirpc。

5、总结

到现在为止，已经给许多手游项目进行了BT移植。相对而言，Neox引擎+python的组合无疑是最方便的，cocos引擎+lua的组合在有了unirpc之后同样也很方便，cocos+js的组合目前还是通过http的方式通信，略逊了一筹，但unirpc的制作计划将js的兼容性也考虑在内，相信以后也可以变得很方便。