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小时就悉数跑完，当天就能出成果，直接就能依据陈述反应去组织方案。

　　这样一来，大幅度削减了咱们在人力上的投入，完结测验所需的时刻也大幅缩短，进步了测验的履行与反应功率，极大推动了咱们项目的进程。

　　感谢天纵团队的共享，在主动化测验结构规划上给咱们带来的十分有用且详尽的经历。比较于每次都推倒重来，这种体系性地展开和保护主动化测验作业的做法，可以进一步优化流程和进步功率，期望能为咱们的主动化测验作业带来更多的思路和学习。