1. 每次测试都要专人重新编辑脚本，内容重复造轮子，费时费力，甚至不如人工测试方便；

　　2. 提前写好多个不同功能的脚本，编辑风格导致脚本间差异巨大；大量调试修改降低了脚本复用性，脚本维护困难重重。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　通过这样的方式，大家对不正常的情况可以有效的进行及时的记录和干预，方便后续处理相应的问题。

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

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

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

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

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

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

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

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

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

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

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

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

　　特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。

　　妈妈在逗宝宝玩，宝宝咯咯笑，爸爸看到后，也想试试，万万没想到...网友：关键他还不甘心，试了两次

　　小男孩在台下看变脸表演入了迷演员谢幕后 小男孩自己上台开演了没想到一段表演直接惊呆众人

　　妈妈纪录双胞胎儿子每天跟着视频锻炼，两个孩子从小梦想就是当兵，网友：中国少年 未来可期

　　传音 TECNO MEGABOOK S1 炫彩版笔记本亮相，A 面可动态变色