作者介绍

崔宇，2018年加入去哪儿网，现在担任机票客户端开发负责人，擅长ios、android以及RN技术，主导了 TARS-UI主动化测验体系的开发和落地运用。

一、前言

去哪儿旅行 UI 主动化体系 TARS 于 2020 年 3 月发动，到 2020 年底达到一期估计方针。掩盖公共、机票、酒店等多个部门接入，月版发版30屡次，回归履行主动化上百次，200多个项目发布履行 400 屡次，发版无 P1、P2 毛病，节约人力近千 pd 。

持续运转一段时刻后，TARS 团队收集了运转中的各种问题，并拟定处理计划，发动了新一轮的迭代设计。

二、TARS 中心指标和问题

要洞悉到 TARS 体系有哪些问题，首要要有一个合理的点评规范。在 TARS 体系运转过程中，咱们总结了五个首要指标来体现 UI 主动化的履行状况。

– 掩盖度

• 包含事务线掩盖度与 case 掩盖度。

• 事务线掩盖度代表是否掩盖了公司一切事务线。

• case 掩盖度指每个事务线回归 case 的掩盖程度。

– 阻拦越过率

• 咱们对前端项目的发版进行了 UI 主动化阻拦，必须经过主动化才能发布。

• 在某些状况下，假如不能跑主动化，能够恳求越过。

• 阻拦越过率代表发布项目中没有跑主动化使命的份额。归纳反响了 TARS 体系是否好用。

– 精确率

假设一个主动化使命跑 100 个 case，经过的有 90 个，未经过的有 10 个。但未经过的10个不必定都是bug导致的，或许有 5 个是 case 不完善导致的，有 4 个是体系不稳定导致的，只要 1 个是真实的 bug，那么就以为精确率为 91% 。

– 运转时长

• 一个主动化使命均匀运转时刻。

– bug 召回率

假设要发布的项目有 10 个 bug，经过主动化测验测出来 3 个，那么召回率便是 30% 。

经过对这些中心指标的持续关注，咱们发现了以下几个问题：

1. 掩盖度低，新事务线接入很少，case 更新也不频频。 剖析原因，首要是由于老的体系接入本钱太高，需求 QA 把握许多 UI 主动化运转环境的知识。并且 case 编写本钱比较高，咱们添加新 case 的意愿比较低。case 掩盖度低的话，那么就不能掩盖足够多的事务场景，bug 召回率就会下降。

2. 阻拦越过率高。 剖析原因，是由于每一次主动化使命履行时刻比较长，并且由于体系原因构成的 case 失利率高，常常误报不经过。操作体会也比较差，同学们为了尽快发布，常常会挑选越过主动化使命。

3. 精确率不到80%。 剖析原因有几个方面的问题。首要是，运用线上数据进行测验，由于事务一直在迭代，运用线上数据常常会遇到 case 没有掩盖到的操作，比方新弹窗等。第二，人工编写的 case质量参差不齐，这也决定了 case 是否健壮稳定。第三，主动化结构不稳定常常会构成手机控制失利，case 运转不起来等问题导致 case 履行失利。

4. 每个使命运转时刻比较长。 剖析原因，case失利导致重试的次数多以及设备没有充分被使用是首要原因。

怎么处理以上问题，便是咱们本次重构的要害。总结下来，咱们要处理的问题如下：

• case编写难度高，线上数据改动多，case 不简单掩盖各种状况；
• 体系环境接入复杂，并且稳定性差；
• 使命履行时刻长，设备没有被充分使用；
• 渠道操作体会需求提高

接下来，咱们先来看看怎么处理第一个问题。

三、主动录制 case 计划

1、UI 主动化技术简介

UI 主动化的中心逻辑便是经过模仿用户的操作来完结主动化测验。模仿用户操作的要害技术便是怎么查找页面元素。现在查找页面元素的办法大致有两种：图像辨认和元素标识。

– 图像辨认

图像辨认是脱离页面 UI 组成结构，模仿人眼看图的逻辑来辨认元素。比较盛行的计划有图像比对、文字辨认、AI技术辨认等。这种办法的长处是不受程序完结办法与体系的约束，能够更加通用牢靠的完结查找元素。缺陷是对元素含义的辨认比较困难，简单查找到错误的元素。

– 元素标识

元素辨认是根据代码结构，经过界面上的元素标识、path 途径、文字等办法来定位一个页面元素。这种办法的长处是能够比较精确的找到事务需求的元素，缺陷是受限于程序的完结办法和体系的约束，有时分获取元素标识会不稳定，给元素加标识作业量比较大。尽管作业量会大一点，可是经过元素标识的办法来查找页面元素现在对咱们来说是更可行牢靠的计划，所以咱们是根据元素标识的办法来完结主动化 case 的录制回放。就元素标识辨认的办法来说，它在实践的过程中也阅历了一些开展演变：

计划	阐明	长处	缺陷
绝对途径	最早根据绝对途径来查找元素，也便是彻底根据元素树来生成元素的仅有定位标识	能够很快的录制操作，生成case	保护性太差，代码稍微一改动构成途径改动，case就都不能用了
DOM	为了处理绝对途径元素标识常常改动的问题，经过给元素加标签，或许运用相似 xpath 的办法来进行相对途径的查找	代码改动对元素标识查找影响可控，case保护本钱大大下降	case 脚本编写本钱高，需求人工加标签并编写 case 脚本
POM	将元素标识与页面行为进行封装，case 编写人员只需求调用页面行为办法编写脚本即可	下降了 case 脚本编写本钱，假如事务发生了改动，只需求改动一个当地就能够确保一切的 case 正常运转	对脚本编写人员的代码设计能力要求比较高，需求设计通用牢靠复用性高的PageObject

2、TARS 编写 case 办法

TARS 编写主动化测验 case 是根据POM原理。过程如下图：

首要，咱们先手动在代码中给要操作的元素添加标签，比方com.Qunar:id/ato_flight_tv_dep_city

第二，为了防止代码迭代对 case 保护构成影响，咱们在 case 脚本中将标签封装成了元素组件 arr_city，这样，即便界面结构发生了改动，只要该元素还存在，就依然能精确找到这个元素，并不需求常常保护。

第三，然后咱们封装了根据元素的操作行为，比方挑选抵达城市。在实践编写 case 的时分，QA 同学就能够直接调用交互办法来组成一个 case 操作流程。

第四，在履行 case 的时分，咱们会经过数据东西拉取线上符合咱们 case 要求的数据环境，然后在数据环境的指导下操作 APP 履行 case。

第五，终究 case 脚本依照固定的步骤履行，假如元素标签发生了改动或许元素功用需求保护，只需求修正对应的标签或办法即可，并不需求对 case 脚本进行修正。

这种办法现已十分好的处理了脚本编写作业量大，保护本钱高的问题。可是在实践落地过程中，QA人员依然会由于 case 编写难度高而很少新增新的 case。

为了考虑怎么更进一步的下降 case 编写本钱，咱们将编写 case 中心功用点笼统如下：

笼统出来编写 case 的中心功用点之后，咱们发现了一些问题：

• 手动保护 UI 元素标签：标签保护作业量大，每次有标签的修正还要重新发布版别，并且人工编写简单犯错。
• case 编写学习门槛高：尽管咱们现已很大程度上对页面的交互进行了封装，QA 同学只需求调用即可，可是总会遇到未封装的行为，关于 QA 同学的编码设计能力有必定的要求。
• 运用线上数据履行 case：线上数据常常会出现改动，需求不断的保护新增的预期外的流程。并且简单构成 case 履行的不稳定。

这些问题就构成了 QA 觉得编写 case 是一种担负，导致了 case 掩盖度不行，进一步导致召回率低。运用线上数据履行以及 case 编写质量参差不齐构成了精确率的下降。case 履行的精确率低就会构成 case 重试次数增多，导致履行时刻长，然后就影响了阻拦越过率。所以咱们需求考虑能不能运用主动生成标签、主动生成脚本、运用稳定的数据来履行 case 的主动录制 case 的办法来编写 case。

3、怎么主动录制 case

能够主动添加标签、主动编写脚本，这种 case 录制办法咱们叫它“主动录制 case”。理论上，假如程序代码相同、数据相同的话，相同的操作就能复现相同的成果。在这个基础上，假如用最新开发的代码进行回放，数据相同，操作相同，可是成果不相同，那就或许是两个原因，一个是 case 需求保护，一个是代码写错了。case 需求保护的状况一般来说是相关功用进行了改版，老 case 不适用于新事务。这种状况肯定是要保护 case 的。主动化测验的含义在于将重复的劳动主动化履行。也便是说，是对老功用进行回归，而不是对新功用进行测验，所以由于新功用的上线构成一些老 case 被废弃是必定的。那么把这部分 case 去掉，其他的没有履行经过的 case，大概率便是测出bug了，所以用录制回放的机制来作为主动化测验的 case 是可行的。想要把用户的操作行为记载下来进行回放，首要要处理怎么记载元素的问题。也便是主动生成元素仅有标签，经过仅有标签来定位元素。这种办法看上去和根据绝对途径的 case 录制很像，由于之所以运用绝对途径生成 case，便是由于它是天然的元素仅有标识，可是这样咱们的元素标识就会十分不稳定。稍微有一点改动就会导致找不到曾经的标识。那么怎么既能够主动生成元素标签，又能够必定程度上比较稳定呢？

– 主动添加标签

首要咱们要考虑的是标签生成的规范是什么？经过咱们的考虑，首要有两点:

1. 页面仅有。标签必须是仅有的，不然或许回放 case 的时分会点错元素，导致最后测验成果有误。

2. 必定程度上能够反抗 DOM 树的改动，不会由于事务迭代而发生频频的标签改动。

经过研究，咱们以为用组件树的办法来生成标签比较符合要求。

首要，一个页面的元素在咱们的代码中是有一个组件层级归属联系的。比方之前抵达城市那个按钮，它的索引联系为机票主页-搜索面板-单程面板-抵达城市，一般来说，咱们的代码都是会依照页面、模块、组件这样的办法来进行安排。这就天然构成了一种标签的规矩，便是依照组件层级进行仅有定位。

可是在实践操作中有一些特例。比方，某些元素是经过 for 循环来生成的，这样每一个元素标识都是相同的，所以咱们就追加每一个元素的key来仅有标识。还有或许在一个代码文件中同一个元素写在了多个当地，这种状况咱们就用元素地点的代码行数来仅有标识。

这样，咱们生成的标签大概是这个姿态的：

flight|OrderFillView|OrderFillPage_NewPassengerCard_ListPassengers_ToAddPassengerListView_ToAddPassengerItemView|TouchableOpacity_line=110

能够看到，这个标签能够明晰的标识出元素的事务线、页面、事务模块、组件类型。

标签规矩定好了，咱们就能够依照这个规矩主动生成元素标签。为了防止人为破坏标签，咱们挑选在代码编译期经过插件的办法将标签信息注入到相关的元素组件上。这样，开发人员不会在代码中看到他们，防止了人为修正的保护问题。

标签主动生成必定是根据相关代码版别的，一旦代码发生了改动，很或许重新生成的标签和上一次的标签不相同。这样咱们根据上一次标签版别录制的 case 就跑不了了，由于元素都找不到了。

那么关于组件层级生成的标签，是否会由于代码的改动而常常需求保护？

一般假如仅仅简单的添加新功用，一般是不会破坏组件层级的。而列表项的仅有标识是与数据相关，只要数据不变，key 就不会变。

那么现在就剩下line标识或许会常常需求保护了。

– 主动保护标签

根据之前的剖析，咱们关于经过 line 标识来进行仅有性区分的标签或许会频频的发生改动，导致 case 履行失利。所以关于这种状况，咱们需求尽量经过主动保护标签的办法来防止添加人工保护的作业量。

那么咱们能否辨认出新老版别的标签对应联系，将他们进行一致性相关？

咱们先整理一下代码改动对标签发生的影响或许有那些。

第一种状况是标签地点的元素组件代码没有修正，可是代码文件其他当地发生了改动。

第二种是标签地点的组件被删去。

第三种是标签地点的组件被修正。

关于第二种和第三种，咱们肯定是要人工对 case 进行保护，由于这种状况归于事务本身发生了改动，曾经的 case 不适用了。

而第一种状况是咱们需求进行主动相关的状况。咱们能够经过 diff 的办法来辨认新标签曾经是哪一个标签，然后在跑 case 之前先进行标签的相关，然后再跑 case。

– 记载 QA 操作主动生成 case 脚本

所谓记载便是要在可交互元素触发操作的时分，记载下来哪个元素在哪个时刻被做了什么操作。所以，咱们需求阻拦元素的事情回调办法，先记载埋点，再调用曾经的逻辑。

咱们经过装修器形式，在编译期对可交互元素进行包装，这样，QA 操作元素的时分就会先记载埋点。

埋点信息里面包含元素标签、事务线、地点页面、地点模块、操作时刻、操作类型、代码版别等信息。

然后在录制 case 的时分，咱们将埋点数据保存下来，构成用户操作列表。case 便是将这个操作列表的操作翻译成主动化脚本进行模仿点击。

– 保存数据现场

现在咱们主动将 QA 的操作记载了下来生成了主动化脚本，同时还需求将数据现场进行保存，不然咱们就无法正确的回放 case。

在 QA 操作 APP 的时分，咱们会将每一个接口恳求的恳求数据和回来数据进行存储，当回放的时分，咱们按顺序运用本地的接口数据替换每一个接口恳求的回来值，也便是 mock 。

这样，就能够确保 case 脚本所操作元素都在，除非代码进行了迭代。并且运用 mock 数据，防止了复杂的线上数据场景，增强了 case 履行的稳定性。

这样，咱们录制 case 便是将 QA 的操作和数据存储下来，履行 case 便是用这个数据在被测代码中进行回放。

– 主动生成断语

一个 case，要有一个成果来断定是否经过。一般来讲，咱们是经过断语来断定 case 最后是否履行成功。咱们来看一个例子：

主页->产品列表->挑选产品->产品概况->购买->联系人->进入承认订单页

当上面这个 case 履行完之后，咱们需求判别，是否承认“进入了承认订单页”。这个操作咱们当然也不能手写。

为此，咱们与算法组合作，引入了“智能 OCR 辨认”功用。普通的 OCR 辨认是匹配页面上的文字，可是关于咱们的场景来说还不能彻底满意，由于或许页面上有多个相同的文字。所以咱们还需求知道文字地点的上下文，比方方位，相关的其他案牍等。

“智能 OCR 辨认”功用能够先将页面模块进行划分，然后辨认每一个模块中咱们要查找的文字，然后回来文字地点模块的一切信息。这样，咱们就能够精准界说咱们的断语条件了。

有了“智能OCR辨认”，咱们能够将断语写成一个条件，作为 case 的一个特点信息一起保存在 case 数据中。不需求手动编写代码脚本来判别。

事务逻辑的断语验证完还不算 case 真实经过，咱们还需求验证数据的断语。

由于咱们运用的 mock 数据来跑 case，便是咱们代码写错将恳求参数拼错了，也不会影响数据回来成果。所以假如出现了这种 bug，咱们就感知不到了。所以，咱们需求对被测代码中的恳求数据进行校验。

由于咱们保存了接口的恳求数据，理论上假如跑 case 的时分，生成的恳求数据和保存的恳求数据彻底一致，那肯定是没问题的。可是由于事务迭代，恳求数据一般会发生改动，所以咱们要比对的是要害的数据节点。要害数据节点前后彻底一致，就能够以为恳求数据的逻辑是对的。

事务断语和数据断语都经过，一个 case 就算是经过了。

– 改造后的流程

主动录制 case 的机制完结今后，流程变成了下图姿态，基本上彻底完结了主动化，下降了 case 编写的难度：

录制完 case 之后，只需求在渠道上进行上传即可。

主动录制 case 处理了 case 编写难的问题，也必定程度上提高了主动化使命的精确率。下面咱们来看看怎么提高结构稳定性，下降接入本钱，充分使用设备，优化操作体会。

四、全新的主动化渠道

第一个问题处理了，然后为了处理其他的问题，咱们也对整个主动化体系进行了晋级，包含基础设施、调度渠道、报告等。

1、TARS基础设施晋级

晋级前，咱们的底层体系架构如下：

体系中的问题都会构成 case 履行的精确率下降。改造后的体系如下：

2、分布式设备调度

曾经，咱们是每一个事务线自己保护一套设备。由于不同事务线履行主动化使命的频率不相同，就构成了设备运用上的浪费，有大量的手机一直在搁置。

为了处理这个问题，咱们根据 STF 打造了分布式的设备调度体系。更全面的掩盖了手机设备型号，重复使用设备能力，由更灵活的设备调度战略来管理 case 运转。

3、TARS 云测渠道

为了进一步提高用户体会，满意开发或 QA 同学对主动化渠道的各种需求，咱们打造了全新的主动化渠道，供给了丰富的功用，优化了日常运用的效率。

云测渠道不仅仅能够支持日常的 case 使命履行，还能支持远程真机租借、性能等专项测验、行为回溯等功用，为咱们供给更多根据主动化技术的服务。

五、总结规划

晋级改造后的渠道各项指标都达到了预期的方针。

1. 事务线接入十分方便，录制 case 也很方便
2. 阻拦越过率降到了 8% 以内
3. 精确率达到了 95% 以上
4. 均匀一个主动化使命履行时刻在10分钟以内
5. 提高了主动化掩盖度

可是在实践场景中，主动录制 case 并不能彻底取代手动编写 case。由于它需求用 mock 数据进行测验，也便是说，关于需求运用线上数据进行测验的场景就无能为力了。

计划	适用场景	掩盖 case 等级
手动编写 case	端到端测验。比方一些后端的发布，需求前端的主动化测验对一些事务场景进行掩盖。	P1、P2
主动录制 case	前端发布测验。关于只关注前端 bug 的测验，主动录制 case 是能够胜任的。	P1、P2、P3

所以手动编写 case 本身还需求进一步的提高体会，比方未来咱们会经过强壮的 IDE 功用来简化 case 编写操作，也或许会凭借 AI 来帮助处理一些广告弹窗等 case 未掩盖的问题。