背景

随着支付宝作为数字化平台的不断发展壮大，接入到支付宝当中的生态小程序数量越来越多。面对数以万计的小程序数量，质量同学对其一一进行人工测试是不现实的。当我们需要验证小程序的特定功能时，现有的方法尝试通过脚本编排的方式来实现自动化测试，例如固定一系列点击坐标、结合OCR点击文字等。然而，由于生态小程序通常为商家自行开发，其异构性往往较强，甚至相同场景的不同小程序之间在样式、文字上都千差万别，这导致了脚本编排的方式天然存在着覆盖率低、泛化性差的问题。举个例子：在餐饮小程序的首页上，点餐功能的入口不仅位置不同，也有着“去下单”、“点单”、“到点”等不同的表述方式。这就导致了最终质量同学还是需要反复迭代、编写大量的脚本，本质上仍然是“伪”自动化的。在这样的背景下，我们希望借助UI智能的力量，实现真正的智能化的生态小程序测试，极大地降低在业务测试上的人力投入，提升测试效能。

能力介绍

从为业务提供的服务层面来看，我们的能力可以大概分为两类：智能动线、页面理解以及其他智能工具。其中智能工具部分目前在建设当中，下面将分别对智能动线和页面理解这两类能力进行介绍。

智能动线

什么是智能动线？从功能的角度来看，智能动线只做一件事情：在当前页面上，做出正确的点击操作，使得小程序页面能够准确地沿着测试链路进行跳转，从而完成所设定好的测试目标。从业务价值的角度来看，智能动线一方面验证了某条链路是否畅通、功能是否可用，另一方面也能够采集到链路上的所有页面，是其他异常检测、信息抽取等能力的前提条件。

在初版能力的建设中，我们参考 Humanoid: A Deep Learning-based Approach to Automated Black-box Android App Testing 一文，建设了一套基于页面特征和控件特征的用户行为推理模型，整体模型图如下：

可以看到，该方法主要通过各类特征提取网络来得到小程序的页面、控件的特征，然后预测最优可能点击的像素点位置。该方法虽然在早期取得了一定的效果，但其仍然存在着多方面的不足，例如：页面像素点过多，手机截图的大小通常为1000x2000左右，这就意味着需要在200w个以上的像素点中找到正确的那个，难度较大；不同模态特征之间的交互方式过于简单，难以做到信息的有效融合等。

基于上述不足之处，我们从多个角度对模型进行了整体升级，升级后的架构如下：

在原有模型上的基础上，我们做出了若干的改进：

1. 修改模型输出，将整个用户行为预测看做一个控件推荐任务，极大地降低了Label Space的大小（200w个像素点-->100个控件）；

2. 引入控件特征交互模块，使得不同的控件之间能够“相互看见”，获取到更高阶的控件组合特征信息；

3. 引入控件的位置信息，例如“去下单”、“确认”等按钮往往位于下方偏右的位置，这一信息可以辅助模型做出更加精确的预测；

4. 升级图片编码模型、引入多模态信息融合模块等等。

基于这些改进，我们在餐饮小程序下单、商家小程序下单，医院小程序预约挂号等动线上取得了不错的效果。示例如下：

可以看到，我们的模型给出了【点击文字(到店自提)->点击文字(+)->点击文字(去结算)->点击文字(用户登录)->点击文字(去结算)->点击文字(立即支付)】这一条点击路径，顺利地完成了商品加购、下单、登录等一系列操作，最终完成对于这个餐饮小程序的下单功能的验证。

页面理解

什么是页面理解？对于小程序UI页面的理解其实是一个非常抽象的概念，虽然说“理解”得本质就是对UI信息的概括，但是从不同的动机出发，所希望得到的结果也是完全不同的。在S1中，立足于生态小程序测试这一场景，为了能够快速地做到对质量业务的支持，我们将页面理解拆分为两个核心问题：

1. 当前是什么页面？

2. 当前页面中有哪些核心的元素，分别对应哪个控件？

具体来说，在不同行业的小程序中，我们会联合业务方共同沉淀一套对应场景下的页面标签标准以及页面元素识别标准，并根据这些标准来提供相应的算法能力。

页面标签识别

从算法角度来看，该能力本质上是属于图片分类范畴。示例如下：

在小程序场景下，除了页面的样式外，页面中的文本往往也能一定程序上决定该页面的具体标签。因此，在实际的算法模型中，我们会通过OCR来结合页面中的文字信息，以多模态的方式综合判断页面标签。

页面元素识别

以商品库巡检专项为例，我们商品下单链路中的页面分为了“商详页”、“SKU页”、“订单页”、“登录页”、“授权页”等几大类；同时，针对每一个类别，我们会制定好该类别页面下的具体元素类别、属性，如“商详页”种会包含该商品的图片、标题、价格以及去购买的按钮。示例如下：

这样做的好处在哪呢？在智能动线的算法服务中，我们需要预设好动线的目标，换言之，每一个模型只能做到对一条动线的支持。例如，在商品相关的小程序中，我们可以为“下单”链路训练一个智能动线模型，该模型无法用于“会员卡领取”等其他链路上。这就导致了当质量同学想要对新的的功能进行智能化测试时，就需要重新走一遍标注、训练、算法服务部署、联调这一系列过程，效率比较低下。但如果我们能够做到对于商品小程序不同页面的充分理解，就完全能够让质量同学基于页面的标签自行指定动作，例如“在商品详情页上点击购买按钮”、“在SKU页上选择指定的SKU并下单”，使得整个动线链路更具确定性、更加多样。

从算法角度来看，该能力本质上属于目标检测范畴。为了能够快速地支持业务落地，同时综合考虑性能及效率，我们目前采用了Yolov8来作为基础模型。后续会考虑结合页面文字的语义信息来进一步提升精确性。

页面信息抽取

除了上述功能之外，抛弃掉控件维度，我们还有着针对页面文字的信息抽取能力。一个简单的示例如下：

在就业岗位详情页，我们能够识别出页面中所包含的岗位标题、岗位薪资（最高薪资、最低薪资、结算周期）、工作地点、年龄限制、招聘人数等信息。从控件的角度来看，这些信息都属于文本，但是我们能够从语义的角度对这些文本进行分类，从而支持质量同学进行更为细致的分析。

通用控件识别

随着业务范围的不断拓展，我们发现，在很多场景下都会存在一些通用的、与页面标签无关的控件。例如，在下面两张图分别属于“直接付款页”和“登录页”：

在这两类页面中，我们分别需要去定义红框部分为“支付方式选择栏”和“协议栏”。但是从控件的本质上来看，这两个部分我们需要点击的控件，实际上都属于“单选按钮”。也就是说，在不同的场景下实际上我们会有一些重复的定义，这实际上造成了标准、能力的冗余。

从这一点出发，我们尝试抽象出了一些通用控件的定义，例如输入框、单选框、弹窗、按钮等，并建设了通用控件的识别能力。一个简单的识别结果示例如下:

相关成果

在S1期间，我们与不同业务方向的质量团队达成了深度合作，并在多个业务场景下共同取得了不错的结果：

• 数字政企质量：以医疗行业“预约挂号”链路为试点业务，从0到1建设医疗行业深度巡检能力，经历多次分析迭代，各项指标（从医院小程序首页到预约完成页面的到达率、整体问题发现准确率等）得以明显提升；

• 商家开放质量

• 数字商业质量：为了规范小程序代运营服务商为商家提供的服务质量，在S1阶段，我们提供了基于UI的小程序商品数量检测、商品同质化判断、页面标签识别等算法服务，助力商家小程序质量保障；

• 生态审核质检平台：在商品库质量巡检专项中，我们构建了页面标签、元素的标准模型，并配套提供了页面标签识别、元素识别等算法服务，与质检平台共同建设了自动化“商品下单”的能力，取得了较高的到达率。

总结

未来规划

在后续时间中，我们将围绕算法广度和深度这两个方面分别进行能力的升级。

• 提升广度：提供新能力，建设新服务

一方面，我们需要不忘初心，继续紧贴业务场景，面向业务质量同学的需求进行能力建设；另一方面，在业务需求之外，我们会围绕这“智能化测试”这一命题，尝试抽象出一些通用能力，例如通用控件识别、页面语义化、控件语义化、页面异常识别等等。

• 挖掘深度：探索新技术，提出新方案

理想是驱动长期坚持做一件事的必备条件。在我们的理想中，UI智能化测试的最终形态是：只需要质量同学通过自然语言阐述测试的目标，模型便能够自动地理解目标、制定测试步骤并完成每一步操作。沿着实现该理想的路径，我们实际上还有很多需要回答的问题：如何能够让模型理解测试目标并制定测试计划？如何让模型“真正地”理解UI页面，以及应该理解到什么粒度？短期内，我们希望做这样两件事：

1. 充分利用目前海量的采集数据，沉淀小程序UI理大模型；

2. 深度探索多模态大模型在UI智能化测试上的可能性。

不积跬步，无以至千里；不积小流，无以成江海。未来我们会沿着UI智能化测试这一条路不断深入探索，为测试这件事情带来新的改变。同时也欢迎有想要合作的同学联系我们，探索新的业务场景下的落地。

如对本文有任何建议或问题，请关注我们的微信公众号，我们将私信回复 ❤️