测试用例的处理方法、装置及电子设备与流程

文档序号:15517695发布日期:2018-09-25 18:44阅读:146来源:国知局

本申请涉及计算机技术领域,尤其涉及一种测试用例的处理方法、装置及电子设备。



背景技术:

junit是一个用于编写和运行可重复的测试的java回归测试框架,可实现测试期望结果的断言,方便的组织和运行测试。现有junit执行用例测试的流程,每次执行测试用例需要花费2~3分钟来初始化容器(如pandora容器)及加载用例运行需要的bean(javabean,一种java语言写成的可重用组件)数据等资源,用例执行完成之后会释放资源及关闭容器。当再次执行测试用例时需要再次花费2~3分钟来重新初始容器及加载资源。

现有测试用例执行方案中,每次运行测试用例代码启动容器和加载bean资源的时间大概2~3分钟,而实际运行时间(执行用例测试,结果处理)通常在5秒钟以内,运行测试用例的大量时间基本花费在初始化环境上,增加了运行测试用例的时间成本。



技术实现要素:

本发明提供了一种测试用例的处理方法、装置及电子设备,以减少运行测试用例的时间,提高测试效率。

为达到上述目的,本发明的实施例采用如下技术方案:

第一方面,提供了一种测试用例的处理方法,所述处理方法涉及多次执行在同一资源环境下所运行的多个测试用例,在每次执行所述测试用例的过程中,包括如下处理:

监听在junit框架下的第一用例测试进程中、在执行所述测试用例的过程中开启第一容器的请求,所述第一容器用于加载所述测试用例所需要的bean资源;

当监听到所述请求后,中止第一用例测试进程中所述测试用例的执行,并将所述测试用例的执行任务转移至所述junit框架以外的第二用例测试进程中执行,

其中,所述第二用例测试进程在第一次加载所述第一容器以及所述bean资源后,保持所述第一容器以及所述bean资源。

第二方面,提供了一种测试用例的处理方法,所述处理方法涉及多次执行在同一资源环境下所运行的多个测试用例,在每次执行所述测试用例的过程中,包括如下处理:

监听在第一系统框架下的第一用例测试进程中、在执行所述测试用例的过程中开启第一容器的请求,所述第一容器用于加载所述测试用例所需要的测试环境资源;

当监听到所述请求后,中止第一用例测试进程中所述测试用例的执行,并将所述测试用例的执行任务转移至所述第一系统框架以外的第二用例测试进程中执行,

其中,所述第二用例测试进程在第一次加载所述第一容器以及所述测试环境资源后,保持所述第一容器以及测试环境资源。

第三方面,提供了一种测试用例的处理装置,所述处理装置用于多次执行在同一资源环境下所运行的多个测试用例,所述处理装置包括:监听模块和进程控制模块;在每次执行所述测试用例的过程中:

所述监听模块,用于监听在第一系统框架下的第一用例测试进程中、在执行所述测试用例的过程中开启第一容器的请求,所述第一容器用于加载所述测试用例所需要的测试环境资源;

所述进程控制模块,用于当所述监听模块监听到所述请求后,中止第一用例测试进程中所述测试用例的执行,并将所述测试用例的执行任务转移至所述第一系统框架以外的第二用例测试进程中执行,

其中,所述第二用例测试进程在第一次加载所述第一容器以及所述测试环境资源后,保持所述第一容器以及所述测试环境资源。

第四方面,提供了一种电子设备,包括:

存储器,用于存储程序;

处理器,耦合至所述存储器,用于执行所述程序,以用于:

监听在第一系统框架下的第一用例测试进程中、在执行所述测试用例的过程中开启第一容器的请求,所述第一容器用于加载所述测试用例所需要的测试环境资源;

当监听到所述请求后,中止第一用例测试进程中所述测试用例的执行,并将所述测试用例的执行任务转移至所述第一系统框架以外的第二用例测试进程中执行,

其中,所述第二用例测试进程在第一次加载所述第一容器以及所述测试环境资源后,保持所述第一容器以及所述测试环境资源。

本发明提供的测试用例的处理方法、装置及电子设备,通过监听在第一系统框架下的第一用例测试进程中、在执行测试用例的过程中开启第一容器的请求;然后在监听到该请求后,中止第一用例测试进程中测试用例的执行,并将测试用例的执行任务转移至第一系统框架以外的第二用例测试进程中执行,并控制第二用例测试进程在第一次加载第一容器以及测试环境资源后,保持第一容器以及测试环境资源,以使得后续的测试用例被执行时,不需要再从新开启第一容器以及测试环境资源,提高了测试效率。

上述说明仅是本申请技术方案的概述,为了能够更清楚了解本申请的技术手段,而可依照说明书的内容予以实施,并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂,以下特举本申请的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述,各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的,而并不认为是对本申请的限制。而且在整个附图中,用相同的参考符号表示相同的部件。在附图中:

图1为现有技术中的测试用例的处理的逻辑示意图;

图2为本发明实施例的测试用例的处理的逻辑示意图;

图3为本发明实施例的测试用例的处理方法流程图;

图4为本发明实施例的测试用例的处理装置结构图;

图5为本发明实施例的电子设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。

图1为现有技术中的在junit框架下测试用例的处理的逻辑示意图。如图1所示,现有的在junit框架下测试用例的处理的逻辑可以从上层的应用程序层面和底层的执行层面两个侧面进行描述,当然这两个层面是相互对应的,底层的内容可视为上层内容的具体实现过程。当junitintellijide(内置junit插件)开始运行时,其对应的执行层面就已经开始请求操作系统开启java虚拟机(javavirtualmachine,jvm)容器,并加载资源,而这些是在执行测试之前需要准备的环境。在junit框架下执行测试的方法(junit执行代码的部分)分为两类,一个是junit框架方法,可视为是junit自己的代码执行方法;另一个是执行测试用例的方法,也是本发明实施例所针对的被改进的现有技术部分。图1中,结合底层的执行层面对执行测试用例方法的过程进行了对照描述。

在应用程序层面启动执行测试用例方法后,会申请操作系统为该操作过程开启一个进程,本实施例中称之为第一用例测试进程,该测试进程可理解为是基于junit框架的本地执行测试用例的过程。一个测试用例包括资源加载部分和测试过程部分,所述资源加载部分用于请求开启当前被测试的测试代码所需要的第一容器(如pandora容器)并向该第一容器加载bean资源,待资源加载完成后执行测试过程部分。一次执行测试用例方法的过程所包括的:开启第一容器、加载bean资源以及执行测试代码均是在第一用例测试进程中的第一主线程中完成的。当测试用例方法执行完成后,第一主线程关闭,同时第一用例测试进程也随之关闭,之前开启的pandora容器和加载的bean资源也会被关闭和释放掉。

上述执行测试用例方法的过程被设置在了junitintellijide中,是很难或不能更改的,而junitintellijide的操作就是为每个测试用例的执行过程开启一个进程,而不是线程。因此,在测试完成后,被加载的资源会被释放掉,待到下次执行测试用例时,再从新启动上述第一用例测试进程,并在新建的第一主线程中执行一遍上述过程,从而导致资源要被反复开启,消耗大量时间,这也是本专利中要解决的技术问题。

本发明实施例改变了现有技术中,基于junit框架的执行测试用例的方法中,需要针对每次测试用例的过程从新开启一个进程,并在执行测试用例结束后,关闭该进程,从而导致被加载的bean资源被释放,其核心思想在于,在第一用例测试进程被开启后,强行干预其第一主线程的处理过程。并通过进程间通信,将原本应在第一主线程中完成的执行测试用例的任务转移到junit框架以外的第二用例测试进程中的第二主线程中执行,而该第二主线程在第一次加载第一容器以及bean资源后,将该第一容器以及bean资源保持在第二用例测试进程中,供其下的所有线程使用,从而使得后续再执行测试用例时不必再反复开启容器和加载资源,节省了测试时间,提高测试效率。

图2为本发明实施例提供的测试用例的处理逻辑示意图,基于本发明的上述核心思想,在现有逻辑架构上,在上层的应用程序层面增加了一个服务程序(以下将该服务称为server),相对应的在底层的执行层面则增加了一个第二用例测试进程。该第二用例测试进程是junit框架以外的进程,不受控于junitintellijide的逻辑代码控制,而是通过server实现对第二用例测试进程的开启、关闭和资源维持等操作的。

具体地,在现有的第一用例测试进程中,第一主线程通常会先发出开启pandora容器的调用请求,然后系统才在本地开启pandora容器。本方案针对该操作进行了干预,即在第一主线程发出开启pandora容器的调用请求时,对该请求进行拦截,此时主线程的操作被中止,进入等待状态。被拦截的请求以及后续测试过程对应的任务被全部转移到第二用例测试进程中的第二主线程中继续执行。在第二主线程接收到执行测试用例的任务后,会创建一个子线程,然后在该子线程中执行开启pandora容器,并在该容器中加载bean资源,并将资源维持(hold),资源加载完成后执行测试过程。在执行完测试用例后,该子线程关闭,第二主线程一直保持启动状态,同时向第一用例测试进程返回测试结果。第一用例测试进程接收到测试结果后,可对测试结果进行预设处理,使其符合junit框架下测试结果的输出要求,并将测试结果返回给junit主程序,然后关闭第一用例测试进程,本次执行测试用例方法结束。

当在执行新的一次的测试用例时,重新建立第一用例测试进程和第一主线程。然后,仍然对第一主线程中的执行过程进行干预,将测试任务转移到第二用例测试进程中,由第二主线程执行完成,第二主线程接收执行测试用例的任务后会再次创建一个子线程,然后在该子线程中顺序执行开启pandora容器、加载bean资源和执行测试过程。此时由于第二用例测试进程中已经开启了pandora容器并加载了bean资源,因此,子线程可跳过该过程,直接进入到执行测试过程,节省了开启容器和加载资源所需要的时间,提高了测试效率。

需要说明的是,虽然本发明实施例以junit框架下测试用例的处理过程来进行说明,但是本领域技术人员应当理解,本发明实施例的技术方案完全可以应用到与junit框架下测试用例的处理过程类似的情况。因此,可以将junit框架抽象为用于进行用例测试的第一系统框架,将pandora容器抽象为用于加载测试用例所需要的测试环境资源的第一容器,将bean资源抽象为测试环境资源。基于此,本发明实施例的技术思想可以抽象为将原本在基于第一系统框架下的第一用例测试进程中执行的测试过程,转移到第一系统框架以外的第二用例测试进程中执行,从而跳出第一系统框架的限制,从而更加灵活有效地利用测试环境资源,提高测试用例的测试效率。

下面通过多个实施例来进一步说明本申请的技术方案,为了便于说明,以下仍然以junit框架为具体示例进行说明,但是本领域技术人员应当理解,以下的各个实施例的描述中,junit框架均可以替代为上述第一系统框架,bean资源可以替代为上述测试环境资源。

实施例一

基于上述将原本在基于junit框架下的第一用例测试进程中执行的测试过程,转移到junit框架以外的第二用例测试进程中执行的方案思想,如图3所示,其为本发明实施例示出的测试用例的处理方法流程图,该处理方法涉及多次执行在同一资源环境下所运行的多个测试用例,结合图2中的内容,在每次执行测试用例的过程中,均包括如下处理步骤:

s310,监听在junit框架下的第一用例测试进程中、在执行测试用例的过程中开启第一容器的请求,第一容器用于加载测试用例所需要的bean资源。

具体地,通过junit框架下的监听器(lisener)可以实时监听第一用例测试进程中执行的操作,这些操作也包括第一用例测试进程中的第一主线程发出开启第一容器的请求。该第一容器可为pandora容器,用于加载测试用例所需要的bean资源。

s320,当监听到上述请求后,中止第一用例测试进程中测试用例的执行,并将测试用例的执行任务转移至junit框架以外的第二用例测试进程中执行,其中,第二用例测试进程在第一次加载第一容器以及bean资源后,保持第一容器以及bean资源。

具体地,通过扩展现有junit的runner(执行器,junit框架中的一个组件),使测试用例使用自定义runner,在自定义的runner中设置代理,以拦截执行测试用例的过程中,第一主线程所触发的开启第一容器的请求,然后可将拦截后的请求转换为http服务请求,以通过该请求访问本地的除junit框架以外的服务程序,并将测试用例的执行任务转移到该junit框架以外的服务程序所对应的第二用例测试中,继续完成测试任务。

当第二用例测试进程开启后,接到第一用例测试进程转移过来的首个测试用例的执行任务时,第二用例测试进程中的第二主线程会依据测试用例的内容执行测试用例过程,并且在首次加载第一容器以及bean资源后,一直保持第一容器以及bean资源。

当第二用例测试进程后续再次接到第一用例测试进程转移过来的测试用例的执行任务时,仍然依据测试用例的内容执行测试过程,但由于第二用例测试进程在第一次加载第一容器以及bean资源后,保持第一容器以及bean资源,因此在后续的测试任务中,不需要花费额外的时间去从新开启容器和加载资源,提高了测试效率。

进一步地,在步骤s320的一种具体实现方式中,可通过执行如下步骤,实现将测试用例的执行任务转移至junit框架以外的第二用例测试进程中执行。

首先,向第二用例测试进程发送通知消息,该通知消息包括测试用例的调用信息;

例如,自定义的runner在拦截了执行测试用例的过程中,第一主线程所触发的开启第一容器的请求后,可依据该请求形成http服务请求,并以http服务请求的方式向第二用例测试进程发送通知消息,该通知消息包括测试用例的调用信息。

然后,第二用例测试进程接收到通知消息后,根据调用信息调用测试用例并执行;

具体地,第二用例测试进程接收到通知消息后,根据调用信息调用测试用例并依据测试用例中指定的操作步骤依次执行操作。

进一步地,上述测试用例包括资源加载部分和测试过程部分,上述第二用例测试进程包括第二主线程,其中,资源加载部分用于请求开启第一容器并向第一容器加载bean资源,

在第二用例测试进程中执行测试用例过程中,通过第二主线程创建一个子线程,并在该子线程中顺序执行资源加载部分和测试过程部分,待测试过程部分执行完成后,关闭该子线程。由于在执行测试过程完成后,仅仅关闭了子线程,而第二主线程仍处于挂起状态,因此,在第一次加载第一容器以及bean资源后,就可以将第一容器以及bean资源保持在第二用例测试进程内,使其不被关闭或释放。

最后,在执行完测试用例后,第二用例测试进程向第一用例测试进程返回测试结果。

例如,第二用例测试进程可将测试结果以扩展后的junitrunlistener封装,封装结果通过httpresponse方式返给第一用例测试进程。

进一步地,第一用例测试进程在接收到上述测试结果后,关闭该第一用例测试进程,至此一次完整的执行测试用例方法的过程结束。

具体地,在第二用例测试进程中的子线程中执行完成测试过程部分后,可向第一用例测试进程的第一主线程返回测试结果,第一主线程接收到测试结果,并完成针对测试结果的预设处理后,关闭第一主线程和第一用例测试进程。

其中,针对测试结果的预设处理可包括:第一用例测试进程解析返回的测试结果并通过runnotifier通知上层的junitintellijide应用程序。

在实现上述方案过程中,还可采用jrebel(一套javaee开发工具)热部署插件方式将变更的代码同步到第二用例测试进程对应的上层应用程序中,代码变更后代码实时生效,便于实现对第二用例测试进程的优化。

另外,还可以通过远程方式访问第二用例测试进程对应的上层应用程序,从而对整个测试过程进行调试和访问。

本发明实施例提供的测试用例的处理方法,通过监听在junit框架下的第一用例测试进程中、在执行测试用例的过程中开启第一容器的请求;然后在监听到该请求后,中止第一用例测试进程中测试用例的执行,并将测试用例的执行任务转移至junit框架以外的第二用例测试进程中执行,并控制第二用例测试进程在第一次加载第一容器以及bean资源后,保持第一容器以及bean资源,以使得后续的测试用例被执行时,不需要再从新开启第一容器以及bean资源,提高了测试效率。

实施例二

如图4所示,为本发明实施例的测试用例的处理装置结构图,该测试用例的处理装置,处理装置用于多次执行在同一资源环境下所运行的多个测试用例,可用于执行如图3所示的方法步骤,处理装置包括:监听模块410和进程控制模块420;其中:

监听模块410,用于监听在junit框架下的第一用例测试进程中、在执行测试用例的过程中开启第一容器的请求,第一容器用于加载测试用例所需要的bean资源;

进程控制模块420,用于当监听模块410监听到请求后,中止第一用例测试进程中测试用例的执行,并将测试用例的执行任务转移至junit框架以外的第二用例测试进程中执行,其中,第二用例测试进程在第一次加载第一容器以及bean资源后,保持第一容器以及bean资源。

进一步地,进程控制模块420将测试用例的执行任务转移至junit框架以外的第二用例测试进程中执行,包括:

向第二用例测试进程发送通知消息,该通知消息包括测试用例的调用信息;

第二用例测试进程接收到通知消息后,根据调用信息调用测试用例并执行,

在执行完测试用例后,向第一用例测试进程返回测试结果。

进一步地,第一用例测试进程在接收到测试结果后,关闭该第一用例测试进程。

进一步地,测试用例包括资源加载部分和测试过程部分,第二用例测试进程包括第二主线程,资源加载部分用于请求开启第一容器并向第一容器加载bean资源,

在所述第二用例测试进程中执行所述测试用例过程中,通过所述第二主线程创建一个子线程,并在该子线程中顺序执行所述资源加载部分和所述测试过程部分,待所述测试过程部分执行完成后,关闭所述子线程,第二主线程在第一次加载第一容器以及bean资源后,保持第一容器以及bean资源。

进一步地,第一用例测试进程包括第一主线程,测试用例在第一主线程中执行,在上述子线程中执行测试过程部分后,还包括:向第一用例测试进程的第一主线程返回测试结果,第一主线程接收到测试结果后,完成针对测试结果的预设处理后,关闭第一主线程和第一用例测试进程。

本发明实施例提供的测试用例的处理装置,通过监听在junit框架下的第一用例测试进程中、在执行测试用例的过程中开启第一容器的请求;然后在监听到该请求后,中止第一用例测试进程中测试用例的执行,并将测试用例的执行任务转移至junit框架以外的第二用例测试进程中执行,并控制第二用例测试进程在第一次加载第一容器以及bean资源后,保持第一容器以及bean资源,以使得后续的测试用例被执行时,不需要再从新开启第一容器以及bean资源,提高了测试效率。

实施例三

前面描述了目标驱动有限资源的负载均衡装置的整体架构,该装置的功能可借助一种电子设备实现完成,如图5所示,其为本发明实施例的电子设备的结构示意图,具体包括:存储器510和处理器520。

存储器510,用于存储程序。

除上述程序之外,存储器510还可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令,联系人数据,电话簿数据,消息,图片,视频等。

存储器510可以由任何类型的易失性或非易失性存储设备或者它们的组合实现,如静态随机存取存储器(sram),电可擦除可编程只读存储器(eeprom),可擦除可编程只读存储器(eprom),可编程只读存储器(prom),只读存储器(rom),磁存储器,快闪存储器,磁盘或光盘。

处理器520,耦合至存储器510,用于执行存储器510中的程序,以用于:

监听在junit框架下的第一用例测试进程中、在执行测试用例的过程中开启第一容器的请求,第一容器用于加载测试用例所需要的bean资源;

当监听到请求后,中止第一用例测试进程中测试用例的执行,并将测试用例的执行任务转移至junit框架以外的第二用例测试进程中执行,

其中,第二用例测试进程在第一次加载第一容器以及bean资源后,保持第一容器以及bean资源。

上述的具体处理操作已经在前面实施例中进行了详细说明,在此不再赘述。

进一步,如图5所示,电子设备还可以包括:通信组件530、电源组件540、音频组件550、显示器560等其它组件。图5中仅示意性给出部分组件,并不意味着电子设备只包括图5所示组件。

通信组件530被配置为便于电子设备和其他设备之间有线或无线方式的通信。电子设备可以接入基于通信标准的无线网络,如wifi,2g或3g,或它们的组合。在一个示例性实施例中,通信组件530经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中,通信组件530还包括近场通信(nfc)模块,以促进短程通信。例如,在nfc模块可基于射频识别(rfid)技术,红外数据协会(irda)技术,超宽带(uwb)技术,蓝牙(bt)技术和其他技术来实现。

电源组件540,为电子设备的各种组件提供电力。电源组件540可以包括电源管理系统,一个或多个电源,及其他与为电子设备生成、管理和分配电力相关联的组件。

音频组件550被配置为输出和/或输入音频信号。例如,音频组件550包括一个麦克风(mic),当电子设备处于操作模式,如呼叫模式、记录模式和语音识别模式时,麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器510或经由通信组件530发送。在一些实施例中,音频组件550还包括一个扬声器,用于输出音频信号。

显示器560包括屏幕,其屏幕可以包括液晶显示器(lcd)和触摸面板(tp)。如果屏幕包括触摸面板,屏幕可以被实现为触摸屏,以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界,而且还检测与触摸或滑动操作相关的持续时间和压力。

本领域普通技术人员可以理解:实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时,执行包括上述各方法实施例的步骤;而前述的存储介质包括:rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是:以上各实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述各实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1