做游戏测试时，关于自动化的思考

lsekfe

15年到18年，自动化相关的内容特别多，也特别火，似乎自动化测试是测试领域，特别是游戏测试的一个救命良药。19年到20年，测试领域这方面，就理智了很多，但是仍然也有很多维自动化论的说法。这里记录下自己相关的思考。
　　15-16年，我也尝试在游戏领域做了一些相关的自动化测试内容。不过我当时主要是为了解决性能体验相关的一些测试做的自动化测试，这个性能体验主要是为了解决量化游戏操作的灵敏度的问题。当时尝试用的方法是，adb的点击方案，minitouch的，以及配合图形方案来做的。当然也包括嵌入游戏引擎调用接口相关，直接与游戏交互的方案。
　　由于在W厂和T厂都待过较长时间 ，也有机会去深入接触这两个大厂在自动化层面做的一些内容。W厂由于比较封闭（QA无法接触游戏引擎源码）侧重于黑盒层面的研究，并且做标准化，黑盒层面的意思是尽量与引擎剥离，最后该方案也被谷歌纳入自动化测试的官方方案。T厂由于大工作室较多，各自的方案也较多，大部分人都可以接触到引擎源码，技术氛围也更好，所以侧重于从引擎层面做支持。
　　自我总结下，游戏自动化测试目前主要两个方向：
　　1，无侵入式，第三方的方向。侧重于不依赖引擎方面的研究，主要是对系统的研究，以及图形学方面的研究。如何更稳定的覆盖各个系统，以及如何更快，更稳定的图形算法是主要的问题。但是问题是，无法更精准的控制游戏内行为，如操作度非常高的游戏，大部分3D mmo游戏的自由度都很高，攀爬，360度方向旋转。然而这类方案对UI的自动化测试却非常合适。
　　2，侵入式，引擎层面方向。侧重于通过引擎相关支持，开发支持特定引擎平台的自动化方案。如何对结果进行验证，以及如何覆盖更多引擎是主要问题，不过对于单一游戏足够了。但是主要问题是，引擎依赖太高，对自动化用例的编写能力要求也挺高的。需要单独维护一整套自动化的内容，这个对团队要求比较高。
　　上述两个方案都可以解决自动化的相关问题，两者也有各自的优缺点。但是在我看来目前自动化天然具有以下两个问题，需要解决。
　　1，成本层面。成本是第一位的，一个成熟的自动化解决方案，需要让自动化的case编写，执行，部署，做到成本最低。如果一个自动化花费的人力，比人工执行还要高，那这个方案还是需要优化的（当然如果是纯粹做一些重复性的工作，如 性能对比 基础测试之类的，倒是可以接受）。
　　目前游戏行业有一个特点，生命周期短，至少移动游戏是这样。当然也有像王者，梦幻，这类的长生命周期的游戏。但是不可否认的是，移动游戏生命周期确实比较短，实际上开发周期也是比较短的（随着游戏越来越重度，这个现状在改变）。如果一个游戏的活跃生命周期是2年（2年后，可能就只有很少人员在维护了），需要花半年左右建立自动化方案部署，对于绝大部分中小型游戏公司是无法容忍。
　　另外游戏行业的另外一个特点是，需要迎合市场玩家的喜好，改变UI布局，角色表现等，这样对一些纯图像的自动化方案是有一定天然相悖的。我曾见过，游戏项目策划为了玩家审美变化，将UI布局和表现进行重构的，这样导致纯图像非侵入式的方案受到较大影响。
　　2，结果确定性层面：游戏自动化的另外一个非常重要的问题是结果确定性层面。自动化测试需要明确输入和输出，和程序里的0和1比较像。自动化执行完毕后，需要明确给出，0或者1，即结果正确或者错误。另外一个种并不是特别完备的方案是，如果1无法明确，至少得做到0需要明确，即保证输出的标记为错误的case是100%正确的。如果无法做到这一点，自动化方案也是很难执行下去的。我们可以借用机器学习领域衡量模型正确率和错误率的方法。

其中
　　TP：本身为正确，被自动化判断为正确的case，不重要。
　　FP：本身为错误，自动化判断为正确，不可接受。
　　FN：本身为正确，判断为错误，可接受。
　　TN：本身为错误，判断也为错误，最重要。
　　如果一个自动化方案存在较多FP，是无法接受的，因为这样会导致游戏bug放到外服去了。另外TN的比率是衡量一个自动化方案优劣的一个重要参数。
　　目前我个人觉得自动化可以应用的领域：
　　1，兼容性测试：兼容性是一项比较重要，同时又非常耗费人力的测试内容。是最适合自动化方案开展的，比较推荐的是配合图形学相关算法，系统的相对执行情况，发现不同机型，不同系统，不同硬件（主要显卡），不同opengl，vulkan等版本下的问题。兼容性情况下，做到TN比率较高。
　　2，性能自动化：性能测试很多内容是可以自动化的，因为性能测试很多时候是需要同一个测试用例，不同版本之间进行对比的。自动化的固定执行，恰好可以让两次执行是一样的case，方便进行对比。
　　3，回归测试：回归测试指的是，每次出版本前，可以覆盖执行一遍基本的测试用例，保证玩家接触最多的玩法和操作是正确的。因为每次版本迭代，是非常容易出现因为功能和代码交叉导致改动牵连面过多的情况的。自动化的回归测试非常适合这一项，但是可能耗费的人力会比较多，需要有专人进行维护。

周柏豪

gametestinwm 发表于 2022-2-10 17:47
现在我在的公司还有我在观望的WY都在开始推进自动化进程，但是总觉得能做的和东西有限。我觉得作为游戏测 ...

+1

gametestinwm

lsekfe 发表于 2022-2-10 17:23
国内游戏测试很多都以手工测试为主，尤其是代理的游戏无需你做自动化测试。其实真的想好好做自动化测试， ...

现在我在的公司还有我在观望的WY都在开始推进自动化进程，但是总觉得能做的和东西有限。我觉得作为游戏测试仅仅去做手工测试长期下来除了对业务的能力上有提升外，对技能方面没有人任何提升。所以我现在对游戏测试的后续发展非常困惑....

lsekfe

gametestinwm 发表于 2022-2-10 17:13
大佬 请问做游戏测试进阶需要专业系统的学习软件测试的各种理论和工具吗？
我现在在学习过程中发现软件测 ...

国内游戏测试很多都以手工测试为主，尤其是代理的游戏无需你做自动化测试。其实真的想好好做自动化测试，我不太建议往游戏测试发展。就算自主研发的游戏基本开发测掉了。

gametestinwm

大佬 请问做游戏测试进阶需要专业系统的学习软件测试的各种理论和工具吗？
我现在在学习过程中发现软件测试的东西很少有能用到游戏测试中的，大都是基础的测试技能。
往上进阶到自动化相关之后游戏测试的相关教程又少之甚少，现在我不知道该如何去学习游戏测试的进阶技能，是需要掌握游戏引擎的知识？还是深挖自动化的知识呢？