外卖平台的自动化测试实践与落地（一）
本帖最后由 草帽路飞UU 于 2022-10-25 15:57 编辑1. 项目背景
美团外卖的业务场景比较多元化，除了外卖自身的业务，还作为平台承接了闪购、团好货、医药、跑腿等其他业务。除此之外，在全链路动态化的大基调下，外卖各个页面的技术形态也变得越来越复杂，
除了Native代码，还包括Mach（外卖自研动态化框架）、React Native、美团小程序、H5等，不同技术栈的底层技术实现不同，渲染机制不同，进而对测试方式要求也有所不同，这也在无形中增
加了测试的难度。下图汇总了美团多业务、多技术、多App的一些典型场景。
图1 多业务、多技术栈、多App
在产品交付上线的过程中，测试的占比也是非常大的，甚至大于总时长的30%。如下图所示，整个测试包括了冒烟测试、新功能测试、二轮回归测试、三轮测试。然而，现在需求测试绝大部分还是
采用非自动化的方式，这就使得人力成本变得非常之高。
图2 外卖迭代模型
另一方面，相比于2018年，2022年的测试用例数量增长近3倍，已经超过1万2千条（如下图所示）。同时，外卖的业务是“三端复用”，除了外卖App，还需要集成到美团App和大众点评App上，这样一来，
测试工作量就翻了3倍，业务测试压力之大可想而知。如果按照当前的增长趋势持续下去，要保障外卖业务的稳定，就必须持续不断地投入大量的人力成本，所以引入能够支持外卖“多业务场景”、“多App
复用”、“多技术栈” 特点的自动化测试工具来提升人效和质量，势在必行。
图3 近几年用例增长变化
2. 项目目标
为了解决外卖面临的测试困境，我们尝试去探索一种零学习成本、低维护、高可用的自动化测试方案，能够支持外卖复杂多变的测试场景，它必须同时满足下面几点要求：
易用性：工具/平台的上手难度，使用复杂度应该尽可能的低，因为自动化测试的目的是提效人力，而不是增加人力负担。
平台支持：移动端至少需要覆盖iOS和Android双平台，同时基于外卖的业务特点，不仅需要对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 指令编辑器
图6 平台远端录制演示
4.2 前置条件准备
一键环境模拟，解决操作繁琐的用例执行前的环境准备。
进行一个用例的测试之前，往往需要做大量的准备工作，比如切换API环境，定位到某个地点，登录指定账户等。这些需要准备的环境条件我们统称为前置条件。我们知道，前置条件的准备操作通常都不
是一两个步骤就可以完成的，比如账号登录/切换：我们需要进入登录页，填写手机号+密码/验证码，点击登录等一系列动作来完成这个过程，非常繁琐，并且每次测试我们都需要准备，重复性高。因此，我
们给AlphaTest设计了独立的前置条件模块，将用例拆成了两个部分：前置条件 + 操作步骤。
图7 前置条件
与其它测试框架不同的是，AlphaTest采用了SDK集成，但对业务无侵入的方式，因此可以通过编写白盒代码来实现前置条件的自动配置，只需要在平台添加需要的指令，下发到SDK后，即可根据相关指令完
成前置条件的自动配置，不再需要重复进行相关的操作。并且这些前置条件支持复用，也不需要每次进行用例准备时的重复配置。AlphaTest的前置条件，不仅有着基于美团内部服务及底层Hook的默认实现，
也提供了API支持业务方自定义实现，比如实现不同的账号体系。
4.3 用例录制与回放的数据一致性
影响用例执行的不仅是代码，还有数据。
很多时候，自动化用例无法正常执行完成，可能是因为App回放时的本地数据及网络数据与录制时的不一致，从而导致用例执行流程的阻塞或App界面展示的不同。这也是大多数自动化测试工具/平台测试
通过率不高的主要因素，因此要保证测试成功率，我们需要控制变量，排除由数据产生的影响。
图8 数据一致性
App运行依赖的数据，有两部分——本地数据和网络数据：
本地数据是App在运行期间产生的缓存数据或持久化的存储数据。为了让用例在录制回放时都能够保持一致的本地数据环境，我们在录制和回放前都对App的本地数据进行了清理操作，这样用例在录制和
回放的过程中，都可以保持一致的App初始化环境。
网络数据是驱动App交互呈现的基石，各种策略和API升级都会影响网络数据的响应，因此我们将用例录制过程中产生的网络数据也进行了录制，并将网络数据和对应的操作指令进行了关联和绑定，确定
了数据产生的事件源。排除数据影响后，我们的自动化测试的成功率就取决于自动化操作的准确性了，这就回到了常见自动化框架范畴。
页:
[1]
