[发明专利]业务功能的测试方法和装置

说明书

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

技术领域

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

背景技术

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

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

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

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

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

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

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

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

发明内容

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