游戏自动化测试覆盖率提升之路

本文基于某MMORPG项目，挑选出具有代表性的多个功能模块，分析对其进行自动化测试覆盖过程中的难点，并总结出一系列方法和技巧，希望可以帮助有能力，有意愿的测试同学更有效率地提升类似模块的自动化测试覆盖率。
自动化覆盖率也有多种指标，例如功能覆盖率，路径覆盖率，状态覆盖率等等，本文讨论的覆盖率是游戏测试中常用的功能模块覆盖率。

01 功能模块分类

自动化测试的覆盖率是贯穿整个项目测试周期的重要指标，经常被用作衡量自动化测试的质量和有效性，几乎所有的项目都会将提升自动化测试覆盖率作为自动化测试体系的主要目标。

想要提升自动化覆盖率，首先要对目标任务进行拆分和整理。以一款大型 MMORPG游戏为例，其中包含的功能模块大约有两百多个，数量多，功能杂，类型广，本文挑选了十五个具有代表性的功能模块如下：

1背包与道具 6人物加点 11多人战场
2人物技能 7装备洗练重铸 12主线任务
3英灵抽卡 8组队组团 13时装外观
4英灵培养 9好友 14公平竞技
5科举考试 10聊天 15心魔

如果不加以一定的分析和梳理，很难快速厘清自动化测试用例开发思路。因此，需要对游戏内功能模块进行特征提取。根据不同的模块特点，可以将以上功能分为以下几组：

①基础系统与功能：1、2、3、4、6、7、8、9、10、13

②流程长、复杂：1、5、9、12、14

③流程短，简单：2、3、4、6、10

④多人可完成：8、9、10、11、14、15

⑤单人可完成：1、2、3、4、5、6、7、12、13

⑥涉及表现：13

⑦涉及数值：2、3、6、7

⑧涉及限时：5、11、14、15

……（可以任意添加特征）

可以看到，不同的功能特征之间存在联系和区别，例如特征④和特征⑤互斥，特征①、②、⑤ 可以兼容等等。由于不同特征的功能在编写自动化用例的时候需要着重关注的点不尽相同，所以在初期，我们要做的就是使用尽可能多的特征，将游戏内的功能模块划分出一个初步的脉络，便于规划自动化测试用例的编写。

02 了解功能玩法

在完成了初步的划分之后，就可以开始着手针对每一类不同的功能，梳理编写顺序，总结相应的用例编写重点，并开始编写用例了。接下来本文将以上提出的几个特征为例，分别进行说明：

1. 基础系统与功能

基础系统与功能是我们自动化铺量初期，最先容易关注到的部分，针对这一类功能进行自动化， 也比较符合我们对于“游戏自动化测试”的直观认知。

在编写这一类功能的自动化测试用例时，我们可以将平时手工回归不到的 P2,P3 级别的测试用例，尽可能的多转化为自动化测试用例。例如组队系统的自动化测试，“申请入队”“邀请入队”“退出队伍”等用例，在没有作为其他用例的前置用例时，在非 DailyBuild 场景下，几乎没有进行自动化测试的必要，因为如果出现问题，很快就会被手工测试的 QA 和其他同事发现“组队系统挂了”；而诸如“队长长时间挂机，自动转让队长”之类的功能，由于其被关注度过低，就很适合出现在自动化测试用例中。

2. 流程长、复杂的功能

对于体量大，流程长，功能点复杂的功能，原则上不建议全部写在同一个 case 中，应该分门别类写出多个 case 单独执行。由于自动化测试对干净环境的需求度较高，如果整合在同一个用例中执行，当前半部分的用例执行出现错误，或遇到一些特殊突发情况（临时节日活动弹窗等）时， 就有可能导致后续用例出现误报或无法执行，一定程度上浪费了执行资源。

如果功能确实逻辑性过强不易拆分，那么更建议在自动化测试用例中增加一些强防错步骤，保证用例最大程度可执行。例如某挖宝流程包括“获得宝图碎片——合成宝图——开宝图”共三个步骤，那么可以在合成宝图的步骤之后，增加“清空背包——指令添加完整新宝图”两个步骤， 就可以在合成宝图出错的时候，仍然可以测试开宝图的流程。

3. 多人参与的功能

对于有多个玩家参与的功能模块，我们编写自动化用例时大体上分为两种思路：要么使用协议机器人或者辅助脚本，帮助我们进行测试；要么将多玩家测试点从该模块的自动化测试用例中剥离， 使其变为单人测试用例。

设想如下一个经验本玩法：至少三人参与，玩家需要进入副本杀死怪物，全队玩家获得经验值。

传统思路：编写一个协议机器人 AI，可以自动进入队伍，自动战斗，并且能检查自己的经验。传统思路的用例比较好构思，难点在于编码复杂度和执行负责度比较高，需要对机器人进行调度等，属于比较常用的测试思路。

剥离思路：将该自动化测试用例的测试点分析剥离，可以得到以下几个测试点：

副本外三人组队→队长开启副本→进入副本击杀怪物→队伍检查经验奖励→退出副本
可以发现，“副本外三人组队”“队伍检查经验奖励”两个测试点，可以剥离并放到“组队系统”的自动化测试用例中（因为组队系统自动化测试时，无论如何都需要借助协议机器人），那么我们只需要将“该副本要求的准入队伍人数”从 3 调整为 1，就可以得到一系列单人测试用例：

自己创建队伍→开启副本→击杀怪物→检查经验→退出副本

同时只需要在组队系统的自动化测试用例中，额外加上“检查队伍是否可以共享经验值掉落”，就可以变相的降低这个副本自动化测试用例的编写和执行成本。

4. 涉及数值

涉及到数值的自动化测试用例，可以额外对数值的正确性做回归测试。比较常用的思路是：在做装备洗练的自动化测试时，对该装备连续洗练一千次（时间允许的情况下），并统计出现不同类型的结果的频率，与标准概率数据库进行比对。如果概率符合期望，那么结束测试；如果概率不符合期望，则再跑一千次（或增大次数到五千次），再次对比期望，如果仍然出现问题，则可以抛出预警。

要实现数值用例的自动回归，比较重要的步骤是建立标准概率数据库，对于固定期望的功能， 可以选择读策划表（例如抽卡用例中，对于一个特定卡池，抽出 SSR 的概率基本是恒定的）或者写死在测试用例代码中（不是很推荐，需要经常维护）；如果是非固定期望功能，则可以参考基于统计数据建立数据库的做法。

5. 涉及表现

涉及表现的自动化测试用例一直是覆盖率提升的巨大难点。这里提到的表现，主要指的是外形， 颜色，动作等等代码层无法直接检测或检测成本巨大的测试用例。对于这一类测试用例，我们除了传统的图像识别等解决方案外，可以考虑综合利用各种资源和手段，将复杂问题转化为较为简单的问题，case by case 的提升覆盖率。

这里举一个例子：检查时装商店的每一款时装，是否出现资源丢失情况。

每一款时装虽然表现各不一致，但是终究会落到各类图形技术指标上，如 RGB，渲染面数等等，如果游戏引擎层支持的话，可以开发一个自动化测试用例脚本可以访问的性能数据接口，辅助我们进行测试。

初始默认时装，Tris 的数量为 146.4k

一款华丽的时装，Tris 数据达到了 224.3k

模型丢失的时装，Tris 数据只有 92.2k

如果可以在脚本层拿到 Tris 数据，那么只需要依次点击每一件时装试穿，记录每一件时装的Tris 数量，就可以知道是否存在模型丢失的情况。

6. 主线任务

对于数量极大，重复度高，分步骤明确的测试（主线任务等），推荐使用 AI 机器学习自动测试，可以大幅降低后续自动化测试用例脚本的维护成本，这里暂时不做更加详细的介绍。

03 基于框架的优化

另一个不可忽视的点是，所有的自动化测试用例，都是需要有代码能力的测试同学去手工堆砌的，如果能提升自动化测试用例脚本的编写效率，就能在投入的人力工时不变的情况下，提升自动化测试覆盖率的增速。这里也总结了两点编写自动化测试用例脚本及维护框架时，可以参考的经验。

1. 重视脚本层公共库的维护

对于一些使用频度极高的自动化测试行为（例如：点击二次确认，检查某种道具的个数，检查玩家身上的某一项属性，获得指定金钱等），使用公共库里的脚本是最佳选择。一方面，不需要每个同学去关心“如何拿到玩家身上的 XXX 属性”，只需要了解如何调用接口，分析返回值即可；一方面，如果游戏内代码逻辑出现了变动使得原代码片失效了，只需要维护公共库中的脚本，而不需要逐个文件去修复。

2. 用户（测试同学）友好度

很多自动化测试框架在开发时，着重于保障测试流程顺利进行以及提升脚本执行效率，而对用户侧的体验就相对关注的较少。例如：如果在编写脚本的过程中需要使用循环语句，则需要使用较为复杂的 table 嵌套来实现；如果脚本执行出错了， 调试起来也非常复杂，几乎等同于需要静态查错。如果能优化和提升测试同学编码时的体验，增强框架代码的可读性和可扩展性，也能在一定程度上提升测试脚本的编写效率。

同理，针对负责跟进功能的功能测试同学，也可以通过改进使用流程上的细节，提升处理问题的便利度。例如维护一个易于查看测试结果的前端；某个功能测试出现问题时，及时通过邮件等方式通知对应跟进QA等。

04 总结

自动化测试的覆盖率提升无法做到一蹴而就，只有在堆砌的过程中，持续提炼经验并进行优化， 才能更高效的达成目标。

行动吧，在路上总比一直观望的要好，未来的你肯定会感 谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入群： 759968159，里面有各种测试开发资料和技术可以一起交流哦。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取 【保证100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。
​
​