经验谈，转载自个人博客：https://utmhikari.top/2022/04/03/testlife/btree_autotest_talk/

在游戏自动化测试领域，行为树由于其强大的描述玩家（Agent）行为逻辑的功能，在很多场景的自动化测试都能得到应用。但是，如果对行为树的作用认识不足，很容易导致整一个自动化测试项目出现难以维护的窘境。因此，这篇文章谈一谈在游戏自动化测试里，用行为树做测试的一些误区。

首先第一点是，很多行为树的框架/GUI 系统提供了强大的可视化编程的能力。但是如果真要用行为树框架去几乎完全替代纯代码编程，做很细致的的逻辑控制，这个想法是有误的。

行为树本身最方便的地方是能够通过可视化界面的方式去维护玩家行为（以业务逻辑的拆分抽象为基准），而不是维护程序行为（以函数/变量为基准）。针对前者的场景，如果没有行为树，一般的解决方法是先用其它流程图工具（或者手记）捋一下流程，然后再通过纯代码的方式设计接口流程，做流程图的复刻，而有了行为树工具，就可以在实现流程图编辑的基础上，实现自动生成基础代码，这样会极大提升业务实现的效率。而针对后者的场景，可视化编程相对于纯代码其实可维护性更差，编程效率更低——在对底层 api 都很熟悉的基础上，纯打字肯定比拖拽一堆控件还填一堆 form 来的快。

再者第二点是，行为树的滥用问题，不是所有自动化测试场景都可以用到行为树，而是要针对我们自动化测试的场景，做严格的系统分析，否则就会陷入为技术而技术的地狱。

这涉及到自动化测试的本质，自动化是手段，测试是目标。严格上来讲，通过自动化手段不仅可以实现功能测试，也可以实现数据收集的需求，结合其它工具，去辅助我们完整的测试工作。因此我们在做自动化的时候还是要首先关注我们的测试目标是什么，然后才是适不适合用行为树的问题。对于大部分的自动化工作，引入行为树框架会带来更多技术上的复杂度以及学习上的难度，其实是不适合的。只有一些需要玩家（不是程序）做大量行为决策的测试场景，用行为树才比较适合，比如比如说做任务、副本的跑测，或是 PVP 的 AI 实现。

最后一点是，在一个涉及到行为树的自动化测试设计当中，不应当将行为树看作为整个技术设计的核心。

这可以类比去做一个 pyqt 为基础的 GUI 软件，这个软件的核心应该是其内部的业务逻辑，而且在设计上也应当可以脱离 GUI 去运行，而 pyqt-designer 只能作为快速设计原型，生成基础代码的手段。行为树也是也是这样的作用，它能达到的目标是快速生成行为决策的描述以及各个行为的定义，行为的实现却是需要用户去详细编写的，而恰巧正是行为实现的内容才有比较大的维护量。因此我们在做游戏自动化测试时，建议是通过对玩家在游戏里不同的行为进行封装抽象，形成 “行为库”，然后再去套用到不同场景的行为树设计上。把 “行为库” 做好，是自动化测试得以大量应用的关键。