一种模型构建方法及装置
技术领域
本公开涉及计算机技术领域,具体而言,涉及一种模型构建方法及装置。
背景技术
随着计算机技术的飞速发展,越来越多的应用程序涌入了人们的视野中来。业务人员根据用户各式各样的需求来开发应用程序,开发的应用程序通常会在多个平台上发布。
为了保证好应用程序的服务质量,需要对开发完成的应用程序进行软件测试,软件测试通常对应用程序内可操作的功能组件进行测试,还可以根据应用程序的测试结果生成应用程序的测试模型,通过测试模型能够更好的分析测试结果,进行后续的测试规划等。
发明内容
本公开实施例至少提供一种模型构建方法及装置。
第一方面,本公开实施例提供了一种模型构建方法,包括:
在针对目标应用程序的不同的软件测试过程结束后,分别获取目标应用程序与所述软件测试过程对应的至少两个测试模型;所述测试模型是通过对所述目标应用程序的软件测试过程进行测试建模得到的;所述测试模型中包含表征页面中功能组件集合的节点和表征页面操作的连接边;不同的所述软件测试过程的测试路径不同;
基于所述至少两个测试模型的模型结构信息,将所述至少两个测试模型进行并集处理得到融合模型;所述融合模型能够用于生成针对所述目标应用程序的新创建的软件测试过程中的测试路径。
一种可选的实施方式中,基于所述至少两个测试模型的模型结构信息,将所述至少两个测试模型进行并集处理得到融合模型,包括:
从所述至少两个测试模型中选择一测试模型作为基准模型;
将所述至少两个测试模型中除所述基准模型外的其它每个测试模型依次作为待融合测试模型,基于所述模型结构信息,将存在于待融合测试模型但不存在于所述基准模型中的节点和连接边添加到所述基准模型中;
将所有待融合测试模型遍历结束时更新的基准模型作为融合模型。
一种可选的实施方式中,所述将所述至少两个测试模型中除所述基准模型外的其它每个测试模型依次作为待融合测试模型,将存在于待融合测试模型但不存在于所述基准模型中的节点和连接边添加到所述基准模型中,包括:
遍历所述待融合测试模型中的每个节点,判断该节点是否存在于最新的基准模型中,若不存在,则将该节点添加到所述基准模型中;
在遍历完所述待融合测试模型中的节点后,遍历所述待融合测试模型中的每条连接边,判断该连接边是否存在于最新的基准模型中,若不存在,则将该连接边添加到所述基准模型中,直到遍历完所述待融合测试模型中的边。
一种可选的实施方式中,所述从所述至少两个测试模型中选择一测试模型作为基准模型,包括:
确定每个所述测试模型的节点数量,选取所述节点数量最大的测试模型作为所述基准模型;或者,
从所述至少两个测试模型中选择代码覆盖率最高的测试模型作为所述基准模型;或者,
从所述至少两个测试模型中选择测试时长最长的测试模型作为所述基准模型;或者,
从所述至少两个测试模型中随机选择一个测试模型作为所述基准模型。
一种可选的实施方式中,所述方法还包括:
在获取到新的测试模型后,基于所述新的测试模型和所述融合模型的模型结构信息,将所述新的测试模型和所述融合模型进行并集处理得到更新后的融合模型。
第二方面,本公开实施例还提供一种模型构建装置,包括:
获取模块,用于在针对目标应用程序的不同的软件测试过程结束后,分别获取目标应用程序与所述软件测试过程对应的至少两个测试模型;所述测试模型是通过对所述目标应用程序的软件测试过程进行测试建模得到的;所述测试模型中包含表征页面中功能组件集合的节点和表征页面操作的连接边;不同的所述软件测试过程的测试路径不同;
融合模块,用于基于所述至少两个测试模型的模型结构信息,将所述至少两个测试模型并集处理得到融合模型;所述融合模型能够用于生成针对所述目标应用程序的新创建的软件测试过程中的测试路径。
一种可选的实施方式中,所述融合模块具体用于:
从所述至少两个测试模型中选择一测试模型作为基准模型;
将所述至少两个测试模型中除所述基准模型外的其它每个测试模型依次作为待融合测试模型,基于所述模型结构信息,将存在于待融合测试模型但不存在于所述基准模型中的节点和连接边添加到所述基准模型中;
将所有待融合测试模型遍历结束时更新的基准模型作为融合模型。
一种可选的实施方式中,所述融合模块在将所述至少两个测试模型中除所述基准模型外的其它每个测试模型依次作为待融合测试模型,将存在于待融合测试模型但不存在于所述基准模型中的节点和连接边添加到所述基准模型中时,具体用于:
遍历所述待融合测试模型中的每个节点,判断该节点是否存在于最新的基准模型中,若不存在,则将该节点添加到所述基准模型中;
在遍历完所述待融合测试模型中的节点后,遍历所述待融合测试模型中的每条连接边,判断该连接边是否存在于最新的基准模型中,若不存在,则将该连接边添加到所述基准模型中,直到遍历完所述待融合测试模型中的边。
一种可选的实施方式中,所述融合模块在从所述至少两个测试模型中选择一测试模型作为基准模型时,具体用于:
确定每个所述测试模型的节点数量,选取所述节点数量最大的测试模型作为所述基准模型;或者,
从所述至少两个测试模型中选择代码覆盖率最高的测试模型作为所述基准模型;或者,
从所述至少两个测试模型中选择测试时长最长的测试模型作为所述基准模型;或者,
从所述至少两个测试模型中随机选择一个测试模型作为所述基准模型。
一种可选的实施方式中,所述融合模块还用于:
在获取到新的测试模型后,基于所述新的测试模型和所述融合模型的模型结构信息,将所述新的测试模型和所述融合模型进行并集处理得到更新后的融合模型。
第三方面,本公开实施例还提供一种计算机设备,包括:处理器、存储器和总线,所述存储器存储有所述处理器可执行的机器可读指令,当计算机设备运行时,所述处理器与所述存储器之间通过总线通信,所述机器可读指令被所述处理器执行时执行上述第一方面,或第一方面中任一种可能的实施方式中的步骤。
第四方面,本公开实施例还提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行上述第一方面,或第一方面中任一种可能的实施方式中的步骤。
关于上述模型构建装置、计算机设备、及计算机可读存储介质的效果描述参见上述模型构建方法的说明,这里不再赘述。
本公开实施例提供的模型构建的方法及装置,能够基于测试模型的模型结构信息,将目标应用程序在不同的软件测试过程对应的测试模型融合,使不同测试中的测试信息结合到一起,建立更加完整的融合后的测试模型,这样得到的测试模型的测试覆盖率更高,方便进行后续的测试分析及测试优化,比如,可以基于融合后的测试模型生成目标应用程序的测试路径,省去计算生成测试路径的时间,进而提高软件测试的效率。
为使本公开的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
附图说明
为了更清楚地说明本公开实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,此处的附图被并入说明书中并构成本说明书中的一部分,这些附图示出了符合本公开的实施例,并与说明书一起用于说明本公开的技术方案。应当理解,以下附图仅示出了本公开的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
图1示出了本公开实施例所提供的一种模型构建方法的流程图;
图2a示出了本公开实施例所提供的一种模型构建方法中,测试模型Ⅰ的示意图;
图2b示出了本公开实施例所提供的一种模型构建方法中,测试模型Ⅱ的示意图;
图3示出了本公开实施例所提供的一种模型构建方法中,融合模型的示意图;
图4示出了本公开实施例所提供的一种模型构建装置的示意图;
图5示出了本公开实施例所提供的一种计算机设备的示意图。
具体实施方式
为使本公开实施例的目的、技术方案和优点更加清楚,下面将结合本公开实施例中附图,对本公开实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本公开一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围,而是仅仅表示本公开的选定实施例。基于本公开的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本公开保护的范围。
经研究发现,在现有的软件测试过程中,建立的测试模型通常仅用于当次测试,寻找出现错误的功能组件;并且,在测试的过程中,由于应用程序的可操作性功能组件数量庞大,无法对每个功能组件的每个操作进行测试,软件测试的局限较多,而测试路径也只能按照预设的简单算法进行,无法对应用程序进行有效的测试。
基于上述研究,本公开提供了一种模型构建方法,能够基于测试模型的模型结构信息,将目标应用程序在不同次测试下的测试模型融合,使多次测试中的测试信息结合到一起,使关于目标应用程序的测试模型更为完整,便于对测试结果进行研究与分析,融合模型能够反映多次测试的测试结果,测试的功能组件及操作较多,测试覆盖率高。
针对以上方案所存在的缺陷,均是发明人在经过实践并仔细研究后得出的结果,因此,上述问题的发现过程以及下文中本公开针对上述问题所提出的解决方案,都应该是发明人在本公开过程中对本公开做出的贡献。
应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。
为便于对本实施例进行理解,首先对本公开实施例所公开的一种模型构建方法进行详细介绍,本公开实施例所提供的模型构建方法的执行主体一般为具有一定计算能力的计算机设备,该计算机设备例如包括:终端设备或服务器或其它处理设备,终端设备可以为用户设备(User Equipment,UE)、移动设备、用户终端、终端、蜂窝电话、无绳电话、个人数字处理(Personal Digital Assistant,PDA)、手持设备、计算设备、车载设备、可穿戴设备等。在一些可能的实现方式中,该模型构建方法可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。
下面以执行主体为终端设备为例对本公开实施例提供的模型构建方法加以说明。
参见图1所示,为本公开实施例提供的模型构建方法的流程图,所述方法包括步骤S101~S102,其中:
S101:在针对目标应用程序的不同的软件测试过程结束后,分别获取目标应用程序与所述软件测试过程对应的至少两个测试模型;所述测试模型是通过对所述目标应用程序的软件测试过程进行测试建模得到的;所述测试模型中包含表征页面中功能组件集合的节点和表征页面操作的连接边;不同的所述软件测试过程的测试路径不同。
在软件测试的过程中,测试客户端可以对目标应用程序中的功能组件进行遍历,按照一定的操作路径(即测试路径),执行功能组件对应的操作,实现对应用程序的测试,在进行测试的同时,测试客户端可以将一个页面中的功能组件进行聚合,生成表征页面中功能组件集合的节点,再根据该页面上执行的页面操作,生成表征页面操作的连接边,每当测试客户端访问了一个页面,即生成该页面对应的节点与连接边,测试模型随测试进行内容不断增加。这里,测试模型能够通过节点与连接边,反映各个测试页面的状态信息以及状态迁移信息。
示例性的,可以通过安卓***底层提供的接口,提取出页面对应的树状结构,该树状结构有页面中可操作性以及不可操作的功能组件组成,再讲页面的树状结构抽象成为节点。
这里,页面中的功能组件可以为页面中的图形用户控件,这些在图形用户控件上可以实现一种或多种的操作,可以通过这些操作实现功能组件的各种功能,跳转至其他页面。
比如,若测试过程中,对页面a中的控件x做出了操作y,跳转至了页面b,则测试模型中即可包括表征页面a中的功能组件集合的节点A,与表征页面b的功能组件集合的节点B,连接两个节点的连接边ab表征操作y,这里,连接边ab的方向为从节点A指向节点B。
该步骤中,在针对目标应用程序的软件测试过程结束后,即可获取与该软件测试过程对应的测试模型。由于不同的软件测试过程的测试路径不同,基于测试得到的测试模型也不同。
其中,所述连接边具有连接方向,所述连接方向用于指示对应的页面操作关联的两个节点之间的逻辑关系。
该步骤中,每进行测试一个页面,即生成该页面对应的节点,按照测试顺序,逐一生成多个节点,及其对应的连接边,若跳转的目的节点已经存在,则直接生成当前节点与目的节点之间的连接边。
这里,连接边表示从当前节点跳转到目的节点所执行的操作,连接边的方向可以是从当前节点指向目的节点,表示由当前节点跳转至目的节点。
S102:基于所述至少两个测试模型的模型结构信息,将所述至少两个测试模型进行并集处理得到融合模型;所述融合模型能够用于生成针对所述目标应用程序的新创建的软件测试过程中的测试路径。
该步骤中,可以对比测试模型的模型结构信息,确定至少两个测试模型之间节点与连接边的异同,并将至少两个测试模型进行并集处理,得到融合模型。
在融合模型中,同时包含了上述至少两个测试模型节点的连接关系,由于测试模型中包含了测试中各个页面的状态信息及状态迁移信息,融合模型则同时包含了上述至少两个测试模型对应的测试中目标应用程序各个页面的状态信息及迁移信息。
这样,通过对至少两个测试模型的融合,使得融合模型具有至少两次测试的信息,使测试模型更为完整,测试覆盖率高。
融合模型可以用于生成目标应用程序在新创建的软件测试过程中的测试路径,其中,新创建的软件测试过程可以指当前尚未进行的软件测试过程,由于融合模型中包含了多次软件测试的测试路径,因此,可以直接从融合模型中提取出可行的测试路径,并应用于新创建的软件测试过程中,进行测试,不需要通过寻路算法来生成测试路径,从而将用来计算测试路径的时间来进行测试,能够有效提高软件测试的效率。
本公开实施例提供的模型构建的方法,能够基于测试模型的模型结构信息,将目标应用程序在不同的软件测试过程对应的测试模型融合,使不同测试中的测试信息结合到一起,建立更加完整的融合后的测试模型,这样得到的测试模型的测试覆盖率更高,方便进行后续的测试分析及测试优化,比如,可以基于融合后的测试模型生成目标应用程序的测试路径,生成的测试路径具有更好的路径深度,能够省去计算生成测试路径的时间,进而提高软件测试的效率。
在一种可能的实施方式中,基于所述至少两个测试模型的模型结构信息,将所述至少两个测试模型进行并集处理得到融合模型,包括:
从所述至少两个测试模型中选择一测试模型作为基准模型;
将所述至少两个测试模型中除所述基准模型外的其它每个测试模型依次作为待融合测试模型,基于所述模型结构信息,将存在于待融合测试模型但不存在于所述基准模型中的节点和连接边添加到所述基准模型中;
将所有待融合测试模型遍历结束时更新的基准模型作为融合模型。
该步骤中,可以先从上述至少两个测试模型中选取出一测试模型作为基准模型,选取的方式可以是随机的,也可以是按照测试模型中节点的数量选取的。
在一种可能的实施方式中,所述从所述至少两个测试模型中选择一测试模型作为基准模型,包括:
确定每个所述测试模型的节点数量,选取所述节点数量最大的测试模型作为所述基准模型;或者,
从所述至少两个测试模型中选择代码覆盖率最高的测试模型作为所述基准模型;或者,
从所述至少两个测试模型中选择测试时长最长的测试模型作为所述基准模型;或者,
从所述至少两个测试模型中随机选择一个测试模型作为所述基准模型。
该步骤中,通过选取节点数量最大的测试模型作为基准模型,能够减少在基准模型中生成的节点的数量,进而提高得到融合模型的效率。相似的,代码覆盖率最高的测试模型与测试时长最长的测试模型也同样具有更多的节点,同样能够提高生成融合模型的效率。
在确定了基准模型后,可以针对上述至少两个测试模型中,除基准模型之外的其他每个待融合测试模型,确定出每个测试模型中,每个节点以及每个连接边是否存在于基准模型中,若不存在则将其添加至基准模型中,对基准模型进行更新,直到上述至少两个测试模型融合完成。
在一种可能的实施方式中,所述将所述至少两个测试模型中除所述基准模型外的其它每个测试模型依次作为待融合测试模型,将存在于待融合测试模型但不存在于所述基准模型中的节点和连接边添加到所述基准模型中,包括:
遍历所述待融合测试模型中的每个节点,判断该节点是否存在于最新的基准模型中,若不存在,则将该节点添加到所述基准模型中;
在遍历完所述待融合测试模型中的节点后,遍历所述待融合测试模型中的每条连接边,判断该连接边是否存在于最新的基准模型中,若不存在,则将该连接边添加到所述基准模型中,直到遍历完所述待融合测试模型中的边。
该步骤中,可以先获取一待融合测试模型中的节点信息,分别确定每一节点是否存在于最新的基准模型中,若不存在,则将其添加至基准模型中,在该节点存在于基准模型中后,可以再遍历与该节点通过连接边相连的其他节点是否存在于基准模型中,若不存在则将其加入到基准模型中;在遍历完一个待融合测试模型中的节点后,再获取到该待融合测试模型中的连接边信息,遍历每条连接边是否存在于最新的基准模型中,不存在则将其添加至基准模型,直到遍历完待融合测试模型中的边。
在一种可能的实施方式中,所述方法还包括:
在获取到新的测试模型后,基于所述新的测试模型和所述融合模型的模型结构信息,将所述新的测试模型和所述融合模型进行并集处理得到更新后的融合模型。
该步骤中,在生成融合模型之后,若检测到新生成的测试模型,可以再基于所述新的测试模型和所述融合模型的模型结构信息,将所述新的测试模型和所述融合模型进行并集处理,生成更新后的融合模型。
这样,可以随着新的软件测试的不断进行,不断补充更新融合模型,使融合模型愈发完善。
参照图2a及图2b所示,图2a为本公开实施例提供的一种模型构建方法中,测试模型Ⅰ的示意图,图2b为本公开实施例提供的一种模型构建方法中,测试模型Ⅱ的示意图。测试模型Ⅰ中包括节点A、节点B、节点C、连接边ab、连接边ac;测试模型Ⅱ中包括节点B、节点D、连接边bd;连接边ab的方向为由节点A指向节点B,连接边ac的方向为由节点A指向节点C,连接边bd的方向为由节点B指向节点D。
参照图3所示,为本公开实施例提供的一种模型构建方法中,融合模型的示意图。该融合模型为测试模型Ⅰ与测试模型Ⅱ融合得到的,融合模型包括节点A、节点B、节点C、连接边ab、连接边ac、节点D、连接边bd,连接边ab的方向为由节点A指向节点B,连接边ac的方向为由节点A指向节点C,连接边bd的方向为由节点B指向节点D。
本领域技术人员可以理解,在具体实施方式的上述方法中,各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定,各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。
基于同一发明构思,本公开实施例中还提供了与模型构建方法对应的模型构建装置,由于本公开实施例中的装置解决问题的原理与本公开实施例上述模型构建方法相似,因此装置的实施可以参见方法的实施,重复之处不再赘述。
参照图4所示,为本公开实施例提供的一种模型构建装置的架构示意图,所述模型构建装置400包括:获取模块410、融合模块420;其中,
获取模块410,用于在针对目标应用程序的不同的软件测试过程结束后,分别获取目标应用程序与所述软件测试过程对应的至少两个测试模型;所述测试模型是通过对所述目标应用程序的软件测试过程进行测试建模得到的;所述测试模型中包含表征页面中功能组件集合的节点和表征页面操作的连接边;不同的所述软件测试过程的测试路径不同;
融合模块420,用于基于所述至少两个测试模型的模型结构信息,将所述至少两个测试模型并集处理得到融合模型;所述融合模型能够用于生成针对所述目标应用程序的新创建的软件测试过程中的测试路径。
本公开实施例提供的模型构建装置,能够基于测试模型的模型结构信息,将目标应用程序在不同的软件测试过程对应的测试模型融合,使不同测试中的测试信息结合到一起,建立更加完整的融合后的测试模型,这样得到的测试模型的测试覆盖率更高,方便进行后续的测试分析及测试优化,比如,可以基于融合后的测试模型生成目标应用程序的测试路径,省去计算生成测试路径的时间,进而提高软件测试的效率。
一种可选的实施方式中,所述融合模块420具体用于:
从所述至少两个测试模型中选择一测试模型作为基准模型;
将所述至少两个测试模型中除所述基准模型外的其它每个测试模型依次作为待融合测试模型,基于所述模型结构信息,将存在于待融合测试模型但不存在于所述基准模型中的节点和连接边添加到所述基准模型中;
将所有待融合测试模型遍历结束时更新的基准模型作为融合模型。
一种可选的实施方式中,所述融合模块420在将所述至少两个测试模型中除所述基准模型外的其它每个测试模型依次作为待融合测试模型,将存在于待融合测试模型但不存在于所述基准模型中的节点和连接边添加到所述基准模型中时,具体用于:
遍历所述待融合测试模型中的每个节点,判断该节点是否存在于最新的基准模型中,若不存在,则将该节点添加到所述基准模型中;
在遍历完所述待融合测试模型中的节点后,遍历所述待融合测试模型中的每条连接边,判断该连接边是否存在于最新的基准模型中,若不存在,则将该连接边添加到所述基准模型中,直到遍历完所述待融合测试模型中的边。
一种可选的实施方式中,所述融合模块420在从所述至少两个测试模型中选择一测试模型作为基准模型时,具体用于:
确定每个所述测试模型的节点数量,选取所述节点数量最大的测试模型作为所述基准模型;或者,
从所述至少两个测试模型中选择代码覆盖率最高的测试模型作为所述基准模型;或者,
从所述至少两个测试模型中选择测试时长最长的测试模型作为所述基准模型;或者,
从所述至少两个测试模型中随机选择一个测试模型作为所述基准模型。
一种可选的实施方式中,所述融合模块420还用于:
在获取到新的测试模型后,基于所述新的测试模型和所述融合模型的模型结构信息,将所述新的测试模型和所述融合模型进行并集处理得到更新后的融合模型。
关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明,这里不再详述。
基于同一技术构思,本公开实施例还提供了一种计算机设备。参照图5所示,为本公开实施例提供的计算机设备500的结构示意图,包括处理器501、存储器502、和总线503。其中,存储器502用于存储执行指令,包括内存5021和外部存储器5022;这里的内存5021也称内存储器,用于暂时存放处理器501中的运算数据,以及与硬盘等外部存储器5022交换的数据,处理器501通过内存5021与外部存储器5022进行数据交换,当计算机设备500运行时,处理器501与存储器502之间通过总线503通信,使得处理器501在执行以下指令:
在针对目标应用程序的不同的软件测试过程结束后,分别获取目标应用程序与所述软件测试过程对应的至少两个测试模型;所述测试模型是通过对所述目标应用程序的软件测试过程进行测试建模得到的;所述测试模型中包含表征页面中功能组件集合的节点和表征页面操作的连接边;不同的所述软件测试过程的测试路径不同;
基于所述至少两个测试模型的模型结构信息,将所述至少两个测试模型进行并集处理得到融合模型;所述融合模型用于生成所述目标应用程序在新的软件测试过程的测试路径。
一种可能的实施方式中,处理器501执行的指令中,基于所述至少两个测试模型的模型结构信息,将所述至少两个测试模型进行并集处理得到融合模型,包括:
从所述至少两个测试模型中选择一测试模型作为基准模型;
将所述至少两个测试模型中除所述基准模型外的其它每个测试模型依次作为待融合测试模型,基于所述模型结构信息,将存在于待融合测试模型但不存在于所述基准模型中的节点和连接边添加到所述基准模型中;
将所有待融合测试模型遍历结束时更新的基准模型作为融合模型。
一种可能的实施方式中,处理器501执行的指令中,所述将所述至少两个测试模型中除所述基准模型外的其它每个测试模型依次作为待融合测试模型,将存在于待融合测试模型但不存在于所述基准模型中的节点和连接边添加到所述基准模型中,包括:
遍历所述待融合测试模型中的每个节点,判断该节点是否存在于最新的基准模型中,若不存在,则将该节点添加到所述基准模型中;
在遍历完所述待融合测试模型中的节点后,遍历所述待融合测试模型中的每条连接边,判断该连接边是否存在于最新的基准模型中,若不存在,则将该连接边添加到所述基准模型中,直到遍历完所述待融合测试模型中的边。
一种可能的实施方式中,处理器501执行的指令中,所述从所述至少两个测试模型中选择一测试模型作为基准模型,包括:
确定每个所述测试模型的节点数量,选取所述节点数量最大的测试模型作为所述基准模型;或者,
从所述至少两个测试模型中选择代码覆盖率最高的测试模型作为所述基准模型;或者,
从所述至少两个测试模型中选择测试时长最长的测试模型作为所述基准模型;或者,
从所述至少两个测试模型中随机选择一个测试模型作为所述基准模型。
一种可能的实施方式中,处理器501还用于执行:
在获取到新的测试模型后,基于所述新的测试模型和所述融合模型的模型结构信息,将所述新的测试模型和所述融合模型进行并集处理得到更新后的融合模型。
本公开实施例还提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行上述方法实施例中所述的模型构建方法的步骤。其中,该存储介质可以是易失性或非易失的计算机可读取存储介质。
本公开实施例所提供的模型构建方法的计算机程序产品,包括存储了程序代码的计算机可读存储介质,所述程序代码包括的指令可用于执行上述方法实施例中所述的模型构建方法的步骤,具体可参见上述方法实施例,在此不再赘述。
本公开实施例还提供一种计算机程序,该计算机程序被处理器执行时实现前述实施例的任意一种方法。该计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中,所述计算机程序产品具体体现为计算机存储介质,在另一个可选实施例中,计算机程序产品具体体现为软件产品,例如软件开发包(Software DevelopmentKit,SDK)等等。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的***和装置的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。在本公开所提供的几个实施例中,应该理解到,所揭露的***、装置和方法,可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,又例如,多个单元或组件可以结合或者可以集成到另一个***,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本公开各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解,本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-OnlyMemory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上所述实施例,仅为本公开的具体实施方式,用以说明本公开的技术方案,而非对其限制,本公开的保护范围并不局限于此,尽管参照前述实施例对本公开进行了详细的说明,本领域的普通技术人员应当理解:任何熟悉本技术领域的技术人员在本公开揭露的技术范围内,其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化,或者对其中部分技术特征进行等同替换;而这些修改、变化或者替换,并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围,都应涵盖在本公开的保护范围之内。因此,本公开的保护范围应所述以权利要求的保护范围为准。