在自动化测试工作中,有两个痛点始终困扰着很多团队:
- 每次测试都要专人从新编辑脚本,内容反复造轮子,费时费力,甚至不如人工测试不便;
- 提前写好多个不同性能的脚本,编辑格调导致脚本间差别微小;大量调试批改升高了脚本复用性,脚本保护困难重重。
如果将各类脚本中大量重复性内容固定下来,用对立的规范来标准脚本的编辑,那么团队只须要破费大量工夫精力,根据工作需要批改大量的内容,就能够疾速复用脚本,迅速开展自动化测试。这就是自动化测试框架能实现的事件:
- 代码复用率高
- 标准规范,保护不便
- 用例全面,应用灵便、便捷
广州天纵的测开团队很早就留神到了这点,他们在自动化测试框架的设计和应用上积攒了丰盛教训。接下来咱们就一起和大家分享下天纵团队应用 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 全服务试用就在眼前!