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个或多个埋点日志完全一致，如有发生则会上报错误。
结果校验：回放完成后，我们会对比录制和回放时的埋点数据，根据配置好的字段规则校验埋点上报是否符合预期。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
