Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >自动化测试在美团外卖的实践与落地

自动化测试在美团外卖的实践与落地

作者头像
美团技术团队
发布于 2022-09-20 07:19:11
发布于 2022-09-20 07:19:11
1.4K0
举报
文章被收录于专栏:美团技术团队美团技术团队

总第535篇 | 2022年 第052篇

随着美团到家业务的发展,系统复杂度也在持续增长。测试用例数量近两年增长约一倍,单端数量超过1万2千条,而研发人员的工作从大部分时间在开发,转变成一半时间在开发、一半时间在模拟环境和自测。因此,引入自动化测试就显得十分有必要,本文介绍了美团外卖在自动化测试方向做的一些探索和实践,希望对从事相关领域工作的同学能够带来一些启发或帮助。

  • 1. 项目背景
  • 2. 项目目标
  • 3. 方案选型
  • 4. 实践和探索
    • 4.1 问题和挑战
    • 4.2 前置条件准备
    • 4.3 用例录制与回放的数据一致性
    • 4.4 用例录制与回放的操作一致性
    • 4.5 可溯源的自动化测试
    • 4.6 用例的维护
    • 4.7 跨App回放用例
    • 4.8 埋点的录制回放
  • 5. 测试流程
    • 5.1 自动化任务触发
    • 5.2 回放集群调度
    • 5.3 断言服务
    • 5.4 消息推送
  • 6. 落地与实践
    • 6.1 业务共建
    • 6.2 实践效果

1. 项目背景

美团外卖的业务场景比较多元化,除了外卖自身的业务,还作为平台承接了闪购、团好货、医药、跑腿等其他业务。除此之外,在全链路动态化的大基调下,外卖各个页面的技术形态也变得越来越复杂,除了Native代码,还包括Mach(外卖自研动态化框架)、React Native、美团小程序、H5等,不同技术栈的底层技术实现不同,渲染机制不同,进而对测试方式要求也有所不同,这也在无形中增加了测试的难度。下图汇总了美团多业务、多技术、多App的一些典型场景。

图1 多业务、多技术栈、多App

在产品交付上线的过程中,测试的占比也是非常大的,甚至大于总时长的30%。如下图所示,整个测试包括了冒烟测试、新功能测试、二轮回归测试、三轮测试。然而,现在需求测试绝大部分还是采用非自动化的方式,这就使得人力成本变得非常之高。

图2 外卖迭代模型

另一方面,相比于2018年,2022年的测试用例数量增长近3倍,已经超过1万2千条(如下图所示)。同时,外卖的业务是“三端复用”,除了外卖App,还需要集成到美团App和大众点评App上,这样一来,测试工作量就翻了3倍,业务测试压力之大可想而知。如果按照当前的增长趋势持续下去,要保障外卖业务的稳定,就必须持续不断地投入大量的人力成本,所以引入能够支持外卖“多业务场景”、“多App复用”、“多技术栈” 特点的自动化测试工具来提升人效和质量,势在必行。

图3 近几年用例增长变化

2. 项目目标

为了解决外卖面临的测试困境,我们尝试去探索一种零学习成本、低维护、高可用的自动化测试方案,能够支持外卖复杂多变的测试场景,它必须同时满足下面几点要求:

  • 易用性:工具/平台的上手难度,使用复杂度应该尽可能的低,因为自动化测试的目的是提效人力,而不是增加人力负担。
  • 平台支持:移动端至少需要覆盖iOSAndroid双平台,同时基于外卖的业务特点,不仅需要对Native支持,也需要支持Mach(自研局部动态化框架)、H5、React Native、美团小程序等技术栈。
  • 稳定性:自动化测试用例的执行需要有足够的稳定性和准确性,测试过程中不应因测试工具本身的不稳定而出现稳定性问题。
  • 维护成本:维护成本很大程度上决定了测试工作量的大小,因需求产生变动或架构重构等问题时,用例的维护成本应该尽可能的小。
  • 可扩展性:当测试方案不能满足测试需求时,工具/平台应具备可扩展的能力。

3. 方案选型

自动化测试工具那么多,自研是重复造轮子吗?

针对终端的UI自动化测试工具/平台可谓“屡见不鲜”,市面上也有很多相对成熟的方案,相信大家都有用过,或者至少有所耳闻,但这些方案是否能真的满足我们提效的诉求呢?以下我们挑选了三类非常具有代表性的自动化测试工具/平台 - Appium、Airtest Project、SoloPi进行了分析,来帮助大家对自动化测试技术建立一个认知:

  • 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 指令编辑器

图5 手机录制演示

图6 平台远端录制演示

4.2 前置条件准备

一键环境模拟,解决操作繁琐的用例执行前的环境准备。

进行一个用例的测试之前,往往需要做大量的准备工作,比如切换API环境,定位到某个地点,登录指定账户等。这些需要准备的环境条件我们统称为前置条件。我们知道,前置条件的准备操作通常都不是一两个步骤就可以完成的,比如账号登录/切换:我们需要进入登录页,填写手机号+密码/验证码,点击登录等一系列动作来完成这个过程,非常繁琐,并且每次测试我们都需要准备,重复性高。因此,我们给AlphaTest设计了独立的前置条件模块,将用例拆成了两个部分:前置条件 + 操作步骤。

图7 前置条件

与其它测试框架不同的是,AlphaTest采用了SDK集成,但对业务无侵入的方式,因此可以通过编写白盒代码来实现前置条件的自动配置,只需要在平台添加需要的指令,下发到SDK后,即可根据相关指令完成前置条件的自动配置,不再需要重复进行相关的操作。并且这些前置条件支持复用,也不需要每次进行用例准备时的重复配置。AlphaTest的前置条件,不仅有着基于美团内部服务及底层Hook的默认实现,也提供了API支持业务方自定义实现,比如实现不同的账号体系。

4.3 用例录制与回放的数据一致性

影响用例执行的不仅是代码,还有数据。

很多时候,自动化用例无法正常执行完成,可能是因为App回放时的本地数据及网络数据与录制时的不一致,从而导致用例执行流程的阻塞或App界面展示的不同。这也是大多数自动化测试工具/平台测试通过率不高的主要因素,因此要保证测试成功率,我们需要控制变量,排除由数据产生的影响。

图8 数据一致性

App运行依赖的数据,有两部分——本地数据和网络数据:

  • 本地数据是App在运行期间产生的缓存数据或持久化的存储数据。为了让用例在录制回放时都能够保持一致的本地数据环境,我们在录制和回放前都对App的本地数据进行了清理操作,这样用例在录制和回放的过程中,都可以保持一致的App初始化环境。
  • 网络数据是驱动App交互呈现的基石,各种策略和API升级都会影响网络数据的响应,因此我们将用例录制过程中产生的网络数据也进行了录制,并将网络数据和对应的操作指令进行了关联和绑定,确定了数据产生的事件源。排除数据影响后,我们的自动化测试的成功率就取决于自动化操作的准确性了,这就回到了常见自动化框架范畴。

4.4 用例录制与回放的操作一致性

目标定位的准确性与手势定位的精准性。

UI自动化测试的本质就是代替人去自动的做一步步的操作(点击、长按、输入、滑动等)。录制与回放过程的操作能否一致,是否精准,直接影响测试的成功率,决定了工具/平台的可用性。

  • 目标控件定位准确性:

操作行为是否一致首先需要确认操作目标是否一致。与一般测试工具/平台不同的是AlphaTest采用了ViewPath + 图像 + 坐标的多重定位方案。得益于SDK集成的方式,我们的ViewPath可以记录更多的元素视图特征和执行不同的匹配策略。定位过程中会优先使用ViewPath进行目标控件检索,当目标控件查找异常时,会结合图像匹配和坐标匹配的方式进行兜底查找,来确保界面变化程度不大时,也能准确的查找到目标控件。

图9 图像识别示意图

  • 手势定位的精准性:

有了基于控件的目标定位之后,对于一些常用简单操作手势,比如点击、长按、断言、甚至输入都可以做到很好的支持,只需要找到对应的控件,在控件所在位置下发相应的触摸事件即可。我们知道,App真正接收的触摸事件是屏幕上一个个精准的触摸点,在系统处理后,分发给当前App窗口,App在接收事件后再继续分发,直到找到事件的最佳响应者,后续通过响应者链对事件消化处理。那我们要还原一个触摸事件的坐标点要如何确定呢?由于我们确定的只有控件,所以这个点自然而然就成了控件的中心点了。

大多数情况下,这些都可以很好地进行工作,但是对于一些多响应控件重叠的情况,可能会产生预想不到的操作误差。为了解决这样的问题,我们把控件定位与坐标定位进行了结合:基于纯坐标的定位是一种定位精准度非常高的定位方式,但是稳定性非常差,只有在屏幕分辨率完全一致且回放页面控件位置完全一致的情况下,才具备足够的可靠性,但这往往是不现实的,对测试环境机器量要求过高。

基于控件的定位,又存在着精准度不够的问题。使用坐标定位,如果定位区域足够小的话,那么受屏幕尺寸的影响就会越小,只需要确定在小范围内的相对位置即可。而基于控件目标的定位,恰恰可以把目标区域缩小到一个指定区域,我们刚好可以将二者结合起来,同时解决定位精准度和稳定性的问题。

对于复杂手势的支持,我们同样可以采用微分的方式,将一个复杂手势拆成多个简单手势的组成,比如我们可以将一个滑动操作的定位拆成两个部分:起始位置和终止位置,而这两个位置的定位,就变成了两个普通的单点手势操作定位了,可以通过上面提到的一个目标控件+相对坐标的形式进行定位。核心思想都是将基于屏幕坐标点的定位操作,缩小的目标控件的区域范围内,以达到不受设备分辨率的影响,实现操作行为一致的效果。

图10 手势识别示意图

4.5 可溯源的自动化测试

测试全流程记录,问题溯源一键即达。

测试的目的是保证App运行的稳定,测试过程中出现Bug导致测试未通过时,需要溯源问题原因,发生的场景,乃至具体的执行步骤。这也是大多自动化测试工具/平台所欠缺的,即使发现了问题,排查工作也很困难;这个问题在手工测试的时候,更为严重,往往因为很多缺陷无法复现而难以定位。

AlphaTest的自动化用例最小执行单元是操作指令,我们将测试过程的每一条指令的执行状况和过程中的界面快照进行了记录,并在指令执行失败时,对异常原因进行了初步分析。然后将整个用例的执行组合成了一份完整的测试报告,可快速溯源问题步骤。除此之外,我们还增加大量的日志上报,并将整个用例测试过程进行了视频录制,来进一步帮助疑难问题的排查。真正做到了用例回放测试可溯源。

图11 回放报告-图文详情

4.6 用例的维护

自动化用例需要持续地投入人力来维护么?架构升级,页面重构,用例需要全部重新录制么?

因自动化工具/平台众多,阻碍长期落地使用的一大问题是用例维护成本高,很多工具/平台让我们即便是使用上了自动化,但还需要持续投入人力维护用例的更新,最终的提效收益微乎其微。对于用例更新维护,我们可以梳理划分成三个场景:

  • 需求发生重大变更,整体的业务执行流程及相关的校验点都需要进行大量的调整。对于这种情况,无论是何种自动化测试工具/平台,都是需要正常进行用例变更重录以适应新的需求。
  • 需求发生略微变更,业务流程基本一致,需要调整的校验点、操作以及数据或不影响整体流程的步骤。对于此场景,AlphaTest通过指令编辑器与操作录制,支持指令增删改以及数据和场景的还原,帮助用户快速的进行用例调整,而无需重新录制用例。例如:修改网络数据字段、视图变更路径、断言替换目标等。

图14 指令编辑

  • 和业务需求不同,我们的技术实现也会发生迭代。随着App技术架构不断的演进,经常会面临着架构升级,页面重构甚至技术栈变迁等这样的技术升级。这些变动需要覆盖大量的测试用例,其中大量的自动化用例又可能会因为变动而导致失效,需要重新录制。为此,AlphaTest设计一套利用相近分辨率机器进行用例自动修正的功能:利用图像 + 坐标进行二次识别定位,元素定位成功并校验通过后,生成新的ViewPath,更新对应的用例指令,对用例进行自动修复,修复后可在任意回放。

图15 自修复能力

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 埋点的录制回放

除了功能测试,我们在日常开发和测试的工作中,还会面临另外一个比较重要的问题就是埋点测试。因此,我们在自动化的基础上扩展出埋点自动化测试。埋点自动化测试的核心思想是,通过对比录制时期和回放时期的埋点上报时机和上报参数进行判断。为了保证埋点自动化测试的稳定性,我们主要采用以下的障机制:

图16 埋点自动化测试示意图

  • 字段规则配置:埋点自定义参数千姿百态,甚至有些字段每次代码执行都不一致,如果进行完全匹配结果注定是失败的,所以我们在AlphaTest平台提供了埋点字段规则配置功能,通过人为设置的方式来避免埋点自定义参数校验失败。App重启进入录制状态时,用户就可以操作App,平台会记录用户的操作行为,当产生相应的埋点日志的时候会将日志信息打印在日志区域(如下图17所示),在该过程中也会对埋点日志进行一定的校验。重点将操作时机、埋点日志一并保存到服务端。

图17 埋点上报数据控制台打印

  • 埋点时机校验:针对时机校验,程序并不支持埋点曝光的"1px曝光","下拉刷新曝光","页面切换曝光","切前后台曝光"这些规则,主要的原因是每一个业务方在对埋点曝光的规则都是不一致的,而且该规则的实现会极大耦合业务代码。在针对时机校验我们目前只支持: [1] 点击埋点上报时机校验,程序通过事件监听和埋点类型信息来判断点击埋点上报的时机是否是在点击的操作下产生的,如果不是则报错。 [2] 埋点重复上报校验,针对一般情况下用户一次操作不会产生两个相同的埋点上报,所以程序会校验某个事件下发生的所有埋点日志进行一一校验,检测是否具有2个或多个埋点日志完全一致,如有发生则会上报错误。
  • 结果校验:回放完成后,我们会对比录制和回放时的埋点数据,根据配置好的字段规则校验埋点上报是否符合预期。

图18 埋点校验流程图

5. 测试流程

AlphaTest的核心测试流程始终聚焦在用例的录制与回放环节,整个流程涉及到自动化任务触发、回放集群调度、断言服务、消息推送等核心模块。

以UI自动化和埋点自动化的流程为例,AlphaTest以业务团队为基本单元,可以和各团队的测试用例进行关联,定时同步状态。同时利用需求评审线上化做为基础,将自动化用例和研发流程中的PR、集成打包、二轮回归等节点相结合,定时触发自动化用例并将结果报告推送给相关负责人。

图19 建设自动化测试流程闭环

  • 录制用例: [1] 首先在AlphaTest平台选择要录制的测试用例,打开待测试App进行扫码即可进入用例待录制状态,此时可以设置用例需要的前置条件(账号信息、Mock数据、定位信息等),之后点击开始按钮后,手机便会自动重启,开始录制。 [2] 用户按照测试用例步骤,正常操作手机,AlphaTest会将用户的操作行为全部记录下来,并自动生成语义化的描述语言显示在AlphaTest平台上,与此同时产生的网络数据、埋点数据等校验信息也会一并存储下来。 [3] 在录制的过程中可以快捷的打开断言模式,将页面上想要校验的元素进行文本提取/截图等操作记录下来,用于后续回放过程中对相同元素进行校验。 [4] 测试步骤全都执行完毕后,点击保存按钮即可生成本条自动化用例。
  • 用例回放: [1] 扫描对应自动化用例的二维码即可进行回放,回放过程中会将用户录制的行为、网络数据进行一比一还原,并且辅助有全过程视频录像,用于后续问题排查和溯源。 [2] 回放过程中碰到断言事件时,会将断言的元素进行文本提取/截图,上传至AlphaTest平台。回放完成后,会将回放时候的断言截图和录制时的断言截图进行图像对比,作为整个测试结果的一项。 [3] 回放过程中的埋点数据也会一并记录下来,并和录制时候的埋点数据和上报时机进行对比,自动提取出其中的差异项。 [4] 回放完成后,会生成完整的测试报告并将结果通过OA推送至相关人员。
  • 回放计划:二轮回归测试中,回放用例数量多达几百条,为了做到全流程的自动化,我们提供了回放计划的概念,可以将多个自动化用例进行编组管理,每一组就是一个回放计划。触发一个计划的回放即可自动触发计划内的所有自动化用例。整个计划都执行完成后,会通知到指定的计划负责人或群组。

5.1 自动化任务触发

在整个外卖C端敏捷迭代的流程中,打包平台主要承接了业务需求发起到需求交付的流程,作为AlphaTest的上游平台,可以提供打包信息并触发自动化用例回放任务。以下简单展示AlphaTest与敏捷协同平台的交互流程:

图20 AlphaTest与敏捷协同平台交互流程图

5.2 回放集群调度

整个测试过程真正的解放双手,才能算的上是自动化。因此,我们着手搭建了自己的自动化机器集群,可以 24小时不间断的执行测试任务。为了保证任务回放能够顺利完成,我们在不同阶段增加了相应的保活策略。在极大程度上提高了任务执行完毕的成功率。

  • 执行流程:回放任务通过用户在平台手动触发或者二轮自动触发。新增的回放任务经过任务拆分系统拆分成n个子任务,加入到不同设备的回放任务队列中。每个子任务经过占用设备->安装待测App->应用授权->打开scheme->上报结果等步骤完成回放操作。
  • 节点保活机制:针对回放流程中每一个节点,失败后进行N(默认为3)次重试操作。减少因网络波动,接口偶现异常导致的回放失败数量。
  • 子任务保活机制:每个回放流程,失败后进行N(默认为3)次断点重试。减少因设备异常,SDK心跳上报异常导致的回放失败数量。
  • 父任务保活机制:一个父任务会被拆分成N个子任务,当其中的一个子任务S1在节点保活机制和子任务保活机制下仍然执行失败之后,父任务保活机制会尝试将子任务S1中未执行完毕的用例转移到其他活跃状态的子任务中。减少因设备异常,设备掉线等问题导致的回放失败数量。

图21 机器集群

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进行度量学习。

图22 训练过程

[1] 预训练过程:resnext50网络是使用ImageNet的预训练模型。

[2] 数据增强:为增加数据的丰富性、提高网络的泛化性能,数据增强的方式主要包括:图像右下部分的随机剪切和添加黑色蒙层(相应改变图像对的标签)。这种数据增强符合控键截图实际情况,不会造成数据分布的改变。

[3] 对比损失:对比损失函数采用ContrastiveLoss,它是一种在欧式空间的pair based loss,其作用是减少一致图像对距离,保证不一致图像对的距离大于margin,其中margin=2。

图23 训练过程

[4] 相似度量:相似度量也是采用计算图像对特征向量的欧式距离的方法,并归一化到区间[0, 1],作为输出的图像对相似度。

5.4 消息推送

消息推送作为回放流程的最终环节,我们依赖于美团内部自建的消息队列服务与OA SDK消息推送能力,可以进行测试报告的实时推送。在此之上,还可以针对不同团队的推送诉求,做消息模板的定制化。

  • 消息定制:消息推送与触达的核心,是满足业务诉求;不同业务对自动化测试报告中各项指标的关注点不同,这就需要AlphaTest具备消息推送定制的能力;将消息推送的模板以配置文件的形式提供出来,不同的业务使用不同的业务消息配置文件;再利用OA提供的图文、多媒体等消息推送能力,可以将自动化测试报告的各项指标自定义拆分;除此之外,消息还需要减少冗余,在这个信息泛滥的时代,我们愿意为无孔不入的消息、通知做减法,只将最重要、最核心的消息推送给最需要的人,既可以推动自动化测试流程的高效流转,又可以让各相关业务人员享受到自动化测试能力的便捷性。
  • 一键触达:以往的研发人员冒烟测试,主要依赖于测试人员在用例管理平台建立测试计划,研发人员根据用例进行手工用例测试结果标记,之后去提测完成后续流程。这中间缺失的主要环节是,难以对研发人员冒烟测试的质量进行把控。而AlphaTest正可以解决此问题,流程转换为,研发人员在敏捷协同平台触发一键提测流程,调用AlphaTest的自动化测试能力对冒烟用例进行自动化测试回归,完成之后将测试生成的测试报告同步提测平台,作为研发人员冒烟的结论依据,同时在冒烟过程中发生的问题,也可以及时通知到对应的研发人员与测试人员进行改正。既保证了质量,又避免了人力空耗。

6. 落地与实践

外卖C端主要承担了用户在App端点餐、下单、配送的所有核心流程,场景繁多、业务复杂,这也给测试人员的版本测试带来了诸多挑战,其中最核心也最耗费人力的便是二轮回归测试环节。目前,C端采用的双周敏捷迭代的开发方式,每个迭代周期给测试人员用来进行二轮核心流程回归的时间为三天,为此C端测试团队投入了许多人力资源,但即便如此,仍难以覆盖全部流程;而AlphaTest的设计初衷也正是为解决此问题——UI测试流程全覆盖及自动化验证。

6.1 业务共建

用例的转化与维护

AlphaTest 在外卖C端测试团队的落地初期,我们采用了共建的模式,也就是业务研发人员与对应测试人员共同来进行用例录制与维护的工作;推荐这种工作模式的核心原因是,在C端功能迭代流程中的二轮周期的原有工作模式为,研发人员进行二轮冒烟测试,完成测试之后提交二轮包交由测试人员进行二轮回归测试,所以这本来就是一个双方都需要参与的环节;而二轮测试作为版本上线前的最重要一个测试流程,保证核心流程的正常也是测试人员与研发人员所关心重点。

经过多轮的使用与磨合之后,这种模式被证明是行之有效的,在整个C端二轮用例的转化过程中,测试人员主要负责了用例的录制与迭代流程,研发人员则主要负责版本回放数据的统计及问题用例的发现与解决。

外卖二轮落地情况

目前,AlphaTest已经在外卖多个业务落地,支持了大于15个版本的二轮回归测试,用例覆盖率达到70%。现已覆盖了Native、Mach、React Native、美团小程序、H5 技术栈的测试工作,能力上可进行支持:UI自动化测试、埋点自动化测试、动态化加载成功率自动化测试、无障碍适配率自动化测试。

未来,我们会朝着“智能化”和“精准化”两个方向探索,覆盖更多测试场景的同时,更进一步提升测试人效。

6.2 实践效果

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‍

----------  END  ----------

也许你还想看

  | Spock单元测试框架以及在美团优选的实践

  | 美团智能支付稳定性测试实战

  | Lego:美团接口自动化测试实践

阅读更多

前端 | 算法 | 后端 | 数据

安全 | Android | iOS  | 运维 | 测试

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2022-09-15,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 美团技术团队 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
Android手机QQ的UI自动化实践
可能很多同学都有疑问:我们写了这么多单元测试,为什么还需要UI自动化测试呢? 按照测试金字塔理论,其实每种类型的测试都有自己的意义,UI自动化的意义就在于更贴近用户真实场景的校验,比如对于手机QQ来说,我们需要确保主流程的真实链路是通畅的,而单元测试和接口测试很难做到这一点。
于果
2021/08/25
1.3K0
腾讯自动化测试的AI智能
引子: 本文是林奕在腾讯 DevDays 2018 分享内容的脱敏整理,介绍了 CSIG 测试开发中心(前 SNG 测试开发中心)在自动化测试领域所做的智能化尝试。 大致分成下面几部分: 使用AI面对和解决的问题是什么 AI带来的曙光 使用了哪些技术,效果是怎么样的 未来展望 UI自动化测试的问题 从业务角度看自动化测试,看到的东西仅仅是冰山浮在水面上的一小部分,而在自动化测试深入的过程中,会发现有很多看不见的坑在冰山下面。 1 自动化测试的复杂度障碍 举一个例子来说明, UI自动化测试工具首要要
腾讯大讲堂
2018/10/17
4.1K0
腾讯自动化测试的AI智能
美团外卖持续交付的前世今生
美团外卖自2013年创建以来,业务一直在高速发展,从早期单一的美食业务发展成为包含闪购、跑腿、闪付、营销、广告等在内的平台业务。每个业务团队虽然都有不同的业务形态,但是几乎都有相同的诉求:需求能不能尽快的上线?本文将从外卖的历史实践中,浅谈一个好的持续交付需要综合考虑哪些关键因素,希望对大家有所帮助或启发。
美团技术团队
2020/02/19
1.6K0
美团外卖持续交付的前世今生
对UI自动化测试的一些感悟
把UI自动化框架设计成一个拼图性质的架构。把每个特性都设计成一个独立的部分,然后组装成UI自动化框架:
测试小兵
2019/07/24
1.4K0
基于 Appium 的 Android UI 自动化测试
自动化测试是研发人员进行质量保障的重要一环,良好的自动化测试机制能够让开发者及早发现编码中的逻辑缺陷,将风险前置。日常研发中,由于快速迭代的原因,我们经常需要在各个业务线上进行主流程回归测试,目前这种测试大部分由人工进行,费时费力,重复劳动多。如果能将UI自动化测试与主流程回归结合到一起,一方面保证了代码质量,另一方面大大节约人力成本,可谓一举两得。 为什么需要UI自动化测试 原因主要是以下三点: 保证质量——及早发现代码缺陷,风险前置。 减少重复劳动,节约人力——快速迭代中经常需要进行主流程回归,测试完
美团技术团队
2018/03/12
2.2K0
基于 Appium 的 Android UI 自动化测试
Android自动化测试解决方案
Android自动化测试解决方案 桌面应用程序与浏览器端的自动化测试都已经历了十年的发展,无论是从工具上还是项目管理方 法论上都已经趋于成熟。而移动设备端应用程序的自动化测试近两年才刚起步,似乎一切尚处于探讨与研究阶段。但我们似乎已经看到其爆炸性的需求增长势头。可 以从这两方面着眼分析:其一,移动应用从数量上和逻辑复杂程度上的增长,以及产品发布周期的紧缩,使得快速回归测试迫在眉睫;其二,安卓系统的开放性造成 硬件厂商百家争鸣的局面,设备款式之多,迫使移动应用的兼容性测试提上日程。纵观当前智能手机两 大主
用户1289394
2018/02/26
9770
Android自动化测试解决方案
迷雾中的自动化测试体系建设
在业内如火如荼的 DevOps 转型过程中,自动化测试始终是热点之一,毕竟提供快速质量反馈是达成 DevOps 目标的关键。于是,作为测试领域的“皇冠”,自动化测试的落地实施始终为人们所关注。但是落地当中产生了种种问题甚至是争论,经久不衰,无形中给自动化测试体系建设蒙上了层层迷雾,让人疑惑。下面我们就一些踩过的“坑”进行探讨,期望这些经验分享能够有助于揭开迷雾、看清方向。
腾讯云 CODING
2021/12/30
1.3K0
迷雾中的自动化测试体系建设
应用实践|自动化测试工具应用实践
在当前社会项目市场需求的场景下,项目需求不明确、项目根据市场需求的日益变化而频繁变更、项目时间短且需要快速交付给甲方,敏捷开发俨然成为了很多项目团队的不二之选,而在敏捷开发中,测试工作也是很重要的一个环节,只有通过测试的软件,才能交付到客户的手中。测试工作能在敏捷开发中确保软件质量,提高用户体验,减少软件应用过程中的风险,确保软件的合规使用,保持良好的客户关系担任了一个重要的角色。
六月暴雪飞梨花
2024/10/28
2790
应用实践|自动化测试工具应用实践
如何让自动化框架更自动化
作者:软件质量保障 知乎:https://www.zhihu.com/people/iloverain1024
互联网金融打杂
2022/08/01
5440
如何让自动化框架更自动化
常用功能自动化测试工具汇总
话说自动化测试方面的工具还是非常的多的,不可能也没有必要查看了所有的测试工具;个人觉得当学习众多同类知识或相关主题时,分几步走: 1、学习所有同类知识的共同理论、原理部分【此为共性】 2、学习所有同类知识的独有特性、技巧部分【此为个性】 3、根据具体的实际场景,适当的运用所学知识的【即运用知识的个性部分去解决特定的问题】 学习自动化测试工具也是这样的,之前不愿意学习太多是怕混淆视听,现在对原有知识已有了一定的固化认识【即了解了基本原理】,也就可以从新学习个性化的东西了;而这一步正是为了以后能够适当运用所掌握的知识,顺利的进行自动化测试任务的开展和实施。其目标达矣!
testwalkman
2020/02/28
2.2K0
自动化测试入门:是什么,流程,收益和工具
http://mpvideo.qpic.cn/0bf2jeaaiaaa3eaeb6fj3vpfasodareqabaa.f10002.mp4?dis_k=cc04b07c621debb660c5902
归根落叶
2020/05/15
1.7K0
自动化测试入门:是什么,流程,收益和工具
GrowingIO 数据采集 iOS SDK 测试实践
GrowingIO 是基于用户行为数据的增长平台,精准采集用户行为数据是公司业务的基石,只有及时、准确、可靠的采集到数据,才能支撑上层的数据分析,用户画像,运营等业务,所以公司一直非常注重数据采集 SDK(Software Development Kit) 的质量保证工作。
ios-lan
2020/09/19
2.2K0
软件自动化测试工具之元素智能定位
江湖一直有着这么一句名言“天下武功,唯快不破"。那么在软件测试领域,自然而然我们会想到软件自动化测试。软件自动化测试的实现自然离不开软件自动化测试工具。软件自动化测试工具是软件自动化的载体,只有通过工具,我们才能实现。武林也是一样,成为武功盖世,除了武林秘决之外,还要有依天剑、屠龙刀的配合。
testwalkman
2020/03/08
8510
软件自动化测试工具之元素智能定位
Web UI自动化框架大比拼
对于测试从业者来说,手工测试是一个绕不过去的坎。当年我校招毕业以测试工程师岗位进了一家互联网公司。入职第一天就被师父"拉去干活",至今印象深刻,是一个投顾管理平台(投资顾问管理客户的平台,主要功能是为用户做理财资讯推荐)。主要工作就是让我结合测试用例对这个web页面进行测试,说白了就是点点点。测试新人嘛,这些对于我来说挺新鲜的,但是随着时间的流逝,不到几个月就感觉有点不对了,手工测试完全是个机械化的工作,在执行用例过程大脑是没有思考的,长此以往,会让你的大脑形成固化思维,在测试过程中大脑能得到的测试价值边际效应是递减的,所以这也就解释了大部分手工测试人员普遍测试积极性不高,对未来充满焦虑。
互联网金融打杂
2022/08/01
1.7K0
Web UI自动化框架大比拼
软件自动化测试工具的历史演义
软件测试最早可以追溯到1958年的美国第一个载人航天计划-水星计划,当时在该计划中首次诞生了软件测试团队。当然,在此之前也肯定是有软件测试存在的,但远没有这次有了自己的江湖地位。但这也仅仅是软件测试的萌芽,远没有到开宗立派的地步。因为你想想这时候软件也只是萌芽阶段,各种软件的理论,标准都还没有诞生,所以更别提软件测试了,因此很长一段时间内,软件测试时间内是没有什么发展的。
testwalkman
2020/03/02
1.2K0
软件自动化测试工具的历史演义
MTFlexbox自动化埋点探索
跨平台动态化技术是目前移动互联网领域的重点关注方向,它既能节约人力,又能实现业务快速上线的需求。经过十年的发展,美团App已经变成了一个承载众多业务的超级平台,众多的业务方对业务形态的快速迭代和更新提出了越来越高的要求。传统移动端“静态”的开发方式存在一系列问题,比如包体积增长过快、线上Bug修复困难、发版周期长等,已经不能满足高速发展的业务需要。因此,美团平台自研了一套跨平台动态化方案——MTFlexbox。
美团技术团队
2019/08/20
1.4K0
MTFlexbox自动化埋点探索
UI 自动化测试在有赞的实践
UI 自动化是质量保障的一种重要手段,我们从分层测试金字塔模型可以看出,质量保障更多的应该依靠底层的单元测试和接口集成测试,UI 自动化测试占比是非常小的一部分,众所周知,UI 层的自动化测试稳定性差,成本高。然而我们团队经过一年多的 UI 自动化测试的实践与优化,发现我们 UI 层自动化测试相对性价比是最高的,脚本的稳定性也非常好,误报率降到了 1% 左右,每次上线前能帮助我们回归系统的一些核心业务流程,下面将跟大家分享一些关于我们 UI 自动化测试的实践经验。
有赞coder
2021/04/12
1.9K0
自动化测试,Apipost 真好用
对于一个互联网公司来说,测试人员是公司里不可缺少的一个角色。但从事软件测试的人员不计其数,每年都有很多毕业生卷入互联网的大军。如果一个测试人员的能力还只停留在点点点上,自然是会被新一代的“卷王”们淘汰的。
看、未来
2022/09/27
6050
自动化测试,Apipost 真好用
软件评测师-自动化测试技术
1.自动化测试是把人为驱动的测试行为转化为机器执行的一种过程,模拟手工测试步骤,通过由程序语言编制的测试脚本,自动地完成软件的测试设计、单元测试、功能测试、性能测试等工作,包括测试活动的自动化和测试过程管理的自动化
全栈程序员站长
2022/09/07
5750
软件评测师-自动化测试技术
kylinTOP 测试与监控平台:一款基于 AI 的软件自动化测试工具的介绍
对于一般的传统的自动化测试工具,如:Selenium,robotFramework,QTP等。QTP可以通过操作录制生成自动化用例脚本。生成的脚本与Selenium、robotFramework类似,都是类方法的调用以及各种方法的参数的传递。对于一个学习者来说没有2-3年的工作经验,很验难熟练撑握。而且不同的人写的自动化用例风格不一样,维护起来非常困难,要求测试人员必须撑握一门计算机语言,如:VB、python等。如下所示,是使用robotFramework编辑器基SeleniumLibrary库写的一个自动化测试用例。
jackey422
2019/11/29
1.7K0
kylinTOP 测试与监控平台:一款基于 AI 的软件自动化测试工具的介绍
相关推荐
Android手机QQ的UI自动化实践
更多 >
LV.2
美团美团技术学院
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档