本发明实施例涉及测试技术领域，尤其涉及一种测试方法、装置、设备和存储介质。
背景技术：
当前在利用数据源和单元测试逻辑进行测试时，数据源中的测试场景参数是由测试人员人工构造的。
上述数据源的生成方法不仅费时费力，且测试人员人工构造的测试场景参数存在主观因素。因此基于人工构造的测试场景数据的测试准确率低。
技术实现要素：
本发明实施例提供一种测试方法、装置、设备和存储介质，以解决上述问题。
第一方面，本发明实施例提供了一种测试方法，该方法包括：
在业务人员执行待测试逻辑的过程中，从后台提取所述待测试逻辑的输入数据和输出数据；
根据所述输入数据和所述输出数据确定测试场景参数组，并将所述测试场景参数组存储于数据源中；
从所述数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据；
根据所述至少两个测试场景数据，对所述待测试逻辑进行测试。
第二方面，本发明实施例还提供了一种测试装置，该装置包括：
数据抓取模块，用于在业务人员执行待测试逻辑的过程中，从后台提取所述待测试逻辑的输入数据和输出数据；
数据存储模块，用于根据所述输入数据和所述输出数据确定测试场景参数组，并将所述测试场景参数组存储于数据源中；
场景数据生成模块，用于从所述数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据；
测试模块，用于根据所述至少两个测试场景数据，对所述待测试逻辑进行测试。
第三方面，本发明实施例还提供了一种设备，所述设备包括：
一个或多个处理器；
存储装置，用于存储一个或多个程序，
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如本发明实施例中任一所述的测试方法。
第四方面，本发明实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本发明实施例中任一所述的测试方法。
本发明实施例通过在业务人员执行待测试逻辑的过程中，从后台提取所述待测试逻辑的输入数据和输出数据；根据所述输入数据和所述输出数据确定测试场景参数组，并将所述测试场景参数组存储于数据源中，从而实现对生产环境中真实测试案例的自动抓取，进而解决现有数据源生成方法的构造成本高的问题。因为抓取的测试案例是客观真实的，所以解决了解决现有数据源生成方法的测试准确率低的问题。
附图说明
图1为本发明实施例一提供的一种测试方法的流程图；
图2是本发明实施例二提供的一种测试方法的流程图；
图3是本发明实施例二提供的一种springaop的示意图；
图4是本发明实施例三提供的一种测试装置的结构示意图；
图5为本发明实施例四提供的一种设备的结构示意图。
具体实施方式
下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。
实施例一
图1为本发明实施例一提供的一种测试方法的流程图。本实施例可适用于对生产环境中的真实测试案例进行自动抓取，以降低数据源的构造成本，提高测试准确率的情况。参见图1，本发明实施例提供的测试方法包括：
s110、在业务人员执行待测试逻辑的过程中，从后台提取所述待测试逻辑的输入数据和输出数据。
其中，业务人员是指在生产过程中触发执行待测试逻辑的人。
待测试逻辑是指待测试的业务逻辑。具体可以是方法逻辑，也可以是接口逻辑。
后台是指实现网站编辑内容、修改、数据抓取等功能的系统。
通过从后台提取所述待测试逻辑的输入数据和输出数据，可以实现在业务人员无感知的情况下，输入数据和输出数据的抓取。
s120、根据所述输入数据和所述输出数据确定测试场景参数组，并将所述测试场景参数组存储于数据源中。
其中，数据源是存储测试场景参数组的存储介质。具体地，数据源可以是文件、数据库或表格等。
测试场景参数组是指描述测试场景的参数的组合。
s130、从所述数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据。
其中，场景生成逻辑是生成测试场景数据的逻辑。
测试场景数据是指描述测试场景的数据。
具体地，可以基于junit，从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据。
其中，junit是被广泛应用的java单元测试框架。
s140、根据所述至少两个测试场景数据，对所述待测试逻辑进行测试。
具体地，若待测试逻辑为控制接口逻辑，则根据所述至少两个测试场景数据，对所述待测试逻辑进行测试，可以包括：
根据所述至少两个测试场景数据，使用网络的形式，调用待测试控制接口逻辑；
根据所述待测试控制接口逻辑的输出结果，确定所述待测试控制接口逻辑的测试结果。
其中，控制结构逻辑是指描述控制接口的逻辑。控制接口是指web(网页)应用中的controller接口。
可选地，若待测逻辑为方法逻辑或除控制接口逻辑外的其他接口逻辑，则根据所述至少两个测试场景数据，对所述待测试逻辑进行测试，可以包括：
根据所述至少两个测试场景数据，生成至少两个测试场景的模拟对象；
将所述至少两个测试场景的模拟对象输入待测试逻辑中；
根据所述待测试逻辑的输出结果，确定所述待测试逻辑的测试结果。
本发明实施例通过在业务人员执行待测试逻辑的过程中，从后台提取所述待测试逻辑的输入数据和输出数据；根据所述输入数据和所述输出数据确定测试场景参数组，并将所述测试场景参数组存储于数据源中，从而实现对生产环境中真实测试案例的自动抓取，进而解决现有数据源生成方法的构造成本高和测试准确率低的问题。
实施例二
图2是本发明实施例二提供的一种测试方法的流程图。本实施例是在上述实施例的基础上，对上述s110和s130的进一步优化。参见图2，本发明实施例二提供的测试方法包括：
s111、基于springaop框架，在业务人员执行待测试逻辑的过程中，从后台提取所述待测试逻辑的输入数据和输出数据。
其中，springaop是spring框架中的一个关键组件，即面向切面的编程(aop)框架。面向切面的编程需要把程序逻辑分解成不同的部分称为的切点。跨一个应用程序的多个点的功能被称为横切关注点，这些横切关注点在概念上独立于应用程序的业务逻辑。springaop的应用场景，如日志记录、审计、声明式事务、安全性和缓存等。
参见图3，springaop可以实现对待测试方法逻辑或待测试接口逻辑进行输出报文或输出码，以及输入报文的响应。
s120、根据所述输入数据和所述输出数据确定测试场景参数组，并将所述测试场景参数组存储于数据源中；
s131、基于feed4junit单元测试框架，从所述数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据；
具体地，所述基于feed4junit，从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据，包括：
基于新的单元测试框架，从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据；
其中，所述新的单元测试框架通过修改feed4junit的继承关系得到，所述新的单元测试框架继承于spring框架的执行器。
其中，新的单元测试框架是一个与spring融合的单元测试框架，其实现了数据与代码分离，可以将测试用例和测试驱动代码完全分开，实现测试用例和测试代码的完全解耦，是本人通过扩展feed4junit源码实现，与junit4不是同一个框架，junit4没有实现数据与测试代码的分离，数据与代码需要耦合在一起。
spring框架是一个开源的java平台，它为容易而快速的开发出耐用的java应用程序提供了全面的基础设施，为了解决企业应用程序开发复杂性而创建的，目前，从国有企业到互联网企业，从传统民营企业到股份制企业等，涉及的web系统几乎都是通过spring框架构建。
s140、根据所述至少两个测试场景数据，对所述待测试逻辑进行测试。
本发明实施例的技术方案，通过将新的单元测试框架的数据和代码分离测试优势和springaop切面编程的特性优势相融合，利用springaop技术对源码程序没有任何无侵入的情况下实现测试案例的自动生成，即业务测试人员在进行正常业务测试的时候，本发明可以在业务人员无感的情况下自动抓取业务人员的录入测试案例并进行保存，生成测试案例。通过业务人员全场景测试，将每只交互的全场景测试案例保存到数据源中。根据这些案例，利用新的单元测试框架对接口、方法等进行回归测试。
换而言之，本发明实施例通过自动抓取业务测试人员或者开发人员的测试案例，并且可以部署到生产环境，抓取生产环境的真实测试案例，利用这些测试案例对系统的回归测试，解决了测试编写困难、测试用例覆盖不全、测试用例无法积累沉淀的问题，极大减轻了开发人员编写测试用例的压力、将业务测试、生产环境的用例沉淀和积累下来。
实施例三
图4是本发明实施例三提供的一种测试装置的结构示意图。参见图4，本申请实施例提供的测试装置，包括：数据抓取模块10、数据存储模块20、场景数据生成模块30和测试模块40。
其中，数据抓取模块10，用于在业务人员执行待测试逻辑的过程中，从后台提取所述待测试逻辑的输入数据和输出数据；
数据存储模块20，用于根据所述输入数据和所述输出数据确定测试场景参数组，并将所述测试场景参数组存储于数据源中；
场景数据生成模块30，用于从所述数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据；
测试模块40，用于根据所述至少两个测试场景数据，对所述待测试逻辑进行测试。
本发明实施例通过在业务人员执行待测试逻辑的过程中，从后台提取所述待测试逻辑的输入数据和输出数据；根据所述输入数据和所述输出数据确定测试场景参数组，并将所述测试场景参数组存储于数据源中，从而实现对生产环境中真实测试案例的自动抓取，进而解决现有数据源生成方法的构造成本高和测试准确率低的问题。
进一步地，所述数据抓取模块，包括：
数据抓取单元，用于基于springaop框架，在业务人员执行待测试逻辑的过程中，从后台提取所述待测试逻辑的输入数据和输出数据。
进一步地，所述场景数据生成模块，包括：
场景数据生成单元，用于基于feed4junit单元测试框架，从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据。
进一步地，所述场景数据生成单元，具体用于：
基于新的单元测试框架，从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据；
其中，所述新的单元测试框架通过修改feed4junit的继承关系得到，所述新的单元测试框架继承于spring框架的执行器。
实施例四
图5为本发明实施例四提供的一种设备的结构示意图。如图5所示，该设备包括处理器50、存储器51、输入装置52和输出装置53；设备中处理器50的数量可以是一个或多个，图5中以一个处理器50为例；设备中的处理器50、存储器51、输入装置52和输出装置53可以通过总线或其他方式连接，图5中以通过总线连接为例。
存储器51作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明实施例中的测试方法对应的程序指令/模块(例如，测试装置中的数据抓取模块10、数据存储模块20、场景数据生成模块30和测试模块40)。处理器50通过运行存储在存储器51中的软件程序、指令以及模块，从而执行设备的各种功能应用以及数据处理，即实现上述的测试方法。
存储器51可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器51可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器51可进一步包括相对于处理器50远程设置的存储器，这些远程存储器可以通过网络连接至设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
输入装置52可用于接收输入的数字或字符信息，以及产生与设备的用户设置以及功能控制有关的键信号输入。输出装置53可包括显示屏等显示设备。
实施例五
本发明实施例五还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行一种测试方法，该方法包括：
在业务人员执行待测试逻辑的过程中，从后台提取所述待测试逻辑的输入数据和输出数据；
根据所述输入数据和所述输出数据确定测试场景参数组，并将所述测试场景参数组存储于数据源中；
从所述数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据；
根据所述至少两个测试场景数据，对所述待测试逻辑进行测试。
当然,本发明实施例所提供的一种包含计算机可执行指令的存储介质,其计算机可执行指令不限于如上所述的方法操作,还可以执行本发明任意实施例所提供的测试方法中的相关操作。
通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(read-onlymemory,rom)、随机存取存储器(randomaccessmemory,ram)、闪存(flash)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
值得注意的是，上述测试装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。
注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。
1.一种测试方法，其特征在于，包括：
在业务人员执行待测试逻辑的过程中，从后台提取所述待测试逻辑的输入数据和输出数据；
根据所述输入数据和所述输出数据确定测试场景参数组，并将所述测试场景参数组存储于数据源中；
从所述数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据；
根据所述至少两个测试场景数据，对所述待测试逻辑进行测试。
2.根据权利要求1所述的方法，其特征在于，所述在业务人员执行待测试逻辑的过程中，从后台提取所述待测试逻辑的输入数据和输出数据，包括：
基于springaop框架，在业务人员执行待测试逻辑的过程中，从后台提取所述待测试逻辑的输入数据和输出数据。
3.根据权利要求1或2所述的方法，其特征在于，所述从所述数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据，包括：
基于feed4junit单元测试框架，从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据。
4.根据权利要求3所述的方法，其特征在于，所述基于feed4junit，从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据，包括：
基于新的单元测试框架，从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据；
其中，所述新的单元测试框架通过修改feed4junit的继承关系得到，所述新的单元测试框架继承于spring框架的执行器。
5.一种测试装置，其特征在于，包括：
数据抓取模块，用于在业务人员执行待测试逻辑的过程中，从后台提取所述待测试逻辑的输入数据和输出数据；
数据存储模块，用于根据所述输入数据和所述输出数据确定测试场景参数组，并将所述测试场景参数组存储于数据源中；
场景数据生成模块，用于从所述数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据；
测试模块，用于根据所述至少两个测试场景数据，对所述待测试逻辑进行测试。
6.根据权利要求5所述的装置，其特征在于，所述数据抓取模块，包括：
数据抓取单元，用于基于springaop框架，在业务人员执行待测试逻辑的过程中，从后台提取所述待测试逻辑的输入数据和输出数据。
7.根据权利要求5或6所述的装置，其特征在于，所述场景数据生成模块，包括：
场景数据生成单元，用于基于feed4junit单元测试框架，从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据。
8.根据权利要求7所述的装置，其特征在于，所述场景数据生成单元，具体用于：
修改feed4junit的继承关系，得到新的单元测试框架，使新的单元测试框架继承于spring框架的执行器；
基于新的单元测试框架，从数据源中读取至少两个测试场景参数组，并基于至少一个场景生成逻辑，根据读取的至少两个测试场景参数组，生成至少两个测试场景数据。
9.一种设备，其特征在于，所述设备包括：
一个或多个处理器；
存储装置，用于存储一个或多个程序，
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-4中任一所述的测试方法。
10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-4中任一所述的测试方法。
技术总结