移动端UI兼容性测试利器-Hydra(上)

发表于:2021-2-19 10:17

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:fin_123    来源:CSDN

  导读:尽管自动化测试技术日新月异,但是自动化case构建成本、执行稳定性等问题的存在,使手工测试依然移动端质量保证的重要手段。传统手工测试必须通过人工操作的方式执行测试用例,效率提升依赖测试人员的操作熟练度。本文从介绍百度内UI兼容性测试现状切入,引出“一机多控”并以此概念为基础打造的工具Hydra。然后从技术实现的角度,介绍了Hydra整体的设计思想以及部分核心模块的设计。
  一、背景
  1.1移动端UI兼容性测试
  移动端的UI兼容性测试,顾名思义就是对移动端应用在不同机型、不同分辨率、尺寸的移动设备上UI界面展示的一致性进行测试。
  作为移动端应用质量保证的重要组成部分,长久以来依然通过纯手工的方式进行操作测试。传统的移动端手工兼容性测试,在百度的应用开发流程中主要在以下两个阶段:
  a. 功能测试阶段:通常1~2人,在少量业务线手机(约1~3台),总计测试时间在10~20小时。
  b. 上线前全功能(回归)测试阶段:1~4人,在业务线手机(5~12台),总计测试时间在20~50小时。
  1.2面临的问题
  在当前采用的移动端手工兼容性测试,存在以下两个问题:
  a. 效能提升困难:举例个简单的例子,一次回归测试中UI兼容性在10台设备上验证100个case,每个case耗时1分钟,那么总共就需要验证10x100=1000个case耗时约17个小时。这些case都需要测试人员手工在每台设备上进行操作。那么需要降低测试阶段的耗时,只能通过增加测试人力的方式。
  b. 兼容性测试不够充分:对于UI兼容性测试来说,覆盖的品牌、型号、系统版本、UI版本等因素都会影响测试的召回率;但在现状中,移动设备是每个业务独有且有限的,业务线之间设备难以流通。
  二、一机多控与Hydra
  2.1Hydra如何解决传统移动端手工兼容性的问题
  移动端的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. 群控引擎为“主控”和每一个“从机”建立动作执行队列,并记录“主控”每一次动作的时间戳。在“从机”执行动作的时候,依照“主控”的动作的相对间隔进行执行,确保执行的时序与用户输入尽可能的一致。

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
精选软件测试好文,快来阅读吧~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号