[发明专利]一种业务管道的业务阀门测试方法和装置

说明书

技术领域

本申请涉及计算机技术领域，特别是涉及一种测试方法和装置。

背景技术

随着网络业务的复杂度增加，针对某种应用，出现了长业务的应用，即需要很多处理步骤的应用。如某网站的授权应用，对于用户的授权请求，内部可能需要经10多个逻辑校验，才授权给用户。为了应对这种复杂的长业务，开发使用了面向切面的编程思想，将所述长业务作为一个业务管道，每个逻辑校验定义1个业务阀门，以方便扩展和维护。其中，本申请可能用到的术语大致体定义如下：

测试用例：指软件测试中的用例(Test Case)；

业务管道：来源于Spring的面向切面编程思想，这里指提取的长流程业务逻辑；

业务阀门：管道中的逻辑拦截点，这里包括开发接口的封装、常用工具的实现、数据清理、结果校验等。

参照图1a，其为管道及其业务阀门的结构实例；参照图1b，其为整个授权功能的业务管道，每个校验为1个业务阀门(共11个业务阀门)。

现有技术中，在业务管道中添加业务阀门，用于添加公共的拦截点或控制页面的跳转，实现逻辑校验。对上述长业务对应的业务管道进行测试时，为了验证整个业务流程与期望值一致，常对业务管道的每个业务阀门的业务都增加校验点。上述业务管道中，比如对于排序靠后的业务阀门，验证时依赖与该业务阀门之前打开的业务阀门。参照图2，其为现有技术方案对N业务阀门的进行验证示意图：比如，A至N业务阀门均打开，那么对于验证业务阀门A的用例，其需要在测试场景中(也即测试用业务管道中)编写业务阀门A的测试数据(比如业务阀门运行逻辑)；对于验证业务阀门B的用例，其需要在测试场景中编写业务阀门A+B的测试数据；如此类推，对于验证业务阀门N的用例，其需要在测试场景中编写A+......+N的逻辑。

在这种情况下，针对每个业务阀门测试用例的数据准备和校验方法不一样，从前至后的业务阀门测试用例的数据准备是累加的关系。目前，基于用例生成脚本思想，只能辅助生成类名、方法名、注释，具体的校验逻辑需要各个测试类独自补充。即对于每个业务阀门的测试，在进行数据准备时，每个业务阀门的测试类都需要将其依赖的业务阀门的运行逻辑等准备数据，人工写入其业务阀门测试类中。比如，在业务管道A中，A至N业务阀门打开，测试A业务阀门类时，补充校验点，数据准备为A；测试B业务阀门类，则补充校验点，数据准备为A+B；测试C业务阀门类时，则补充校验点，数据准备为A+B+C，如此类推。那么，需要对“N业务阀门”进行测试时，则需验证前面所有业务阀门，数据准备也包含前面业务阀门的数据。因为业务管道后面业务阀门对应的测试类的数据包括了前面业务阀门的准备数据，导致现有的用例生成脚本思想无计可施，编辑的数据大量重复，代码重复性高，编码工作量大，维护成本高昂。

另外，如果业务管道A选择的业务阀门变化，比如对于A至N业务阀门中，关闭了其中几个业务阀门，那么如测试A业务阀门类，补充校验点和数据准备为A；测试B业务阀门类，若A业务阀门关闭，则补充检查点和数据为B，若A不关闭，则补充A+B；测试C业务阀门类时，有可能补充C或B+C或A+C或A+B+C。也导致现有的用例生成脚本思想无计可施，代码重复性高，编码工作量大、维护成本高。

综上，现有技术对业务阀门的逻辑验证，存在以下缺陷：

首先，对于各业务阀门的验证，该业务阀门的所有被依赖业务阀门的均需验证，从而需要构造各自的测试数据，工作量大，并且数据存在重复性，其各业务阀门的验证需要重复编写验证脚本，代码重复性高，可维护性、可扩展性差。在更改业务管道的业务阀门配置等情况时，比如选择哪些业务阀门开或关的情况时，也存在前述缺点。

其次，针对业务管道对应的一套业务阀门，需要固定各个业务阀门的测试准备数据，对于耦合性高的业务阀门验证，一旦出现异常，或者需要变更业务阀门业务或数据准备或脚本有问题等情况，需要排查所有业务阀门逻辑，更改测试脚本和测试数据，使得测试工作量较大。

再次，各业务阀门测试数据分散，管理成本大。

最后，针对业务管道的各种业务阀门用例，无法简单的基于用例生成脚本，执行测试过程。

发明内容

本申请的目的在于，提供一种业务管道的业务阀门测试方法和装置，以解决现有技术中测试过程中测试数据无法重用，业务阀门测试不灵活，可维护性、可扩展性差等问题。

为了解决上述问题，本申请还公开了一种业务管道的业务阀门测试方法，包括：