游戏项目自动化测试的一些思考和想法

最新推荐文章于 2023-04-21 15:08:32 发布

阿元呐

最新推荐文章于 2023-04-21 15:08:32 发布

阅读量1.7k

点赞数 1

分类专栏：软件工程游戏开发文章标签：游戏开发业务流程测试

本文链接：https://blog.csdn.net/DdogYuan/article/details/122022526

版权

4 篇文章 0 订阅

订阅专栏

3 篇文章 0 订阅

订阅专栏

自动化测试框架需要什么样的前置条件

自动化测试代码需要能够独立地启动游戏，加载所需的资源，并直接跳过不相关的流程，直接步进到需要测试的流程。这个过程越短越好，因此，需要系统在设计上保证不同流程的解耦。例如系统能够在没有登录的状态下直接进入一个游戏场景，并根据配置生成相应的角色和系统。
对于联网游戏，自动化测试代码需要能够独立地生成服务器进程和多个客户端进程，并在客户端进程与服务端进程连接后，分别操纵不同的进程做不同的操作。虚幻引擎的Dedicated Server框架，就保证了这种能力。

一些体验性的、视觉的测试没法做自动化测试，但游戏项目仍然有很多部分可以做自动化测试。
如果一个测试耗时太长，并且涉及进程太多以及易于受到偶然因素影响，那么说明这个测试设计得并不是很好。
如果一个特性还处于prototype阶段，那么没必要为其设计自动化测试代码。因此对于某些新特性而言，先设计测试用例的测试驱动开发方式可能会水土不服，因为有些原型阶段的特性很可能后面都不需要。

Sea of Thieves团队的自动化测试实践[1]中提出了一个概念叫Actor Test，这是一种介于单元测试和集成测试中间的状态。Actor Test破坏了不少集成测试的标准：

一些跟时间有关的测试，使用手动调用引擎的Tick函数以代替真的执行特定时间。
一些行为的检测逻辑，可以使用轮询方式去调用。例如玩家施放了某个技能，判断其是否正确释放，如果检测N秒后行为是否正确释放，那么为行为添加动画、微调行为的释放前摇会不断地破坏这个测试用例。而更健壮的检测逻辑应该是，监听技能释放事件，当技能释放后对行为进行检测。这样可以使得测试代码更加健壮，不容易受到数据迭代的影响。