CN106708719B - 业务功能的测试方法和装置 - Google Patents

Abstract

本申请公开了一种业务功能的测试方法和装置。其中，该方法包括：步骤A，输入测试数据给业务测试链路中的第一测试任务；步骤B，在第一测试任务测试通过之后，将运行第一测试任务得到的测试结果作为新的测试数据输入至第二测试任务，并启动运行第二测试任务；步骤C，根据步骤B的方法依次遍历业务测试链路中的所有测试任务，在任意一个测试任务测试通过之后，将测试通过的测试任务的测试结果作为下一个测试任务的输入，并启动运行下一个测试任务，直至获取到业务测试链路中的所有测试任务的测试结果。本申请解决了为了在集成测试中覆盖所有场景，测试用例会随测试任务的增加呈指数增加，而造成的测试效率低的技术问题。

Description

业务功能的测试方法和装置

技术领域

本申请涉及系统测试领域，具体而言，涉及一种业务功能的测试方法和装置。

背景技术

黑盒测试时通常着眼于系统整体，针对设定的输入数据，仅关注输出数据是否符合逻辑，也就是说，黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。然而，当系统中包含若干业务单元时，除了对每个业务单元进行测试外，还需要确保业务单元连接后，在全局上也能够正常的工作，此时会进行系统集成测试。

在复杂系统的集成测试中，测试人员会根据各个业务单元的模型测试完整的业务链路，从数据源开始，对数据链路中的各个业务逻辑进行测试验收，即以每一个业务单元运行结束作为一个检查点，来验证中间过程中的每一个输入输出逻辑是否符合预期，并且在得到最终的输出数据后，还要验证最终输出数据的正确性。在测试完整业务链路的过程中，需要覆盖中间过程使用的各种不同路径、算法、以及可能出现的异常情况。

目前比较成熟的系统集成测试框架如junit,testNg，一个测试用例的运行方式如下:beforeClass→before→Test→after→afterClass。其中beforeClass完成全局的初始化，针对一个测试类只运行一次；before对资源进行初始化，针对每一个测试方法(Test)都要执行一次；Test为测试方法，即测试用例的实施过程，运行结果作为该测试用例的执行结果；after释放before中初始化的资源，针对每一个测试方法都要执行一次；afterClass释放beforeClass的初始化的资源，针对一个测试类只执行一次。

然而，在一种可能的情况下，目前测试框架(junit/testng)在支持分布式复杂业务逻辑时，测试用例是串行运行的方式，使得对于复杂业务逻辑的业务测试，串行测试降低了系统整体测试的效率，延长了测试运行的时间。当然，可以设置测试框架增加并发运行机制，使得测试用例并发执行，进而使测试运行的速度有所加快，但是，并发运行机制要求测试用例之间的测试数据隔离，使得对于测试数据维护的开销极大的增加。

在另一种可能的情况下，目前测试框架通常预先设置测试用例，在测试用例的设计完成后，测试用例很少发生变动。而实际中，比如需要在全链测试环节中增加一个异常测试任务(比如增加一个服务的主备切换操作)，为了覆盖所有场景，根据上述测试用例设计逻辑，增加的测试用例需要翻倍，这导致了目前测试框架的扩展性较差。

在又一种可能的情况下，目前的测试框架中，当任何一个环节必须发生变换时，其中一个环节的变换会影响到所有相关的测试用例；比如原有业务链路中一个功能下线后，需要变更所有包含该测试任务的测试用例。

在再一种可能的情况下，如果其中某一个核心测试任务失败，导致当前用例失败，当然也会导致后续所有测试用例失败，而目前测试框架感知不到，仍然会继续运行下一个测试用例。由于核心测试任务有问题，结果可想而知，还是失败。花费较长时间做无用功。

针对上述为了在集成测试中覆盖所有场景，测试用例会随测试任务的增加呈指数增加，而造成的测试效率低的问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种业务功能的测试方法和装置，以至少解决为了在集成测试中覆盖所有场景，测试用例会随测试任务的增加呈指数增加，而造成的测试效率低的技术问题。

根据本申请实施例的一个方面，提供了一种业务功能的测试方法，包括：步骤A，输入测试数据给业务测试链路中的第一测试任务；步骤B，在第一测试任务测试通过之后，将运行第一测试任务得到的测试结果作为新的测试数据输入至第二测试任务，并启动运行第二测试任务，其中，第二测试任务为依赖于第一测试任务的任意一个测试任务；步骤C，根据步骤B的方法依次遍历业务测试链路中的所有测试任务，在任意一个测试任务测试通过之后，将测试通过的测试任务的测试结果作为下一个测试任务的输入，并启动运行下一个测试任务，直至获取到业务测试链路中的所有测试任务的测试结果，其中，下一个测试任务依赖于测试通过的测试任务。

根据本申请实施例的另一方面，还提供了一种业务功能的测试装置，包括：第一测试模块，用于输入测试数据给业务测试链路中的第一测试任务；第二测试模块，用于在第一测试任务测试通过之后，将运行第一测试任务得到的测试结果作为新的测试数据输入至第二测试任务，并启动运行第二测试任务，其中，第二测试任务为依赖于第一测试任务的任意一个测试任务；第三测试模块，用于执行第二测试模块的功能依次遍历业务测试链路中的所有测试任务，在任意一个测试任务测试通过之后，将测试通过的测试任务的测试结果作为下一个测试任务的输入，并启动运行下一个测试任务，直至获取到业务测试链路中的所有测试任务的测试结果，其中，下一个测试任务依赖于测试通过的测试任务。

在本申请实施例中，采用预先定义测试任务之间依赖关系的方式，通过在测试任务测试通过后，获取依赖于该测试任务的下游测试任务，并运行依赖于该测试任务的下游测试任务，达到了在该下游测试任务测试通过后，获取并运行依赖于该下游测试任务的测试任务的目的，如此依次执行，从而实现了以更短的时间开销获取业务测试链中所有测试任务的测试结果的技术效果，进而解决了为了在集成测试中覆盖所有场景，测试用例会随测试任务的增加呈指数增加，而造成的测试效率低的技术问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据现有技术的一种测试运行模型的示意图；

图2是根据本申请实施例的一种业务功能的测试方法的计算机终端的硬件结构框图；

图3是根据本申请实施例一的业务功能的测试方法的流程示意图；

图4是根据本申请实施例一的一种可选地测试运行模型的示意图；

图5是根据本申请实施例一的一种可选的业务功能的测试方法的流程示意图；

图6是根据本申请实施例二的业务功能的测试装置的结构示意图；

图7是根据本申请图6所示实施例的一种可选的第二测试模块的结构示意图；

图8是根据本申请图7所示实施例的一种可选的业务功能的测试装置的结构示意图；

图9是根据本申请图8所示实施例的一种可选的业务功能的测试装置的结构示意图；以及

图10是根据本申请实施例的一种计算机终端的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本申请涉及到的名词解释如下：

云端：一种用于提供远程数据存储和访问的云服务，例如阿里巴巴提供的阿里云服务器，解决大数据存储，数据开发，数据同步，离线，实时，离线数据计算，实时数据计算，极限存储，数据清洗，数据质量监控等完整的大数据解决方案。

数据链路：或称业务链路，是一个端到端的解决方案，一般由多个子系统合作，从业务方的数据库导出数据开始，同步到云端进行分析和处理，最后回流到业务方。

测试任务:一个数据链路中针对某一个功能进行验收的逻辑，通常完成服务调用，数据输出检查等功能。

测试依赖:用户在复杂的分布式系统集成测试中，会根据业务链路定义各种测试任务，而所定义的测试任务常常会彼此依赖，如测试A依赖测试B的结束或者输出，A的输出会作为另一个测试C的输入。这种测试之间的依赖关系定义为测试依赖。

此处需要说明的是，对于复杂业务场景的系统集成测试，测试人员会根据业务模型，测试完整的业务链路，并考虑覆盖中间过程使用的不同的路径和算法以及可能出现的异常情况，从数据源数据产出开始，验证中间每一个输入输出逻辑是否符合预期，并验证最后回流数据的的正确性。

此处还需要说明的是，可以看出上面涉及的测试模型中，测试任务之间是相互影响，一个测试任务的完成触发下一个测试任务的启动，每个测试任务完成全链测试中一个业务逻辑的测试，如传输时采用实时还是离线，或者不同的离线数据分析方法。不同的测试任务组成一条新的测试链路，不同的测试链路之间有重叠的部分，比如一个测试链测试重点在离线计算采用不同的算法，那么算法之前的测试过程是相同，这部分考虑是否可以重用，即对于重复的的测试过程，测试框架只需要执行一遍即可。同时，测试任务执行是有依赖的，一个任务的输出是另一个任务的输入，也就是定义出测试任务间的依赖关系，根据依赖关系运行测试用例。

本申请提供的实施例可以与如下应用场景下的示例进行比对说明，下面将该应用场景的一种可选方案举例说明如下：

以云端分布式业务场景为例，在云端分布式的业务应用场景中，一个典型数据链路由如下业务逻辑组成：业务1、数据产生(本申请中或称A)，即业务方产生数据源；业务2、数据传输(本申请中或称B)，即将数据从关系型数据库传输至云端；业务3、数据清洗(本申请中或称C)，即取出业务方数据中无用的信息；业务4、数据存储(本申请中或称D)；业务5、数据分析(本申请中或称E)；业务6、数据回流(本申请中或称F)。

此处需要说明的是，在上述云端分布式业务场景中，数据传输B例如的可以通过离线方式和实时方式两种路径(本申请中或称B1和B2)；数据清洗C例如的可以使用两种不同清洗方式(本申请中或称C1和C2)；数据存储D例如的可以映射两种不同的索引字段(本申请中或称D1和D2)；数据分析E例如的可以借助两种不同的分析算法(本申请中或称E1和E2)；数据回流F例如的回流至两个不同的业务方(本申请中或称F1和F2)。

针对上述云端分布式业务场景中的一个数据链路，测试人员可以从该数据链路中抽象出如下的测试任务：任务1、模拟业务方产生数据源(本申请中或称A’)，例如，产生1000条记录/分钟，持续30分钟；任务2.模拟数据的同步传输(本申请中或称B’)。即测试数据同步的功能，例如，通过实时(本申请中或称B1’)或者离线(本申请中或称B2’)的方式将任务1中产生数据上传到云端，传输完成后进行数据对比，判断是否符合预期；任务3.模拟数据清洗(本申请中或称C’)。即测试数据清洗的功能，例如，对完成上传到云端的数据通过两种方式(本申请中或称C1’、C2’)进行清洗，去除不需要的信息，清洗完成后，验收结果表，判断是否符合预期；任务4.模拟数据的极限存储(本申请中或称D’)，即测试数据极限存储的功能，例如，对清洗完成后的数据采用两种不同的极限存储方式(本申请中或称D1’、D2’)，以使得提高数据的存储效率。在极限存储完成后，验证存储结果符合预期。任务5.模拟数据分析(本申请中或称E’)，即测试数据分析算法的功能，例如，对数据通过两种不同的算法(本申请中或称E1’、E2’)进行离线计算，得到极限存储后的数据的结算结果，验证运算结果是否符合预期；任务6.模拟数据回流(本申请中或称F’)，即测试数据回流的功能，例如，对模拟数据分析完成的运算结果数据回流到不同的业务方(本申请中或称F1’、F2’)，验证回流的数据符合预期。

首先结合上述具体应用场景，对相关技术中的方法进行说明如下：

假设在上述具体实例中使用jun it作为测试框架，则各个阶段目标定义如下：beforeCl ass:完成数据源数据模拟A’。before:数据源数据确认。Test:一次全链路业务测试。After:回流数据验收通过，符合预期。afterCl ass:清空测试数据。

具体的，一个测试用例包括：模拟数据的同步传输B，即启动离线传输模式，数据传输完成，数据验收通过；模拟数据清洗C，即启动数据清洗功能，清洗完成，清洗结果检查通过；模拟数据的极限存储D，即启动极限存储方案1，存储结果验收通过；模拟数据分析E，即启动离线数据计算，计算结果验证通过；模拟数据回流F，即启动数据回流，数据回流完成。其中，在每一个测试用例执行完上述阶段后，转去启动下一个测试用例，直至所有测试用例执行完毕。在所有测试用例执行完成后，对当前测试类的执行完成，生成并输出测试报告。

图1是根据现有技术的一种测试运行模型的示意图，结合图1所示，根据业务模型设计如下测试场景，针对一个数据源的某一张表产生模拟数据，根据中间过程的变化和不同的路径，算法，一个覆盖全场景的完整的业务测试链路如下：

A’→B1’→C1’→D1’→E1’→F1’

A’→B2’→C1’→D1’→E1’→F1’

A’→B1’→C2’→D1’→E1’→F1’,

A’→B1’→C1’→D2’→E1’→F1’

……

根据中间过程的变化点组合，由于有2种数据传输路径，2种数据清洗方式，2种数据存储方式，2种数据分析方法，2种数据回流业务方，因此，共有2*2*2*2*2＝32种场景需要功能测试。测试人员会设计32个测试用例进行测试。

可以看出，即便为了提高效率，将数据源数据产生可抽象到beforeClass中只运行一次，在相关技术中，使用上述测试框架进行此类系统集成测试的时间开销仍旧高至：32*5T+T，其中，为简化计算，假设各个测试任务运行时间一样都为T；5T为运行一次Test所需的时间。进一步地，如果考虑从不同的数据源(mySql,oracle)产生数据，那么运行整个回归的时间开销为n*(32*5T+T),其中，n为数据源类型。

实施例1

根据本申请实施例，还提供了一种业务功能的测试方法的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请实施例一所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在计算机终端上为例，图2是根据本申请实施例的一种业务功能的测试方法的计算机终端的硬件结构框图。如图2所示，计算机终端10可以包括一个或多个(图中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输模块106。本领域普通技术人员可以理解，图2所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算机终端10还可包括比图2中所示更多或者更少的组件，或者具有与图2所示不同的配置。

存储器104可用于存储应用软件的软件程序以及模块，如本申请实施例中的业务功能的测试方法对应的程序指令/模块，处理器102通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的漏洞检测方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端10的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

在上述运行环境下，本申请提供了如图3所示的业务功能的测试方法。图3是根据本申请实施例一的业务功能的测试方法的流程图。

结合图2和图3可知，上述计算机终端10可以是执行测试任务的终端设备。如图3所示，一种可选的业务功能的测试方法包括如下实施步骤：

步骤S302：输入测试数据给业务测试链路中的第一测试任务。

本申请上述步骤S302中，一个业务逻辑中一般会包含多个子业务逻辑组成，每个子业务逻辑完成不同的任务。业务逻辑中的数据在经过比较长的业务链路后，输出业务结果给最终用户使用。业务测试链路，可以是对设计完成的业务链路进行测试时定义的测试链路。在一个业务测试链路中会定义至少一个测试任务。第一测试任务可选的为业务测试链路中的根任务节点，例如模拟业务方产生数据，此时测试数据用于触发根任务节点运行，输出结果为模拟的业务方产生的数据。

在一种可选场景中，业务测试链路中可能包含数据产生、数据传输、数据处理等业务逻辑。在测试完整的业务链路时，需要对每一个业务逻辑进行测试验收，因而会将每一个业务功能的运行结束设置为一个检查点。同时，中间的业务逻辑可能会使用不同的路径，例如可通过不同的传输路径来传输数据，通过不同的算法来处理数据等。因此在测试完整的业务链路时，针对一个业务逻辑，可能会定义与路径相对应的多个测试任务。此处需要说明的是，业务链路中间的某些业务功能并非一定要定义测试任务。

例如，以云端分布式业务场景为例，第一测试任务为数据产生任务A，运行第一测试任务A后，得到的第一测试任务A的结果为模拟的业务方产生的数据。第一测试任务为云端分布式业务场景的典型数据链路中的最上游的任务。

步骤S304：在第一测试任务测试通过之后，将运行第一测试任务得到的测试结果作为新的测试数据输入至第二测试任务，并启动运行第二测试任务，其中，第二测试任务为依赖于第一测试任务的任意一个测试任务。

本申请上述步骤S304中，一个业务逻辑中包含的多个子业务逻辑之间可以互相依赖，即一个子业务逻辑的输出作为另一个子业务逻辑的输入，或者一个子业务逻辑过程跨多个子系统，需要和不同的系统交互。当测试任务之间产生测试依赖时，测试任务之间是相互影响的，即一个测试任务的完成触发下一个测试任务的启动，一个测试任务的输出结果作为下一个测试任务的输入数据。

此处需要说明的是，本申请实施例的业务测试链路，不同于相关技术中的业务测试链路。结合图1可知，相关技术中通常会组成若干条测试链路，不同的测试链路之间有重叠的部分。而即便是重叠的部分，在每一条测试链路都要再次运行。

在本申请实施例所提供的可选方案中，当业务测试链路中定义了多个测试任务时，所定义的测试任务之间可能会产生测试依赖。考虑到测试任务的业务逻辑之间的关系，为每一个测试任务定义上下游关系，即确定每一个测试任务所依赖的上游测试任务，以及确定每一个测试任务被依赖的下游测试任务，也就是定义出测试任务间的依赖关系。在测试运行时，会根据预先定义的测试任务之间的依赖关系来运行测试用例，而不会依次执行组成的每一条测试链路，例如，在第一测试任务运行结束并验证通过后，根据预先定义测试任务间的依赖关系，运行依赖于第一测试任务的第二测试任务；当有多个测试任务均依赖于第一测试任务时，则分别运行依赖于第一测试任务的其他测试任务，对于第一测试任务及其上游的测试任务，避免了相同测试链路的重复运行。

仍旧以云端分布式业务场景为例，数据产生任务A运行后产生的数据，需要同步传输至云端，而同步传输至云端的方式可以为实时方式B1，也可以为离线方式B2，因此，可以预先定义实时数据传输任务B1和离线数据传输任务B2为依赖于数据产生任务A的下游测试任务。当数据产生任务A测试通过后，将数据产生任务A所产生的数据输入至数据传输任务B1和B2，并启动运行数据传输任务B1和B2，分别将数据产生任务A所输出的数据通过实时和离线方式模拟上传至云端。

步骤S306：根据步骤S304的方法依次遍历业务测试链路中的所有测试任务，在任意一个测试任务测试通过之后，将测试通过的测试任务的测试结果作为下一个测试任务的输入，并启动运行下一个测试任务，直至获取到业务测试链路中的所有测试任务的测试结果，其中，下一个测试任务依赖于测试通过的测试任务。

本申请上述步骤S306中，根据步骤S304的方法依次遍历业务测试链路中的所有测试任务可以包括：当第二测试任务测试通过之后，将运行第二测试任务得到的测试结果作为新的测试数据输入至第三测试任务，并启动运行第三测试任务，其中，第三测试任务为依赖于第二测试任务的任意一个测试任务；同样的，当第三测试任务测试通过之后，将运行第三测试任务得到的测试结果作为新的测试数据输入至第四测试任务，并启动运行第四测试任务，其中，第四测试任务为依赖于第三测试任务的任意一个测试任务，依次类推，直至运行完业务测试链路中的所有测试任务并获取到所有测试任务的测试结果。

仍旧以云端分布式业务场景为例，图4是根据本申请实施例一的一种可选地测试运行模型的示意图；结合图4可知，预先定义的测试任务之间的依赖关系为：依赖A的下游测试任务为B1和B2，依赖B1和B2的下游测试任务均为C1和C2，依赖C1和C2的下游测试任务均为D1和D2，依赖D1和D2的下游测试任务均为E1和E2，依赖E1和E2的下游测试任务均为F1和F2，其中，A为数据产生任务，B1为实时数据传输任务，B2为离线数据传输任务，C1为基于方法一数据清洗任务，C2为基于方法二的数据清洗任务，D1为映射索引字段一的数据存储任务，D2为映射索引字段二的数据存储任务，E1为基于算法一的数据分析任务，E2为基于算法二的数据分析任务，F1为回流至业务方一的数据回流任务，F2为回流至业务方二的数据回流任务。

具体的，在任务A测试通过后，将任务A中产生的数据分别输入至依赖任务A的任务B1和任务B2；以任务B1为例(任务B2同理)，在任务B1测试通过后，将任务B1中上传至云端的数据分别输入至依赖任务B1的任务C1和任务C2；以任务C1为例(任务C2同理)，在任务C1测试通过后，将任务C1中清洗完成的数据分别输入至任务D1和任务D2，后续流程可依次类推。从上述分析可以看出，对于重复的的测试过程，本申请实施例中的测试框架只需要执行一遍，测试用时少、效率高，在更为复杂的分布式业务测试中，本申请实施例所提供的测试方法效果更佳。

下面对本申请实施例中的测试用时与相关技术中的测试用时进行比较说明：

在相关技术的测试中，假设为了测试数据回流的不同方法F1,F2，之前的测试链路会重复运行两次(X→F1，X→F2)，相关技术中的测试执行逻辑为：

A→B→C→D→E→F1测试用例1

A→B→C→D→E→F2测试用例2

由上述可知，相关技术中的测试所需的运行开销为:12T。

在本发明实施例中，测试执行逻辑为：

A→B→C→D→E→F1/F2

由上述可知，本发明实施例中的测试所需的运行开销：6T。通过与相关技术中的运行时间比对可知，在相同的数据源下，本申请实施例中的测试方法针对重复运行的测试过程只运行一次，从而极大的缩短测试运行时间，节省了测试开销。

表1：

	A	B	C	D	E	F
							本发明实施例	1	2	4	8	16	32
相关技术	1	32	32	32	32	32

上表1为本申请实施例中的测试任务运行次数与相关技术中的测试任务运行次数的比对结果，由上表1可知，当任务节点数为n，且假设是每个任务节点只有两种变化时，本发明实施例中所有测试任务的总运行次数为2ⁿ-1，相关技术中的所有测试任务的总运行次数为(n-1)*2^(n-1)+1。

由上可知，在本申请实施例中，采用预先定义测试任务之间依赖关系的方式，通过在测试任务测试通过后，获取依赖于该测试任务的下游测试任务，并运行依赖于该测试任务的下游测试任务，达到了在该下游测试任务测试通过后，获取并运行依赖于该下游测试任务的测试任务的目的，如此依次执行，从而实现了以更短的时间开销获取业务测试链中所有测试任务的测试结果的技术效果，进而解决了为了在集成测试中覆盖所有场景，测试用例会随测试任务的增加呈指数增加，而造成的测试效率低的技术问题。本申请实施例中的测试方法，在测试执行依靠测试任务依赖关系进行，使得重复的测试场景仅运行一次，极大的提升运行效率。

本申请上述实施例提供的一种可选方案中，步骤S304：在第一测试任务测试通过之后，将运行第一测试任务得到的测试结果作为新的测试数据输入至第二测试任务，并启动运行第二测试任务包括如下具体实施步骤：

步骤S3042：运行第一测试任务，在第一测试任务测试通过的情况下，生成第一测试结果。

步骤S3044：从业务测试链路中获取依赖于第一测试任务的至少一个第二测试任务。

本申请上述步骤S3044中，当业务测试链路中不存在依赖于第一测试任务的第二测试任务时，则确定该业务测试链路中的所有测试任务均运行过。

步骤S3046：将第一测试结果作为新的测试数据输入至任意一个第二测试任务。

步骤S3048：启动运行任意一个第二测试任务，生成任意一个第二测试任务的测试结果。

由上可知，本申请上述步骤S3042至步骤S3048提供了一种业务测试链路中测试链路的运行方法，通过启动运行第一测试任务并生成第一测试结果，并将第一测试结果输入给获取到的依赖于第一测试任务的第二测试任务，然后触发运行第二测试任务并得到第二测试结果。

可选地，在步骤S306中，针对每一个当前测试任务，都可以使用步骤S3042至步骤S3048所提供的方案，具体的，当前测试任务被触发后，则运行当前测试任务，在当前测试任务测试通过的情况下，生成当前测试结果；从业务测试链路中获取依赖于当前测试任务的至少一个下游测试任务，若不存在下游测试任务，则认为已经获取到业务测试链路中的所有测试任务的测试结果；将当前测试结果作为新的测试数据输入至当前测试任务的至少一个下游测试任务；启动运行该至少一个下游测试任务，生成该至少一个下游测试任务的测试结果。

本申请上述实施例提供的一种可选方案中，在执行步骤S3044：在从业务测试链路中获取依赖于第一测试任务的至少一个第二测试任务之前，还可以执行如下实施步骤：

步骤S30432：判断业务测试链路中是否存在依赖于第一测试任务的测试任务。

本申请上述步骤S30432中，根据预先定义的测试任务之间的依赖关系，判断是否存在依赖于第一测试任务的测试任务。例如，可以通过查询比对的方式，从预先定义的数据表中进行查询，当能够查询到第一测试任务所关联的下游测试任务后，则判断出业务测试链路中存在依赖于第一测试任务的测试任务。相应的，针对每一个当前测试任务，都可在当前测试任务运行通过后、或者在获取依赖当前测试任务的下游测试任务之前，先判断是否存在依赖当前测试任务的下游测试任务。

步骤S30434：在业务测试链路中存在依赖于第一测试任务的测试任务的情况下，执行从业务测试链路中获取依赖于第一测试任务的至少一个第二测试任务的步骤。

由上可知，本申请上述步骤S30432至步骤S30434提供了一种触发第二测试任务运行的可选方案，首先判断业务测试链路中是否存在依赖于第一测试任务的测试任务，在业务测试链路中存在依赖于第一测试任务的测试任务的情况下，才执行从业务测试链路中获取依赖于第一测试任务的至少一个第二测试任务的步骤。

本申请上述实施例提供的一种可选方案中，在执行步骤S30432：判断业务测试链路中是否存在依赖于第一测试任务的测试任务之后，还可以执行如下实施步骤：

步骤S30436：在业务测试链路中不存在依赖于第一测试任务的测试任务的情况下，生成当前业务测试链路所包含的测试任务的测试报告。

由上可知，本申请上述步骤S30436提供了一种触发生成测试报告的可选方式，在业务测试链路中，在没有下游测试任务依赖当前测试任务时，则确定当前业务测试链路中的测试任务均已运行，获取每一个测试任务的测试结果，生成该测试报告。

本申请上述实施例提供的一种可选方案中，业务测试链路中包含多个测试任务，每个测试任务之间具有有向关系，多个测试任务构成的测试任务依赖关系图为一个有向无环图。

具体的，本申请实施例中，整个业务链测试形成一个有向无环测试任务依赖关系图，测试运行时参照测试依赖图，对于一份测试数据输入，从根节点往下依次运行，避免相同的测试链路重复运行。其中，“有向”主要通过依赖关系来确定，即，业务测试链路中测试任务的运行方向，是从当前测试任务向依赖当前测试任务的下游测试任务运行。本申请提供的上述测试任务依赖关系图，可以解决复杂的分布式业务测试，通过为每一个测试任务定义上下游关系，从而设定了触发测试任务的逻辑，使得业务测试链路中的测试任务可以依照依赖关系来运行。

可选地，在定义业务测试链路的过程中，需要考虑如下基本要素：测试任务名称、测试任务的依赖关系、测试任务本身逻辑、测试上下文以及测试任务出错处理逻辑，其中，测试任务名称可以为测试任务的计算机可读标识，例如0010任务，也可为测试任务的表意标识，例如离线数据同步测试任务和实时数据同步测试任务，测试任务名称可选的全局唯一。测试任务的依赖关系包括：当前测试任务所依赖的上游测试任务的名称，以及测试任务所被依赖的下游测试任务的名称，其中，当前测试任务的上游测试任务和下游测试任务均可为多个。测试任务本身逻辑：如调用服务接口启动数据离线同步任务。测试上下文：读取上游测试任务的输出，如一个目标表地址。存放本测试任务的输出。测试任务出错处理逻辑：继续测试，终止测试。

本申请上述实施例提供的一种可选方案中，通过定义任意一个测试任务的有向依赖关系，使得在测试任务依赖关系图中增加或删除一个测试任务。

具体的，当需要在业务测试链路中增加一个测试任务时，通过在测试任务依赖关系图中，增加一个测试任务，并对应修改该测试任务的依赖关系，即增加或修改该测试任务所依赖的上游测试任务以及该测试任务所被依赖的下游测试任务，即可实现在业务测试链路中增加一个测试任务的功能。同理，当需要在业务测试链路中删除(或称下线)一个测试任务时，通过在测试任务依赖关系图中，删除该测试任务，并对应修改该测试任务的依赖关系，即删除该测试任务与上游测试任务或下游测试任务之间的依赖关系，并对应修改该上游测试任务或下游测试任务的依赖任务，即可实现在业务测试链路中删除一个测试任务的功能。

仍旧以云端分布式业务场景为例，假设需要在模拟数据分析任务E后，增加一个一个模拟数据质量检测任务P时，对图4中所示的测试任务之间的依赖关系修改为：依赖A的下游测试任务为B1和B2，依赖B1和B2的下游测试任务均为C1和C2，依赖C1和C2的下游测试任务均为D1和D2，依赖D1和D2的下游测试任务均为E1和E2，依赖E1和E2的下游测试任务修改为P，依赖P的下游测试任务修改为F1和F2。而在相关技术中，在需要新增任务P时，则需要修改所有测试链路(在云端分布式业务场景中测试链路包含32个)，来增加对新增的测试任务P的调用。

由此可见，一个分布式业务测试中，本申请实施例中的业务功能的测试方法通过根据业务(数据)模型定义出一个业务链路中需关注的测试任务集(测试检查点)，并根据业务模型关系定义测试任务依赖关系图，即形成测试任务运行的有向无环图。当需要在业务测试链路中增加或删除一个测试检查点时，可以基于对有向无环图的修改，来修正图中测试任务之间的依赖关系，使得修改后的方案可以基于图的修改而自动化测试运行，也使得测试任务更易维护。

下面对相关技术中的增加或删除测试测试任务的方案，与本申请中增加或删除测试任务的方案进行比对说明：

在相关技术中，如果需要在业务链路中增加一个测试任务，对应变更的测试用例为N,其中，N为现有的测试用例。如果需要在业务链路中下线一个测试任务，对应修改的测试用例为N,N为现有的测试用例。

例如，更具体的，如果要增加一个新的测试任务Y：

在相关技术的原有模型中，如增加一个新的测试任务Y的模型包括：

A→B→C→D→Y→E→F1；

A→B→C→D→Y→E→F2；

而在根据本申请实施例中，如增加一个新的测试任务Y的模型包括：

A→B→C→D→Y→E→F1/F2。

可以看出，增加新的测试任务，本申请实施例中只需要变更一次。

又例如，更具体的，如果要下线一个测试任务C：

在相关技术的原有模型中，如下线一个新的测试任务C的模型包括：

A→B→D→Y→E→F1

A→B→D→Y→E→F2

可以看出，在相关技术中，设计到测试用例都需要变更。

在本申请实施例中，如下线一个新的测试任务C的模型包括：

A→B→D→Y→E→F1/F2

本申请上述实施例提供的一种可选方案中，业务测试链路中至少包括如下任意一个或多个测试任务：模拟业务终端产生源数据、模拟数据的同步传输、模拟数据清洗、模拟数据的极限存储、模拟数据分析和模拟数据回流。

图5是根据本申请实施例一的一种可选的业务功能的测试方法的流程示意图；下面就结合图4与图5所示，将本申请的方案应用在应用场景所实现的功能进行详细描述：

步骤A：启动根节点作为当前测试任务节点。

具体的，在上述步骤A中，根节点为测试任务的开始节点，在云端分布式业务场景中，根节点为数据产生节点A。

步骤B：当前测试任务节点运行结束。

具体的，在上述步骤B中，运行当前测试任务节点，在当前测试任务节点测试通过的情况下，生成当前测试测试结果。

步骤C：判断是否有下游测试任务节点。

具体的，在上述步骤C中，从预先定义的有向无环测试任务依赖关系图中，查找是否有依赖当前测试任务节点的下游测试任务节点，在判断为是的情况下，执行步骤D，在判断为否的情况下，执行步骤E。

步骤D：启动下游测试任务节点作为当前测试任务节点。

具体的，在上述步骤D中，在步骤C中判断出存在下游测试任务节点的情况下，将查找到的下游测试任务节点作为当前测试任务节点，并返回执行步骤B，直至在步骤C中不存在下游任务节点，意味着当前有向无环测试任务依赖关系图中的测试任务已运行完毕。

步骤E：生成当前测试链路报告。

步骤F：完成测试任务，运行完毕。

步骤G：生成测试任务报告。

通过上述步骤A至步骤G，在复杂的分布式业务测试中，根据业务链路整理出链路涉及到的各个子功能，每个功能定义成一个测试任务(检查点)，根据子功能间的关系，为每一个测试任务定义上下游关系，从而整个业务链测试形成一个有向无环图测试任务依赖关系图，测试运行时参照测试依赖图，对于一份测试数据输入，从根节点往下依次运行，避免相同的测试链路重复运行。测试链路中增加(去除)一个新的依赖节点变得非常容易，只需要定义测试任务，变更测试依赖关系即可。解决了一个分布式场景下业务集成测试中测试任务彼此依赖的情况下，如何更好的管理测试用例，提高测试用例的执行效率，扩展性和维护性。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

实施例2

根据本申请实施例，还提供了一种用于实施上述业务功能的测试方法的业务功能的测试装置，本申请上述实施例所提供的装置可以在图2所示的计算机终端上运行。

图6是根据本申请实施例二的业务功能的测试装置的结构示意图；如图6所示，该装置包括：第一测试模块602、第二测试模块604以及第三测试模块606,其中：

第一测试模块602，用于输入测试数据给业务测试链路中的第一测试任务。

第二测试模块604，用于在第一测试任务测试通过之后，将运行第一测试任务得到的测试结果作为新的测试数据输入至第二测试任务，并启动运行第二测试任务，其中，第二测试任务为依赖于第一测试任务的任意一个测试任务。

第三测试模块606，用于执行第二测试模块的功能依次遍历业务测试链路中的所有测试任务，在任意一个测试任务测试通过之后，将测试通过的测试任务的测试结果作为下一个测试任务的输入，并启动运行下一个测试任务，直至获取到业务测试链路中的所有测试任务的测试结果，其中，下一个测试任务依赖于测试通过的测试任务。

由上可知，本申请上述第一测试模块602、第二测试模块604以及第三测试模块606提供了一种业务功能的测试装置，采用预先定义测试任务之间依赖关系的方式，通过在测试任务测试通过后，获取依赖于该测试任务的下游测试任务，并运行依赖于该测试任务的下游测试任务，达到了在该下游测试任务测试通过后，获取并运行依赖于该下游测试任务的测试任务的目的，如此依次执行，从而实现了以更短的时间开销获取业务测试链中所有测试任务的测试结果的技术效果，进而解决了为了在集成测试中覆盖所有场景，测试用例会随测试任务的增加呈指数增加，而造成的测试效率低的技术问题。本申请实施例中的测试方法，在测试执行依靠测试任务依赖关系进行，使得重复的测试场景仅运行一次，极大的提升运行效率。

此处需要说明的是，上述第一测试模块602、第二测试模块604以及第三测试模块606，对应于实施例一中的步骤S302至步骤S306，三个模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例一所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在实施例一提供的计算机终端10中，可以通过软件实现，也可以通过硬件实现。

可选地，图7是根据本申请图6所示实施例的一种可选的第二测试模块的结构示意图；如图7所示，根据本申请实施例的第二测试模块604包括：第一运行单元702、获取单元704、输入单元706以及第二运行单元708，其中：

第一运行单元702，用于运行第一测试任务，在第一测试任务测试通过的情况下，生成第一测试结果。

获取单元704，用于从业务测试链路中获取依赖于第一测试任务的至少一个第二测试任务。

输入单元706，用于将第一测试结果作为新的测试数据输入至任意一个第二测试任务。

第二运行单元708，用于启动运行任意一个第二测试任务，生成任意一个第二测试任务的测试结果。

由上可知，本申请上述第一运行单元702、获取单元704、输入单元706以及第二运行单元708提供了一种可选的业务测试链路中测试链路的运行方案，通过启动运行第一测试任务并生成第一测试结果，并将第一测试结果输入给获取到的依赖于第一测试任务的第二测试任务，然后触发运行第二测试任务并得到第二测试结果。

此处需要说明的是，上述第一运行单元702、获取单元704、输入单元706以及第二运行单元708，对应于实施例一中的步骤S3042至步骤S3048，四个模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例一所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在实施例一提供的计算机终端10中，可以通过软件实现，也可以通过硬件实现。

可选地，图8是根据本申请图7所示实施例的一种可选的业务功能的测试装置的结构示意图；如图8所示，根据本申请实施例的装置还包括：判断单元802以及第一执行单元804，其中:

判断单元802，用于判断业务测试链路中是否存在依赖于第一测试任务的测试任务。

第一执行单元804，用于在业务测试链路中存在依赖于第一测试任务的测试任务的情况下，执行从业务测试链路中获取依赖于第一测试任务的至少一个第二测试任务的步骤。

由上可知，本申请上述判断单元802以及第一执行单元804提供了一种触发第二测试任务运行的可选方案，首先判断业务测试链路中是否存在依赖于第一测试任务的测试任务，在业务测试链路中存在依赖于第一测试任务的测试任务的情况下，才执行从业务测试链路中获取依赖于第一测试任务的至少一个第二测试任务的步骤。

此处需要说明的是，上述判断单元802以及第一执行单元804，对应于实施例一中的步骤S30432至步骤S30434，两个模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例一所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在实施例一提供的计算机终端10中，可以通过软件实现，也可以通过硬件实现。

可选地，图9是根据本申请图8所示实施例的一种可选的业务功能的测试装置的结构示意图；如图9所示，根据本申请实施例的装置还包括：第二执行单元902，其中：

第二执行单元902，用于在业务测试链路中不存在依赖于第一测试任务的测试任务的情况下，生成当前业务测试链路所包含的测试任务的测试报告。

由上可知，本申请上述第二执行单元902提供了一种触发生成测试报告的可选方式，在业务测试链路中，在没有下游测试任务依赖当前测试任务时，则确定当前业务测试链路中的测试任务均已运行，获取每一个测试任务的测试结果，生成该测试报告。

此处需要说明的是，上述第二执行单元902，对应于实施例一中的步骤S30436，模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例一所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在实施例一提供的计算机终端10中，可以通过软件实现，也可以通过硬件实现。

可选地，业务测试链路中包含多个测试任务，每个测试任务之间具有有向关系，多个测试任务构成的测试任务依赖关系图为一个有向无环图。

可选地，通过定义任意一个测试任务的有向依赖关系，使得在测试任务依赖关系图中增加或删除一个测试任务。

可选地，业务测试链路中至少包括如下任意一个或多个测试任务：模拟业务终端产生源数据、模拟数据的同步传输、模拟数据清洗、模拟数据的极限存储、模拟数据分析和模拟数据回流。

本申请上述实施例二所提供的优选实施方案与实施例一所提供的方法实施例的可选方案以及应用场景实施过程相同，但不限于实施例一所提供的方案。

实施例3

本申请的实施例可以提供一种计算机终端，该计算机终端可以是计算机终端群中的任意一个计算机终端设备。可选地，在本实施例中，上述计算机终端也可以替换为移动终端等终端设备。

可选地，在本实施例中，上述计算机终端可以位于计算机网络的多个网络设备中的至少一个网络设备。

在本实施例中，上述计算机终端可以执行应用程序的漏洞检测方法中以下步骤的程序代码：步骤A，输入测试数据给业务测试链路中的第一测试任务；步骤B，在第一测试任务测试通过之后，将运行第一测试任务得到的测试结果作为新的测试数据输入至第二测试任务，并启动运行第二测试任务，其中，第二测试任务为依赖于第一测试任务的任意一个测试任务；步骤C，根据步骤B的方法依次遍历业务测试链路中的所有测试任务，在任意一个测试任务测试通过之后，将测试通过的测试任务的测试结果作为下一个测试任务的输入，并启动运行下一个测试任务，直至获取到业务测试链路中的所有测试任务的测试结果，其中，下一个测试任务依赖于测试通过的测试任务。

可选地，图10是根据本申请实施例的一种计算机终端的结构框图。如图10所示，该计算机终端A可以包括：一个或多个(图中仅示出一个)处理器51、存储器53、以及传输装置55。

其中，存储器53可用于存储软件程序以及模块，如本申请实施例中的安全漏洞检测方法和装置对应的程序指令/模块，处理器51通过运行存储在存储器53内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的系统漏洞攻击的检测方法。存储器53可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器53可进一步包括相对于处理器51远程设置的存储器，这些远程存储器可以通过网络连接至终端A。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

上述的传输装置55用于经由一个网络接收或者发送数据。上述的网络具体实例可包括有线网络及无线网络。在一个实例中，传输装置55包括一个网络适配器(NetworkInterface Controller，NIC)，其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中，传输装置55为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

其中，具体地，存储器53用于存储预设动作条件和预设权限用户的信息、以及应用程序。

处理器51可以通过传输装置调用存储器53存储的信息及应用程序，以执行下述步骤：步骤A，输入测试数据给业务测试链路中的第一测试任务；步骤B，在第一测试任务测试通过之后，将运行第一测试任务得到的测试结果作为新的测试数据输入至第二测试任务，并启动运行第二测试任务，其中，第二测试任务为依赖于第一测试任务的任意一个测试任务；步骤C，根据步骤B的方法依次遍历业务测试链路中的所有测试任务，在任意一个测试任务测试通过之后，将测试通过的测试任务的测试结果作为下一个测试任务的输入，并启动运行下一个测试任务，直至获取到业务测试链路中的所有测试任务的测试结果，其中，下一个测试任务依赖于测试通过的测试任务。

可选的，上述处理器51还可以执行如下步骤的程序代码：运行第一测试任务，在第一测试任务测试通过的情况下，生成第一测试结果；从业务测试链路中获取依赖于第一测试任务的至少一个第二测试任务；将第一测试结果作为新的测试数据输入至任意一个第二测试任务；启动运行任意一个第二测试任务，生成任意一个第二测试任务的测试结果。

可选的，上述处理器51还可以执行如下步骤的程序代码：判断业务测试链路中是否存在依赖于第一测试任务的测试任务；在业务测试链路中存在依赖于第一测试任务的测试任务的情况下，执行从业务测试链路中获取依赖于第一测试任务的至少一个第二测试任务的步骤。

可选的，上述处理器51还可以执行如下步骤的程序代码：在业务测试链路中不存在依赖于第一测试任务的测试任务的情况下，生成当前业务测试链路所包含的测试任务的测试报告。

可选的，上述处理器51还可以执行如下步骤的程序代码：业务测试链路中包含多个测试任务，每个测试任务之间具有有向关系，多个测试任务构成的测试任务依赖关系图为一个有向无环图。

可选的，上述处理器51还可以执行如下步骤的程序代码：通过定义任意一个测试任务的有向依赖关系，使得在测试任务依赖关系图中增加或删除一个测试任务。

可选的，上述处理器51还可以执行如下步骤的程序代码：业务测试链路中至少包括如下任意一个或多个测试任务：模拟业务终端产生源数据、模拟数据的同步传输、模拟数据清洗、模拟数据的极限存储、模拟数据分析和模拟数据回流。

采用本申请实施例，采用预先定义测试任务之间依赖关系的方式，通过在测试任务测试通过后，获取依赖于该测试任务的下游测试任务，并运行依赖于该测试任务的下游测试任务，达到了在该下游测试任务测试通过后，获取并运行依赖于该下游测试任务的测试任务的目的，如此依次执行，从而实现了以更短的时间开销获取业务测试链中所有测试任务的测试结果的技术效果，进而解决了为了在集成测试中覆盖所有场景，测试用例会随测试任务的增加呈指数增加，而造成的测试效率低的技术问题。本申请实施例中的测试方法，在测试执行依靠测试任务依赖关系进行，使得重复的测试场景仅运行一次，极大的提升运行效率。

本领域普通技术人员可以理解，图10所示的结构仅为示意，计算机终端也可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌声电脑以及移动互联网设备(MobileInternet Devices，MID)、PAD等终端设备。图10其并不对上述电子装置的结构造成限定。例如，计算机终端10还可包括比图10中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图10所示不同的配置。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(RandomAccess Memory，RAM)、磁盘或光盘等。

实施例4

本申请的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于保存上述实施例一所提供的业务功能的测试方法所执行的程序代码。

可选地，在本实施例中，上述存储介质可以位于计算机网络中计算机终端群中的任意一个计算机终端中，或者位于移动终端群中的任意一个移动终端中。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：步骤A，输入测试数据给业务测试链路中的第一测试任务；步骤B，在所述第一测试任务测试通过之后，将运行所述第一测试任务得到的测试结果作为新的测试数据输入至第二测试任务，并启动运行所述第二测试任务，其中，所述第二测试任务为依赖于所述第一测试任务的任意一个测试任务；步骤C，根据所述步骤B的方法依次遍历所述业务测试链路中的所有测试任务，在任意一个测试任务测试通过之后，将测试通过的测试任务的测试结果作为下一个测试任务的输入，并启动运行所述下一个测试任务，直至获取到所述业务测试链路中的所有测试任务的测试结果，其中，所述下一个测试任务依赖于所述测试通过的测试任务。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：运行第一测试任务，在第一测试任务测试通过的情况下，生成第一测试结果；从业务测试链路中获取依赖于第一测试任务的至少一个第二测试任务；将第一测试结果作为新的测试数据输入至任意一个第二测试任务；启动运行任意一个第二测试任务，生成任意一个第二测试任务的测试结果。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：判断业务测试链路中是否存在依赖于第一测试任务的测试任务；在业务测试链路中存在依赖于第一测试任务的测试任务的情况下，执行从业务测试链路中获取依赖于第一测试任务的至少一个第二测试任务的步骤。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：在业务测试链路中不存在依赖于第一测试任务的测试任务的情况下，生成当前业务测试链路所包含的测试任务的测试报告。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：业务测试链路中包含多个测试任务，每个测试任务之间具有有向关系，多个测试任务构成的测试任务依赖关系图为一个有向无环图。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：通过定义任意一个测试任务的有向依赖关系，使得在测试任务依赖关系图中增加或删除一个测试任务。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：业务测试链路中至少包括如下任意一个或多个测试任务：模拟业务终端产生源数据、模拟数据的同步传输、模拟数据清洗、模拟数据的极限存储、模拟数据分析和模拟数据回流。

此处需要说明的是，上述计算机终端群中的任意一个可以与网站服务器和扫描器建立通信关系，扫描器可以扫描计算机终端上php执行的web应用程序的值命令。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (14)

1.一种业务功能的测试方法，其特征在于，包括：

步骤A，输入测试数据给业务测试链路中的第一测试任务，其中，所述第一测试任务为所述业务测试链路中的根任务节点，所述测试数据用于触发所述根任务节点运行；

步骤B，在所述第一测试任务测试通过之后，将运行所述第一测试任务得到的测试结果作为新的测试数据输入至第二测试任务，并启动运行所述第二测试任务，其中，所述第二测试任务为依赖于所述第一测试任务的任意一个测试任务，所述测试结果为模拟的业务方产生的数据；

步骤C，根据所述步骤B的方法依次遍历所述业务测试链路中的所有测试任务，在任意一个测试任务测试通过之后，将测试通过的测试任务的测试结果作为下一个测试任务的输入，并启动运行所述下一个测试任务，直至获取到所述业务测试链路中的所有测试任务的测试结果，其中，所述下一个测试任务依赖于所述测试通过的测试任务。

2.根据权利要求1所述的方法，其特征在于，所述步骤B，包括：

运行所述第一测试任务，在所述第一测试任务测试通过的情况下，生成第一测试结果；

从所述业务测试链路中获取依赖于所述第一测试任务的至少一个第二测试任务；

将所述第一测试结果作为所述新的测试数据输入至任意一个第二测试任务；

启动运行所述任意一个第二测试任务，生成所述任意一个第二测试任务的测试结果。

3.根据权利要求2所述的方法，其特征在于，在从所述业务测试链路中获取依赖于所述第一测试任务的至少一个第二测试任务之前，所述方法还包括：

判断所述业务测试链路中是否存在依赖于所述第一测试任务的测试任务；

在所述业务测试链路中存在依赖于所述第一测试任务的测试任务的情况下，执行从所述业务测试链路中获取依赖于所述第一测试任务的至少一个第二测试任务的步骤。

4.根据权利要求3所述的方法，其特征在于，在所述业务测试链路中不存在依赖于所述第一测试任务的测试任务的情况下，生成当前业务测试链路所包含的测试任务的测试报告。

5.根据权利要求1至4中任意一项所述的方法，其特征在于，所述业务测试链路中包含多个测试任务，每个测试任务之间具有有向关系，所述多个测试任务构成的测试任务依赖关系图为一个有向无环图。

6.根据权利要求5所述的方法，其特征在于，通过定义任意一个测试任务的有向依赖关系，使得在所述测试任务依赖关系图中增加或删除一个测试任务。

7.根据权利要求1所述的方法，其特征在于，所述业务测试链路中至少包括如下任意一个或多个测试任务：模拟业务终端产生源数据、模拟数据的同步传输、模拟数据清洗、模拟数据的极限存储、模拟数据分析和模拟数据回流。

8.一种业务功能的测试装置，其特征在于，包括：

第一测试模块，用于输入测试数据给业务测试链路中的第一测试任务，其中，所述第一测试任务为所述业务测试链路中的根任务节点，所述测试数据用于触发所述根任务节点运行；

第二测试模块，用于在所述第一测试任务测试通过之后，将运行所述第一测试任务得到的测试结果作为新的测试数据输入至第二测试任务，并启动运行所述第二测试任务，其中，所述第二测试任务为依赖于所述第一测试任务的任意一个测试任务，所述测试结果为模拟的业务方产生的数据；

第三测试模块，用于执行所述第二测试模块的功能依次遍历所述业务测试链路中的所有测试任务，在任意一个测试任务测试通过之后，将测试通过的测试任务的测试结果作为下一个测试任务的输入，并启动运行所述下一个测试任务，直至获取到所述业务测试链路中的所有测试任务的测试结果，其中，所述下一个测试任务依赖于所述测试通过的测试任务。

9.根据权利要求8所述的装置，其特征在于，所述第二测试模块包括：

第一运行单元，用于运行所述第一测试任务，在所述第一测试任务测试通过的情况下，生成第一测试结果；

获取单元，用于从所述业务测试链路中获取依赖于所述第一测试任务的至少一个第二测试任务；

输入单元，用于将所述第一测试结果作为所述新的测试数据输入至任意一个第二测试任务；

第二运行单元，用于启动运行所述任意一个第二测试任务，生成所述任意一个第二测试任务的测试结果。

10.根据权利要求9所述的装置，其特征在于，所述装置还包括：

判断单元，用于判断所述业务测试链路中是否存在依赖于所述第一测试任务的测试任务；

第一执行单元，用于在所述业务测试链路中存在依赖于所述第一测试任务的测试任务的情况下，执行从所述业务测试链路中获取依赖于所述第一测试任务的至少一个第二测试任务的步骤。

11.根据权利要求10所述的装置，其特征在于，所述装置还包括：

第二执行单元，用于在所述业务测试链路中不存在依赖于所述第一测试任务的测试任务的情况下，生成当前业务测试链路所包含的测试任务的测试报告。

12.根据权利要求8至11中任意一项所述的装置，其特征在于，所述业务测试链路中包含多个测试任务，每个测试任务之间具有有向关系，所述多个测试任务构成的测试任务依赖关系图为一个有向无环图。

13.根据权利要求12所述的装置，其特征在于，通过定义任意一个测试任务的有向依赖关系，使得在所述测试任务依赖关系图中增加或删除一个测试任务。

14.根据权利要求8所述的装置，其特征在于，所述业务测试链路中至少包括如下任意一个或多个测试任务：模拟业务终端产生源数据、模拟数据的同步传输、模拟数据清洗、模拟数据的极限存储、模拟数据分析和模拟数据回流。

Images