随着美团到家业务的倒退,零碎复杂度也在持续增长。测试用例数量近两年增长约一倍,单端数量超过 1 万 2 千条,而研发人员的工作从大部分工夫在开发,转变成一半工夫在开发、一半工夫在模仿环境和自测。因而,引入自动化测试就显得非常有必要,本文介绍了美团外卖在自动化测试方向做的一些摸索和实际,心愿对从事相干畛域工作的同学可能带来一些启发或帮忙。
1. 我的项目背景
美团外卖的业务场景比拟多元化,除了外卖本身的业务,还作为平台承接了闪购、团好货、医药、跑腿等其余业务。除此之外,在全链路动态化的大基调下,外卖各个页面的技术状态也变得越来越简单,除了 Native 代码,还包含 Mach(外卖自研动态化框架)、React Native、美团小程序、H5 等,不同技术栈的底层技术实现不同,渲染机制不同,进而对测试形式要求也有所不同,这也在无形中减少了测试的难度。下图汇总了美团多业务、多技术、多 App 的一些典型场景。
在产品交付上线的过程中,测试的占比也是十分大的,甚至大于总时长的 30%。如下图所示,整个测试包含了冒烟测试、新功能测试、二轮回归测试、三轮测试。然而,当初需要测试绝大部分还是采纳非自动化的形式,这就使得人力老本变得十分之高。
另一方面,相比于 2018 年,2022 年的测试用例数量增长近 3 倍,曾经超过 1 万 2 千条(如下图所示)。同时,外卖的业务是“三端复用”,除了外卖 App,还须要集成到美团 App 和公众点评 App 上,这样一来,测试工作量就翻了 3 倍,业务测试压力之大可想而知。如果依照以后的增长趋势继续上来,要保障外卖业务的稳固,就必须继续一直地投入大量的人力老本,所以引入可能反对外卖“多业务场景”、“多 App 复用”、“多技术栈”特点的自动化测试工具来晋升人效和品质,势在必行。
2. 我的项目指标
为了解决外卖面临的测试窘境,咱们尝试去摸索一种零学习老本、低保护、高可用的自动化测试计划,可能反对外卖复杂多变的测试场景,它必须同时满足上面几点要求:
- 易用性:工具 / 平台的上手难度,应用复杂度应该尽可能的低,因为自动化测试的目标是提效人力,而不是减少人力累赘。
- 平台反对:挪动端至多须要笼罩 iOS 和 Android 双平台,同时基于外卖的业务特点,不仅须要对 Native 反对,也须要反对 Mach(自研部分动态化框架)、H5、React Native、美团小程序等技术栈。
- 稳定性:自动化测试用例的执行须要有足够的稳定性和准确性,测试过程中不应因测试工具自身的不稳固而呈现稳定性问题。
- 保护老本:保护老本很大水平上决定了测试工作量的大小,因需要产生变动或架构重构等问题时,用例的保护老本应该尽可能的小。
- 可扩展性:当测试计划不能满足测试需要时,工具 / 平台应具备可扩大的能力。
3. 计划选型
自动化测试工具那么多,自研是反复造轮子吗?
针对终端的 UI 自动化测试工具 / 平台堪称“不足为奇”,市面上也有很多绝对成熟的计划,置信大家都有用过,或者至多有所耳闻,但这些计划是否能真的满足咱们提效的诉求呢?以下咱们筛选了三类十分具备代表性的自动化测试工具 / 平台 – Appium、Airtest Project、SoloPi 进行了剖析,来帮忙大家对自动化测试技术建设一个认知:
— | Appium | Airtest Project | SoloPi |
---|---|---|---|
脚本语言 | 反对 Python,Java,JavaScript,PHP,C#,Ruby,OC 等 | Python | / |
数据记录(网络 / 本地) | 不反对 | 不反对 | 不反对 |
环境模拟 | 不反对 | 不反对 | 不反对 |
上手难度 | 高,须要各种环境反对和语言学习 | 个别,不相熟编程语言,也能够肯定水平应用 | 低,用例即操作,不展现 |
问题溯源老本 | 高 | 高 | 高 |
保护老本 | 高 | 高 | 高 |
视图检索 | 基于 UI 控件的检索,反对 10 多种 UI 控件查找形式 | 基于图像识别和基于 UI 控件检索两种形式 | 基于图像识别和基于 UI 控件检索两种形式 |
源码集成 | 无需 | 可选 | 无需 |
WebView 反对 | 反对 | 反对 | 反对 |
用例编辑 | 反对 | 反对 | 反对 |
平台反对 | iOS、Android、Windows | iOS、Android、Windows、游戏测试 | Android |
- Appium 是一个开源工具,用于自动化测试 iOS 手机、Android 手机和 Windows 桌面平台上的原生、挪动 Web 和混合利用。它应用了各零碎自带的自动化框架,无需 SDK 集成,Appium 把这些零碎自身提供的框架包装进一套 API——WebDriver API 中,能够应用任何语言编写 Client 脚本向服务器发送适当的 HTTP 申请。这让不同技术栈的人员都能疾速上手编写测试用例,能够抉择本人最为相熟的语言,然而对于没有语言开发根底的人来说,还是有肯定学习老本,而且这种形式在多人合作时并没有太大作用,为了保障自动化用例的可维护性,团队外部应该须要对立脚本语言。值得一提的是:Appium 在 iOS、Android 和 Windows 测试套件之间可做的肯定水平的复用代码。然而因为不同端界面及元素定位的差别,这往往是不事实的,更无奈保障测试的准确性,所以这种所谓的“跨端”就变得毫无意义。
- Airtest Project 是由网易游戏推出的一款自动化测试平台,除了反对通过零碎自带的自动化测试框架,还反对了通过图像识别的形式,对于非基于原生 UI 零碎的一些游戏引擎提供了 SDK 的反对。其上手难度稍低,能够肯定水平上通过 IDE 进行相干操作来生成简略的脚本指令。Airtest 尽管基于图像进行控件辨认,为跨端提供了肯定的可能性,然而图像识别并不能达到人眼辨认的准确度,除此之外挪动端页面的形成和游戏页面也存在不小的差异,页面元素的展现规定和款式受屏幕分辨率影响较大,单纯依附图像识别来进行元素查找成功率不高,无奈保障测试的准确性。
- SoloPi 是一个无线化、非侵入式的自动化测试工具,通过录制回放的形式进行 UI 自动化测试,SoloPi 尽管只反对 Android,然而在录制回放的这种形式中,还是极具代表性的。传统的自动化测试工具因为须要编写测试脚本,所以存在着肯定的上手难度(Airtest 还是存在代码编辑的),便产生了 SoloPi 这种纯基于录制回放的自动化测试形式,将用例的所有操作事件进行录制,生成一个残缺的录制脚本,通过对脚本的回放来还原所有的操作,从而进行自动化测试。然而,这种形式只能记录操作,而不能记录数据,在外卖这种数据驱动展现的场景下无奈满足测试要求。并且外卖的业务要复用到美团 App 和公众点评 App 中,不同 App 存在局部视图和逻辑性的差别,SoloPi 也无奈反对咱们“一端录制多端回放”的测试场景。
能够看出,以上这些自动化测试工具 / 平台对于数据记录,环境模拟、保护老本、跨 App 复用等方面,都是有所欠缺的。所以无论是哪种计划,在易用性、保护老本、稳定性、可扩展性以及最终的测试成果上,都无奈满足咱们对自动化测试的需要。咱们并不是为了自动化而自动化,而是要解决理论的提效问题。
那么,怎样才能确定一个自动化工具 / 平台的可用性,并长期落地去应用自动化,带着上述提到的较高门槛的上手老本、操作繁琐的环境模拟、差强人意的测试成功率、定位含糊的测试缺点、难以保护的用例脚本等几大重要痛点,本文咱们将介绍美团外卖自研的测试平台——AlphaTest,都具备哪些能力以及是如何解决这些问题。
4. 实际和摸索
一个自动化测试工具 / 平台能不能用起来,取决于他的上手老本和稳定性,即便工具的测试稳定性做的再好,应用的门槛高也会让人望而生却,反之亦然。所以 AlphaTest 平台为了上手简略,升高应用老本,采纳了 基于录制回放 的形式进行设计,并且补救了惯例录制回放无奈编辑的痛点,同时在手势操作的根底上减少了数据录制。整合美团系 App 的个性减少了环境模拟、跨 App 反对、混合技术栈的反对等能力,在应用简略的同时,也保障了用例的可维护性、测试的准确性等。咱们先通过视频简略的理解一下:
用例录制:
点击查看视频
用例回放:
点击查看视频
回放报告:
点击查看视频
4.1 问题和挑战
注:这里咱们将生成的自动化脚本统称为指令,将平台生成的用例统称自动化用例,将录制回放变成可视化的脚本指令,让用例变的易懂、易保护。
录制回放自身是一连串的操作数据的汇合,是连续性的、不可拆分,因而简直不具备可编辑性,这也就导致了用例保护老本极高。AlphaTest 尽管同样基于录制回放的形式生成自动化用例,然而咱们将每一步的操作都具化成结构化的指令数据,并提供可视化指令编辑器,以反对查看编辑。
这些可视化的指令,齐全通过录制主动生成,也不依赖于任何脚本语言。通过可视化用例指令编辑器,不仅为用例提供了编辑的可能性,同时大大地进步了用例的可浏览性,每一条测试用例在测试过程中每一步都做了什么、过后的界面是什么样的、都有哪些断言校验点,是不言而喻的,不会存在像传统图文形容的测试用例那样,呈现了解偏差。指令生成演示,手机录制与平台远端录制双模式反对:
4.2 前置条件筹备
一键环境模拟,解决操作繁琐的用例执行前的环境筹备。
进行一个用例的测试之前,往往须要做大量的筹备工作,比方切换 API 环境,定位到某个地点,登录指定账户等。这些须要筹备的环境条件咱们统称为前置条件。咱们晓得,前置条件的筹备操作通常都不是一两个步骤就能够实现的,比方账号登录 / 切换:咱们须要进入登录页,填写手机号 + 明码 / 验证码,点击登录等一系列动作来实现这个过程,十分繁琐,并且每次测试咱们都须要筹备,重复性高。因而,咱们给 AlphaTest 设计了独立的前置条件模块,将用例拆成了两个局部:前置条件 + 操作步骤。
与其它测试框架不同的是,AlphaTest 采纳了 SDK 集成,但对业务无侵入的形式,因而能够通过编写白盒代码来实现前置条件的主动配置,只须要在平台增加须要的指令,下发到 SDK 后,即可依据相干指令实现前置条件的主动配置,不再须要反复进行相干的操作。并且这些前置条件反对复用,也不须要每次进行用例筹备时的反复配置。AlphaTest 的前置条件,不仅有着基于美团外部服务及底层 Hook 的默认实现,也提供了 API 反对业务方自定义实现,比方实现不同的账号体系。
4.3 用例录制与回放的数据一致性
影响用例执行的不仅是代码,还有数据。
很多时候,自动化用例无奈失常执行实现,可能是因为 App 回放时的本地数据及网络数据与录制时的不统一,从而导致用例执行流程的阻塞或 App 界面展现的不同。这也是大多数自动化测试工具 / 平台测试通过率不高的次要因素,因而要保障测试成功率,咱们须要控制变量,排除由数据产生的影响。
App 运行依赖的数据,有两局部——本地数据和网络数据:
- 本地数据是 App 在运行期间产生的缓存数据或长久化的存储数据。为了让用例在录制回放时都可能保持一致的本地数据环境,咱们在录制和回放前都对 App 的本地数据进行了清理操作,这样用例在录制和回放的过程中,都能够保持一致的 App 初始化环境。
- 网络数据是驱动 App 交互出现的基石,各种策略和 API 降级都会影响网络数据的响应,因而咱们将用例录制过程中产生的网络数据也进行了录制,并将网络数据和对应的操作指令进行了关联和绑定,确定了数据产生的事件源。排除数据影响后,咱们的自动化测试的成功率就取决于自动化操作的准确性了,这就回到了常见自动化框架领域。
4.4 用例录制与回放的操作一致性
指标定位的准确性与手势定位的精准性。
UI 自动化测试的实质就是代替人去主动的做一步步的操作(点击、长按、输出、滑动等)。录制与回放过程的操作是否统一,是否精准,间接影响测试的成功率,决定了工具 / 平台的可用性。
- 指标控件定位准确性:
操作行为是否统一首先须要确认操作指标是否统一。与个别测试工具 / 平台不同的是 AlphaTest 采纳了 ViewPath + 图像 + 坐标的多重定位计划。得益于 SDK 集成的形式,咱们的 ViewPath 能够记录更多的元素视图特色和执行不同的匹配策略。定位过程中会优先应用 ViewPath 进行指标控件检索,当指标控件查找异样时,会联合图像匹配和坐标匹配的形式进行兜底查找,来确保界面变动水平不大时,也能精确的查找到指标控件。
- 手势定位的精准性:
有了基于控件的指标定位之后,对于一些罕用简略操作手势,比方点击、长按、断言、甚至输出都能够做到很好的反对,只须要找到对应的控件,在控件所在位置下发相应的触摸事件即可。咱们晓得,App 真正接管的触摸事件是屏幕上一个个精准的触摸点,在零碎解决后,分发给以后 App 窗口,App 在接管事件后再持续散发,直到找到事件的最佳响应者,后续通过响应者链对事件消化解决。那咱们要还原一个触摸事件的坐标点要如何确定呢?因为咱们确定的只有控件,所以这个点自然而然就成了控件的中心点了。
大多数状况下,这些都能够很好地进行工作,然而对于一些多响应控件重叠的状况,可能会产生料想不到的操作误差。为了解决这样的问题,咱们把控件定位与坐标定位进行了联合:基于纯坐标的定位是一种定位精准度十分高的定位形式,然而稳定性十分差,只有在屏幕分辨率完全一致且回放页面控件地位完全一致的状况下,才具备足够的可靠性,但这往往是不事实的,对测试环境机器量要求过高。
基于控件的定位,又存在着精准度不够的问题。应用坐标定位,如果定位区域足够小的话,那么受屏幕尺寸的影响就会越小,只须要确定在小范畴内的绝对地位即可。而基于控件指标的定位,恰好能够把指标区域放大到一个指定区域,咱们刚好能够将二者联合起来,同时解决定位精准度和稳定性的问题。
对于简单手势的反对,咱们同样能够采纳微分的形式,将一个简单手势拆成多个简略手势的组成,比方咱们能够将一个滑动操作的定位拆成两个局部:起始地位和终止地位,而这两个地位的定位,就变成了两个一般的单点手势操作定位了,能够通过下面提到的一个指标控件 + 绝对坐标的模式进行定位。核心思想都是将基于屏幕坐标点的定位操作,放大的指标控件的区域范畴内,以达到不受设施分辨率的影响,实现操作行为统一的成果。
4.5 可溯源的自动化测试
测试全流程记录,问题溯源一键即达。
测试的目标是保障 App 运行的稳固,测试过程中呈现 Bug 导致测试未通过时,须要溯源问题起因,产生的场景,乃至具体的执行步骤。这也是大多自动化测试工具 / 平台所欠缺的,即便发现了问题,排查工作也很艰难;这个问题在手工测试的时候,更为严重,往往因为很多缺点无奈复现而难以定位。
AlphaTest 的自动化用例最小执行单元是操作指令,咱们将测试过程的每一条指令的执行情况和过程中的界面快照进行了记录,并在指令执行失败时,对异样起因进行了初步剖析。而后将整个用例的执行组合成了一份残缺的测试报告,可疾速溯源问题步骤。除此之外,咱们还减少大量的日志上报,并将整个用例测试过程进行了视频录制,来进一步帮忙疑难问题的排查。真正做到了用例回放测试可溯源。
4.6 用例的保护
自动化用例须要继续地投入人力来保护么?架构降级,页面重构,用例须要全副从新录制么?
因自动化工具 / 平台泛滥,妨碍长期落地应用的一大问题是用例保护老本高,很多工具 / 平台让咱们即使是应用上了自动化,但还须要继续投入人力保护用例的更新,最终的提效收益微不足道。对于用例更新保护,咱们能够梳理划分成三个场景:
- 需要产生重大变更,整体的业务执行流程及相干的校验点都须要进行大量的调整。对于这种状况,无论是何种自动化测试工具 / 平台,都是须要失常进行用例变更重录以适应新的需要。
- 需要产生稍微变更,业务流程基本一致,须要调整的校验点、操作以及数据或不影响整体流程的步骤。对于此场景,AlphaTest 通过指令编辑器与操作录制,反对指令增删改以及数据和场景的还原,帮忙用户疾速的进行用例调整,而无需从新录制用例。例如:批改网络数据字段、视图变更门路、断言替换指标等。
- 和业务需要不同,咱们的技术实现也会产生迭代。随着 App 技术架构一直的演进,常常会面临着架构降级,页面重构甚至技术栈变迁等这样的技术升级。这些变动须要笼罩大量的测试用例,其中大量的自动化用例又可能会因为变动而导致生效,须要从新录制。为此,AlphaTest 设计一套利用相近分辨率机器进行用例主动修改的性能:利用图像 + 坐标进行二次辨认定位,元素定位胜利并校验通过后,生成新的 ViewPath,更新对应的用例指令,对用例进行主动修复,修复后可在任意回放。
4.7 跨 App 回放用例
同一份代码运行在不同的 App 上,是否须要从新编写多份用例?
美团系的一些业务可能会复用在多个 App 上。比方外卖有独立 App,但同时也要复用到美团和点评 App 上,这些性能,简直共用一份代码,而测试人员却不得不对每个 App 上的业务性能都进行测试,保护多份用例。因为业务自身实现是统一的,那咱们能够通过适配不同 App 之间的差别,来让一个业务 Case 能够横跨多个 App 回放,这便能够将老本缩减好几倍,这些差别次要体现在:
- 前置条件和初始页面:业务的初始页面进入门路不同,例如外卖 App 关上 App 就进入到了外卖首页,然而在美团 App 中就须要从美团首页跳转到外卖频道。同时因为不同 App 的款式格调、设计规范、业务个性等因素,也会造成首页代码逻辑和视图层级的差别。
- AB 试验配置:不同 App 所配置的试验可能不同,不同的试验会导致不同的款式和代码逻辑。
- 网路接口映射:不同 App 中雷同业务场景波及的接口有所不同。
- 页面 Scheme 映射:不同 App 中雷同页面的跳转 Scheme 也不雷同。
AlphaTest 平台反对 App 维度各项差别数据配置,当 SDK 检测用例回放环境与录制环境不统一时,会主动进行映射适配,从而让用例运行到了不同 App 上。
4.8 埋点的录制回放
除了功能测试,咱们在日常开发和测试的工作中,还会面临另外一个比拟重要的问题就是埋点测试。因而,咱们在自动化的根底上扩大出埋点自动化测试。埋点自动化测试的核心思想是,通过比照录制期间和回放期间的埋点上报机会和上报参数进行判断。为了保障埋点自动化测试的稳定性,咱们次要采纳以下的障机制:
- 字段规定配置:埋点自定义参数千姿百态,甚至有些字段每次代码执行都不统一,如果进行齐全匹配后果注定是失败的,所以咱们在 AlphaTest 平台提供了埋点字段规定配置性能,通过人为设置的形式来防止埋点自定义参数校验失败。App 重启进入录制状态时,用户就能够操作 App,平台会记录用户的操作行为,当产生相应的埋点日志的时候会将日志信息打印在日志区域(如下图 17 所示),在该过程中也会对埋点日志进行肯定的校验。重点将操作机会、埋点日志一并保留到服务端。
-
埋点机会校验:针对机会校验,程序并不反对埋点曝光的 ”1px 曝光 ”,” 下拉刷新曝光 ”,” 页面切换曝光 ”,” 切前后台曝光 ” 这些规定,次要的起因是每一个业务方在对埋点曝光的规定都是不统一的,而且该规定的实现会极大耦合业务代码。在针对机会校验咱们目前只反对:
[1] 点击埋点上报机会校验,程序通过事件监听和埋点类型信息来判断点击埋点上报的机会是否是在点击的操作下产生的,如果不是则报错。
[2] 埋点反复上报校验,针对个别状况下用户一次操作不会产生两个雷同的埋点上报,所以程序会校验某个事件下产生的所有埋点日志进行一一校验,检测是否具备 2 个或多个埋点日志完全一致,如有产生则会上报谬误。
- 后果校验:回放实现后,咱们会比照录制和回放时的埋点数据,依据配置好的字段规定校验埋点上报是否合乎预期。
5. 测试流程
AlphaTest 的外围测试流程始终聚焦在用例的录制与回放环节,整个流程波及到自动化工作触发、回放集群调度、断言服务、音讯推送等外围模块。
以 UI 自动化和埋点自动化的流程为例,AlphaTest 以业务团队为根本单元,能够和各团队的测试用例进行关联,定时同步状态。同时利用需要评审线上化做为根底,将自动化用例和研发流程中的 PR、集成打包、二轮回归等节点相结合,定时触发自动化用例并将后果报告推送给相干负责人。
-
录制用例:
[1] 首先在 AlphaTest 平台抉择要录制的测试用例,关上待测试 App 进行扫码即可进入用例待录制状态,此时能够设置用例须要的前置条件(账号信息、Mock 数据、定位信息等),之后点击开始按钮后,手机便会主动重启,开始录制。
[2] 用户依照测试用例步骤,失常操作手机,AlphaTest 会将用户的操作行为全副记录下来,并主动生成语义化的描述语言显示在 AlphaTest 平台上,与此同时产生的网络数据、埋点数据等校验信息也会一并存储下来。
[3] 在录制的过程中能够快捷的关上断言模式,将页面上想要校验的元素进行文本提取 / 截图等操作记录下来,用于后续回放过程中对雷同元素进行校验。
[4] 测试步骤全都执行结束后,点击保留按钮即可生成本条自动化用例。
-
用例回放:
[1] 扫描对应自动化用例的二维码即可进行回放,回放过程中会将用户录制的行为、网络数据进行一比一还原,并且辅助有全过程视频录像,用于后续问题排查和溯源。
[2] 回放过程中碰到断言事件时,会将断言的元素进行文本提取 / 截图,上传至 AlphaTest 平台。回放实现后,会将回放时候的断言截图和录制时的断言截图进行图像比照,作为整个测试后果的一项。
[3] 回放过程中的埋点数据也会一并记录下来,并和录制时候的埋点数据和上报机会进行比照,主动提取出其中的差别项。
[4] 回放实现后,会生成残缺的测试报告并将后果通过 OA 推送至相干人员。
- 回放打算:二轮回归测试中,回放用例数量多达几百条,为了做到全流程的自动化,咱们提供了回放打算的概念,能够将多个自动化用例进行编组治理,每一组就是一个回放打算。触发一个打算的回放即可主动触发打算内的所有自动化用例。整个打算都执行实现后,会告诉到指定的打算负责人或群组。
5.1 自动化工作触发
在整个外卖 C 端麻利迭代的流程中,打包平台次要承接了业务需要发动到需要交付的流程,作为 AlphaTest 的上游平台,能够提供打包信息并触发自动化用例回放工作。以下简略展现 AlphaTest 与麻利协同平台的交互流程:
5.2 回放集群调度
整个测试过程真正的解放双手,能力算的上是自动化。因而,咱们着手搭建了本人的自动化机器集群,能够 24 小时不间断的执行测试工作。为了保障工作回放可能顺利完成,咱们在不同阶段减少了相应的保活策略。在极大水平上进步了工作执行结束的成功率。
- 执行流程:回放工作通过用户在平台手动触发或者二轮主动触发。新增的回放工作通过工作拆分零碎拆分成 n 个子工作,退出到不同设施的回放工作队列中。每个子工作通过占用设施 -> 装置待测 App-> 利用受权 -> 关上 scheme-> 上报后果等步骤实现回放操作。
- 节点保活机制:针对回放流程中每一个节点,失败后进行 N(默认为 3)次重试操作。缩小因网络稳定,接口偶现异样导致的回放失败数量。
- 子工作保活机制:每个回放流程,失败后进行 N(默认为 3)次断点重试。缩小因设施异样,SDK 心跳上报异样导致的回放失败数量。
- 父工作保活机制:一个父工作会被拆分成 N 个子工作,当其中的一个子工作 S1 在节点保活机制和子工作保活机制下依然执行失败之后,父工作保活机制会尝试将子工作 S1 中未执行结束的用例转移到其余沉闷状态的子工作中。缩小因设施异样,设施掉线等问题导致的回放失败数量。
5.3 断言服务
用例断言是整个自动化用例验证的外围步骤,咱们的断言服务根据用例的理论情景能够别离进行文字与图像的断言。其中图像断言服务依靠于自建的图像比照算法服务,能够高效进行录制回放断言图像的比照,图像比照准确率能够达到 99% 以上。
-
录制阶段:
[1] 录制时减少断言决策信息的主动采集。
[2] 和失常流程一样,提取区域的截图信息。
[3] 如果是文本组件,则提取文本内容,如果是图片组件,则提取图片二进制编码或图片 URL,同时提取区域内的布局信息。
-
回放阶段:
[1] 回放时,提取和录制时统一的内容(文本信息、图片编码、区域截图、布局信息)。
[2] 将回放时的断言信息上传至 AlphaTest 平台。
[3] AlphaTest 平台对断言后果进行校验,首先是基于模型的图像比照,如果断定为统一,则间接标记后果。
[4] 如果断定为不统一、则匹配“断言失败数据集”,如果可能匹配上,则标记后果。如果匹配不上,则须要人工抉择匹配类型。
[5] 匹配类型为“文本校验”、“依据图片信息校验”、“人工校验”。如果前两项断定为统一,则间接标记后果。如果“人工校验”的后果为的确两张图不统一,则间接标记后果,完结。
[6] 如果“人工校验”后果为统一,既上述所有断定都不精确,则须要人工对两张图中断定谬误的起因进行分类(具体类型待定),同时将断言存储到失败数据集。
[7] 模型主动训练,当数据集超过肯定的阈值、通过定时触发、或者手动触发的形式,触发模型主动训练,训练实现后主动部署到 AlphaTest 平台,一直迭代。
- 图像服务:图像比照模型采纳基于度量学习的比照算法,将图像对的一致性判断转换为图像语义的类似度量问题。度量学习(Metric Learning),也称间隔度量学习(Distance Metric Learning,DML)属于机器学习的一种。其本质就是类似度的学习,也能够认为间隔学习。因为在肯定条件下,类似度和间隔能够互相转换。比方在空间坐标的两条向量,既能够用余弦类似度的大小,也能够应用欧式间隔的远近来掂量类似水平。度量学习的网络采纳经典的 Siamese 构造,应用基于 resnext50 的骨干网络提取图像的高级语义特色,后接 spplayer 实现多尺度特色交融,交融后的特色输入作为表白图像语义的特征向量,应用 ContrastiveLoss 进行度量学习。
[1] 预训练过程:resnext50 网络是应用 ImageNet 的预训练模型。
[2] 数据加强:为减少数据的丰富性、进步网络的泛化性能,数据加强的形式次要包含:图像右下局部的随机剪切和增加彩色蒙层(相应扭转图像对的标签)。这种数据加强合乎控键截图理论状况,不会造成数据分布的扭转。
[3] 比照损失:比照损失函数采纳 ContrastiveLoss,它是一种在欧式空间的 pair based loss,其作用是缩小统一图像对间隔,保障不统一图像对的间隔大于 margin,其中 margin=2。
[4] 类似度量:类似度量也是采纳计算图像对特征向量的欧式间隔的办法,并归一化到区间[0, 1],作为输入的图像对类似度。
5.4 音讯推送
音讯推送作为回放流程的最终环节,咱们依赖于美团外部自建的音讯队列服务与 OA SDK 音讯推送能力,能够进行测试报告的实时推送。在此之上,还能够针对不同团队的推送诉求,做音讯模板的定制化。
- 音讯定制:音讯推送与触达的外围,是满足业务诉求;不同业务对自动化测试报告中各项指标的关注点不同,这就须要 AlphaTest 具备音讯推送定制的能力;将音讯推送的模板以配置文件的模式提供进去,不同的业务应用不同的业务音讯配置文件;再利用 OA 提供的图文、多媒体等音讯推送能力,能够将自动化测试报告的各项指标自定义拆分;除此之外,音讯还须要缩小冗余,在这个信息泛滥的时代,咱们违心为无孔不入的音讯、告诉做减法,只将最重要、最外围的音讯推送给最须要的人,既能够推动自动化测试流程的高效流转,又能够让各相干业务人员享受到自动化测试能力的便捷性。
- 一键触达:以往的研发人员冒烟测试,次要依赖于测试人员在用例治理平台建设测试计划,研发人员依据用例进行手工用例测试后果标记,之后去提测实现后续流程。这两头缺失的次要环节是,难以对研发人员冒烟测试的品质进行把控。而 AlphaTest 正能够解决此问题,流程转换为,研发人员在麻利协同平台触发一键提测流程,调用 AlphaTest 的自动化测试能力对冒烟用例进行自动化测试回归,实现之后将测试生成的测试报告同步提测平台,作为研发人员冒烟的论断根据,同时在冒烟过程中产生的问题,也能够及时告诉到对应的研发人员与测试人员进行改过。既保证了品质,又防止了人力空耗。
6. 落地与实际
外卖 C 端次要承当了用户在 App 端点餐、下单、配送的所有外围流程,场景繁多、业务简单,这也给测试人员的版本测试带来了诸多挑战,其中最外围也最消耗人力的便是二轮回归测试环节。目前,C 端采纳的双周麻利迭代的开发方式,每个迭代周期给测试人员用来进行二轮外围流程回归的工夫为三天,为此 C 端测试团队投入了许多人力资源,但即便如此,仍难以笼罩全副流程;而 AlphaTest 的设计初衷也正是为解决此问题——UI 测试流程全笼罩及自动化验证。
6.1 业务共建
用例的转化与保护
[1] AlphaTest 在外卖 C 端测试团队的落地初期,咱们采纳了共建的模式,也就是业务研发人员与对应测试人员独特来进行用例录制与保护的工作;举荐这种工作模式的外围起因是,在 C 端性能迭代流程中的二轮周期的原有工作模式为,研发人员进行二轮冒烟测试,实现测试之后提交二轮包交由测试人员进行二轮回归测试,所以这原本就是一个单方都须要参加的环节;而二轮测试作为版本上线前的最重要一个测试流程,保障外围流程的失常也是测试人员与研发人员所关怀重点。
[2] 通过多轮的应用与磨合之后,这种模式被证实是卓有成效的,在整个 C 端二轮用例的转化过程中,测试人员次要负责了用例的录制与迭代流程,研发人员则次要负责版本回放数据的统计及问题用例的发现与解决。
外卖二轮落地状况
[1] 目前,AlphaTest 曾经在外卖多个业务落地,反对了大于 15 个版本的二轮回归测试,用例覆盖率达到 70%。
[2] 笼罩了 Native、Mach、React Native、美团小程序、H5 技术栈的测试工作,能力上可进行反对:UI 自动化测试、埋点自动化测试、动态化加载成功率自动化测试、无障碍适配率自动化测试。
将来,咱们会朝着“智能化”和“精准化”两个方向摸索,笼罩更多测试场景的同时,更进一步晋升测试人效。
6.2 实际成果
测试方向 | 同 App 回放成功率 | 跨 App 回放成功率 |
---|---|---|
性能自动化 | iOS:97.4%、Android: 94.7% | iOS:95.8%、Android: 91.1% |
埋点自动化 | iOS:96.3%、Android: 96% | iOS:95%、Android: 91% |
7. 参考资料
- [1] https://appium.io
- [2] http://docs.seleniumhq.org/projects/webdriver
- [3] http://airtest.netease.com/index.html
- [4] https://github.com/alipay/SoloPi
浏览美团技术团队更多技术文章合集
前端 | 算法 | 后端 | 数据 | 平安 | 运维 | iOS | Android | 测试
| 在公众号菜单栏对话框回复【2021 年货】、【2020 年货】、【2019 年货】、【2018 年货】、【2017 年货】等关键词,可查看美团技术团队历年技术文章合集。
| 本文系美团技术团队出品,著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容,敬请注明“内容转载自美团技术团队”。本文未经许可,不得进行商业性转载或者应用。任何商用行为,请发送邮件至 tech@meituan.com 申请受权。