导读：只管自动化测试技术突飞猛进，然而自动化 case 构建老本、执行稳定性等问题的存在，使手工测试仍然挪动端质量保证的重要伎俩。传统手工测试必须通过人工操作的形式执行测试用例，效率晋升依赖测试人员的操作熟练度。本文从介绍百度内 UI 兼容性测试现状切入，引出“一机多控”并以此概念为根底打造的工具 Hydra。而后从技术实现的角度，介绍了 Hydra 整体的设计思维以及局部外围模块的设计。
一、背景
1.1 挪动端 UI 兼容性测试
挪动端的 UI 兼容性测试，顾名思义就是对挪动端利用在不同机型、不同分辨率、尺寸的挪动设施上 UI 界面展现的一致性进行测试。
作为挪动端利用质量保证的重要组成部分，长久以来仍然通过纯手工的形式进行操作测试。传统的挪动端手工兼容性测试，在百度的利用开发流程中次要在以下两个阶段：
a. 功能测试阶段
通常 12 人，在大量业务线手机（约 13 台），总计测试工夫在 10~20 小时。
b. 上线前全功能 (回归) 测试阶段
14 人，在业务线手机（512 台），总计测试工夫在 20~50 小时。
1.2 面临的问题
在以后采纳的挪动端手工兼容性测试，存在以下两个问题：
a. 效力晋升艰难
举例个简略的例子，一次回归测试中 UI 兼容性在 10 台设施上验证 100 个 case，每个 case 耗时 1 分钟，那么总共就须要验证 10×100=1000 个 case 耗时约 17 个小时。这些 case 都须要测试人员手工在每台设施上进行操作。那么须要升高测试阶段的耗时，只能通过减少测试人力的形式。
b. 兼容性测试不够充沛
对于 UI 兼容性测试来说，笼罩的品牌、型号、零碎版本、UI 版本等因素都会影响测试的召回率；但在现状中，挪动设施是每个业务独有且无限的，业务线之间设施难以流通。
二、一机多控与 Hydra
2.1 Hydra 如何解决传统挪动端手工兼容性的问题
挪动端的 UI 兼容性测试仍然采纳手工测试形式来执行，存在目前尚无奈解决的客观原因，比方：挪动端利用 UI 界面迭代快、自动化测试用例生成老本高；UI 兼容性稳固无奈进行标准化定义，召回艰难，等等。
对于效率问题，Hydra 试图从另一个思路——也就是通过“一机多控”的形式，晋升手工执行测试的效率。一机多控顾名思义就是测试人员管制一台“主控”设施，他的操控动作可能同时管制多台“从控”设施，并进行人工的 UI 校验，达到在单位工夫内进行更多测试的目标。而设施有余的问题，则是通过将“一机多控”与云设施平台对接，解脱物理设施的限度来解决，例如云设施来晋升兼容性测试覆盖度。
2.2 用户的需要
对于这样一款提效手工测试的一机多控工具，一线测试人员又是什么冀望呢？总结来说是以下四个方面：
a. 准：在“主控”设施操控的地位、成果，可能准确无误地复制到“从控”设施上。这是一机多控工具的基本功能。
b. 多：包含设施数量多、设施品种多、反对的利用品种多。
c. 易用：操控的体验、交互该当是不便、快捷、合乎应用习惯的。
d. 快：操控的速度快。
2.3 Hydra 的计划
综合思考用户需要之后，确定了 Hydra 的根本状态与技术计划：
首先咱们思考到“多”的因素，因为当初支流挪动端有 Android 和 IOS 两大零碎，设施的驱动形式、工具集差异十分大；其次非原生利用模式如小程序、H5 越来越多地涌现进去，原生利用的驱动形式并不适宜这些新形态的利用。因而咱们决定采纳图像算法来作为动作“复制”的外围算法。
采纳图像算法，就会引申出更快地获取图像、更快地对图像计算的问题，因而采纳通过 PC 机有线连贯的形式，从而更好地满足用户对准、快的需要。
Hydra 的根本状态是一个 PC 程序，用户能够通过有线形式连贯本地设施，或者通过网络连接云设施。所有被测利用在设施上的画面在浏览器上间接展现，使测试人员可能更加直观地对 UI 界面进行校验，从而召回 UI 兼容性问题。这种展现形式也解决了设施增多之后带来的校验效率问题。
出于对测试人员应用习惯的思考，Hydra 也反对通过挪动设施作为“主控”来操作。
三、Hydra 的技术架构
Hydra 整体采纳 BS 架构，通过 http/websocket 协定与前端展现进行通信。具体的展示模式与能力实现进行解耦，能够十分不便地扩大出新的展示类型，比方手机客户端。
在性能组件中，比拟外围的是群控引擎与图像合成器，别离负责“一机多控”性能的输出与输入局部。
通过浏览器 / 客户端捕捉用户在“主控”设施上的实时输出，经由群控引擎进行复制之后，同时操作每一台“从控设施”。操作的反馈经由“实时图像流”，展现在用户的浏览器 / 客户端上。以此达到“所见即所得”的实时操控体验。
下文将对性能组件中，几个外围模块的设计与实现进行介绍。
3.1 群控引擎
群控引擎的设计指标是实现一次动作，屡次执行。
其中的难点在于：
a. 不同分辨率下，实现坐标相干的用户输出的精确映射。
b. 不同设施性能下，单次动作在不同设施上的执行先后问题。
c. 屡次动作组合的时序问题。（如点击变长按）
针对 a. 所指的坐标映射解决，是通过“多场景高性能图像算法”来解决，将在后续大节具体介绍。
对 b. 群控引擎在并行处理“从机”执行动作的时候，会期待所有的坐标映射解决实现，对立登程执行，对于用户来说达到的成果，就是一个动作会“同时”反馈。
对 c. 群控引擎为“主控”和每一个“从机”建设动作执行队列，并记录“主控”每一次动作的工夫戳。在“从机”执行动作的时候，按照“主控”的动作的绝对距离进行执行，确保执行的时序与用户输出尽可能的统一。
3.2 实时图像流
实时图像流是一条设施图像与展示的传输通路，其设计指标是可能实现多机“实时”图像展现，让用户可能更快地查看操作反馈。
其中的难点：
a. 不同设施性能下，输入图像帧率是不同的
b. 网络设备的图像输入帧率不稳固
c. 不受控的帧率导致数据传输多，性能耗费大，影响实时性。
d. 前端展现回调爆炸
要解决以上稳固，咱们首先须要明确，对于实时图像流来说，实时性比起晦涩度（帧率）是更重要的。因为用户的输出动作是一个离散的行为，通常须要须要辨认的 UI 兼容性问题也是动态的。因而咱们首先限度了设施的输出帧率为 16 帧并升高 / 衡量每帧图像的尺寸，满足“晦涩”的根本需要，同时也尽可能升高了数据量造成的性能问题。
限度了单台帧率之后，多台设施叠加造成的前端回调爆炸问题，通过自定义的数据协定。将多机图像合成，从而升高展示层接管到的图像帧率。在实现的时候，采纳固定合成帧率，定时采集所有设施的输出图像，为前端展现屏蔽不同设施的图像帧率差别。
如上图，咱们有 n 台设施，设施 #1 以固定帧率稳固输入图像，设施#2 以较低帧率稳固输入图像，设施#n 则是不稳固输入图形。Hydra 建设了独自的“图像合成”线程，以预期的固定帧率（16fps），从所有设施采集最新的的图像，作为给用户展现的图像，并进行合成。
上图展现了自定义的合成数据协定的设计。每一帧中蕴含所有图像的数据，在帧头中对帧的根本信息进行形容，其中就包含蕴含多少设施图像。接着在每隔一个设施的独自图像数据中，蕴含数据头。数据头形容了设施与图像的相干信息。同时对整个数据帧的数据局部进行再次压缩，以缩小数据传输量。
3.3 多场景高性能图像算法
在实现了群控引擎和实时图像流之后，就实现了群控的根本雏形。然而要让群控的体验更好，就联合本节介绍的图像算法。
坐标映射的处于架构的外围地位，须要满足性能、准确率、通用性。咱们选取的算法须要综合思考上述要求，并进行衡量。因为咱们整体属于实时零碎，对于性能的要求会更高。
最根本的咱们能够选取坐标值的数学转换，依据屏幕尺寸按比率进行换算。很显然这种算法最简略，性能最高，然而准确率是没方法满足的。因为只有当所有设施的图像是完全一致的时候，这种算法才可能精确换算。图像模板匹配是一种高性能、高准确率的图像算法，然而对于图像形变之后就无奈辨认，通用性无奈满足。
咱们选取了 sift 算法作为根本的图像算法，通过计算后的特色点进行换算映射。间接利用 sift 算法，在准确率、通用性都有比拟好的体现，然而性能上有十分大的瓶颈，均匀一组图像的解决耗时在 2s，无奈达到实时要求。因而咱们须要对 sift 算法的利用进行优化：
首先咱们对主控和从控设施的图像做了一次区域截取，升高算法的计算量；接着并没有间接应用计算后的特色点来映射，因为特色点的散布与图像无关，而坐标的输出能够是任意的。因而咱们通过选取已有的 2 个特色点（图中红、绿点）a、b，计算在主控中指标点 c 与 a、b 之间关系（偏移角度与间隔）。并将这种关系利用从控图像上进行计算，从而计算出指标坐标。
上述算法在大部分场景下能够体现良好，然而在局部场景（如列表）下准确率存在问题。因而须要进一步进行优化。
在一次群控映射发动的时候，首先选用 cnn 算法对页面进行辨认，确定以后是否处于列表页面，接着再采纳 dnn 对象辨认来检测图像中是否曾经存在预训练的图标。上述过程只在一次群控映射执行一次，基于以上的后果，在对每一个设施进行映射的时候，能够采取不同的策略：如果曾经存在预设的图标，那么间接采纳 dnn 辨认出对象即可。接着依据是否处于列表页，决定 sift 算法的参数（更大的选取框、更高的特色阈值）。
基于以上算法，Hydra 实现了均匀 160ms 内的坐标映射和 97.52% 的准确率。
3.4 一致性修复
在理论应用过程中，设施图像呈现不统一是比拟常见的景象。起因可能是“从机”没有如预期那样依照“主控”的动作点击或者呈现了如零碎弹窗之类的预期外界面。群控中呈现不统一是预期中的，为了提高效率，设计了高效的修复伎俩。
首先，在 Hydra 的操控设计时候，反对在群控过程中对每一台设施的独自查看与管制，当呈现个别设施呈现不统一的状况，能够立刻对其进行修复，并回到失常的测试操作流程中。
其次对于比拟容易呈现不统一的场景，如列表页，提供了半自动化的滑动一致性修复。
如上图，当“主控”与“从控”在列表页滑动的地位不统一的时候，会别离对两个图像进行 sift 计算，失去对应的特色点。通过特色点连线之间的斜率，来判断以后“从控”图像是否存在滑动不统一的状况。
并不是所有的特色点都可能采纳。咱们试想一个列表页面，导航栏和标签页是不能滑动的，只有两头的内容才能够滑动呈现不统一。因而咱们将图像从上到下分成四个区域，并对每个区域中的特色点应用不同的权重，最上局部和最下局部不会变动的区域，权重值最低。两头可滑动局部也分成高低两个局部，下半局部因为屏幕尺寸关系，展现的内容高度会存在少许不统一，容易造成误导，因而赋予中等权重。上半区域是咱们次要用来判断的区域，赋予最高的权重。
当失去不同权重的特色点连线之后，咱们对其进行加权均匀，即可依据后果判断是否存在滑动不统一的状况，并依据斜率计算差别，而后主动操控设施进行反向滑动弥补，即实现了滑动一致性修复。
3.5 挪动端手持管制
测试人员传统的测试形式是间接手持设施进行操控，鼠键操控的习惯无奈适应。因而 Hydra 也提供了通过挪动手持管制的操作形式。Hydra 提供了两种手持管制的计划：
- 遥控计划
这种计划下，与浏览器计划一样，先抉择一台设施作为主控。接着利用现有的前端技术。从“主控”设施采集到的图像，会发送到在遥控设施的浏览器上并展现，同时采集用户输出发送到真正的“主控”上。就如同在遥控“主控“设施一样。
这种计划的劣势是实现简略，利用现有的前端技术，并且兼容性好，在 Android 和 IOS 上都通用。
然而，毛病也很显著：（1）遥控设施本身并不能用来测试，会节约一台设施。（2）如果遥控设施和主控设施的分辨率尺寸不统一，那么在遥控设施上展现的显示成果会存在缩放，显示成果不佳。
- Android 客户端计划
这种计划是利用 Android 平台的开放性，Hydra 提供了 Android 客户端，当应用这台设施作为主控的时候，能够间接进行操控。Hydra 的客户端会采集用户的输出，间接群控所有的“从控”设施。
那么如何捕捉用户输出呢？
客户端会事后在手机上建设双层的悬浮窗。当用户在手机上进行操控的时候，（比方这里用户点击了（400，1000）这个坐标，那么会被 layer#1 拦挡到触摸动作的坐标。如果用户点击的是如 back 的虚构按键，那么会由 layer#2 进行拦挡。当获取到动作坐标以及按键信息的时候，客户端将这些信息发送至群控引擎，“复制”触发所有“从控”机进行执行。同时，因为用户动作曾经被拦挡，这些动作无奈间接失效。因而 Hydra 客户端上，还蕴含了微型的执行引擎，能够对用户动作进行解释，并且在以后设施上进行操作。
基于上述两个计划，就实现了让用户应用挪动设施来一机多控的能力。
四、Hydra 的落地成果
Hydra 目前已在百度内多条业务线进行落地，并在 app 回归、广告测试、经营流动等多种业务场景获得了正向的收益，每周均匀提效在 20%~70%。
当然 Hydra 也存在肯定的局限性，在局部场景并不实用或者成果并不显著：
1. 是不适宜群控的场景，比方不同账号的登录，须要配合内部定制化的输出计划来实现。
2. 是有动静背景如视频的 icon 点击，在辨认上存在比拟大的瓶颈。
3. 是操作链路比拟长，操作类型比较复杂的用例，在肯定工夫的群控之后，呈现不统一的概率会增高。
4. 还不反对一些简单的手势操作如缩放、旋转等。以上问题咱们在继续的进行优化改良。
五、更进一步提效手工测试——工具箱
通常咱们实现挪动端手工测试，须要测试人员去寻找实现测试须要的工具，学习并应用。这种测试过程有肯定学习老本并且成果也很难保障。Hydra 作为挪动端手工兼容性的提效工具，这种应用模式也体现了咱们对于挪动端手工测试畛域的思考——在测试人员与设施之间须要一个连贯的“桥梁”，它是一个工具箱，能够开箱即用实现具体的测试指标。
更进一步地，它能够是对手工测试流程进行标准化的测试过程，这种标准化体现在对测试工作阶段性的定义、工具的应用、测试数据的收集与后果的校验。依据测试场景的不同，对于每个阶段应用的工具集能够抉择举荐。还能够与内部的 case 治理、bug 跟踪零碎买通，造成闭环。通过这种形式，对于手工测试，不仅仅能够对部分的测试工作，更能够从整体实现效率上失去进一步晋升。
原文链接：https://mp.weixin.qq.com/s/OHmWsHS-_ANrNXj8c5bDNg
百度架构师
百度官网技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
欢送各位同学关注！