测试方法、装置、设备和存储介质

技术领域

本发明实施例涉及测试技术领域，尤其涉及一种测试方法、装置、设备和存储介质。

背景技术

MockMvc可以实现对Http请求的模拟，能够直接使用模拟网络请求报文的形式，转换到控制(Controller)接口的调用，使得测试速度快、不依赖网络环境。

虽然MockMvc能够对Http请求报文进行模拟，作为Controller接口的输入。但是每次只能模拟一种请求场景。为了提高接口测试覆盖率，测试多种接口请求场景，需要编写多个单元测试代码，增加了工作压力。

发明内容

本发明实施例提供一种测试方法、装置、设备和存储介质，以实现基于单个场景生成逻辑对多个请求场景的模拟。

第一方面，本发明实施例提供了一种测试方法，该方法包括：

从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据；

根据所述至少两个测试场景数据，使用模拟网络请求报文的形式，调用待测试控制接口逻辑；

根据所述待测试控制接口逻辑的输出结果，确定所述待测试控制接口逻辑的测试结果。

第二方面，本发明实施例还提供了一种测试装置，该装置包括：

场景数据生成模块，用于从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据；

请求模拟模块，用于根据所述至少两个测试场景数据，使用模拟网络请求报文的形式，调用待测试控制接口逻辑；

测试结果确定模块，用于根据所述待测试控制接口逻辑的输出结果，确定所述待测试控制接口逻辑的测试结果。

第三方面，本发明实施例还提供了一种设备，所述设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如本发明实施例中任一所述的测试方法。

第四方面，本发明实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本发明实施例中任一所述的测试方法。

本发明实施例通过从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据；根据所述至少两个测试场景数据，使用模拟网络请求报文的形式，调用待测试控制接口逻辑，从而实现基于单个场景生成逻辑对多个请求场景的模拟，进而实现针对一个被测接口，只需要编写一次场景生成逻辑，将多个报文数据配置于数据源中，使用模拟网络请求报文的形式模拟Http请求，即可实现对接口的充分测试。

附图说明

图1为本发明实施例一提供的一种测试方法的流程图；

图2是本申请实施例二提供的一种测试方法的流程图；

图3是本申请实施例三提供的一种测试方法的流程图；

图4是本申请实施例四提供的一种测试方法的流程图；

图5是本发明实施例四提供的一种输入界面的示意图；

图6是本发明实施例五提供的一种测试装置的结构示意图；

图7为本发明实施例六提供的一种设备的结构示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。

实施例一

图1为本发明实施例一提供的一种测试方法的流程图。本实施例可适用于对待测试控制接口逻辑进行高覆盖率且少工作量的测试的情况。该方法可以由一种测试装置来执行，该装置可以由软件和/或硬件的方式实现。参见图1，本发明实施例提供的测试方法包括：

S110、从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据。

其中，数据源是存储有至少两个测试场景参数组的存储介质。具体地，数据源可以是文件、数据库或表格等。

测试场景参数组是指描述测试场景的至少一个参数的组合。典型地，测试场景参数组可以由测试人员配置得到。

至少两个测试场景参数组包括两个测试场景参数组、三个测试场景参数组以及更多个测试场景参数组。

场景生成逻辑是生成测试场景数据的逻辑。

测试场景数据是指描述测试场景的数据。

具体地，可以基于Junit，从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据。

其中，Junit是被广泛应用的Java单元测试框架。

S120、根据所述至少两个测试场景数据，使用模拟网络请求报文的形式，调用待测试控制接口逻辑。

其中，待测试控制接口逻辑是指待测试的控制接口的执行逻辑。

控制接口是web应用开发中的Controller接口。Controller接口主要处理外部请求。

S130、根据所述待测试控制接口逻辑的输出结果，确定所述待测试控制接口逻辑的测试结果。

具体地，根据所述待测试控制接口逻辑的输出结果，确定所述待测试控制接口逻辑的测试结果，包括：

比较待测试控制接口逻辑的输出结果和对应的真值，根据比较结果确定待测试控制接口逻辑的测试结果。

本发明实施例通过从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据；根据所述至少两个测试场景数据，使用模拟网络请求报文的形式，调用待测试控制接口逻辑，从而实现基于单个场景生成逻辑对多个请求场景的模拟，进而实现针对一个被测接口，只需要编写一次场景生成逻辑，将多个报文数据配置于数据源中，使用模拟网络请求报文的形式模拟Http请求，即可实现对接口的充分测试。

实施例二

图2是本申请实施例二提供的一种测试方法的流程图。本实施例是在上述实施例的基础上，对上述S120的细化。参见图2，本申请实施例提供的测试方法包括：

S110、从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据。

S121、基于具有模拟Http请求的Mock框架，根据所述至少两个测试场景数据，使用模拟网络请求报文的形式，调用待测试控制接口逻辑。

可选地，可以是任意可以模拟Http请求的Mock框架。

典型地，所述具有模拟Http请求的Mock框架包括MockMvc框架。

其中，MockMvc实现对Http请求的模拟，能够直接使用模拟网络请求报文的形式，转换到Controller接口的调用，使得测试速度快、不依赖网络环境。

S130、根据所述待测试控制接口逻辑的输出结果，确定所述待测试控制接口逻辑的测试结果。

本发明实施例通过基于具有模拟Http请求的Mock框架，根据所述至少两个测试场景数据，使用模拟网络请求报文的形式，调用待测试控制接口逻辑，从而实现对Http请求的模拟。

实施例三

图3是本申请实施例三提供的一种测试方法的流程图。本实施例是在上述实施例的基础上，对上述S110的进一步细化。参见图3，本实施例提供的测试方法包括：

S111、基于Feed4Junit，从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据。

其中，Feed4Junit是开源的基于Junit的扩展，通过使用Feed4Junit提供的注释，用户可以很方便的把测试数据存放在文件或其它数据源。

S120、根据所述至少两个测试场景数据，使用模拟网络请求报文的形式，调用待测试控制接口逻辑。

S130、根据所述待测试控制接口逻辑的输出结果，确定所述待测试控制接口逻辑的测试结果。

本发明实施例的技术方案，通过Feed4Junit良好的解决了数据与代码分离的问题，Feed4Junit是Junit测试框架的扩展，它通过操作来自于文件以及不同的数据源的测试数据，使测试变得更容易编写与维护。

因为当前大部分的测试逻辑均是基于Spring框架实现，所以为适应Spring框架，所述基于Feed4Junit，从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据，包括：

基于新的单元测试框架，从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据；

所述新的单元测试框架通过修改Feed4Junit的继承关系得到，所述新的单元测试框架继承于Spring框架的执行器。

其中，新的单元测试框架是一个与Spring融合的单元测试框架，其实现了数据与代码分离，可以将测试用例和测试驱动代码完全分开，实现测试用例和测试代码的完全解耦，是通过扩展Feed4Junit源码实现，与Junit4不是同一个框架，JUnit4没有实现数据与测试代码的分离，数据与代码需要耦合在一起。

Spring框架是一个开源的Java平台，它为容易而快速的开发出耐用的Java应用程序提供了全面的基础设施，为了解决企业应用程序开发复杂性而创建的。目前，从国有企业到互联网企业，从传统民营企业到股份制企业等，涉及的web系统几乎都是通过Spring框架构建。

具体地，Spring框架的执行器可以是SpringJunit4Classrunner。

实施例四

图4是本申请实施例四提供的一种测试方法的流程图。本实施例是在上述实施例的基础上，提供的一种可选方案。参见图4，本申请实施例提供的测试方法包括：

S210、基于新的单元测试框架，从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据。

其中，新的单元测试框架继承于Spring框架的执行器。

S220、基于MockMvc框架，根据所述至少两个测试场景数据，使用模拟网络请求报文的形式，调用待测试控制接口逻辑。

S230、根据所述待测试控制接口逻辑的输出结果，确定所述待测试控制接口逻辑的测试结果。

本发明实施例的关键点在于：

1、由于Feed4Junit框架不支持Spring框架，本发明对Feed4Junit源码进行扩展并重新编译框架，生成新的单元测试框架，该新的单元测试框架实现了与Spring框架的融合，解决Feed4Junit的不足。

2、由于MockMvc每次只能模拟一种测试场景，为了提高单元测试覆盖率，测试接口的多个请求场景，本方案中发明了将新的单元测试框架和MockMvc融合，从而实现针对一个被测接口，只需要编写一次场景生成逻辑，将多个报文数据配置于数据源中，使用模拟网络请求报文的形式模拟Http请求，即可实现对接口的充分测试。

本发明实施例的技术效果为：

本发明实施例对于接口测试可以极大节省接口测试代码，提高接口测试覆盖率。利用本发明可以实现复杂接口的全覆盖。比如图5中的输入界面(对应系统中的一个Controller接口)：如果实现发起部门、业务种类、币种、业务条线、是否收到发票等5个多选框的测试，则组合20×30×30×5×2＝180000,18万个场景，一个接口如果全覆盖5个可选的场景，还有其他输入框的测试组合，比如收款行行号、付款金额等，则全部组合的总场景需要指数级别增长，现有方法对每个场景编写一个接口测试方法，则需要编写海量接口测试方法。

利用本发明实施例，只需要编写1个接口测试方法，所有的18万个测试用例配置到数据源中，本发明的融合框架可以自动化读取18万测用例测试接口，使得接口的全量覆盖成为可能，并且接口测试方法代码只需要编写1个，而现有的测试方式则需要编写18万个。

对于SpringMVC框架的Controller接口的接口测试，也可以实现编写1个接口测试方法，对整个系统的所有Controller接口进行测试，即对整个工程的所有接口测试，利用本发明只需要编写1个测试方法，测试的所有场景的测试用例都配置到数据源中，进一步提升接口测试的效率。

实施例五

图6是本发明实施例五提供的一种测试装置的结构示意图。参见图6，本发明实施例例提供的测试装置包括：场景数据生成模块10、请求模拟模块20和测试结果确定模块30。

其中，场景数据生成模块10，用于从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据；

请求模拟模块20，用于根据所述至少两个测试场景数据，使用模拟网络请求报文的形式，调用待测试控制接口逻辑；

测试结果确定模块30，用于根据所述待测试控制接口逻辑的输出结果，确定所述待测试控制接口逻辑的测试结果。

本发明实施例通过从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据；根据所述至少两个测试场景数据，使用模拟网络请求报文的形式，调用待测试控制接口逻辑，从而实现基于单个场景生成逻辑对多个请求场景的模拟，进而实现针对一个被测接口，只需要编写一次场景生成逻辑，将多个报文数据配置于数据源中，使用模拟网络请求报文的形式模拟Http请求，即可实现对接口的充分测试。

进一步地，所述请求模拟模块，包括：

请求模拟单元，用于基于具有模拟Http请求的Mock框架，根据所述至少两个测试场景数据，使用模拟网络请求报文的形式，调用待测试控制接口逻辑。

进一步地，所述具有模拟Http请求的Mock框架包括MockMvc框架。

进一步地，所述场景数据生成模块，包括：

场景数据生成单元，用于基于Feed4Junit单元测试框架，从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据。

进一步地，所述场景数据生成单元，用于：

修改Feed4Junit的继承关系，得到新的单元测试框架，使新的单元测试框架继承于Spring框架的执行器；

基于新的单元测试框架，从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据。

实施例六

图7为本发明实施例六提供的一种设备的结构示意图，如图7所示，该设备包括处理器70、存储器71、输入装置72和输出装置73；设备中处理器70的数量可以是一个或多个，图7中以一个处理器70为例；设备中的处理器70、存储器71、输入装置72和输出装置73可以通过总线或其他方式连接，图7中以通过总线连接为例。

存储器71作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明实施例中的测试方法对应的程序指令/模块(例如，测试装置中的场景数据生成模块10、请求模拟模块20和测试结果确定模块30)。处理器70通过运行存储在存储器71中的软件程序、指令以及模块，从而执行设备的各种功能应用以及数据处理，即实现上述的测试方法。

存储器71可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器71可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器71可进一步包括相对于处理器70远程设置的存储器，这些远程存储器可以通过网络连接至设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置72可用于接收输入的数字或字符信息，以及产生与设备的用户设置以及功能控制有关的键信号输入。输出装置73可包括显示屏等显示设备。

实施例七

本发明实施例七还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行一种测试方法，该方法包括：

从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据；

根据所述至少两个测试场景数据，使用模拟网络请求报文的形式，调用待测试控制接口逻辑；

根据所述待测试控制接口逻辑的输出结果，确定所述待测试控制接口逻辑的测试结果。

当然,本发明实施例所提供的一种包含计算机可执行指令的存储介质,其计算机可执行指令不限于如上所述的方法操作,还可以执行本发明任意实施例所提供的测试方法中的相关操作.

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

值得注意的是，上述测试装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。