用户界面的测试方法、系统、集群、介质及程序产品与流程

1.本技术涉及软件测试技术领域，尤其涉及一种用户界面的测试方法、系统、集群、计算机可读存储介质以及计算机程序产品。


背景技术：

2.随着计算机技术尤其是前端技术的迅猛发展，许多互联网服务提供商提供了多种客户端类型，以为不同设备的用户提供服务。具体地，互联网服务提供商可以针对互联网软件产品提供网页(web)页面、应用(application，app)程序。其中，web页面可以通过通用的web客户端如浏览器(桌面浏览器、移动端浏览器)呈现给用户，app程序为专用客户端，通常可以基于支持该app程序的操作系统分为不同类型，例如同一软件可以包括android版、ios版等多个版本。
3.在web页面或app程序开发过程中，通常需要对用户界面(user interface，ui)进行测试。目前，业界提出了ui自动化测试工具，例如用于web页面测试的工具selenium以及用于app测试的工具appium等。
4.然而，在编写不同客户端类型的测试用例时，例如编写web类型、app类型的测试用例时，需要集成不同的测试框架进行开发。不同客户端类型的测试用例编写方法不统一，使用的应用程序编程接口(application programming interface，api)也存在差异，导致同样的业务场景，通常需要编写多份代码，测试用例的编写效率低下，进而极大地影响了ui的测试效率。


技术实现要素：

5.本技术提供了一种ui的测试方法。该方法通过抽象出对不同类型客户端统一的界面测试api，使得测试者可以针对不同客户端类型使用统一的界面测试api编写测试用例，将用例编写方法统一和简化，提高了测试用例的编写效率，进而提高了ui的测试效率。并且，本技术还大大减小不同客户端上编写自动化测试用例的成本，节约了测试成本。本技术还提供了上述方法对应的ui的测试系统以及计算机集群、计算机可读存储介质以及计算机程序产品。
6.第一方面，本技术提供了一种ui的测试方法。该方法可以应用于ui的测试系统。ui的测试系统具体可以是软件系统，该软件系统可以部署在包括至少一台计算机的计算机集群中。计算机集群运行该软件系统，以实现多类型客户端统一的ui自动化测试。
7.具体地，ui的测试系统可以针对不同类型客户端提供相同的界面测试api，用户(例如是测试者)可以基于该界面测试api编写不同类型客户端的测试用例，ui的测试系统接收上述不同类型客户端的测试用例，然后执行不同类型客户端的测试用例，从而实现对不同类型客户端的ui的测试。
8.该方法通过抽象出对不同类型客户端统一的界面测试api，使得测试者可以针对不同客户端类型使用统一的界面测试api编写测试用例，将用例编写方法统一和简化，提高
了测试用例的编写效率，进而提高了ui的测试效率。并且，本技术实施例还大大减小不同客户端上编写自动化测试用例的成本，节约了测试成本。
9.在一些可能的实现方式中，所述界面测试api应用于多个平台。如此，测试者在需要对不同平台(不同类型)的ui进行测试时，可以基于上述界面测试api编写测试用例，而无需考虑平台的差异重新编写测试用例的实现代码，例如可以基于同一套实现代码实现对不同平台的ui进行测试，或者在一个平台对应的测试用例的实现代码的基础上进行微调得到另一个平台对应的测试用例的实现代码，并由此实现对不同平台的ui进行测试。
10.在一些可能的实现方式中，所述多个平台包括网页平台和应用平台。其中，网页平台可以是网页客户端如web浏览器。进一步地，网页平台还可以包括移动网页平台和桌面网页平台。应用平台可以是应用(application，app)客户端。app客户端包括电子邮件客户端、即时通信客户端、电子商务客户端或者是游戏客户端等专用客户端。提供相同服务的客户端还可以按照运行该客户端的设备类型或设备上操作系统的类型进行分类。例如，对于某电子邮件客户端，开发者通常可以在应用市场发布针对不同操作系统的版本，以便用户根据各自设备的操作系统选择相应的版本。
11.该方法通过对不同平台统一的界面测试api，实现以统一方法编写不同平台的ui对应的测试用例，对于不同平台均具有较好的适应性，满足了测试需求。
12.在一些可能的实现方式中，ui的测试系统在进行测试时可以先确认客户端类型，然后基于客户端类型选择调用相应的服务进行ui的测试。例如，ui的测试系统可以确认客户端类型为网页客户端，例如是web浏览器，然后根据所述界面测试api调用selenium服务(用于对网页进行测试的服务)进行ui的测试。
13.基于上述方法，一方面可以解决原有测试框架如selenium仅支持特定类型的ui的测试的问题，另一方面无需对原有测试框架进行大幅改动，节省了成本。
14.在一些可能的实现方式中，ui的测试系统在进行测试时可以先确认客户端类型，然后基于客户端类型选择调用相应的服务进行ui的测试。例如，ui的测试系统可以确认客户端类型为app客户端，然后可以根据所述界面测试api调用appium服务进行用户界面的测试。由此解决了原有测试框架如appium仅支持特定类型的ui的测试的问题，另一方面无需对原有测试框架进行大幅改动，节省了成本。
15.在一些可能的实现方式中，ui的测试系统在执行测试用例，以对ui进行测试时，还可以出现异常情况，例如出现对ui控件操作异常的情况。ui的测试系统可以检测异常类型，然后根据所述异常类型，调整等待时间，以完成对所述用户界面控件的操作。
16.与直接使用原有的测试框架如selenium、appium，本技术通过智能等待提高了控件操作的成功率，进而提高了测试效率和测试质量。
17.在一些可能的实现方式中，所述异常类型包括：所述ui控件未加载完成或者是所述ui控件已加载且所述ui控件的关联数据未加载完成。其中，ui控件未加载完成可以进一步分为以下几种情况：(1)ui控件在页面中查找失败，且无法对ui控件操作；(2)ui控件在页面中查找成功，但是无法对ui控件操作，例如ui控件出现在页面中，但处于灰化状态。
18.上述ui的测试方法可以实现在多种异常情况下进行智能等待，当异常恢复后，再执行测试用例。如此，可以实现高效、稳定的ui测试。
19.第二方面，本技术提供一种ui的测试系统。所述系统包括：
20.接口单元，用于针对不同类型客户端提供相同的界面测试api；
21.通信单元，用于接收不同类型客户端的测试用例，所述不同类型客户端的测试用例基于所述相同的界面测试api编写；
22.测试单元，用于执行所述不同类型客户端的测试用例，实现对不同类型客户端的用户界面的测试。
23.在一些可能的实现方式中，所述界面测试api应用于多个平台。
24.在一些可能的实现方式中，所述多个平台包括网页平台和应用平台。
25.在一些可能的实现方式中，所述测试单元具体用于：
26.确认客户端类型为网页客户端，根据所述界面测试api调用selenium服务进行用户界面的测试。
27.在一些可能的实现方式中，所述测试单元具体用于：
28.确认客户端类型为应用客户端，根据所述界面测试api调用appium服务进行用户界面的测试。
29.在一些可能的实现方式中，所述测试单元具体用于：
30.对所述用户界面控件的操作异常时，检测异常类型；
31.根据所述异常类型，调整等待时间，以完成对所述用户界面控件的操作。
32.在一些可能的实现方式中，所述异常类型包括：所述ui控件未加载完成或者是所述ui控件已加载且所述用户界面控件的关联数据未加载完成。
33.第三方面，本技术提供一种计算机集群。所述计算机集群包括至少一台计算机，所述计算机包括处理器和存储器，所述存储器中存储有计算机可读指令，所述处理器执行所述计算机可读指令，以执行如第一方面或第一方面的任一种实现方式中的用户界面的测试方法。
34.第四方面，本技术提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，所述指令指示设备执行上述第一方面或第一方面的任一种实现方式所述的用户界面的测试方法。
35.第五方面，本技术提供了一种包含指令的计算机程序产品，当其在设备上运行时，使得设备执行上述第一方面或第一方面的任一种实现方式所述的用户界面的测试方法。
36.本技术在上述各方面提供的实现方式的基础上，还可以进行进一步组合以提供更多实现方式。
附图说明
37.为了更清楚地说明本技术实施例的技术方法，下面将对实施例中所需使用的附图作以简单地介绍。
38.图1为本技术实施例提供的一种计算机集群的系统架构图；
39.图2为本技术实施例提供的一种ui的测试系统的结构示意图；
40.图3为本技术实施例提供的一种ui的测试方法的流程图；
41.图4为本技术实施例提供的一种云服务购买界面的示意图；
42.图5为本技术实施例提供的一种云服务购买界面的示意图；
43.图6为本技术实施例提供的一种订单管理界面的示意图；
44.图7为本技术实施例提供的一种计算机集群的结构示意图。
具体实施方式
45.本技术实施例中的术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。
46.为了便于理解本技术实施例，首先，对本技术涉及的部分术语进行解释说明。
47.网页web页面：一种由超文本标记语言(hyper text markup language，html)建立，且能够被浏览器解释或翻译的信息载体。该信息载体能够承载文字、图片、声音、视频等多媒体信息中的任意一种或多种。web页面可以包括各种组织的官方网页或者是信息管理系统的网页。
48.客户端：一种为客户提供本地服务的程序。客户端也可以称作用户端，客户端可以在本地设备独立运行，或者与远端服务器上的服务端协作运行。客户端可以分为通用的web客户端(例如是浏览器)和专用的app客户端。通用的web客户端可以通过不同web页面实现不同功能，例如实现电子邮件、电子商务等功能，专用的app客户端包括电子邮件客户端、即时通信客户端、电子商务客户端或者是游戏客户端等等。其中，提供相同服务的客户端还可以按照运行该客户端的设备类型或设备上操作系统的类型进行分类。例如，对于某电子邮件客户端，开发者通常可以在应用市场发布针对不同操作系统的版本，以便用户根据各自设备的操作系统选择相应的版本。
49.测试框架：一种为自动化测试用例或者脚本提供执行环境而搭建的基础设施软件。测试框架提供有丰富的组件，从而为软件测试提供帮助。例如，测试框架提供有日志管理组件、测试报告生成及管理组件、测试用例管理组件、测试数据管理组件等等。
50.在web页面或app客户端开发过程中，通常需要对用户界面ui进行测试。目前，业界提出了ui自动化测试工具，例如用于web页面测试的工具selenium以及用于app客户端测试的工具appium等。然而，在编写不同客户端类型的测试用例时，例如编写web类型、app类型的测试用例时，需要集成不同的测试框架进行开发。不同客户端类型的测试用例编写方法不统一，使用的应用程序编程接口api也存在差异，导致同样的业务场景，通常需要编写多份代码，测试用例的编写效率低下，进而极大地影响了ui的测试效率。
51.为了解决上述技术问题，本技术实施例提供一种ui的测试方法。该方法可以应用于ui的测试系统。ui的测试系统具体可以是软件系统，该软件系统可以部署在包括至少一台计算机的计算机集群中。计算机集群运行该软件系统，以实现多类型客户端统一的ui自动化测试。
52.具体地，ui的测试系统可以针对不同类型客户端提供相同的界面测试api，用户(例如是测试者)可以基于该界面测试api编写不同类型客户端的测试用例，ui的测试系统接收上述不同类型客户端的测试用例，然后执行不同类型客户端的测试用例，从而实现对不同类型客户端的ui的测试。
53.本技术实施例通过抽象出对不同类型客户端统一的界面测试api，使得测试者可以针对不同客户端类型使用统一的界面测试api编写测试用例，将用例编写方法统一和简化，提高了测试用例的编写效率，进而提高了ui的测试效率。并且，本技术实施例还大大减
小不同客户端上编写自动化测试用例的成本，节约了测试成本。
54.下文将围绕以上介绍的总体思路对本技术实施例作出详细介绍。
55.首先请参见图1，图1是根据本技术实施例的计算机集群的系统架构示意图。
56.如图1所示，计算机集群100包括服务器110和终端120，服务器110和终端120通过网络130连接。服务器110可以是云环境中的云服务器。其中，云环境指示云服务提供商拥有的，用于提供计算、存储、通信资源的计算集群。服务器110也可以是本地数据中心的本地服务器。本地数据中心是指用户如测试者所属数据中心。终端120可以是台式机、笔记本电脑、平板电脑或者其他设备。测试者可以通过终端120与服务器110交互，从而实现对不同类型客户端的ui进行统一测试。
57.具体地，服务器110包括硬件资源和软件资源。硬件资源包括网卡、处理器、存储器
……
等服务器通用的硬件设备。其中，处理器可以包括中央处理器(central processing unit，cpu)和图形处理器(graphics processing unit，gpu)中的至少一个。一个服务器可以包括至少一个cpu以及至少一个gpu。图1以一个服务器包括一个cpu和一个gpu进行示例说明。
58.软件资源包括服务器操作系统以及ui的测试系统。其中，服务器操作系统用于对服务器110的硬件设备和部署在服务器110中的软件进行直接控制和管理协调。ui的测试系统运行在服务器操作系统上，用于对不同类型客户端的ui进行统一测试。
59.其中，不同类型客户端包括web客户端和app客户端中的至少一个。web客户端的ui包括web页面。app客户端的ui包括app客户端的登录页面、主页面、详情页面、配置页面等等。web客户端可以根据客户端所在设备分为mobile web客户端和个人电脑(personal computer，pc)web客户端。app客户端可以根据客户端所在设备(或者是设备上的操作系统)分为不同类型。
60.为了使得本技术的技术方案更加清楚、易于理解，以下请参见图2，图2是根据本技术实施例的ui的测试系统的结构示意图，如图2所示，ui的测试系统200包括接口单元202、通信单元204和测试单元206。下面对各个单元的功能进行说明。
61.接口单元202用于针对不同类型客户端提供相同的界面测试api。该界面测试api包括控件操作层中控件操作方法对应的api。控件操作层封装有ui控件的操作类对应的控件操作方法。其中，ui控件是指用于生成ui的控件，包括但不限于选择控件、输入控件、提交控件等。操作类具体可以包括点击(单击、双击等)、选中等操作的抽象类。操作类可以实例化，从而生成对应的控件操作方法。该控件操作方法相对于不同类型客户端(例如是mobile web客户端、pc web客户端或者是基于特定操作系统的app客户端)统一。
62.通信单元204用于接收不同类型客户端的测试用例。其中，不同类型客户端的测试用例可以是用户(例如为测试者)基于所述相同的界面测试api编写。
63.测试单元204用于执行上述不同类型客户端的测试用例，实现对不同类型客户端的用户界面的测试。由此可以实现对不同类型客户端，例如是web客户端和app客户端的ui的一体化测试。
64.在一些可能的实现方式中，界面测试api可以应用于多个平台，例如是网页平台和应用平台，从而实现对相应类型的客户端进行ui的测试。在一些可能的实现方式中，界面测试api还可以应用于其他平台，从而实现对其他类型的客户端进行ui的测试。
65.具体地，接口单元202还针对不同平台提供对应的操作方法的api。具体地，接口单元202还包括平台操作层，例如包括网页平台操作和应用平台操作层。其中，网页平台操作层基于selenium服务封装web客户端如浏览器的操作方法，应用平台操作层基于appium服务封装app客户端的操作方法。其中，app客户端的操作方法还包括设备连接管理方法，用于对部署app客户端的设备如手机等进行连接管理。控件操作层的api可以调用平台操作层的api，形成api调用链，通过api调用链实现对相应类型的客户端的ui的测试。
66.进一步地，应用平台还可以根据操作系统类型分为不同的应用平台。基于此，接口单元202还针对不同操作系统类型对应的应用分别提供相应的驱动(drive)。具体地，应用平台包括第一应用平台和第二应用平台，第一应用平台和第二应用平台对应不同类型的操作系统。接口单元202还包括第一应用平台驱动层和第二应用平台驱动层。第一应用平台驱动层包括第一应用平台的驱动，第二应用平台驱动层包括第二应用平台的驱动。
67.需要说明的是，平台操作层不限于上述网页平台操作层和应用平台操作层，还可以支持其他更多的平台。
68.在一些可能的实现方式中，接口单元202还可以提供通用操作的api。参见图2，接口单元202还包括基础层，该基础层封装有通用操作方法，例如是超文本传输协议(hyper text transfer protocol，http)请求、模拟(mock)操作或者数据库操作等通用操作方法。基础层提供上述通用操作方法的api，以便于测试调用上述api。此外，基础层还可以实现对测试用例的统一调度。对测试用例的统一调度具体为对不同测试用例执行相同处理。例如，针对不同测试用例增加公共前置条件或公共后置处理，该公共前置条件例如可以是设置环境变量，该公共后置处理例如可以是数据清理、信息收集等。
69.接口单元202提供的基础层、控件操作层、平台操作层等可以形成web客户端和app客户端一体化的测试框架。该一体化的测试框架可以提供selenium服务和appium服务。测试单元206在执行不同类型客户端的测试用例时，可以确认客户端类型。当客户端类型为网页客户端，则根据所述界面测试api调用selenium服务进行ui的测试。当客户端类型为应用客户端，根据所述界面测试api调用appium服务进行ui的测试。
70.接下来，将结合附图，从ui的测试系统角度对本技术实施例提供的ui的测试方法进行详细说明。
71.参见图3所示的ui的测试方法的流程图，该方法包括：
72.s302：ui的测试系统针对不同类型客户端提供相同的界面测试api。
73.具体地，客户端可以基于通用程度分为通用的web客户端和专用的app客户端。其中，web客户端还可以基于适用的设备分为mobile web客户端和pc web客户端，app客户端还可以基于适用的设备(具体是设备中的操作系统)分为桌面客户端和嵌入式客户端，其中，嵌入式客户端可以包括不同嵌入式操作系统对应的客户端。
74.针对上述不同类型客户端，ui的测试系统基于一体化的测试框架，提供相同的界面测试api，以供测试者基于上述界面测试api编写测试用例。其中，一体化的测试框架包括控件操作层，该控件操作层封装有ui控件的操作类对应的控件操作方法。控件操作层可以暴露上述ui控件的操作类对应的控件操作方法的api，也即界面测试api。
75.由于控件操作层中封装的控件操作方法时基于selenium、appium等测试框架封装的方法抽象得到，基于此，控件操作层暴露的api如界面测试api对于不同类型客户端是相
同的。
76.s304：ui的测试系统接收不同类型客户端的测试用例。
77.不同类型客户端的测试用例可以是用户(例如为测试者)基于s302中所述的相同的界面测试api编写。具体地，针对不同类型的客户端，用户可以通过相同的界面测试api编写测试用例的实现代码。例如，ui包括点击控件时，用户均可以使用clickelement()方法，ui包括文本输入控件时，用户均可以使用inputtext()方法，ui包括等待元素加载控件时，用户均可以使用waitelementappear()方法。
78.本技术实施例还以某网站的登录页面的测试用例进行示例说明。
79.pc web客户端如pc浏览器登录网站时的登录页面对应的测试用例如下所示：
[0080][0081]
mobile web客户端如手机浏览器登录网站时的登录页面对应的测试用例如下所示：
[0082]
[0083][0084]
基于上述实现代码，可知不同类型客户端的登录页面的方法类的实现代码几乎一致，实现代码主要包括界面测试api的调用，界面测试api在不同平台或者不同类型客户端上的调用方法可以是一致的。不同客户端对应的测试用例的实现代码的主要区别在于类名、测试用例名称等信息。因此，用户如测试者在编写完一个类型客户端的测试用例后，可以对已编写的测试用例进行微调得到其他类型客户端的测试用例。
[0085]
s306：ui的测试系统执行所述不同类型客户端的测试用例，实现对不同类型客户端的用户界面的测试。
[0086]
ui的测试系统提供了不同类型客户端的测试用例的执行环境，ui的测试系统可以在该执行环境下执行不同类型客户端的测试用例，从而实现对不同类型客户端的ui的测试。
[0087]
需要说明的是，ui的测试系统执行测试用例时，还可以出现对ui控件的操作异常的情况。基于此，ui的测试系统还可以在对ui控件的操作异常时，检测异常类型。其中，异常类型可以包括以下类型：(1)ui控件未加载完成；(2)ui控件已加载且所述ui控件的关联数据未加载完成。其中，ui控件未加载完成可以包括多种情况，一种情况是ui控件尚未在页面中显示，另一种情况是ui控件在页面中显示，但处于不可用状态(例如是灰化状态)。ui的测试系统可以根据上述异常类型，调整等待时间，以完成对所述用户界面控件的操作。如此解决了selenium、appium等测试框架的操作方法不稳定的问题，提升了控件操作成功率，进而提高了测试质量和测试效率。
[0088]
为了便于理解，下面结合界面图对上述异常情况及其处理结果进行示例说明。
[0089]
第一种异常情况：ui控件未加载完成，具体是ui控件在页面中查找失败，且无法对ui控件操作。
[0090]
参见如图4所示的云服务购买界面的示意图，界面400中显示了区域控件，未显示“计费模式”和“购买时长”等控件。本技术实施例的ui测试系统在检测到第一种异常情况，例如“计费模式”和“购买时长”等控件在页面中未显示时，可以预测上述控件的加载完成时间，然后调整等待时间。具体地，测试框架通常设置有默认等待时间，该默认等待时间可以
是最大等待时间，例如可以为60秒(second，s)。在本技术实施例中，ui的测试系统可以调整等待时间，例如在默认等待时间的区间内，每间隔设定时间，例如为10s，检测ui控件是否出现，若是，则停止等待，自动完成对上述控件的操作，如选择“包年包月”的计费模式以及选择“购买时长”为1个月。
[0091]
第二种异常情况：ui控件未加载完成，具体是ui控件在页面中查找成功，但是无法对ui控件操作(例如是ui控件处于灰化状态)。
[0092]
参见图5所示的云服务购买界面的示意图，界面500中显示了“加入清单”控件，但是该控件处于灰化状态，无法对该控件进行操作。本技术实施例的ui测试系统在检测到第二种异常情况，例如“加入清单”控件在页面中显示，但不可用时，可以预测上述控件由不可用变为可用的等待时间，然后调整等待时间。具体地，测试框架通常设置有默认等待时间，该默认等待时间可以是最大等待时间，例如可以为60秒(second，s)。ui的测试系统可以调整等待时间，例如在默认等待时间的区间内，每间隔设定时间，例如为10s，获取ui控件如“加入清单”控件的属性，基于该属性确定控件是否可用，若是，则停止等待，并对上述控件执行相应的操作。
[0093]
第三种异常情况：ui控件加载完成，但ui控件关联的数据未加载完成。
[0094]
参见如图6所示的订单管理界面的示意图，界面500中展示了产品类型控件和区域控件，然而产品类型控件关联的数据以及区域控件关联的数据并未返回，界面500中悬浮了加载框，用于标识数据仍在加载。本技术实施例的ui的测试系统在检测到第三种异常情况，可以预测关联的数据的加载完成时间，当加载完成时间到达时，ui的测试系统可以自动检测是否能触发对ui控件的操作，例如是触发对产品类型控件中特定产品类型的筛选操作，或者是触发对区域控件中特点区域的筛选操作。若是，则执行上述操作完成ui的测试。
[0095]
基于上述内容描述，本技术实施例提供了一种ui的测试方法。该方法通过抽象出对不同类型客户端统一的界面测试api，使得测试者可以针对不同客户端类型使用统一的界面测试api编写测试用例，将用例编写方法统一和简化，提高了测试用例的编写效率，进而提高了ui的测试效率。并且，本技术实施例还大大减小不同客户端上编写自动化测试用例的成本，节约了测试成本。
[0096]
进一步地，在执行测试用例过程中，对ui控件的操作异常时，还可以检测异常类型，然后根据所述异常类型，智能调整等待时间，以完成对所述用户界面控件的操作。如此可以解决原生操作方法不稳定的问题，提高控件操作成功率。
[0097]
此外，本技术实施例在设计一体化的测试框架时，采用分层思路，将测试用例统一调度、公共能力、统一控件操作、驱动分层设计，降低了测试用例实现层面的复杂性。
[0098]
上文结合图1至图6对本技术实施例提供的ui的测试方法进行了详细介绍，下面将结合附图对本技术实施例提供的ui的测试系统进行介绍。
[0099]
参见图2所示的ui的测试系统的结构示意图，该系统200包括：
[0100]
接口单元202，用于针对不同类型客户端提供相同的界面测试应用程序编程接口api；
[0101]
通信单元204，用于接收不同类型客户端的测试用例，所述不同类型客户端的测试用例基于所述相同的界面测试api编写；
[0102]
测试单元206，用于执行所述不同类型客户端的测试用例，实现对不同类型客户端
的用户界面的测试。
[0103]
在一些可能的实现方式中，所述界面测试api应用于多个平台。
[0104]
在一些可能的实现方式中，所述多个平台包括网页平台和应用平台。
[0105]
在一些可能的实现方式中，所述测试单元206具体用于：
[0106]
确认客户端类型为网页客户端，根据所述界面测试api调用selenium服务进行用户界面的测试。
[0107]
在一些可能的实现方式中，所述测试单元206具体用于：
[0108]
确认客户端类型为应用客户端，根据所述界面测试api调用appium服务进行用户界面的测试。
[0109]
在一些可能的实现方式中，所述测试单元206具体用于：
[0110]
对所述用户界面控件的操作异常时，检测异常类型；
[0111]
根据所述异常类型，调整等待时间，以完成对所述用户界面控件的操作。
[0112]
在一些可能的实现方式中，所述异常类型包括：所述用户界面控件未加载完成或者是所述用户界面控件已加载且所述用户界面控件的关联数据未加载完成。
[0113]
根据本技术实施例的ui的测试系统200可对应于执行本技术实施例中描述的方法，并且ui的测试系统200的各个模块/单元的上述和其它操作和/或功能分别为了实现图3所示实施例中的各个方法的相应流程，为了简洁，在此不再赘述。
[0114]
本技术实施例还提供了一种计算机集群。该计算机集群可以是云环境、边缘环境或者终端设备中的至少一台计算机形成的计算机集群。该计算机集群具体用于实现如图2所示实施例中ui的测试系统200的功能。
[0115]
图7提供了一种计算机集群的结构示意图，如图7所示，计算机集群70包括至少一台计算机700，计算机700包括总线701、处理器702、通信接口703和存储器704。处理器702、存储器704和通信接口703之间通过总线701通信。
[0116]
总线701可以是外设部件互连标准(peripheral component interconnect，pci)总线或扩展工业标准结构(extended industry standard architecture，eisa)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
[0117]
处理器702可以为中央处理器(central processing unit，cpu)、图形处理器(graphics processing unit，gpu)、微处理器(micro processor，mp)或者数字信号处理器(digital signal processor，dsp)等处理器中的任意一种或多种。
[0118]
通信接口703用于与外部通信。例如，一台计算机的通信接口703可以用于接收不同类型客户端的测试用例等等。
[0119]
存储器704可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，ram)。存储器704还可以包括非易失性存储器(non-volatile memory)，例如只读存储器(read-only memory，rom)，快闪存储器，硬盘驱动器(hard disk drive，hdd)或固态驱动器(solid state drive，ssd)。
[0120]
存储器704中存储有可执行代码，处理器702执行该可执行代码以执行前述ui的测试。
[0121]
具体地，在实现图2所示实施例的情况下，且图2实施例中所描述的ui的测试系统
200的各模块为通过软件实现的情况下，图2中通信单元204功能由通信接口703实现，执行图2中功能所需的软件或程序代码可以存储在存储器704中。处理器702执行存储器704中存储的上述模块或单元对应的程序代码，以执行前述ui的测试方法。
[0122]
本技术实施例还提供了一种计算机可读存储介质。所述计算机可读存储介质可以是计算设备能够存储的任何可用介质或者是包含一个或多个可用介质的数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘)等。该计算机可读存储介质包括指令，所述指令指示计算设备执行上述ui的测试方法。
[0123]
本技术实施例还提供了一种计算机程序产品。所述计算机程序产品包括一个或多个计算机指令。在计算设备上加载和执行所述计算机指令时，全部或部分地产生按照本技术实施例所述的流程或功能。
[0124]
所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机或数据中心进行传输。
[0125]
所述计算机程序产品可以为一个软件安装包，在需要使用前述ui的测试方法的任一方法的情况下，可以下载该计算机程序产品并在计算设备上执行该计算机程序产品。
[0126]
上述各个附图对应的流程或结构的描述各有侧重，某个流程或结构中没有详述的部分，可以参见其他流程或结构的相关描述。