一种用户界面的测试方法及装置、电子设备、存储介质与流程

1.本技术涉及应用测试技术领域，特别涉及一种用户界面的测试方法及装置、电子设备、存储介质。


背景技术：

2.当前大部分公司都有自己的移动端应用，并且随着移动端应用的功能越来越丰富，通常都会采用自动化测试的方式来对应用进行用户界面测试，以能提升测试的效率。
3.在进行应用的用户界面测试时，应用会加载内容，并基于这些内容展示用户界面。所以测试人员在编写并调度完ui脚本后，需要一个固定的测试环境或者固定的接口数据返回，以能保证每次脚本执行的页面加载内容是一致，从而保证测试脚本的执行成功率。因此当前还需要测试人员在执行脚本时，人工维护该脚本相应的测试桩，以通过该测试桩保证页面加载内容的一致。
4.但是通过测试人员在执行脚本时人工维护该脚本相应的测试桩的方式，需要花费较多的时间，所以不够便捷，并且由于比较依赖于测试人员的水平，所以也无法有效地保证准确性。


技术实现要素：

5.基于上述现有技术的不足，本技术提供了一种用户界面的测试方法及装置、电子设备、存储介质，以解决现有技术不够便捷，且不能有效保证准确性的问题。
6.为了实现上述目的，本技术提供了以下技术方案：
7.本技术第一方面提供了一种用户界面的测试方法，包括：
8.捕获待测试应用的多条网络请求信息；其中，一条所述网络请求信息包括向服务器发送的一个网络请求中的数据以及所述服务器响应所述网络请求所反馈的数据；
9.基于预先配置的白名单，从各条所述网络请求信息中过滤出目标测试场景下的所有所述网络请求信息；
10.基于所述目标测试场景下的所有所述网络请求信息，构建所述目标测试场景对应的测试桩；
11.将所述目标测试场景对应的测试脚本与所述目标测试场景对应的测试桩关联；
12.执行所述目标测试场景对应的测试脚本；
13.每当接收到所述待测试应用发送的当前网络请求时，从所述目标测试场景对应的测试桩中的各条所述网络请求信息中，匹配出所包含的访问地址与所述当前网络请求的访问地址一致的目标网络请求信息；
14.将所述目标网络请求信息反馈给所述待测试应用。
15.可选地，在上述的用户界面的测试方法中，所述捕获待测试应用的多条网络请求信息，包括：
16.将开源库mitmproxy作为所述待测试应用的设备的网络代理；
17.开启网络代理服务，并清空已捕获的信息；
18.通过所述网络代理服务捕获所述待测试应用向所述服务器发送的网络请求中的数据以及所述服务器响应所述网络请求所反馈的数据，得到一条所述网络请求信息。
19.可选地，在上述的用户界面的测试方法中，所述基于所述目标测试场景下的所有所述网络请求信息，构建所述目标测试场景对应的测试桩，包括：
20.将所述目标测试场景下的所有所述网络请求信息存储至目标数据表中；
21.在所述目标数据表中添加所述目标测试场景对应的场景标识以及运行状态，得到所述目标测试场景对应的测试桩；其中，所述运行状态初始为失效状态。
22.可选地，在上述的用户界面的测试方法中，所述将所述目标测试场景对应的测试脚本与所述目标测试场景对应的测试桩关联，包括：
23.将所述目标测试场景对应的测试脚本的网络请求全部存取至指定数据库，并上传所述目标测试场景的场景标识至所述指定数据库中，以基于所述目标测试场景的场景标识，与所述目标测试场景对应的测试桩进行关联。
24.可选地，在上述的用户界面的测试方法中，所述执行所述目标测试场景对应的测试脚本之前，还包括：
25.将所有测试桩的运行状态初始化为失效状态；
26.将所述目标测试场景对应的测试桩的运行状态置为有效状态。
27.可选地，在上述的用户界面的测试方法中，所述从所述目标测试场景对应的测试桩中的各条所述网络请求信息中，匹配出所包含的访问地址与所述当前网络请求的访问地址一致的目标网络请求信息，包括：
28.基于各个所述测试桩的运行状态，查找出所述目标测试场景对应的测试桩；
29.将所述当前网络请求的访问地址与所述目标测试场景对应的测试桩中的各个访问地址进行一致性匹配；
30.若所述目标测试场景对应的测试桩中存在与所述当前网络请求的访问地址匹配成功的访问地址，则将匹配成功的所述访问地址所属的所述网络请求信息作为所述目标网络请求。
31.可选地，在上述的用户界面的测试方法中，还包括：
32.在结束所述目标测试场景的用户界面测试后，将所述目标测试场景对应的测试桩的运行状态置为失效状态。
33.本技术第二方面提供了一种用户界面的测试装置，包括：
34.信息捕获单元，用于捕获待测试应用的多条网络请求信息；其中，一条所述网络请求信息包括向服务器发送的一个网络请求中的数据以及所述服务器响应所述网络请求所反馈的数据；
35.过滤单元，用于基于预先配置的白名单，从各条所述网络请求信息中过滤出目标测试场景下的所有所述网络请求信息；
36.测试桩构建单元，用于基于所述目标测试场景下的所有所述网络请求信息，构建所述目标测试场景对应的测试桩；
37.关联单元，用于将所述目标测试场景对应的测试脚本与所述目标测试场景对应的测试桩关联；
38.脚本执行单元，用于执行所述目标测试场景对应的测试脚本；
39.信息匹配单元，用于每当接收到所述待测试应用发送的当前网络请求时，从所述目标测试场景对应的测试桩中的各条所述网络请求信息中，匹配出所包含的访问地址与所述当前网络请求的访问地址一致的目标网络请求信息；
40.信息反馈单元，用于将所述目标网络请求信息反馈给所述待测试应用。
41.可选地，在上述的用户界面的测试装置中，所述信息捕获单元，包括：
42.代理单元，用于将开源库mitmproxy作为所述待测试应用的设备的网络代理；
43.预处理单元，用于开启网络代理服务，并清空已捕获的信息；
44.采集单元，用于通过所述网络代理服务捕获所述待测试应用向所述服务器发送的网络请求中的数据以及所述服务器响应所述网络请求所反馈的数据，得到一条所述网络请求信息。
45.可选地，在上述的用户界面的测试装置中，所述测试桩构建单元，包括：
46.存储单元，用于将所述目标测试场景下的所有所述网络请求信息存储至目标数据表中；
47.添加单元，用于在所述目标数据表中添加所述目标测试场景对应的场景标识以及运行状态，得到所述目标测试场景对应的测试桩；其中，所述运行状态初始为失效状态。
48.可选地，在上述的用户界面的测试装置中，所述关联单元，包括：
49.关联子单元，用于将所述目标测试场景对应的测试脚本的网络请求全部存取至指定数据库，并上传所述目标测试场景的场景标识至所述指定数据库中，以基于所述目标测试场景的场景标识，与所述目标测试场景对应的测试桩进行关联。
50.可选地，在上述的用户界面的测试装置中，还包括：
51.初始化单元，用于将所有测试桩的运行状态初始化为失效状态；
52.第一设置单元，用于将所述目标测试场景对应的测试桩的运行状态置为有效状态。
53.可选地，在上述的用户界面的测试装置中，所述信息匹配单元，包括：
54.查找单元，用于基于各个所述测试桩的运行状态，查找出所述目标测试场景对应的测试桩；
55.地址匹配单元，用于将所述当前网络请求的访问地址与所述目标测试场景对应的测试桩中的各个访问地址进行一致性匹配；
56.信息确定单元，用于在所述目标测试场景对应的测试桩中存在与所述当前网络请求的访问地址匹配成功的访问地址时，将匹配成功的所述访问地址所属的所述网络请求信息作为所述目标网络请求。
57.可选地，在上述的用户界面的测试装置中，还包括：
58.第二设置单元，用于在结束所述目标测试场景的用户界面测试后，将所述目标测试场景对应的测试桩的运行状态置为失效状态。
59.本技术第三方面提供了一种电子设备，包括：
60.存储器和处理器；
61.其中，所述存储器用于存储程序；
62.所述处理器用于执行所述程序，所述程序被执行时，具体用于实现如上述任意一
项所述的用户界面的测试方法。
63.本技术第四方面提供了一种计算机存储介质，用于存储计算机程序，所述计算机程序被执行时，用于实现如上述任意一项所述的用户界面的测试方法。
64.本技术提供的一种用户界面的测试方法，先捕获待测试应用的多条网络请求信息。其中，一条网络请求信息包括向服务器发送的一个网络请求中的数据以及服务器响应网络请求所反馈的数据。然后基于预先配置的白名单，从各条网络请求信息中过滤出目标测试场景下的所有网络请求信息，以能应对目标测试场景下的各个网络请求。接着基于目标测试场景下的所有网络请求信息，构建目标测试场景对应的测试桩，从而实现了测试桩的自动生成。在需要测试时，将目标测试场景对应的测试脚本与目标测试场景对应的测试桩关联，然后执行目标测试场景对应的测试脚本。每当接收到待测试应用发送的当前网络请求时，从目标测试场景对应的测试桩中的各条网络请求信息中，匹配出所包含的访问地址与当前网络请求的访问地址一致的目标网络请求信息，并将目标网络请求信息反馈给待测试应用，从而保证每次执行测试脚本时，都可以从测试桩中加载到一致的内容，保证测试脚本执行的成功率，不再需要人工维护测试桩，有效提高了测试的便捷性，也保证了测试的准确性。
附图说明
65.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
66.图1为本技术实施例提供的一种用户界面的测试方法的流程图；
67.图2为本技术实施例提供的一种捕获网络请求信息的方法的流程图；
68.图3为本技术实施例提供的一种构建目标测试场景对应的测试桩的方法的流程图；
69.图4为本技术另一实施例提供的另一种用户界面的测试方法的流程图；
70.图5为本技术另一实施例提供的一种用户界面的测试装置的结构示意图；
71.图6为本技术另一实施例提供的一种电子设备的结构示意图。
具体实施方式
72.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
73.在本技术中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。
在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
74.本技术实施例提供了一种用户界面的测试方法，如图1所示，包括：
75.s101、捕获待测试应用的多条网络请求信息。
76.其中，一条网络请求信息包括向服务器发送的一个网络请求中的数据以及服务器响应网络请求所反馈的数据。需要说明的是，一条网络请求信息可以值包括网络请求中的部分数据以及服务器反馈的数据中的一部分数据。可选地，一条网络请求信息可以至少包括访问地址，即网络请求的url、请求参数、请求方式、以及请求返回内容等。
77.其中，请求参数为请求的url的参数。具体对于请求参数的格式，get请求的请求参数为键值对格式，post请求则为json参数格式。请求方式则可以包括get和post方式。请求返回内容一般为json或者xml方式。
78.具体的，在待测试应用向服务器发送网络请求时，获取该网络请求中的所需要的数据以及在服务器响应该网络请求反馈的数据中所需的数据，并将捕获到的该网络请求的数据作为一条网络请求信息进行存储，后续可以用于构建测试桩。
79.可选地，在本技术另一实施例中，步骤s101的一种具体实施方式，如图2所示，包括：
80.s201、将开源库mitmproxy作为待测试应用的设备的网络代理。
81.在本技术实施例中，通过python语言的开源库mitmproxy来实现移动端设备的网络代理，从而通过该mitmproxy服务来捕获网络请求信息。mitmproxy服务启动后，移动设备绑定对应的端口，即可收集过滤网络请求的数据。
82.s202、开启网络代理服务，并清空已捕获的信息。
83.需要说明的是，在需要采集网络请求信息时，先开启网络代理服务。并且可以采用自动化的方式进行采集，所以此时可以启动自动化脚本。而为了避免本次捕获的网络请求信，与之前捕获的其他测试场景的网络请求的信息混淆，所以在本技术实施例中，先将数据库中之前采集的网络请求信息清空。然后就可以开启网络请求捕获的开关。
84.s203、通过网络代理服务捕获待测试应用向服务器发送的网络请求中的数据以及服务器响应网络请求所反馈的数据，得到一条网络请求信息。
85.具体的，在开启网络请求捕获的开关后，就可以进入自动化指定场景，即可以使用ui自动化测试工具模拟用户行为进入对应的ui页面，此时待测试应用将会向服务器发送网络请求，而服务器在收到网络请求后，会响应该网络请求并返回相应的数据，所以就可以捕获待测试应用向服务器发送的网络请求中的数据以及服务器响应网络请求所反馈的数据。
86.s102、基于预先配置的白名单，从各条网络请求信息中过滤出目标测试场景下的所有网络请求信息。
87.需要说明的是，由于部分网络请求是与待测试应用无关的，并且测试过程中是分别针对不同的测试场景的，所以在本技术实施例中，针对需要测试的目标测试场景，预先配置了相应的白名单，从而可以基于预先配置的白名单，从各条网络请求信息中过滤出目标测试场景下的所有网络请求信息。
88.还需要说明的是，为了保证目标测试场景的测试桩的数据是完整的，所以需要获取目标测试场景下的所有网络请求信息，若是当前捕获的网络请求信息还未能包括目标测
试场景下的所有网络请求，则可以继续进行捕获。当然，也可以是每捕获一个网络请求信息，则利用白名单对其进行过滤，直至得到目标测试场景下的所有网络请求信息。
89.s103、基于目标测试场景下的所有网络请求信息，构建目标测试场景对应的测试桩。
90.具体的，可以将目标测试场景下的所有网络请求信息进行汇总，并存储至指定的数据表中，构建出目标测试场景对应的测试桩。
91.可选地，在本技术另一实施例中，步骤s103的一种具体实施方式，如图3所示，包括：
92.s301、将目标测试场景下的所有网络请求信息存储至目标数据表中。
93.在本技术实施例中，对于筛选出的目标测试场景下的网络请求信息会存储一个数据库表中，ui自动化脚本执行端在查询到目标测试差昂家的网络请求信息列表后，可以加上目标测试场景对应的场景标识以及运行状态，并存入目标数据表中，以便与后续使用。
94.s302、在目标数据表中添加目标测试场景对应的场景标识以及运行状态，得到目标测试场景对应的测试桩。
95.其中，运行状态初始为失效状态。
96.需要说明的是，为了能使目标测试场景对应的测试桩与目标测试场景对应的测试脚本所关联，所以在本技术实施例中，会在测试桩中添加目标测试场景对应的场景标识，后续就可以根据场景标识进行关联。
97.而为了避免不同测试场景中的测试桩之间相互影响，所以在本技术实施例中，还为每个测试桩设置了运行状态。该运行状态初始为失效状态，而处于失效状态的测试桩不能被使用。只有在运行状态处于有效状态下，才可以被使用。
98.s104、将目标测试场景对应的测试脚本与目标测试场景对应的测试桩关联。
99.可选地，在采用如图3所示的方式实施步骤s103时，相应的，步骤s104的一种实施方式，具体可以为：
100.将目标测试场景对应的测试脚本的网络请求全部存取至指定数据库，并上传目标测试场景的场景标识至指定数据库中，以基于目标测试场景的场景标识，与目标测试场景对应的测试桩进行关联。
101.具体的，ui自动化脚本执行过程中针对需要打桩的场景，执行该场景前打开网络请求获取开关，即可把接下来执行的ui脚本信息的网络请求全部存取指定数据库，并上传场景标识，从而可以根据场景标识与其测试桩关联。
102.s105、执行目标测试场景对应的测试脚本。
103.s106、每当接收到待测试应用发送的当前网络请求时，从目标测试场景对应的测试桩中的各条网络请求信息中，匹配出所包含的访问地址与当前网络请求的访问地址一致的目标网络请求信息。
104.在测试过程中，待测试应用会发送网络请求，以能加载相应的内容进行界面展示，此时可以根据发送的当前网络请求的url，从测试桩匹配出具有相同url的网络请求信息，而该网络请求信息中包括了服务器反馈的数据，所以可以将其反馈给待测试应用，以供待测试应用展示界面。所以每次执行脚本时，都可以从测试桩中反馈一致的内容，从而可以有效保证测试脚本执行的成功率。
105.s107、将目标网络请求信息反馈给待测试应用。
106.本技术实施例提供了一种用户界面的测试方法，先捕获待测试应用的多条网络请求信息。其中，一条网络请求信息包括向服务器发送的一个网络请求中的数据以及服务器响应网络请求所反馈的数据。然后基于预先配置的白名单，从各条网络请求信息中过滤出目标测试场景下的所有网络请求信息，以能应对目标测试场景下的各个网络请求。接着基于目标测试场景下的所有网络请求信息，构建目标测试场景对应的测试桩，从而实现了测试桩的自动生成。在需要测试时，将目标测试场景对应的测试脚本与目标测试场景对应的测试桩关联，然后执行目标测试场景对应的测试脚本。每当接收到待测试应用发送的当前网络请求时，从目标测试场景对应的测试桩中的各条网络请求信息中，匹配出所包含的访问地址与当前网络请求的访问地址一致的目标网络请求信息，并将目标网络请求信息反馈给待测试应用，从而保证每次执行测试脚本时，都可以从测试桩中加载到一致的内容，保证测试脚本执行的成功率，不再需要人工维护测试桩，有效提高了测试的便捷性，也保证了测试的准确性。
107.本技术另一实施例提供了另一种用户界面的测试方法，如图4所示，包括：
108.s401、捕获待测试应用的多条网络请求信息。
109.其中，一条网络请求信息包括向服务器发送的一个网络请求中的数据以及服务器响应网络请求所反馈的数据。
110.s402、基于预先配置的白名单，从各条网络请求信息中过滤出目标测试场景下的所有网络请求信息。
111.需要说明的是，步骤s401和步骤s402的具体实施方式，可相应地参考上述方法实施中的步骤s101和步骤s102，此处不再赘述。
112.s403、将目标测试场景下的所有网络请求信息存储至目标数据表中。
113.s404、在目标数据表中添加目标测试场景对应的场景标识以及运行状态，得到目标测试场景对应的测试桩。
114.其中，运行状态初始为失效状态。
115.需要说明的是，需要说明的是，步骤s403和步骤s404的具体实施方式，可相应地参考上述方法实施中的步骤s301和步骤s302，此处不再赘述。
116.s405、将目标测试场景对应的测试脚本与目标测试场景对应的测试桩关联。
117.s406、将所有测试桩的运行状态初始化为失效状态。
118.需要说明的是，为了避免其他测试桩对当前测试场景的测试造成相应，所以在本技术实施例中，在正式开始测试时，先将所有测试桩的运行状态初始化为失效状态，以保证所有的测试桩都是出于失效状态，然后再执行步骤s407。
119.s407、将目标测试场景对应的测试桩的运行状态置为有效状态。
120.由于在步骤s406中已经所有测试桩的运行状态置为了失效状态，而在目标测试场景的测试过程中，需要用到目标测试场景对应的测试桩，所有需要将目标测试场景对应的测试桩的运行状态置为有效状态，从而可以保证只有目标测试场景对应的测试桩是有效的，其他测试桩处于无效状态，不会对测试过程造成影响。
121.s408、执行目标测试场景对应的测试脚本。
122.s409、每当接收到待测试应用发送的当前网络请求时，基于各个测试桩的运行状
态，查找出目标测试场景对应的测试桩。
123.需要说明的是，由于此时只有目标测试场景对应的测试桩为有效状态，所以可以直接获取运行状态为有效状态的测试桩，则可以得到目标测试场景对应的测试桩。
124.s410、将当前网络请求的访问地址与目标测试场景对应的测试桩中的各个访问地址进行一致性匹配。
125.s411、判断目标测试场景对应的测试桩中是否存在与当前网络请求的访问地址匹配成功的访问地址。
126.其中，若目标测试场景对应的测试桩中存在与当前网络请求的访问地址匹配成功的访问地址，则执行步骤s412。
127.可选地，若目标测试场景对应的测试桩中不存在与当前网络请求的访问地址匹配成功的访问地址，则说明该当前网络请求不处于白名单中，即不属于目标测试场景需要测试的网络请求，所以对于此时的当前网络请求可以走真实用户场景，即通过实际的服务器相应该当前网络请求，获取并反馈数据，不再通过测试桩获取数据。
128.s412、将匹配成功的访问地址所属的网络请求信息作为目标网络请求。
129.s413、将目标网络请求信息反馈给待测试应用。
130.s414、在结束目标测试场景的用户界面测试后，将目标测试场景对应的测试桩的运行状态置为失效状态。
131.由于此时已结束目标测试场景的用户界面测试，已经不需要在用到目标测试场景对应的测试桩，所以此时将其运行状态置为失效状态。
132.本技术另一实施例提供了一种用户界面的测试装置，如图5所示，包括：
133.信息捕获单元501，用于捕获待测试应用的多条网络请求信息。
134.其中，一条网络请求信息包括向服务器发送的一个网络请求中的数据以及服务器响应网络请求所反馈的数据。
135.过滤单元502，用于基于预先配置的白名单，从各条网络请求信息中过滤出目标测试场景下的所有网络请求信息。
136.测试桩构建单元503，用于基于目标测试场景下的所有网络请求信息，构建目标测试场景对应的测试桩。
137.关联单元504，用于将目标测试场景对应的测试脚本与目标测试场景对应的测试桩关联。
138.脚本执行单元505，用于执行目标测试场景对应的测试脚本。
139.信息匹配单元506，用于每当接收到待测试应用发送的当前网络请求时，从目标测试场景对应的测试桩中的各条网络请求信息中，匹配出所包含的访问地址与当前网络请求的访问地址一致的目标网络请求信息。
140.信息反馈单元507，用于将目标网络请求信息反馈给待测试应用。
141.可选地，在本技术另一实施例提供的用户界面的测试装置中，信息捕获单元，包括：
142.代理单元，用于将开源库mitmproxy作为待测试应用的设备的网络代理。
143.预处理单元，用于开启网络代理服务，并清空已捕获的信息。
144.采集单元，用于通过网络代理服务捕获待测试应用向服务器发送的网络请求中的
数据以及服务器响应网络请求所反馈的数据，得到一条网络请求信息。
145.可选地，在本技术另一实施例提供的用户界面的测试装置中，测试桩构建单元，包括：
146.存储单元，用于将目标测试场景下的所有网络请求信息存储至目标数据表中。
147.添加单元，用于在目标数据表中添加目标测试场景对应的场景标识以及运行状态，得到目标测试场景对应的测试桩。其中，运行状态初始为失效状态。
148.可选地，在本技术另一实施例提供的用户界面的测试装置中，关联单元，包括：
149.关联子单元，用于将目标测试场景对应的测试脚本的网络请求全部存取至指定数据库，并上传目标测试场景的场景标识至指定数据库中，以基于目标测试场景的场景标识，与目标测试场景对应的测试桩进行关联。
150.可选地，在本技术另一实施例提供的用户界面的测试装置中，还包括：
151.初始化单元，用于将所有测试桩的运行状态初始化为失效状态。
152.第一设置单元，用于将目标测试场景对应的测试桩的运行状态置为有效状态。
153.可选地，在上述的用户界面的测试装置中，信息匹配单元，包括：
154.查找单元，用于基于各个测试桩的运行状态，查找出目标测试场景对应的测试桩。
155.地址匹配单元，用于将当前网络请求的访问地址与目标测试场景对应的测试桩中的各个访问地址进行一致性匹配。
156.信息确定单元，用于在目标测试场景对应的测试桩中存在与当前网络请求的访问地址匹配成功的访问地址时，将匹配成功的访问地址所属的网络请求信息作为目标网络请求。
157.可选地，在本技术另一实施例提供的用户界面的测试装置中，还包括：
158.第二设置单元，用于在结束目标测试场景的用户界面测试后，将目标测试场景对应的测试桩的运行状态置为失效状态。
159.需要说明的是，本技术上述实施例提供的各个单元的具体工作过程，可相应地参考上述方法实施例中的相应的步骤，此处不再赘述。
160.本技术另一实施例提供了一种电子设备，如图6所示，包括：
161.存储器601和处理器602。
162.其中，存储器601用于存储程序。
163.处理器602用于执行存储器601存储的程序，该程序被执行时，具体用于实现如上述任意一个实施例提供的用户界面的测试方法。
164.本技术另一实施例提供了一种计算机存储介质，用于存储计算机程序，该计算机程序被执行时，用于实现如上述任意一个实施例提供的用户界面的测试方法。
165.计算机存储介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机
可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
166.专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
167.对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本技术。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本技术的精神或范围的情况下，在其它实施例中实现。因此，本技术将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。