在自动化测试工作中，有两个痛点一直困扰着很多团队：
1. 每次测试都要专人重新编辑脚本，内容重复造轮子，费时费力，甚至不如人工测试方便；
2. 提前写好多个不同功能的脚本，编辑风格导致脚本间差异巨大；大量调试修改降低了脚本复用性，脚本维护困难重重。
如果将各类脚本中大量重复性内容固定下来，用统一的标准来规范脚本的编辑，那么团队只需要花费少量时间精力，依据任务需求修改少量的内容，就可以快速复用脚本，迅速开展自动化测试。这就是自动化测试框架能完成的事情：
- 代码复用率高
- 标准规范，维护方便
- 用例全面，使用灵活、便捷
广州天纵的测开团队很早就注意到了这点，他们在自动化测试框架的设计和使用上积累了丰富经验。接下来我们就一起和大家分享下天纵团队使用UWA Pipeline实现自动化测试框架的设计经验。
一、自动化测试框架
天纵团队通过设计这套自动化测试框架，在每次开展测试任务时，都能根据需求，灵活配置对应的测试用例，将游戏内复杂的GM操作简单化，实现了UI按钮的截图生成与配置。这些都极大地方便了自动化测试工作的开展。
1. 执行步骤的切分与组合
1.1 拆到不同的脚本中
在框架中，使用动态导入所有的用例文件，通过动态model对象去调用用例中的指定函数来执行对应用例，例如model.Run()，代码逻辑写在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地址。
通过这样的方式，大家对异常情况能够进行及时的记录和干预，方便后续处理相应的问题。
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使用案例分享可以查看：
网友评论