日常生活中，我们经常会看到不同的平台使用不同的评分制度来展示用户对产品或服务的评价。例如，豆瓣和虎扑采用10分制，而淘宝店铺和美团点评则选择5分制。那么，为什么同样是为了反映用户评价的功能会有不同的分制呢？这背后是否有着特定的考量？

01 一个有意思的现象

最近在人人都是产品经理上看到了一个非常有意思的问题。为什么豆瓣、虎扑等用十分制评分，而淘宝店铺、美团点评等用五分制？(https://wen.woshipm.com/question/detail/8s2csf.html)。这个问题我从来没有注意过，去app上一看，果然如此。豆瓣、虎扑都是十分制，淘宝、美团都是五分制。

那么问题来了，为啥同样都是评价性质的功能，还要搞不同的分制呢？是不是可以统一成五分制或十分制呢？如果不能，背后有什么考量吗？

02 什么是星级评分

想探究以上的这些问题，就要搞清楚星级评分的一些基本概念。从本质上讲，星级评分是评估产品质量或受欢迎程度的一种算法。在一定意义上，星级评分能够比较真实地反映用户对产品的评价或情感，是一种相对客观的方法。

回想一下，每次去吃一家不太熟悉的餐馆，场景是不是先看一下大众点评上的分数咋样，然后再决定去不去。这就是星级评分的好处，它不需要用户很繁琐地看具体评价，可以通过一个分数，直接获知一个产品或是店铺的优劣，大大节省了用户决策的时间成本。另外，这些数据对于一些有良心的企业，也是监控他们的产品是否得到消费者的信赖和支持的良好指标。

星级评分这种收集用户反馈的方式非常常见。目前主流的评价方式，都是给一个五颗星，然后把所有人的评价通过一个算法转化成分数，分数有五分制和十分制之分。其他的星级评价方式，诸如三星级，十星级都见过，但是不较五星级少见。

回到文章开头的五分制和十分制的问题。既然星级评分就是一种算法，那是不是也可以只给两颗星星让用户去评价，或者一个赞的按钮，一个踩的按钮来评价呢？我觉得是没有问题的，因为这也是一种评价，也反映了用户比较真实的看法和情感。

所以，是什么东西影响使用的评分方式和分制呢？

03 影响星级评分方式和分制的因素

1. 成本因素

从心理测量学角度来说，星级评价可以看做是一种量表。而心理测量学中被广泛使用的测量方法是李克特量表。这是一种总加量表类型的一种，主要是用来反映填写者整体的认同程度和主观评价。一般量表大多采用5级，但是也有7级的，6级的，甚至11级的。

但是从成本角度来说，误差成本会随着量表等级的增加逐步降低，回答成本会随着量表等级的增加而增加。很好理解，回答的星级越多，越能够真实反应用户对产品的满意程度和评价，但是星级越多，让用户回答起来就会非常痛苦，最好的就是能够既让误差没那么大，用户填写起来也不太痛苦。这里贴一个网上的图，图显示，星级为5的时候，是最优的。

2. 量表指标因素

既然星级评价是一种量表，那就需要考虑一些量表指标，比如，信效度、区分度等。

最近在开奥运会，我用奥运会的一个项目举例子说明一下信效度。一个射击运动员，每次都射击6环，我们可以说他信度高，所以，信度代表的是量表的可靠程度。还有一个运动员，虽然不是每次都能够射击同一环数，但是要不就是10环，要不就是9环。我们可以说这个运动员效度比较高。

所以，效度代表的是量表的准确程度。区分度呢，就是这个量表测量的东西，一定能够把不同水平的人给区别开。如果靶子设定的特别大，枪法好和枪法差的都能很轻松地打出10环，那这个靶子的区分度就非常差。

搞清楚了这几个概念，我们就看一下，不同星级评价数量对这几个指标的影响。

曾经有学者做研究表明，7个等级的星级评价要比5个等级的星级评价能得到更可靠的结果，也就是信度会更高些。但是，信度和等级数量之间并不是线性关系。另外的研究表明，等级数量超过9个时，不同等级的差异就没有意义了，不会再提供更多的有效信息，反而会让用户填写起来非常累和困惑。

3. 用户使用习惯问题

通过以上的分析，星级评价的等级数基本锚定在5到9个左右。这和人类短时记忆的容量，7±2个组块的数量不谋而合。所以，在星级评价数量的选取的时候，也要遵循用户的使用习惯。

首先用户是非常不喜欢思考的。对一个事物的评价，最优解就给我一个好还是不好的选项，二极管思维是最受大多数用户的喜爱了。但是这种评价的区分度又太差。又想评价准，又想有区分度，又想不让用户那么累，避免评价数过少，最后分析下来，只有5个等级是最合适的了。

4. 产品调性、对象特征

评价都是为了还原用户对产品整体的认同程度和主观评价。那么，准确和恰当是非常重要的。

比如，B站上，用户对视频的评价就只有顶或者踩。在B站，用户对视频的评价，不是一个谱系，而是一个是或否的关系，要不好看，要不难看，没有稍微不好看，或者稍微好看，这对于用户来说，区分好看和稍微好看非常有难度，且没有必要。这种情况下，就可以牺牲区分度，采用两星级评价。

但是对于电影来说，需要评价的维度特别多，如果仅仅用顶或者踩，准确性会大大折扣。所以，主流的网站，大多采用5等级星级评价。

04 分数呈现有什么讲究

回到开头我们讨论的那个现象，会发现，不管是十分制的豆瓣、虎扑，还是五分制的点评、美团。都采用的是五等级的星级评价。但是分数最终呈现却不是一样的。这有什么讲究吗？

要想知道不同分制的区别，我们就要知道分数是咋算出来的。具体的规则细节肯定是获取不到，我们也不需要知道的那么详细。

简单来说，分数主要还是来自于分数平均（可以看一下豆瓣CEO阿北的回答）。我理解，算法主要是处理评价是否可信的问题，比如，阿北提到的，“和影托或者其他非正常个人意见PK”，“时间和打分这自身的情况”。

这些都是在识别，某一个或某一些评价是否是真实的评价，而不是刷的，或者只是因为个人情绪，恶意给的差评。

算法可以理解是一个门槛，这个门槛只让真实的评价进去，只要你能进去，那算法就简单了，就是计算平均分，阿北也说了嘛，“接近和还原普通观众最原汁原味的平均观影意见。”

其他的平台也应该是这种考虑和算法。

那么，同样的五等级评分，有的是五分制，为啥有的十分制呢？

两种分制的不同，可以理解成，分制越大，区分度越大，越能够将细微的好坏差别体现出来。所以，分制的不同，要回归用户。

如果某个平台上的用户，对某个事物具体比较高的了解程度和鉴赏水准，那就需要比较高的分制。如果某个平台上的用户，对某个事物没有高的了解程度，那就需要给用户一个相对来说较为简单明了的分数，那就需要一个稍微低一点的分制。

所以，这就是为啥同样的五等级评分，美团用五分制，而豆瓣用十分制。

参考

问卷设计：量表到底是要用5级还是6级？– 人人都是产品经理

评价体系用什么规则好?豆瓣是5星10分制，时光网是10星10分制，淘宝是5星5分制 – 知乎

量表等级，5分、7分、10分哪种更好？等级量表数据应该如何分析？

为什么豆瓣、虎扑等用10分制评分，而淘宝店铺、美团点评等用5分制?

本文由 @孟老湿 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自pixabay，基于CC0协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。

着美团到家业务的发展，系统复杂度也在持续增长。测试用例数量近两年增长约一倍，单端数量超过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是一个开源工具，用于自动化测试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 实践效果

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

| 本文系美团技术团队出品，著作权归属美团。欢迎出于分享和交流等非商业目的转载或使用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者使用。任何商用行为，请发送邮件至tech@meituan.com申请授权。

IOps，最初的定义是Algorithm IT Operations，是利用运维算法来实现运维的自动化，最终走向无人化运维。随着技术成熟，逐步确定为Artificial Intelligence for IT Operations——智能运维，将人工智能应用于运维领域，基于已有的运维数据（日志、监控信息、应用信息等），通过机器学习的方式来进一步解决自动化运维无法解决的问题。

本文系AIOps在美团的探索与实践的第一部分，如何自动发现故障问题，其中重点介绍了美团时序数据异常检测系统Horae的架构与设计。

一、背景

早期的运维工作大部分是由运维人员手工完成的，手工运维在互联网业务快速扩张、人力成本高企的时代，难以维系。于是，自动化运维应运而生，它主要通过可被自动触发、预定义规则的脚本，来执行常见、重复性的运维工作，从而减少人力成本，提高运维的效率。总的来说，自动化运维可以认为是一种基于行业领域知识和运维场景领域知识的专家系统。随着整个互联网业务急剧膨胀，以及服务类型的复杂多样，“基于人为指定规则”的专家系统逐渐变得力不从心，自动化运维的不足，日益凸显，当前美团在业务监控和运维层面也面临着同样的困境。

DevOps的出现，部分解决了上述问题，它强调从价值交付的全局视角，但DevOps更强调横向融合及打通，AIOps则是DevOps在运维（技术运营）侧的高阶实现，两者并不冲突。AIOps不依赖于人为指定规则，主张由机器学习算法自动地从海量运维数据（包括事件本身以及运维人员的人工处理日志）中不断地学习，不断提炼并总结规则。AIOps在自动化运维的基础上，增加了一个基于机器学习的大脑，指挥监测系统采集大脑决策所需的数据，做出分析、决策，并指挥自动化脚本去执行大脑的决策，从而达到运维系统的整体目标。综上看，自动化运维水平是AIOps的重要基石，而AIOps将基于自动化运维，将AI和运维很好地结合起来，这个过程需要三方面的知识：

• 行业、业务领域知识，跟业务特点相关的知识经验积累，熟悉生产实践中的难题。
• 运维领域知识，如指标监控、异常检测、故障发现、故障止损、成本优化、容量规划和性能调优等。
• 算法、机器学习知识，把实际问题转化为算法问题，常用算法包括如聚类、决策树、卷积神经网络等。

美团技术团队在行业、业务领域知识和运维领域的知识等方面有着长期的积累，已经沉淀出不少工具和产品，实现了自动化运维，同时在AIOps方面也有一些初步的成果。我们希望通过在AIOps上持续投入、迭代和钻研，将之前积累的行业、业务和运维领域的知识应用到AIOps中，从而能让AIOps为业务研发、产品和运营团队赋能，提高整个公司的生产效率。

二、技术路线规划

2.1 AIOps能力建设

AIOps的建设可以先由无到局部单点探索，在单点探索上得到初步的成果，再对单点能力进行完善，形成解决某个局部问题的运维AI学件，再由多个具有AI能力的单运维能力点组合成一个智能运维流程。行业通用的演进路线如下：

• 开始尝试应用AI能力，还无较为成熟的单点应用。
• 具备单场景的AI运维能力，可以初步形成供内部使用的学件。
• 有由多个单场景AI运维模块串联起来的流程化AI运维能力，可以对外提供可靠的运维AI学件。
• 主要运维场景均已实现流程化免干预AI运维能力，可以对外提供供可靠的AIOps服务。
• 有核心中枢AI，可以在成本、质量、效率间从容调整，达到业务不同生命周期对三个方面不同的指标要求，可实现多目标下的最优或按需最优。

所谓学件，亦称AI运维组件[1]（南京大学周志华老师提出），类似程序中的API或公共库，但API及公共库不含具体业务数据，只是某种算法，而AI运维组件（或称学件），则是在类似API的基础上，兼具对某个运维场景智能化解决的“记忆”能力，将处理这个场景的智能规则保存在了这个组件中，学件（Learnware）=模型（Model）+规约（Specification）。