应用控件的测试方法、装置、电子设备及存储介质与流程

1.本发明涉及软件工程技术领域，具体而言，涉及一种应用控件的测试方法、装置、电子设备及存储介质。


背景技术：

2.随着信息化的迅速发展，电子应用快速交付压力迫使开发周期不断缩短，如何在保障效率的同时提升应用质量成为软件开发者普遍面临的问题。
3.现有的应用测试方法，基于众包测试或者自动化测试工具实现，由于众包测试中测试人员水平参差不齐，且测试过程主观性强，难以对测试流程进行复现。基于自动化测试工具实现的应用测试需要专业人员撰写测试脚本，且由于弹窗、回退等问题难以覆盖应用中的全部控件。因此，迫切需要一种控件覆盖广且能够实现自动化测试的应用测试方法。


技术实现要素：

4.本发明的目的在于，针对上述现有技术中的不足，提供一种应用控件的测试方法、装置、电子设备及存储介质，以便对目前应用控件测试方法进行优化。
5.为实现上述目的，本技术实施例采用的技术方案如下：第一方面，本技术实施例提供了一种应用控件的测试方法，所述方法包括：获得第一覆盖树信息和第二覆盖树信息，所述第一覆盖树信息表征经由自动测试产生的应用控件路径信息；所述第二覆盖树信息表征经由至少一个用户操作产生的应用控件路径信息；将所述第一覆盖树信息与所述第二覆盖树信息进行比较；当存在差异节点数据时，对所述第一覆盖树信息的每个所述差异节点数据进行搜索，直至获得全部所述差异节点数据对应的下游路径信息；其中，所述应用控件路径信息包括节点数据，所述差异节点数据为所述第一覆盖树信息与所述第二覆盖树信息一致，且对应的下游路径存在差异的节点数据；根据全部所述下游路径信息对所述第一覆盖树信息进行更新。
6.可选的，所述第一覆盖树信息和所述第二覆盖树信息采用树状拓扑结构生成，所述树状拓扑结构中节点为所述节点数据；所述将所述第一覆盖树信息与所述第二覆盖树信息进行比较的步骤，包括：当存在差异节点数据时，对所述第一覆盖树信息的每个差异节点数据进行搜索，直至获得全部所述差异节点数据对应的下游节点数据，及所述下游节点数据的至少一个节点顺序信息；所述差异节点数据为所述第一覆盖树信息与所述第二覆盖树信息一致，且对应的下游节点数据存在差异的节点；根据全部所述下游节点数据、节点顺序信息对所述第一覆盖树信息进行更新。
7.可选的，所述第一覆盖树信息的生成方法包括：生成第一覆盖树模型；
根据所述自动测试产生的所述应用控件路径信息，获取所述应用控件路径信息中的所述节点数据及节点顺序信息；根据所述节点数据及所述节点顺序信息，更新所述第一覆盖树模型，生成所述第一覆盖树。
8.可选的，所述自动测试产生所述应用控件路径信息的方法包括：获得第一应用界面上的应用控件信息；当所述第一应用界面中存在未激活的应用控件信息时，对所述每个未激活的应用控件信息进行激活，并获得所述应用控件路径信息，直至获得所述第一应用界面中全部应用控件信息对应的应用控件路径信息。
9.可选的，所述对所述每个未激活的应用控件信息进行激活，并获得所述应用控件路径信息的步骤，包括：若激活所述应用控件信息并进入第二应用界面时，获取所述第二应用界面上的应用控件信息；当所述第二应用界面中存在未激活的应用控件信息时，对所述每个未激活的应用控件信息进行激活，并获得所述应用控件路径信息，直至获得所述第二应用界面中全部应用控件信息对应的应用控件路径信息；返回所述第一应用界面，对所述第一应用界面中未激活的应用控件信息进行激活。
10.可选的，所述第二覆盖树信息的生成方法包括：采用预设格式处理由至少一个用户操作产生的所述应用控件路径信息；根据所述由至少一个用户操作产生的所述应用控件路径信息，获取所述应用控件路径信息中的所述节点数据和所述节点顺序信息；根据所述节点数据和所述节点顺序信息，生成所述第二覆盖树。
11.可选的，所述采用预设格式处理由至少一个用户操作产生的所述应用控件路径信息时，所述方法还包括：创建三元组，所述三元组中包括控件信息、行为信息、触发事件信息；获取所述至少一个用户操作产生的所述应用控件路径信息；根据所述应用控件路径信息，生成至少一个所述三元组；根据多个所述三元组中重复信息，对多个所述三元组进行融合，得到无重复的三元组操作列表，所述重复信息包括：重复的所述控件信息，和/或所述重复的控件信息对应的触发事件信息；所述三元组操作列表包括：多个三元组以及多个所述三元组之间的索引顺序；基于所述三元组操作列表获取所述应用控件路径信息。
12.第二方面，本技术实施例还提供了一种应用控件的测试装置，所述装置包括获取模块、比较模块、处理模块、更新模块；所述获取模块，具体用于获得第一覆盖树信息和第二覆盖树信息，所述第一覆盖树信息表征经由自动测试产生的应用控件路径信息；所述第二覆盖树信息表征经由至少一个用户操作产生的应用控件路径信息；所述比较模块，具体用于将所述第一覆盖树信息与所述第二覆盖树信息进行比
较；所述处理模块，具体用于当存在差异节点数据时，对所述第一覆盖树信息的每个所述差异节点数据进行搜索，直至获得全部所述差异节点数据对应的下游路径信息；其中，所述应用控件路径信息包括节点数据，所述差异节点数据为所述第一覆盖树信息与所述第二覆盖树信息一致，且对应的下游路径存在差异的节点数据；所述更新模块，具体用于根据全部所述下游路径信息对所述第一覆盖树信息进行更新。
13.第三方面，本技术实施例还提供了一种电子设备，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的程序指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述程序指令，以执行时执行如第一方面任一所述的应用控件的测试方法的步骤。
14.第四方面，本技术实施例还提供了一种计算机可读存储介质，所述存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如第一方面任一所述的应用控件的测试方法的步骤。
15.本技术的有益效果是：本技术提供了一种应用控件的测试方法，具体而言，该方法包括：获得第一覆盖树信息和第二覆盖树信息，通过对第一覆盖树信息与第二覆盖树信息进行对比，可以获知其中是否存在差异节点数据，当存在差异节点数据时，对第一覆盖树信息的每个差异节点数据进行搜索，直至获得全部差异节点数据对应的下游路径信息，最后，根据全部下游路径信息对第一覆盖树信息进行更新。在本技术的方法中，采用第二覆盖树信息，将用户操作引入自动测试生成的第一覆盖树信息中，由于第二覆盖树信息包括用户操作产生的应用控件路径信息，具有人类智慧；根据用户操作产生的应用控件路径信息对自动测试的应用控件路径信息进行更新，即利用具有人类知识的用户操作引导自动测试搜索到依据人类智慧才能达到的应用控件；在自动化测试本身高效的基础上，打破了自动测试固有的测试搜索策略，提高自动测试的测试效果，实现对更多应用控件路径信息的覆盖，打破了目前自动测试中覆盖率随时间增长基本持平的瓶颈，对发现更多的系统漏洞也有极大帮助。
16.在此基础上，还可以将更新后的第一覆盖树信息交由测试人员研究，测试人员通过对比更新后的第一覆盖树信息与应用源码，了解未被覆盖的应用控件路径信息，以便指导其后的用户操作方向，如此循环，可以使得第一覆盖树信息所包含的应用控件路径信息越来越完整，使得应用覆盖率不断提高。
附图说明
17.为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
18.图1为本技术一实施例提供的一种应用控件的测试方法的流程图；图2为本技术又一实施例提供的一种应用控件的测试方法中第一覆盖树信息与第二覆盖树信息比较方法的流程图；
图3为本技术另一实施例提供的一种应用控件的测试方法中第一覆盖树信息的生成方法的流程图；图4为本技术再一实施例提供的一种应用控件的测试方法中自动测试产生应用控件路径信息方法的流程图；图5为本技术再二实施例提供的一种应用控件的测试方法中对每个未激活的应用控件信息进行激活的流程图；图6为本技术一实施例提供的一种应用控件的测试方法效果示意图；图7为本技术再三实施例提供的一种应用控件的测试方法中第二覆盖树信息的生成方法的流程图；图8为本技术再三实施例提供的一种应用控件的测试方法中预设格式处理方法的流程图；图9为本技术一实施例提供的一种应用控件的测试装置的示意图；图10为本技术实施例提供的一种电子设备的示意图。
具体实施方式
19.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。
20.在本技术中，除非另有明确的规定和限定，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包含至少一个特征。在本发明中的描述中，“多个”的含义是至少两个，例如两个、三个，除非另有明确具体的限定。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。
21.随着信息化的迅速发展，应用快速交付的压力迫使开发周期不断缩短，如何在保障效率的同时提升应用质量，是应用开发人员普遍面临的问题。在使用中，用户不仅仅关注应用的各项基本功能，对于应用的性能、体验等其他各方面也越来越重视。一旦应用出错，用户对应用的评价也会随之降低，一方面，这可能导致用户使用量的不断下降；另一方面，而如果评价过低，应用甚至可能会被应用市场移除。因此，应用从开发到发布这一系列过程中的质量保障，就变得尤其重要。目前常用的质量测试方法主要有两种：众包测试和自动化测试。
22.众包测试，是由众多不同来源测试人员在不同的应用平台下进行的人工测试。由于其测试的应用平台不同意，环境多样，这种测试方法的测试结果往往更加可靠、经济、高效、快速。但是众包测试中测试人员在进行测试时，通常需要进行大量的重复性工作来达到回归测试的目的。此外，由于测试中测试人员的主观性较强，每一次测试中很难完美地对重复性的工作进行重现。同时，测试的准确性也极度依赖于测试人员本身的知识水平，如果测
试人员的水平不足，很有可能由于提交测试结果存在的缺陷，导致复现难以成功。
23.为了减少应用测试的成本、优化执行效率，应用开发人员还可以使用自动化测试框架和自动化测试工具完成测试工作。
24.自动化测试框架，是指由专业技术人员编写一份能够借由框架进行重复性执行的脚本。一旦应用出现改动需要进行回归测试时，只需对脚本进行少量的修改就能完美复现测试流程。这样的脚本虽然编写起来需要一定的知识与时间，而且会根据编写者水平的高低达到不同的效果，但是编写完成偶，就能够保证编写内容的完美复现。目前工业界的众多测试平台中，大多偏向于使用自动化测试框架来进行自动化测试。众多测试平台中，用户可以通过添加自动化测试脚本在不同的平台上进行测试，这些脚本可由用户自行添加，也可由技术人员协助编写。
25.自动化测试工具，是一种无需人工操作，也无需编写自动化测试脚本就可以全自动的对应用进行遍历的测试工具，例如monkey。这种测试方式通过较高的应用覆盖率，即通过对应用内容的大面积覆盖，来触发应用中可能出现的系统漏洞（bug），并在结果中记录系统漏洞，交由测试人员复现与修改。从2011年开始，学术界就出现许多关于自动化测试工具的研究，如dynodroid，sapienz，puma，evodroid，stoat，a3e等等。这些自动化测试工具确实可以对应用控件做到事无巨细的覆盖，只要到达了新的页面，该页面上的控件一定能够完全被记录下来。但是，由于弹窗问题、回退问题、控件组合型问题等特殊问题的产生，自动化测试工具即使能够发现大部分的控件，但是却很难覆盖实际应用使用情况下的全部控件。近年来已有的相关研究，大多只是解决众多自动化工具问题中的一种，提出对以往工具的一些小的改进。这些工具的论文中所做出的对照性实验，也通常只关注于自己工具的覆盖率相较于其他的工具是否有所提升。但是从宏观上来看，相较众包测试所能达到的覆盖率，自动化测试工具能达到的覆盖率依旧相差甚远。同时，大部分工具的测试流程往往是一次性的，在一次测试流程中，自动化测试工具对于被发现但由于各种问题无法覆盖到的控件以及分支路径，无法重复式利用，来增强自己的覆盖率。
26.根据上述分析，众包测试中，测试人员测试水平参差不齐，可能导致重要的用户操作流程无法复现。而自动化测试工具虽然提高测试效率但是由于缺乏人类知识，收到固有策略的影响，在测试实际效果上远远不如人工测试。针对这些问题，本技术实施例提供了多种应用控件测试的实现方式。如下结合附图通过多个示例进行解释说明。
27.图1为本技术一实施例提供的一种应用控件的测试方法的流程图，该应用控件的测试方法可由运行有上述程序的电子设备实现，该电子设备例如可以为终端设备，也可以为服务器。如图1所示，该方法包括：步骤101：获得第一覆盖树信息和第二覆盖树信息，第一覆盖树信息表征经由自动测试产生的应用控件路径信息；第二覆盖树信息表征经由至少一个用户操作产生的应用控件路径信息。
28.需要说明的是，获取的第一覆盖树信息和第二覆盖树信息表征应用控件路径信息，该应用控件路径信息可以包括以下一类或多类信息：控件名、控件类型、控件激活方式、控件对应的触发事件等，本技术对应用控件路径信息所包含的具体内容不做限定，只要其能够表征每个控件信息、及每个控件对应的触发事件信息即可。根据应用控件路径信息获取方式的不同，得到自动测试产生的第一覆盖树信息和经由至少一个用户操作产生的第二
覆盖树信息。
29.步骤102：将第一覆盖树信息与第二覆盖树信息进行比较。
30.比较第一覆盖树信息和第二覆盖树信息，通常情况下，由于第二覆盖树信息是由用户操作产生的，是包含人类智慧的交互信息，相较自动测试产生的第一覆盖树信息而言，往往包含更多的应用控件路径信息。因此，通过比较第一覆盖树信息和第二覆盖树信息，可以提取两个覆盖树信息中有差异的节点数据。
31.步骤103：当存在差异节点数据时，对第一覆盖树信息的每个差异节点数据进行搜索，直至获得全部差异节点数据对应的下游路径信息；其中，应用控件路径信息包括节点数据，差异节点数据为第一覆盖树信息与第二覆盖树信息一致，且对应的下游路径存在差异的节点数据。
32.通过步骤102中的比较，若第一覆盖树与第二覆盖树中存在差异节点数据时，对第一覆盖树信息中每个差异节点数据进行搜索。在一种可能的实现方式中，对差异节点数据的搜索可以采用遍历的搜索，例如使用for
…
in、for
…
of、filter()，map()，some()，every()等遍历方式，本技术对此不做限定，只要其能够搜索获取所有差异节点数据对应的下游路径信息即可。
33.在一种可能的实现方式中，当存在差异节点数据时，可以依据第二覆盖树的差异节点数据对应的应用控件路径信息复现更新第一覆盖树信息，直到差异节点数据被第一覆盖树信息完全覆盖为止。在另一种可能的实现方式中，当存在差异节点数据时，除了单纯依据第二覆盖树的差异节点数据对应的应用控件路径信息之外，还可以对差异节点数据对应的其他应用控件路径信息进行搜索，从而避免由于用户操作数据不足导致的应用控件路径信息的遗漏。上述仅为示例说明，在实际实现中，对差异节点数据的搜索还可以有其他形式，本技术对此不做限定。
34.在一种具体的实现方式中，对是否存在差异节点数据进行判断，若判断结果为“是”，则表示第一覆盖树信息未包括第二覆盖树信息中的全部应用控件信息，则从第一覆盖树信息中找到差异节点数据，差异节点数据表示该数据在第二覆盖树信息中存在，但是第一覆盖树信息中没有该节点数据的下游路径信息。确认节点数据后，对每个节点数据的下游路径进行搜索，并将搜索结果与第二覆盖树信息进行比较，若还存在差异节点数据，则继续搜索，直到不存在差异节点数据，即获得全部差异节点数据对应的下游路径信息为止。对是否存在差异节点数据进行判断，若判断结果为“否”，则表示第一覆盖树信息已包括第二覆盖树信息中的全部应用控件信息，搜索结束。
35.在另一种具体的实现方式中，还可以通过修改第一覆盖树自动化测试（例如appium相关运行类进行修改、插桩以及重新打包等），当人工编写的具有人类知识的自动化测试脚本执行时，自动捕获相关控件信息以及页面信息，从而获得差异节点数据对应的下游路径信息。
36.步骤104：根据全部下游路径信息对第一覆盖树信息进行更新。
37.根据获取的全部下游路径信息对第一覆盖树信息进行更新。更新后的第一覆盖树信息既包括自动测试产生的应用控件路径信息，还包括用户操作产生的应用控件路径信息。
38.需要说明的是，在步骤103搜索完成后，第一覆盖树信息还可能包括比第二覆盖树
信息更多的应用控件路径信息，这是因为确定差异节点数据后，第一覆盖树信息在针对差异节点数据进行搜索时，并不完全依赖于用户操作的具体流程信息，因此，可能获取到用户操作中不包含的应用控件路径信息。因此，对更新后第一覆盖树信息与第二覆盖树信息所包含应用控件路径信息可能存在的信息量差异，本技术对此不做限定，只要第一覆盖树信息中包括第二覆盖树信息的全部信息即可。由此，上述步骤103停止搜索的条件为：第一覆盖树信息中包括第二覆盖树信息的全部信息时停止，反之不成立。
39.综上，本技术实施例提供一种应用控件的测试方法，具体而言，该方法包括：获得第一覆盖树信息和第二覆盖树信息，通过对第一覆盖树信息与第二覆盖树信息进行对比，可以获知其中是否存在差异节点数据，当存在差异节点数据时，对第一覆盖树信息的每个差异节点数据进行搜索，直至获得全部差异节点数据对应的下游路径信息，最后，根据全部下游路径信息对第一覆盖树信息进行更新。在本技术的方法中，采用第二覆盖树信息，将用户操作引入自动测试生成的第一覆盖树信息中，由于第二覆盖树信息包括用户操作产生的应用控件路径信息，具有人类智慧；根据用户操作产生的应用控件路径信息对自动测试的应用控件路径信息进行更新，即利用具有人类知识的用户操作引导自动测试搜索到依据人类智慧才能达到的应用控件；在自动化测试本身高效的基础上，打破了自动测试固有的测试搜索策略，提高自动测试的测试效果，实现对更多应用控件路径信息的覆盖，打破了目前自动测试中覆盖率随时间增长基本持平的瓶颈，对发现更多的系统漏洞也有极大帮助。
40.在此基础上，还可以将更新后的第一覆盖树信息交由测试人员研究，测试人员通过对比更新后的第一覆盖树信息与应用源码，了解未被覆盖的应用控件路径信息，以便指导其后的用户操作方向，如此循环，可以使得第一覆盖树信息所包含的应用控件路径信息越来越完整，使得应用覆盖率不断提高。
41.可选的，在上述图1的基础上，第一覆盖树信息和第二覆盖树信息采用树状拓扑结构生成，树状拓扑结构中节点为节点数据；本技术还提供一种应用控件的测试方法中将第一覆盖树信息与第二覆盖树信息进行比较的可能实现方式，图2为本技术又一实施例提供的一种应用控件的测试方法中第一覆盖树信息与第二覆盖树信息比较方法的流程图；如图2所示，该方法包括：步骤201：当存在差异节点时，对第一覆盖树信息的每个差异节点数据进行搜索，直至获得全部差异节点数据对应的下游节点数据，及下游节点数据的至少一个节点顺序信息；差异节点数据为第一覆盖树信息与第二覆盖树信息一致，且对应的下游节点数据存在差异的节点。
42.需要说明的是，可以用树状拓扑结构生成第一覆盖树信息与第二覆盖树信息，在一种可能的实现方式中，节点数据包括控件操作信息、控件信息、触发事件信息等，根据实际需要，可以选择节点数据中具体某信息作为节点，例如可以将应用控件路径信息中的控件操作信息作为叶子节点，按照顺序将控件操作信息形成一个覆盖树信息。本技术对该树状拓扑结构具体的节点内容不做限定。
43.若第一覆盖树与第二覆盖树中存在差异节点数据时，对第一覆盖树信息中每个差异节点数据进行搜索。在一种可能的实现方式中，对差异节点数据的搜索可以采用遍历的搜索，例如使用树的前中后遍历、广度优先搜索、深度优先搜索、树的层次遍历等遍历方式，本技术对此不做限定，只要其能够搜索获取所有差异节点数据对应的下游节点数据，及下
游节点数据的至少一个节点顺序信息即可。
44.在一种可能的实现方式中，当存在差异节点数据时，可以依据第二覆盖树的差异节点数据及对应的至少一个节点顺序信息复现更新第一覆盖树信息，直到差异节点数据被第一覆盖树信息完全覆盖为止。在另一种可能的实现方式中，当存在差异节点数据时，除了单纯依据第二覆盖树的差异节点数据及至少一个节点顺序信息之外，还可以对差异节点数据对应的节点进行搜索，从而避免由于用户操作数据不足导致的节点的遗漏。上述仅为示例说明，在实际实现中，对差异节点数据的搜索还可以有其他形式，本技术对此不做限定。
45.在一种具体的实现方式中，对是否存在差异节点数据进行判断，若判断结果为“是”，则表示第一覆盖树信息未包括第二覆盖树信息中的全部节点，则从第一覆盖树信息中找到差异节点数据，差异节点数据表示该数据在第二覆盖树信息中存在，但是第一覆盖树信息中没有该节点的下游节点数据。确认差异节点数据后，对每个差异节点数据的下游路径进行搜索，并将搜索结果与第二覆盖树信息进行比较，若还存在差异节点数据，则继续搜索，直到不存在差异节点数据，即获得全部差异节点数据对应的下游节点数据为止。对是否存在差异节点数据进行判断，若判断结果为“否”，则表示第一覆盖树信息已包括第二覆盖树信息中的全部节点，搜索结束。
46.步骤202：根据全部下游节点数据、节点顺序信息对第一覆盖树信息进行更新。
47.根据获取的全部下游节点数据对第一覆盖树信息进行更新。更新后的第一覆盖树信息既包括自动测试产生的节点，还包括用户操作产生的节点。
48.基于树状拓扑结构生成第一覆盖树信息和第二覆盖树信息，结构简单，维护方便且易于扩展。
49.可选的，在上述图2的基础上，本技术还提供一种应用控件的测试方法中第一覆盖树信息的生成方法的可能实现方式，图3为本技术另一实施例提供的一种应用控件的测试方法中第一覆盖树信息的生成方法的流程图；如图3所示，该方法包括：步骤301：生成第一覆盖树模型。
50.需要说明的是，第一覆盖树模型可以为空白模型，为第一覆盖树的生成提供生成控件；第一覆盖树模型也可以是包含生成模板的空白内容模型，即该模型中包括模型搭建的具体结构信息及相关参数。上述仅为示例说明，在实际实现中，第一覆盖树模型还可以有其他形式，例如第一覆盖树模型还可以为历次测试后生成的第一覆盖树，本技术对此不做限定。
51.步骤302：根据自动测试产生的应用控件路径信息，获取应用控件路径信息中的节点数据及节点顺序信息。
52.在一种可能的实现方式中，自动测试产生的路径信息中包括节点数据和节点的顺序信息，其中，节点的顺序信息可以表示相邻两节点的发生顺序，例如，触发节点a后可能出现节点b、节点c、节点d，则节点顺序信息表示节点a与节点b、节点c、节点d之间的发生顺序，可以记录为a-b，a-c、a-d，在树状拓扑结构的具象化表示中，节点的顺序信息可以表示为两节点之间的连接关系。上述仅为示例说明，节点顺序的记录方式以及获取方式，本技术对此不做限定。
53.步骤303：根据节点数据及节点顺序信息，更新第一覆盖树模型，生成第一覆盖树。
54.根据获取的节点及节点顺序信息，对第一覆盖树模型进行更新，例如，可以根据现
有节点的新增节点顺序信息，将该现有节点进行延伸，并根据该节点顺序对应的延伸方向的节点，向第一覆盖树模型中增加节点等，本技术对第一覆盖树模型的具体更新方式不做限定，更新完成后，得到第一覆盖树。
55.在一种具体的实现方式中，可以使用自动化测试的框架（例如安卓官方开发的uiautomator）进行第一覆盖树信息的生成。通过自动化测试的框架提供的一系列接口，对应用进行一系列的自动化测试操作，比如点击、滑动、键盘输入、触摸、长按，甚至断言方法等。同时，自动化测试的框架还可以将设备当前界面上的所有布局信息和控件信息以快照的方式进行存储。例如：控件id（resource-id）、控件文本（text）、控件所属类（class-name）、控件所属包（package-name）、控件描述信息（desc）等。通过这些属性，可以利用自动化测试的框架提供的应用程序接口对目标属性的控件或一系列控件进行定位、操作，进而生成第一覆盖树信息。上述仅为示例说明，在实际实现中，还可能有其他的第一覆盖树信息生成方式，本技术对此不做限定。在另一种具体的实现方式中，可以利用众包测试的用户测试结果进行第二覆盖树信息的生成。以上仅为示例说明，本技术对第一覆盖树信息和第二覆盖书信息的具体生成方式不做限定，能够获取符合使用需要的覆盖树信息即可。
56.通过上述步骤生成第一覆盖树，该第一覆盖树可以用来向自动测试工具或者自动测试框架描述待测应用已经被覆盖的控件结构。
57.可选的，在上述图3的基础上，本技术还提供一种应用控件的测试方法中自动测试产生应用控件路径信息的方法的可能实现方式，图4为本技术再一实施例提供的一种应用控件的测试方法中自动测试产生应用控件路径信息方法的流程图；如图4所示，该方法包括：步骤401：获得第一应用界面上的应用控件信息。
58.在一种可能的实现方式中，自动测试中在遍历一个页面时，首先记录下该页面的所有应用控件信息。
59.步骤402：当第一应用界面中存在未激活的应用控件信息时，对每个未激活的应用控件信息进行激活，并获得应用控件路径信息，直至获得第一应用界面中全部应用控件信息对应的应用控件路径信息。
60.在一种可能的实现方式中，当记录的第一应用界面中存在未激活的应用控件信息时，激活每一个控件，并记录激活控件后的触发事件等应用控件路径信息，自动化测试工具按照设定好的搜索方式（例如深度优先搜索、广度优先搜索等）完成对控件的覆盖，其中，一些复杂逻辑功能也可以将其看做是新的分支，从而获得第一应用界面中全部应用控件信息对应的应用控件路径信息。当完成搜索之后，记录下第一应用界面中全部应用控件信息对应的应用控件路径信息，之后可以根据记录内容生成第一覆盖树。
61.在一种具体的实现方式中，可以采用appium获取应用控件信息，appium是一款基于node.js的，开源的移动应用自动化测试框架。它不仅仅支持安卓，同样支持ios以及firefoxos的使用。正是这种跨平台性，使得appium在众多自动化测试框架中，能够获得众人的认可。appium可以获取到用户操作流中的应用控件信息，帮助系统轻易定位到每一个控件，从而在后续自动化流程中复现出相应的操作。
62.通过上述步骤获取第一界面中全部应用控件信息对应的应用控件路径信息，为第一覆盖树的生成提供数据基础。
63.可选的，在上述图4的基础上，本技术还提供一种应用控件的测试方法中对每个未激活的应用控件信息进行激活，并获得应用控件路径信息的可能实现方式，图5为本技术再二实施例提供的一种应用控件的测试方法中对每个未激活的应用控件信息进行激活的流程图；如图5所示，该方法包括：步骤501：若激活应用控件信息并进入第二应用界面时，获取第二应用界面上的应用控件信息。
64.在一种可能的实现方式中，第一界面上的应用控件信息在激活后可能会出现界面跳转的情况，即进入第二应用界面。若发生此类跳转，则记录第二应用界面上的所有应用控件信息。
65.步骤502：当第二应用界面中存在未激活的应用控件信息时，对每个未激活的应用控件信息进行激活，并获得应用控件路径信息，直至获得第二应用界面中全部应用控件信息对应的应用控件路径信息。
66.在一种可能的实现方式中，当记录的第二应用界面中存在未激活的应用控件信息时，激活每一个控件，并记录激活控件后的触发事件等应用控件路径信息，自动化测试工具按照设定好的搜索方式（例如深度优先搜索、广度优先搜索等）完成对控件的覆盖，其中，一些复杂逻辑功能也可以将其看做是新的分支，从而获得第二应用界面中全部应用控件信息对应的应用控件路径信息。
67.步骤503：返回第一应用界面，对第一应用界面中未激活的应用控件信息进行激活。
68.当完成搜索之后，返回上一应用界面，对上一应用界面中没有激活单额应用控件信息进行激活，即返回步骤402中，即实现了对节点的深度优先搜索。
69.在一种具体的实现方式中，可以通过多轮自动化测试实现对全部应用界面中应用控件信息的激活，图6为本技术一实施例提供的一种应用控件的测试方法效果示意图，如图6所示第一轮自动化测试执行完毕后，将本次执行过程得到的第一覆盖树（或称操作流）和第二覆盖树进行比对，找出第一覆盖树中仍未被覆盖的节点，在下一轮测试中优先进行覆盖，从而迭代式的进行下一轮测试，直到第二覆盖树所有节点被遍历完为止；对于上述界面中应用控件信息的激活方式，其仅以两个应用界面进行示例性说明，对于应用中存在更多的应用界面的情况，可以想见，对于从任意一个应用界面通过激活应用控件信息而触发进入另一个应用界面的情况，其控件的激活方式都可以采用上述实现方式予以实现。
70.可选的，在上述图2基础上，本技术还提供一种应用控件的测试方法中第二覆盖树信息的生成方法的可能实现方式，图7为本技术再三实施例提供的一种应用控件的测试方法中第二覆盖树信息的生成方法的流程图；如图7所示，该方法包括：步骤701：采用预设格式处理由至少一个用户操作产生的应用控件路径信息。
71.需要说明的是，用户操作产生的应用控件路径信息来自于用户通过众包测试等方式生成的测试报告，也就是说此类应用控件路径信息由于由于用户本身的应用环境、知识储备等问题存在不合格或者错误的问题，因此需要通过预设格式进行处理，以便于后续操作。除此之外，对于一些不合格或者错误的测试报告，还可以由审核测试人员进行处理，本技术对此不作限定。
72.步骤702：根据由至少一个用户操作产生的应用控件路径信息，获取应用控件路径信息中的节点和节点顺序信息。
73.根据处理后的应用控件路径信息，可以获取其中的节点和节点顺序信息。
74.步骤703：根据节点和节点顺序信息，生成第二覆盖树。
75.根据获取的节点和节点顺序信息，生成第二覆盖树。具体的根据节点和节点顺序信息生成第二覆盖树的方式与第一覆盖树的生成方式相同，本技术在此不再赘述。
76.可选的，在上述图7基础上，本技术还提供一种应用控件的测试方法中预设格式处理的可能实现方式，图8为本技术再三实施例提供的一种应用控件的测试方法中预设格式处理方法的流程图；如图8所示，该方法包括：步骤801：创建三元组，三元组中包括控件信息、行为信息、触发事件信息。
77.在一种具体的实现方式中，三元组可以为w = (widgetinfo, behavior, activities)，其中widgetinfo指的是控件信息(包含控件id,text,desc等)；behavior指的是行为信息，包括（包括click、input、slide等）；activities指的是触发事件信息（例如注册、登录等触发事件名或其他触发事件相关的信息）。上述仅为示例说明，在实际实现中，三元组的具体组成、结构、格式等可以根据实际测试需要进行设定，本技术对此不做限定。
78.需要说明的是，对于应用测试而言，应用控件信息覆盖的顺序远比其数量重要，一些应用控件可能需要进行一系列固定的操作才能够到达，因此除了需要记录每一个被覆盖的应用控件信息本身的情况外，还需要记录下被覆盖应用控件信息之间的相互关系，后续可以通过这一关系对相同或者相关信息进行整合。
79.步骤802：获取至少一个用户操作产生的应用控件路径信息。
80.需要说明的是，获取的应用控件路径信息中可以包括一组或多组控件信息、行为信息、触发事件信息。
81.步骤803：根据应用控件路径信息，生成至少一个三元组。
82.根据应用控件路径信息以及三元组的格式要求，生成至少一个三元组。
83.步骤804：根据多个三元组中重复信息，对多个三元组进行融合，得到无重复的三元组操作列表，重复信息包括：重复的控件信息，和/或重复的控件信息对应的触发事件信息；三元组操作列表包括：多个三元组以及多个三元组之间的索引顺序；在一种具体的实现方式中，首先将至少一个用户操作产生的应用控件路径信息以预设格式进行整理，形成格式化的拥有人类知识的数据格式，考虑到用户操作中不同的测试人员测试的用户操作流程存在重复性，需要去除其中重复的操作信息。
84.在一种可能的实现方式中，通过对多个三元组进行融合，生成能够让机器和人都可以读懂的第二覆盖树信息，例如，对于以下测试流程：测试用户点击“用户名栏”控件，输入用户名，点击了“密码栏”控件，输入密码，点击“登录”控件，这样一个操作流程就可以被简化为一个三元组w = (widgetinfo, behavior, activities)列表：list(w) = {w1(id控件信息(包含控件id,text,desc等), click, loginactivity)；w2(id控件信息，input(用户真实id), loginactivity)；w3(password控件信息, click, loginactivity)；w4(password控件信息, input(用户真实密码), loginactivity)；
w5(登陆控件信息, click, loginactivity)}由于用户的操作一定会接触到应用的控件，所以每一份用户操作流程都可以数据化为上述所述的 list(w)，而该列表之中的三元组之间的索引顺序，代表本次操作的应用控件信息的顺序，通常情况下，多条操作流之间有相互重叠的控件，因此需要将这些操作流进行融合，最终生成一个无重复控件操作信息的三元组操作列表，代表目前应用已经被覆盖到的控件以及activity状况。
85.步骤805：基于三元组操作列表获取应用控件路径信息。
86.基于上述获取的无重复的三元组操作列表，获取应用控件路径信息，以生成第二覆盖树信息。在一种可能的实现方式中，还可以将无重复的三元组操作列表进行第二覆盖树信息建模后上传到云端操作支持系统（operation support systems，oss）。
87.通过对用户操作信息的预设格式处理，实现了用户操作信息的规范化，方便后续人工阅读或者程序调用处理，节省操作时间，加快测试进程。
88.可选的，在测试完成后，输出本次测试在引入第二覆盖树信息后，对待测应用覆盖情况的第一覆盖树信息以供研究，还会输出本次测试的测试报告，本技术对此不做限定。
89.可选的，根据第一覆盖树信息中应用控件信息数量以及应用控件信息总数，可以计算第一覆盖树的覆盖率。
90.覆盖率=(至少被执行一次的应用控件信息数量/"应用控件信息总数)
×
100%；在一种具体的实现方式中，可以使用java代码的覆盖率计数工具（java code coverage，jacoco）实现对覆盖率的计算。jacoco是目前最为成熟的测试覆盖率获取工具，可以从整体覆盖率数值上对测试结果进行观察评价，可以包含六种尺度的覆盖率，分别是：指令覆盖率、分支覆盖率、圈复杂度、行覆盖率、方法覆盖率、类覆盖率。上述仅为示例说明，本技术对覆盖率的具体计算方式不做限定。
91.综上，本技术通过提取用户操作的操作流程信息，记录下来控件的顺序以及相关信息，以三元组的形式保存；然后将若干个有重复信息的三元组融合，去除重复的控件信息，最终形成一份无重复的三元组列表；将上述格式化融合得到的三元组列表引入到自动测试中来，从而引导自动测试深入探索，实现人机协同测试；将最终的应用控件信息覆盖结果反馈给测试人员，从而培训测试人员跨越复杂的交互信息形成新的用户操作流程，进而引导自动测试继续深入探索。通过以上步骤，本技术可以提取用户操作信息（例如众包测试中的用户操作信息），然后引导自动测试深度搜索，打破了自动测试固定的测试搜索策略。从而提高自动测试的测试效果。
92.下面通过一个完整的实施方式对本技术进行全局介绍：本实施方式选取运行自动化测试脚本模拟众包测试中的用户操作信息，由专业测试人员编写相关脚本通过框架可以重复性执行。一旦应用出现改动需要进行回归测试时，只需要对脚本进行少量的修改就能完美的对测试流程进行复现。然后记录控件覆盖信息以及控件之间的顺序流程，经过格式化融合形成一份用户操作流文件。自动化测试选择dfs简单遍历的方式，通过用户操作信息的引导，从而提高代码覆盖率以及控件覆盖率。
93.具体实验环境为：ubuntu 16.04，mysql 5.7数据库记录简短信息，文件信息则存储在阿里云oss内。运行内存16gb，jdk 1.8，node 8.12.0。
94.首先，通过appium运行自动化测试脚本代替众包测试的用户来获取用户操作信
息，然后以固定形式保存，一份用户操作信息最终形成一个三元组列表list(w)；其次，融合得到的多个三元组列表list(w)，去除其中相互重复的控件，将这些操作信息进行融合，最终生成一颗无重复控件操作信息的应用控件覆盖树，即第一覆盖树信息，这棵树代表了目前应用已经被覆盖到的控件以及activity情况；接着，根据第一覆盖树信息，引导自动化测试工具（自动化测试工具即为运行自动化测试脚本，以进行自动测试的工具）完成更多控件的覆盖，将activity作为一个节点，然后通过对比第二覆盖树信息，发现未覆盖的activity然后引导自动化测试工具覆盖人工发现的activity；自动化测试执行完成一轮测试后（即自主生成第一覆盖树信息后），获得一个最初的控件覆盖树（最初的第一覆盖树信息），然后通过用户操作信息发现的更多的交互行为，通过控件重定位继续深入探索。此外自动化测试工具并非完成一轮测试，挖掘一支activity即停止，而是不断迭代运行，直到将所有用户操作信息覆盖的控件被全部覆盖，即第一覆盖树信息中包括第二覆盖树信息的全部内容时完全测试。通过调查实际控件信息，由于控件重定位导致所有的控件没有遗漏，全部都被自动化测试工具所覆盖；最终将覆盖情况反馈给人工进行培训，从而继续挖掘更深的信息。
95.之后，当一份用户操作信息已经被自动化测试工具完全覆盖，也就是一棵第二覆盖树信息被全部覆盖，将自动化测试的覆盖结果反馈给人工进行培训。然后继续借用人工完成更加复杂的交互行为，即生成一颗更复杂的第二覆盖树信息，继续引导自动化测试工具探索；测试人员不断引入通过人类高级逻辑思维达到的页面activity，然后引导自动化测试工具深度搜索。引入人类知识从而打破了自动化测试工具固定的测试搜索策略，从而可以探索更多的activity完成更多控件以及代码的覆盖。因此可以打破自动化测试工具随着长时间增加，覆盖率基本持平的瓶颈。
96.下述对用以执行本技术所提供的应用控件的测试装置、电子设备及存储介质等进行说明，其具体的实现过程以及技术效果参见上述，下述不再赘述。
97.本技术实施例提供一种应用控件的测试装置的可能实现示例，能够执行上述实施例提供的应用控件的测试方法。图9为本技术一实施例提供的一种应用控件的测试装置的示意图。如图9所示，上述应用控件的测试装置100，包括：获取模块91、比较模块93、处理模块95、更新模块97；获取模块91，具体用于获得第一覆盖树信息和第二覆盖树信息，第一覆盖树信息表征经由自动测试产生的应用控件路径信息；第二覆盖树信息表征经由至少一个用户操作产生的应用控件路径信息；比较模块93，具体用于将第一覆盖树信息与第二覆盖树信息进行比较；处理模块95，具体用于当存在差异节点数据时，对第一覆盖树信息的每个差异节点数据进行搜索，直至获得全部差异节点数据对应的下游路径信息；其中，应用控件路径信息包括节点数据，差异节点数据为第一覆盖树信息与第二覆盖树信息一致，且对应的下游路径存在差异的节点数据；更新模块97，具体用于根据全部下游路径信息对第一覆盖树信息进行更新。
98.可选的，第一覆盖树信息和第二覆盖树信息采用树状拓扑结构生成，树状拓扑结
构中节点为节点数据；比较模块93，具体用于当存在差异节点数据时，对第一覆盖树信息的每个差异节点数据进行搜索，直至获得全部差异节点数据对应的下游节点数据，及下游节点数据的至少一个节点顺序信息；差异节点数据为第一覆盖树信息与第二覆盖树信息一致，且对应的下游节点数据存在差异的节点；更新模块97，具体用于根据全部下游节点数据、节点顺序信息对第一覆盖树信息进行更新。
99.可选的，上述应用控件的测试装置100，还包括：生成模块；生成模块，具体用于生成第一覆盖树模型；根据自动测试产生的应用控件路径信息，获取应用控件路径信息中的节点数据及节点顺序信息；根据节点数据及节点顺序信息，更新第一覆盖树模型，生成第一覆盖树。
100.可选的，生成模块，具体用于获得第一应用界面上的应用控件信息；当第一应用界面中存在未激活的应用控件信息时，对每个未激活的应用控件信息进行激活，并获得应用控件路径信息，直至获得第一应用界面中全部应用控件信息对应的应用控件路径信息。
101.可选的，生成模块，具体用于若激活应用控件信息并进入第二应用界面时，获取第二应用界面上的应用控件信息；当第二应用界面中存在未激活的应用控件信息时，对每个未激活的应用控件信息进行激活，并获得应用控件路径信息，直至获得第二应用界面中全部应用控件信息对应的应用控件路径信息；返回第一应用界面，对第一应用界面中未激活的应用控件信息进行激活。
102.可选的，生成模块，具体用于采用预设格式处理由至少一个用户操作产生的应用控件路径信息；根据由至少一个用户操作产生的应用控件路径信息，获取应用控件路径信息中的节点和节点顺序信息；根据节点和节点顺序信息，生成第二覆盖树。
103.可选的，生成模块，具体用于创建三元组，三元组中包括控件信息、行为信息、触发事件信息；获取至少一个用户操作产生的应用控件路径信息；根据应用控件路径信息，生成至少一个三元组；根据多个三元组中重复信息，对多个三元组进行融合，得到无重复的三元组操作列表，重复信息包括：重复的控件信息，和/或重复的控件信息对应的触发事件信息；三元组操作列表包括：多个三元组以及多个三元组之间的索引顺序；基于三元组操作列表获取应用控件路径信息。
104.上述装置用于执行前述实施例提供的方法，其实现原理和技术效果类似，在此不再赘述。
105.以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路（application specific integrated circuit，简称asic），或，一个或多个微处理器（digital singnal processor，简称dsp），或，一个或者多个现场可编程门阵列（field programmable gate array，简称fpga）等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器（central processing unit，简称cpu）或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统（system-on-a-chip，简称soc）的形式实现。
106.本技术实施例提供一种电子设备的可能实现示例，能够执行上述实施例提供的应用控件的测试方法。图10为本技术实施例提供的一种电子设备的示意图，该设备可以集成于终端设备或者终端设备的芯片，该终端可以是具备数据处理功能的计算设备。
107.该电子设备包括：处理器1001、存储介质1002和总线，存储介质存储有处理器可执行的程序指令，当控制设备运行时，处理器与存储介质之间通过总线通信，处理器执行程序指令，以执行时执行上述应用控件的测试方法的步骤。具体实现方式和技术效果类似，这里不再赘述。
108.本技术实施例提供一种计算机可读存储介质的可能实现示例，能够执行上述实施例提供的应用控件的测试方法，存储介质上存储有计算机程序，计算机程序被处理器运行时执行上述应用控件的测试方法的步骤。
109.存储在一个存储介质中的计算机程序，可以包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器（英文：processor）执行本发明各个实施例方法的部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器（英文：read-only memory，简称：rom）、随机存取存储器（英文：random access memory，简称：ram）、磁碟或者光盘等各种可以存储程序代码的介质。
110.在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
111.作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
112.另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
113.上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器（英文：processor）执行本发明各个实施例方法的部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器（英文：read-only memory，简称：rom）、随机存取存储器（英文：random access memory，简称：ram）、磁碟或者光盘等各种可以存储程序代码的介质。
114.以上仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以权利要求的保护范围为准。