CN113641594B - 跨端自动化测试方法以及相关装置 - Google Patents

Abstract

本申请公开了一种跨端自动化测试方法以及相关装置，该方法包括：从移动界面框架中获取至少一个待测试控件组件；在每个待测试控件组件上包裹一个转化组件；其中，每个转化组件具有唯一的赋值；根据转化组件获得每个待测试控件组件的界面可达性标识；响应于接收到自动化测试指令，通过界面可达性标识获得与其对应的待测试控件组件，并对待测试控件组件进行自动化测试。通过这种设计方式，可以将Flutter元素转化为原生端元素，并且赋值了一个唯一标签值（id），既不需要依赖虚拟服务器，也不需要自动化测试团队针对跨端页面做特殊处理即可将跨端页面的元素转化为原生端测试工具可以识别的元素。

Description

跨端自动化测试方法以及相关装置

技术领域

本申请涉及Flutter自动化测试技术领域，特别是涉及一种跨端自动化测试方法以及相关装置。

背景技术

虽然Flutter技术能够提高研发效率，但仍需对不同平台的Flutter页面进行测试。目前一般采用Flutter-driver或Appium-Flutter-driver进行测试，其中，Flutter-driver支持集成测试，但是需要在业务代码中手动设置视图元素ID，对业务代码有入侵，而且Flutter-driver仅支持Dart语言编写测试脚本，不支持爬虫语言编写测试脚本，并且Flutter-driver不支持混合栈开发的APP的自动化测试，即Flutter-driver只支持纯Flutter页面的自动化测试，支持不了原生页面和Flutter页面混合的场景的自动化测试。

目前有一部分Flutter测试技术是基于虚拟服务器进行自动化测试的，但是，上述方法存在以下缺陷：（1）虚拟服务器以及选择模式依赖于Flutter的调试（Debug）或者移植（Profile）模式，不是线上使用的发行（release）模式。测试结果很可能因为人为的因素与实际生产环境下不同，造成测试结果的不准确，而且，调试或者移植模式需要知晓Flutter源码才能够打包，而对于外部团队的自动化测试服务，外部团队不太可能提供调试包；（2）需要自建FUT Client服务用于自动化测试，整体自动化测试环境搭建复杂度大，特别是已经有一套原生端Appium测试方案的团队来说，兼容FUT 客户端服务将是一大挑战。因此，亟需一种新的跨端自动化测试方法来解决上述问题。

发明内容

本申请主要解决的技术问题是提供一种跨端自动化测试方法以及相关装置，不需要自动化测试团队针对跨端页面做特殊处理即可将跨端页面的元素转化为原生端测试工具可以识别的元素。

为解决上述技术问题，本申请采用的一个技术方案是：提供一种跨端自动化测试方法，包括：从移动界面框架中获取至少一个待测试控件组件；在每个所述待测试控件组件上包裹一个转化组件；其中，每个所述转化组件具有唯一的赋值；根据所述转化组件获得每个所述待测试控件组件的界面可达性标识；响应于接收到自动化测试指令，通过所述界面可达性标识获得与其对应的待测试控件组件，并对所述待测试控件组件进行自动化测试。

其中，所述在每个所述待测试控件组件上包裹一个转化组件的步骤之前，包括：利用面向切面编程方法通过调用预定类型的钩子函数对原生端开启所述转化组件的实现进行相应修改，以使得在软件开发工具包的应用程序接口中所述待测试控件组件对应的地方实现自动开启所述转化组件。

其中，所述从移动界面框架中获取至少一个待测试控件组件的步骤，包括：从所述移动界面框架中获取多个控件组件；从所述多个控件组件中筛选并获取至少一个所述待测试控件组件；其中，所述待测试控件组件为所述移动界面框架中需要测试的控件组件。

其中，所述从所述多个控件组件中筛选并获取至少一个所述待测试控件组件的步骤之后，包括：在所述移动界面框架中的每个所述控件组件绘制入口，并捕获所述移动界面框架中的所述待测试控件组件；将每个所述待测试控件组件上包裹一个所述转化组件，并将所述转化组件赋值为所述待测试控件组件对应的标签值；将包裹所述转化组件的待测试控件组件返回至绘制流程。

其中，所述将每个所述待测试控件组件上包裹一个所述转化组件，并将所述转化组件赋值为所述待测试控件组件对应的标签值的步骤之前，包括：根据所述移动界面框架所在的页面的第一信息获取所述移动界面框架的定位信息；根据所述待测试控件组件的第二信息和所述定位信息获取所述待测试控件组件在所述页面上的层级路径和元素下标；将所述层级路径和所述元素下标转换为字符串，并将所述字符串作为所述待测试控件组件对应的标签值。

其中，所述根据所述转化组件获得每个所述待测试控件组件的界面可达性标识的步骤，包括：将所述待测试控件组件的界面可达性值赋值为所述待测试控件组件对应的标签值；将所述标签值从所述界面可达性值同步到所述待测试控件组件的所述界面可达性标识上；其中，所述界面可达性标识的值与所述界面可达性值保持一致。

其中，所述根据所述转化组件获得每个所述待测试控件组件的界面可达性标识的步骤，还包括：将用户界面可访问性对象的可达性标识符设置为所述字符串、以及将所述用户界面可访问性对象的可达性值设置为所述标签值；通过面向切面编程方法将所述待测试控件组件的界面可达性标识的调用指向所述可达性值，以根据所述可达性标识符和所述可达性值将所述界面可达性标识补全。

其中，所述待测试控件组件对应的标签值是唯一的，且在所述待测试控件组件所在的页面不发生变化时不会发生变化。

为解决上述技术问题，本申请采用的另一个技术方案是：提供一种电子设备，包括相互耦接的存储器和处理器，所述存储器内存储有程序指令，所述处理器用于执行所述程序指令以实现上述任一实施例所提及的跨端自动化测试方法。

为解决上述技术问题，本申请采用的又一个技术方案是：提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序用于实现上述任一实施例所提及的跨端自动化测试方法。

区别于现有技术的情况，本申请的有益效果是：本申请提供的跨端自动化测试方法包括：从移动界面框架中获取至少一个待测试控件组件；在每个待测试控件组件上包裹一个转化组件；其中，每个转化组件具有唯一的赋值；根据转化组件获得每个待测试控件组件的界面可达性标识；响应于接收到自动化测试指令，通过界面可达性标识获得与其对应的待测试控件组件，并对待测试控件组件进行自动化测试。通过这种设计方式，可以将Flutter元素转化为原生端元素，并且赋值了一个唯一标签值（id），既不需要依赖虚拟服务器，也不需要自动化测试团队针对跨端页面做特殊处理即可将跨端页面的元素转化为原生端测试工具可以识别的元素。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。其中：

图1是现有技术中ios原生端自动化测试架构示意图；

图2是本申请跨端自动化测试方法一实施方式的流程示意图；

图3是图2中步骤S1一实施方式的流程示意图；

图4是图3中步骤S11之后一实施方式的流程示意图；

图5是图4中步骤S21之前一实施方式的流程示意图；

图6是将Flutter元素转化为原生端自动化测试工具可识别元素的示意图；

图7是图2中步骤S3一实施方式的流程示意图；

图8是将Value值赋值给界面可达性标识的逻辑示意图；

图9是图1中步骤S3另一实施方式的流程示意图；

图10是Flutter/ios混合应用自动化测试架构示意图；

图11是本申请跨端自动化测试装置一实施方式的结构示意图；

图12是本申请电子设备一实施方式的框架示意图；

图13是本申请计算机可读存储介质一实施方式的框架示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性的劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在现有技术中，移动界面框架（Flutter）测试技术主要基于以下方案的一种或者多种：Flutter driver、Intergration test、Appium-Flutter-driver、Appium-Flutter-driver结合图片识别的方案、基于虚拟服务器进行自动化测试的方案（例如，贝壳的自动化测试方案）等，但是，Flutter driver的方案存在以下几种缺陷：（1）只能用dart代码写自动化测试脚本，并且只支持纯Flutter项目，不支持混合应用的自动化测试；（2）这种方法需要手动加入ID，业务代码侵入大；（3）元素定位不方便，没有inspect工具去dump元素，编写测试脚本的开发只能结合源码编写自动化测试脚本，而且不能批量操作元素，一旦定位元素超过1个就会抛出异常。Intergration test的方案存在以下几种缺陷：（1）测试脚本打包到APP中，每次修改脚本都需要重新打包；（2）这种方法对端到端测试不够友好，需要额外函数来等待数据加载完毕；（3）不适合全链路级别的页面测试；（4）可扩展性弱。Appium-Flutter-driver的方案存在以下几种缺陷：（1）需要Flutter的debug包或者Profile包；（2）在Appium中只能看到部分Flutter元素的信息；（3）元素ID需要开发手动编写，业务代码侵入性大。Appium-Flutter-driver结合图片识别的方案存在以下几种缺陷：（1）在Appium中只能看到部分Flutter元素的信息，看不到信息的部分利用图片识别技术判断元素并加以操作；（2）需要强大的图片识别测试工具支持；（3）随着版本迭代，测试脚本也需要不断迭代。基于虚拟服务器进行自动化测试的方案存在以下几种缺陷：（1）需要Flutter的debug包或者Profile包；（2）需要自建FUT Client服务，用来实现自动化测试的交互，包括dump元素和调用元素响应。

总的来讲，现有技术存在以下两种缺陷：（1）虚拟服务器需要debug包或者Profile包；（2）已有原生端自动化测试方案的团队，需要投入资源搭建client服务或者图片识别服务，无法做到无感接入。

Flutter使用的是Skia引擎进行页面UI的渲染，而渲染方式的不同注定了直接使用Flutter进行自动化测试是无法获取到对应元素的信息的。但是，Flutter提供了一个转化的入口：语义组件（Semantic）。其中，语义组件（Semantic）可以实现将Flutter元素转化为原生端自动化测试工具可以识别的元素。

语义组件（Semantic）是Flutter提供的一个转化组件，用于描述微件（Widget）的含义最终达到描述应用程序的页面UI。这些描述可以通过辅助工具、搜索引擎和其他语义分析软件使用，它和超文本标记语言（HTML5）的语义元素提供相近的功能，在安卓（Android）、苹果操作系统（iOS）上更多是用于读屏，帮助一些有视力障碍的人使用我们的软件安卓盲人模式（AndroidTalkBack）和苹果语音辅助程序（ iOS VoiceOver）。在原生端（比如iOS端）也正是使用VoiceOver的部分功能，来达到支持自动化测试的目的。

在介绍本申请的跨端自动化测试方法之前，先简单介绍一下原生端自动化测试方案的简单原理。同样以iOS端为例，请参阅图1，图1是现有技术中ios原生端自动化测试架构示意图。自动化测试方案是使用iOS系统开给视障人士的VoiceOver的部分功能（在开发中主要是界面可访问对象（UIAccessiblityObject）相关的子类），具体地，客户端将待测试控件组件送至Appium服务端（Appium server），Appium服务端中的ios移动测试框架（WebDriverAgent）运行待测试控件组件并将待测试控件组件输入至ios的单元测试框架（XC Test framework），将自动化使用的标签值（id）赋值给界面可达性标识（UIAccessiblityIdentity），在使用Appium等自动化测试工具时，就能通过界面可达性标识（UIAccessiblityIdentity）拿到App中对应的具体的控件组件，从而使用用于动态调追踪和分析OSX和iOS的代码的性能分析和测试工具（Instruments）进行操作或者判断等自动化操作。

请参阅图2，图2是本申请跨端自动化测试方法一实施方式的流程示意图。该跨端自动化测试方法包括：

S1：从移动界面框架中获取至少一个待测试控件组件。

具体地，在本实施例中，请参阅图3，图3是图2中步骤S1一实施方式的流程示意图。具体而言，步骤S1包括：

S10：从移动界面框架中获取多个控件组件。

具体而言，从Flutter中获取多个控件组件，例如视图元素等，本申请在此不作限定。

S11：从多个控件组件中筛选并获取至少一个待测试控件组件。

具体而言，待测试控件组件为Flutter中需要测试的控件组件。

如果APP中的全部页面和元素的自动化测试的标签值（id）都通过开发手动打标来进行维护，在开发和后续升级迭代中会给开发人员增加较大的负担和维护成本。为了解决上述问题，请参阅图4，图4是图3中步骤S11之后一实施方式的流程示意图。具体而言，步骤S11之后包括：

S20：在移动界面框架中的每个控件组件绘制入口，并捕获移动界面框架中的待测试控件组件。

具体而言，结合面向切面编程的思想，在Flutter中的每一个控件组件绘制入口，并捕获其中的待测试控件组件，即上述步骤S11中获取到的待测试控件组件。

S21：将每个待测试控件组件上包裹一个转化组件，并将转化组件赋值为待测试控件组件对应的标签值。

具体而言，将上述步骤S20中捕获的待测试控件组件上包裹一层转化组件，在本实施例中，上述转化组件可以为语义组件（Semantic），当然，在其他实施例中，上述转化组件也可以为其他可以通往原生端元素的转化组件，本申请在此不作限定。由于Flutter转化的原生端元素对应的标签值（id）在APP中是唯一的，因此将待测试控件组件上包裹上语义组件（Semantic）之后，将待测试控件组件对应的标签值（id）赋值给对应的语义组件（Semantic），这样，每一个用来包裹控件组件的语义组件（Semantic）便拥有了对应的标签值（id）。

在一个实施例中，标签值（id）的赋值时机是在组件绘制入口，这就限制了我们生成唯一标签值（id）也是在组件绘制入口，也就是页面构建的时候。请参阅图5，图5是图4中步骤S21之前一实施方式的流程示意图。具体而言，步骤S21之前包括：

S210：根据移动界面框架所在的页面的第一信息获取移动界面框架的定位信息。

具体地，在本实施例中，Flutter为当前组件，Flutter所在的页面为Flutter的父组件，Flutter中的图标、文本等控件组件为Flutter的子组件。在本实施例中，根据Flutter所在的页面（即父组件）的第一信息（插槽）获取Flutter（即当前组件）的定位信息。

S211：根据待测试控件组件的第二信息和定位信息获取待测试控件组件在页面上的层级路径和元素下标。

具体而言，根据待测试控件组件（子组件）的第二信息和移动界面框架（Flutter）（当前组件）的定位信息获取待测试控件组件（子组件）在页面上的层级路径和元素下标。

S212：将层级路径和元素下标转换为字符串，并将字符串作为待测试控件组件对应的标签值。

具体而言，将上述步骤S211中获得的层级路径和元素下标转化为字符串之后就可以作为待测试控件组件对应的唯一标签值（id）来使用。

S22：将包裹转化组件的待测试控件组件返回至绘制流程。

具体而言，在上述步骤S21之后，将包裹转化组件的待测试控件组件返回至绘制流程。通过这样的设计方式，可以实现自动打标，Flutter中每一个待测试控件组件都是对应的转化组件包裹的含有对应标签值（id）的控件组件，在开发和后续升级迭代中降低开发人员增打标的负担和维护成本。

具体地，在本实施例中，待测试控件组件对应的标签值（id）是唯一的，且在待测试控件组件所在的页面不发生变化时不会发生变化。当然，标签值（id）也可以支持开发手动设置，以便于在比较重要的位置设定特定的标签值（id）。

当然，在其他实施例中，标签值（id）也可以是在点击时候生成的，本申请在此不作限定。

S2：在每个待测试控件组件上包裹一个转化组件。

具体而言，每个转化组件具有唯一的赋值。上述转化组件可以为语义组件（Semantic），当然，本申请中所提及的转化组件也可以为其他可以通往原生端的组件，本申请在此不作限定。

在最新的移动界面框架数据传输（FlutterSDK）中，语义组件（Semantic）在发行（release）的时候是默认关闭的，只有在调试（Debug）模式下才会默认打开，并且，开启语义组件（Semantic）的方法，在软件开发工具包（SDK）的应用程序接口（Api）中是不公开的。我们已经通过SDK源码得知以上逻辑，那么在本实施例中，在步骤S2之前，包括：利用面向切面编程（AOP）方法通过调用预定类型的钩子函数（hook SDK）对原生端开启转化组件的实现进行相应修改，以使得在软件开发工具包的应用程序接口中待测试控件组件对应的地方实现自动开启转化组件。请参阅图6，图6是将Flutter元素转化为原生端自动化测试工具可识别元素的示意图。如图6所示，（a）为Flutter端页面样式，（b）为不开启语义组件在测试工具中看到的样子，（c）为开启语义组件在测试工具中看到的样子，可以看到开启语义组件之后看到的样子与Flutter端页面原来的样式是一样的。通过上述设计方式，在需要打开语义组件（Semantic）的地方，就可以打开语义组件（Semantic），从而使得Flutter元素转化为原生端自动化测试工具可识别的元素。这里需要说明的是，（a）和（c）中的字母是写乱了的拉丁语，是网页设计中排版用的假文字，并没有什么实际含义。

S3：根据转化组件获得每个待测试控件组件的界面可达性标识。

在解决了打开语义组件（Semantic）的问题之后，发现存在只有部分Flutter元素被转换为原生组件的问题。在打开语义组件（Semantic）后，会发现只有部分元素具有信息，比如Flutter端的宏组件（Text组件）被转化为iOS端的标签控件（Label），xpath上有值，界面可达性值（UI AccessiblityValue）的值是Text组件的显示内容，并且界面可达性值（UIAccessiblityValue）会随着显示内容的变化而变化，界面可达性标识（UIAccessiblityIdentity）。而其他Flutter元素组件却没有转化为相应的原生组件，更不用说界面可达性标识（UIAccessiblityIdentity）的值了。

为了解决上述问题，利用上述步骤S2：在每个待测试控件组件上包裹一个语义组件，并给对应的语义组件（Semantic）进行赋值。这样，再在自动化测试工具上查看时，我们能够看到包含Text组件在内的所有组件都转化为了原生组件，并且界面可达性值（UIAccessiblityValue）上对应着开发阶段给语义组件（Semantic）的赋值。通过前边介绍过的原生端自动化测试方案，界面可达性标识（UIAccessiblityIdentity）的属性上需要有正确的赋值才能够支持自动化测试。但是，界面可达性标识（UIAccessiblityIdentity）的值仍然是空的。

为了解决上述问题，在一个实施例中，请一并参阅图7-图8，图7是图2中步骤S3一实施方式的流程示意图，图8是将Value值赋值给界面可达性标识的逻辑示意图。具体而言，步骤S3包括：

S30：将待测试控件组件的界面可达性值赋值为待测试控件组件对应的标签值。

具体地，在本实施例中，在编码阶段，也就是步骤S21中将待测试控件组件上包裹上语义组件（Semantic）之后，将待测试控件组件对应的标签值（id）赋值给对应的语义组件（Semantic），这样，如图8所示，每一个用来包裹控件组件的语义组件（Semantic）便拥有了对应的标签值（即图8中的赋值（Value）），通过这样的方式，待测试控件组件的界面可达性值也得到了待测试控件组件对应的标签值（id）。

S31：将标签值从界面可达性值同步到待测试控件组件的界面可达性标识上。

具体而言，将上述步骤S30中赋值给界面可达性值的标签值（即图8中的Value值）同步到对应待测试控件组件的界面可达性标识上，在本实施例中，界面可达性标识的值与界面可达性值保持一致。

为了解决上述问题，除了可以采用步骤S30-S31之外，在另一个实施例中，请一并参阅图8-图9，图9是图2中步骤S3另一实施方式的流程示意图。具体而言，步骤S3还包括：

S40：将用户界面可访问性对象的可达性标识符设置为字符串、以及将用户界面可访问性对象的可达性值设置为标签值。

通过FlutterEngine的语义组件（Semantic）部分的源码阅读了解到，语义组件（Semantic）转化为支持自动化测试的原生组件，其实是转换为了用户界面可访问性对象（UIAccessiblityObject），在FlutterEngine中实现了利用可达性值（accessibilityValue）的方法获取到了标签值（即图8中的Value值）。具体地，在本实施例中，将用户界面可访问性对象的可达性标识符（accessibilityIdentifier）设置为字符串，并将用户界面可访问性对象的可达性值（accessibilityValue）设置为上述步骤S21中用来包裹控件组件的语义组件（Semantic）的标签值（Value值）。

S41：通过面向切面编程方法将待测试控件组件的界面可达性标识的调用指向可达性值，以根据可达性标识符和可达性值将界面可达性标识补全。

具体而言，通过面向切面编程（AOP）方法将待测试控件组件的界面可达性标识（UIAccessiblityIdentity）的调用指向可达性值（accessibilityValue），以根据可达性标识符（accessibilityIdentifier）和可达性值（accessibilityValue）将界面可达性标识（UIAccessiblityIdentity）补全，从而获得待测试控件组件对应的完整的界面可达性标识（UIAccessiblityIdentity）。

S4：响应于接收到自动化测试指令时，通过界面可达性标识获得与其对应的待测试控件组件，并对待测试控件组件进行自动化测试。

具体地，在本实施例中，请参阅图10，图10是Flutter/ios混合应用自动化测试架构示意图。当接收到Appium等自动化测试工具的自动化测试指令时，通过界面可达性标识（UIAccessiblityIdentity）获得与其对应的待测试控件组件，并对待测试控件组件进行操作或这判断等自动化测试，此时待测试控件组件由于语义组件（Semantic）已经转化为原生端可以识别的原生组件，因此，自动化测试人员就不需要关心当前页面是Flutter还是原生端，只需要获取界面可达性标识（UIAccessiblityIdentity）然后进行自动化操作即可。具体地，客户端将待测试控件组件送至Appium服务端（Appium server），Appium服务端中的ios移动测试框架（WebDriverAgent）运行待测试控件组件并将待测试控件组件输入至ios的单元测试框架（XC Test framework），在使用Appium等自动化测试工具时，就能通过界面可达性标识（UI Accessiblity Identity）拿到混合应用（Flutter/App）中对应的具体的控件组件，从而使用用于动态调追踪和分析OSX和iOS的代码的性能分析和测试工具（Instruments）进行操作或者判断等自动化操作。

通过这种设计方式，可以将Flutter元素转化为原生端元素，并且赋值了一个唯一标签值（id），既不需要依赖虚拟服务器，也不需要自动化测试团队针对跨端页面做特殊处理即可将跨端页面的元素转化为原生端测试工具可以识别的元素。

在这里需要说明的是，将Flutter元素转化为原生测试控件组件的方式，除开通过语义组件（Semantic）的转化方式，可以通过其他转化组件的方式转化，也可以通过类似服务数据中转进行数据转化等方式，本申请在此不作限定。

请参阅图11，图11是本申请跨端自动化测试装置一实施方式的结构示意图。该跨端自动化测试装置具体包括：

获取模块10，用于从移动界面框架中获取至少一个待测试控件组件。

处理模块12，与获取模块10耦接，用于在每个待测试控件组件上包裹一个转化组件。此外，处理模块12还用于根据转化组件获得每个待测试控件组件的界面可达性标识。

测试模块14，与处理模块12耦接，用于响应于接收到自动化测试指令，通过界面可达性标识获得与其对应的待测试控件组件，并对待测试控件组件进行自动化测试。

请参阅图12，图12是本申请电子设备一实施方式的框架示意图。该电子设备具体包括相互耦接的存储器20和处理器22。具体地，在本实施例中，存储器20内存储有程序指令，处理器22用于执行程序指令以实现上述任一实施例所提及的跨端自动化测试方法。

具体而言，处理器22还可以称为CPU（Central Processing Unit，中央处理单元）。处理器22可能是一种集成电路芯片，具有信号的处理能力。处理器22还可以是通用处理器、数字信号处理器（Digital Signal Processor, DSP）、专用集成电路（ApplicationSpecific Integrated Circuit, ASIC）、现场可编程门阵列（Field-Programmable GateArray, FPGA）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。另外，处理器22可以由多个集成电路芯片共同实现。

请参阅图13，图13是本申请计算机可读存储介质一实施方式的框架示意图。该计算机可读存储介质30存储有计算机程序300，能够被计算机所读取，计算机程序300能够被处理器执行，以实现上述任一实施例中所提及的跨端自动化测试方法。其中，该计算机程序300可以以软件产品的形式存储在上述计算机可读存储介质30中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器（processor）执行本申请各个实施方式所述方法的全部或部分步骤。具有存储功能的计算机可读存储介质30可以是U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，RandomAccess Memory）、磁碟或者光盘等各种可以存储程序代码的介质，或者是计算机、服务器、手机、平板等终端设备。

总而言之，区别于现有技术的情况，本申请提供的跨端自动化测试方法包括：从移动界面框架中获取至少一个待测试控件组件；在每个待测试控件组件上包裹一个转化组件；其中，每个转化组件具有唯一的赋值；根据转化组件获得每个待测试控件组件的界面可达性标识；响应于接收到自动化测试指令，通过界面可达性标识获得与其对应的待测试控件组件，并对待测试控件组件进行自动化测试。通过这种设计方式，可以将Flutter元素转化为原生端元素，并且赋值了一个唯一标签值，既不需要依赖虚拟服务器，也不需要自动化测试团队针对跨端页面做特殊处理即可将跨端页面的元素转化为原生端测试工具可以识别的元素。

以上所述仅为本申请的实施方式，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (7)

1.一种跨端自动化测试方法，其特征在于，包括：

从移动界面框架中获取至少一个待测试控件组件；

在每个所述待测试控件组件上包裹一个转化组件；其中，每个所述转化组件具有唯一的赋值；

根据所述转化组件获得每个所述待测试控件组件的界面可达性标识；

响应于接收到自动化测试指令，通过所述界面可达性标识获得与其对应的待测试控件组件，并对所述待测试控件组件进行自动化测试；

所述从移动界面框架中获取至少一个待测试控件组件的步骤，包括：从所述移动界面框架中获取多个控件组件；从所述多个控件组件中筛选并获取至少一个所述待测试控件组件；其中，所述待测试控件组件为所述移动界面框架中需要测试的控件组件；

所述从所述多个控件组件中筛选并获取至少一个所述待测试控件组件的步骤之后，包括：在所述移动界面框架中的每个所述控件组件绘制入口，并捕获所述移动界面框架中的所述待测试控件组件；将每个所述待测试控件组件上包裹一个所述转化组件，并将所述转化组件赋值为所述待测试控件组件对应的标签值；将包裹所述转化组件的待测试控件组件返回至绘制流程；

所述将每个所述待测试控件组件上包裹一个所述转化组件，并将所述转化组件赋值为所述待测试控件组件对应的标签值的步骤之前，包括：根据所述移动界面框架所在的页面的第一信息获取所述移动界面框架的定位信息；根据所述待测试控件组件的第二信息和所述定位信息获取所述待测试控件组件在所述页面上的层级路径和元素下标；将所述层级路径和所述元素下标转换为字符串，并将所述字符串作为所述待测试控件组件对应的标签值。

2.根据权利要求1所述的跨端自动化测试方法，其特征在于，所述在每个所述待测试控件组件上包裹一个转化组件的步骤之前，包括：

利用面向切面编程方法通过调用预定类型的钩子函数对原生端开启所述转化组件的实现进行相应修改，以使得在软件开发工具包的应用程序接口中所述待测试控件组件对应的地方实现自动开启所述转化组件。

3.根据权利要求1所述的跨端自动化测试方法，其特征在于，所述根据所述转化组件获得每个所述待测试控件组件的界面可达性标识的步骤，包括：

将所述待测试控件组件的界面可达性值赋值为所述待测试控件组件对应的标签值；

将所述标签值从所述界面可达性值同步到所述待测试控件组件的所述界面可达性标识上；其中，所述界面可达性标识的值与所述界面可达性值保持一致。

4.根据权利要求1所述的跨端自动化测试方法，其特征在于，所述根据所述转化组件获得每个所述待测试控件组件的界面可达性标识的步骤，还包括：

将用户界面可访问性对象的可达性标识符设置为所述字符串、以及将所述用户界面可访问性对象的可达性值设置为所述标签值；

通过面向切面编程方法将所述待测试控件组件的界面可达性标识的调用指向所述可达性值，以根据所述可达性标识符和所述可达性值将所述界面可达性标识补全。

5.根据权利要求1所述的跨端自动化测试方法，其特征在于，

所述待测试控件组件对应的标签值是唯一的，且在所述待测试控件组件所在的页面不发生变化时不会发生变化。

6.一种电子设备，其特征在于，包括相互耦接的存储器和处理器，所述存储器内存储有程序指令，所述处理器用于执行所述程序指令以实现权利要求1至5中任一项所述的跨端自动化测试方法。

7.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序用于实现权利要求1至5任一项所述的跨端自动化测试方法。

Images