高效、易用的自动化测试框架设计

在自动化测试工作中，有两个痛点一直困扰着很多团队：

1. 每次测试都要专人重新编辑脚本，内容重复造轮子，费时费力，甚至不如人工测试方便；
2. 提前写好多个不同功能的脚本，编辑风格导致脚本间差异巨大；大量调试修改降低了脚本复用性，脚本维护困难重重。

如果将各类脚本中大量重复性内容固定下来，用统一的标准来规范脚本的编辑，那么团队只需要花费少量时间精力，依据任务需求修改少量的内容，就可以快速复用脚本，迅速开展自动化测试。这就是自动化测试框架能完成的事情：

• 代码复用率高
• 标准规范，维护方便
• 用例全面，使用灵活、便捷

广州天纵的测开团队很早就注意到了这点，他们在自动化测试框架的设计和使用上积累了丰富经验。接下来我们就一起和大家分享下天纵团队使用UWA Pipeline实现自动化测试框架的设计经验。

一、自动化测试框架

天纵团队通过设计这套自动化测试框架，在每次开展测试任务时，都能根据需求，灵活配置对应的测试用例，将游戏内复杂的GM操作简单化，实现了UI按钮的截图生成与配置。这些都极大地方便了自动化测试工作的开展。

1. 执行步骤的切分与组合

1.1 拆到不同的脚本中
在框架中，使用动态导入所有的用例文件，通过动态model对象去调用用例中的指定函数来执行对应用例，例如model.Run()，代码逻辑写在run()里面。

#用os库，获取用例文件下所有用例返回列表list
#遍历列表，使用importlib库，动态导入所有模块
import os, importlib
list = os.listdir('./示例/用例')
for case in list:
    mod = importlib.import_module(f'示例.用例.{case}')
    mod.run()

由此就将项目的测试内容拆分为一个个小的模块，在选择执行用例时，就可以进行灵活的拼接组合。

1.2 按照ID与分类进行划分
一般项目的新手流程中任务会很多，而且更改也很频繁，如果不对任务做一个分类，直接上代码，那么当有某个任务流程有调整时，后面可能全部都要跟着调整，导致消耗大量的人力和时间。

因此，天纵团队对任务做了分类，每类任务对应1个任务ID。例如对话任务的任务ID为1，那就写一个方法task1()，对话任务的流程就写在task1()里面。多个对话任务，都是调用task1()方法，以后，不管对话任务有新增或减少，都不需要改代码，若是流程有改变，只需要改task1()里面的逻辑。

2. 通过RPC调用客户端接口

在Unity集成的Poco SDK中，客户端程序人员增加了“接收Python通过Poco发出的消息”的功能，然后可以根据接收到的不同消息内容去执行对应的功能。

目前已实现的功能有“返回游戏中Lua的配置表数据”、“打开指定界面”，以及上图的“调用GM命令”，原本需要人工打开GM界面手动进行配置的各种GM调试工作，现在在自动化测试过程中直接代码调用就能完成。

在此天纵团队提醒大家：对于用Poco去读取Lua配置获得数据的操作，尽量放在游戏任务流程前，或者说放在开始收集性能数据前。因为Poco读表会带来一定的性能开销，大家需要避免这个开销对游戏性能分析的影响。

3. 按钮的配置

自动化测试中，各类按钮的点击，是相当普遍和频繁的。天纵在框架中维护了两套按钮的点击方式，分别是“图片”和“字符串”，前者通过Airtest的图像识别进行按钮定位和点击，后者通过Poco的UI层级信息执行点击。

但随着项目迭代，UI的改动会很大，图片资源会被替换，UI元素名字也会更改，导致脚本也要频繁修改。为了解决这个痛点，于是在框架中将数据分离，把按钮按照名称进行索引，把索引关系保存在配置表里面，在执行用例时，从表格中获取按钮来执行点击。

对于通过Poco的UI层级信息执行点击的方案，提醒大家在游戏开发前期就要同步好结构，把按钮的name写在配置表里，客户端程序人员通过读取按钮的name生成UI树，这样就能通过读取配置表来生成Poco的配置。

而对于通过Airtest的图像识别进行点击的方式，主要是考虑到低端机，用图片可提高框架兼容性。

4. 测试异常自动通知

为了应对大批量设备进行自动化测试且没有人员在现场值守的情况，天纵团队实现了测试情况的自动同步：在脚本报错后捕获异常，将相关的截图和报错信息等，自动地通过沟通工具实时发送消息到群里提醒对应成员，方便大家及时同步消息和进行处理。

这里可以根据大家日常办公的沟通工具进行选择，比如企业微信、飞书等，简单一点也可以用发邮件的方式。以飞书为例，先建个群，加入飞书机器人，建群完成后，获取webhook地址。

import json， requests

# webhook地址
url = "https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxxxxxxxxxxxx"

payload_message = {
    "msg_type": "text",
    "content": {
        "text": "你要发送的消息"
    }
}
headers = {
    'Content-Type': 'application/json'
}

response = requests.request("POST", url, headers=headers, data=json.dumps(payload_message))

通过这样的方式，大家对异常情况能够进行及时的记录和干预，方便后续处理相应的问题。

5. 在UWA Pipeline上运行

天纵团队将自动化测试工程打成zip包后，可以在UWA Pipeline上正常运行。在UWA Pipeline中创建定时任务，结合UWA Pipeline提供的云真机系统，完成日常的自动化测试。

这里有个细节需要注意：自动测试代码中涉及到路径的功能，在上传到UWA Pipeline中运行时可能会出现异常。比如，通过相对或绝对路径获取的文件无法找到，运行报错。这里有两个方案：一个是通过os库提供的功能获取当前脚本的路径，从而确定当前运行的Workspace，进而拼接出其他文件的绝对路径，获取路径的代码，如：os.path.dirname(__file__)；另一个方案是，通过相对路径查询文件，这需要将当前的Workspace路径添加到环境变量的PATH变量中。

二、自动化测试分担了QA的工作负荷

援引自天纵团队

这套自动化测试框架的运行，为我们节省了相当多的人力和时间，它在承担传统QA工作的同时，也带来了相当大的变革。

首先，配合项目的研发进程，我们现阶段的自动化脚本，主要承担了自动跑GOT Online的工作，通过定期运行脚本，生成性能数据报告，从而检查游戏性能问题，做到当场发现、当场解决，保证性能问题不积压。

其次是回归测试，我们目前虽然只编写了主线任务的脚本，但主线任务已经覆盖了几十个功能模块，这样我们每次发版本前运行脚本，通过自动化测试就可以节约大量人力，及时发现可能导致流程卡住的各种问题。

同时，自动化测试也承担了一些人工手动测试中难以完成的工作。例如点击去做任务，除了要点击按钮，还要校验任务文本，确定要跑的任务是否正确。这时候利用poco(MainUi.taskText,textMatches=f'.*{param[0]}*.').click()，就可以通过textMatches这个参数来进行校验。

后面随着游戏版本的稳定，我们会编写更多的自动化测试脚本去满足更多的回归测试需求，增加更多的检查点，保证游戏功能正常。

三、前期投入和收获

在这方面，天纵团队也表示

相较于传统人力测试只需短期简单培训，我们在这套自动化测试框架上初步投入的时间比较多。第一版的框架写了2周左右，然后主线任务脚本的调试花了1个月左右，还有中途根据使用情况的修改优化、脚本的维护，也投入了比较多的时间。但当这套自动化框架完成后，对应的我们的收获也很明显。

在以前，比如通过GOT Online跑新手流程获得性能数据，Overview、Resource、Lua、Mono这4个性能模式，每台手机都要跑4次新手流程；手机要是多了，测试人员就得手动跑几十次新手流程，每次耗时30分钟，单单10台手机跑完4个模式就要需要20个小时。

而现在我们通过这套测试框架，不考虑其他因素，自动化跑一个性能模式持续一小时，多台手机并行跑，这样无论多少个手机，所有性能模式只需4小时就全部跑完，当天就能出结果，直接就能根据报告反馈去安排计划。

这样一来，大幅度减少了我们在人力上的投入，完成测试所需的时间也大幅缩短，提高了测试的执行与反馈效率，极大推动了我们项目的进程。

---

感谢天纵团队的分享，在自动化测试框架设计上给我们带来的非常实用且细致的经验。相比于每次都推倒重来，这种系统性地开展和维护自动化测试工作的做法，能够进一步优化流程和提高效率，希望能为大家的自动化测试工作带来更多的思路和借鉴。

更多UWA Pipeline使用案例分享可以查看：
《乐享元游的 UWA Pipeline 最佳实践分享》
《一款ARPG游戏是如何搭建云真机系统的》
《再也不用焦虑特效造成的性能问题了》
《你需要同款“Unreal项目自动化编译、打包和部署”方案吗？》

想要实际体验UWA Pipeline？请点击《免费试用 ｜UWA性能保障体系全体验》，15天Pipeline全服务试用就在眼前！