一种业务管道的业务阀门测试方法和装置

摘要

本申请提供了一种测试方法和装置，涉及计算机技术领域。所述方法包括：读取业务管道的配置信息，执行系统初始化操作；所述业务管道是指长流程业务的业务逻辑，所述业务管道中包括多个作为逻辑拦截点的业务阀门；启动用于装载请求数据的第一对象和用于装载返回的结果数据的第二对象，以实现测试的数据的流通；读取针对当前测试用例的测试配置文件，通过选择业务阀门链，进而组装得到测试用业务管道；读取针对当前测试用例的测试参数文件，并利用第一对象和第二对象，依次在测试用业务管道中运行各个业务阀门；以自定义的展现形式输出各业务阀门运行的结果。本申请中测试数据可重用，提高了业务阀门测试的灵活性，以及可维护性、可扩展性。

说明书

技术领域

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

背景技术

随着网络业务的复杂度增加，针对某种应用，出现了长业务的应用，即 需要很多处理步骤的应用。如某网站的授权应用，对于用户的授权请求，内 部可能需要经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。也导致现有的用例生成脚本思想无计可施，代 码重复性高，编码工作量大、维护成本高。

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

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

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

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

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

发明内容

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

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

读取业务管道的配置信息，执行系统初始化操作；所述业务管道是指长 流程业务的业务逻辑，所述业务管道中包括多个作为逻辑拦截点的业务阀 门；

启动用于装载请求数据的第一对象和用于装载返回的结果数据的第二 对象，以实现测试的数据的流通；

读取针对当前测试用例的测试配置文件，通过选择业务阀门链，进而组 装得到测试用业务管道；

读取针对当前测试用例的测试参数文件，依次在测试用业务管道中运行 各个业务阀门；其中，业务阀门运行所需的请求数据从所述第一对象中获取， 业务阀门运行后的结果数据存储到所述第二对象中；

以自定义的展现形式输出各业务阀门运行的结果。

优选的，还包括：

针对一测试用例，预先配置测试配置文件，所述测试配置文件包括用于 选择业务阀门链以组装测试用业务管道的信息；预先配置测试参数文件，所 述测试参数文件包括针对每个业务阀门运行时所需的请求数据。

优选的，所述读取针对当前测试用例的测试配置文件，通过选择业务阀 门链，进而组装得到测试用业务管道包括：

根据当前测试用例的测试配置文件所需的第一业务阀门集，和系统根据 业务管道的配置信息进行初始化操作后得到的第二业务阀门集中，选择第一 业务阀门集和第二业务阀门集的交集中的业务阀门组成业务阀门链，进而组 装得到测试用业务管道。

优选的，所述业务管道包括用于形成测试用业务管道运行报告的结果集 阀门。

优选的，所述以自定义的展现形式输出各业务阀门运行的结果包括：

通过所述结果集阀门提取所述第二对象中存储的各业务阀门的结果数 据，形成测试用业务管道的运行报告。

相应的，本申请还提供了一种业务管道的业务阀门测试装置，包括：

业务管道初始化模块，用于读取业务管道的配置信息，执行系统初始化 操作；所述业务管道是指长流程业务的业务逻辑，所述业务管道中包括多个 作为逻辑拦截点的业务阀门；

对象启动模块，用于启动用于装载请求数据的第一对象和用于装载返回 的结果数据的第二对象，以实现测试的数据的流通；

测试用管道组装模块，用于读取针对当前测试用例的测试配置文件，通 过选择业务阀门链，进而组装得到测试用业务管道；

测试用管道运行模块，用于读取针对当前测试用例的测试参数文件，依 次在测试用业务管道中运行各个业务阀门；其中，业务阀门运行所需的请求 数据从所述第一对象中获取，业务阀门运行后的结果数据存储到所述第二对 象中；

结果输出模块，用于以自定义的展现形式输出各业务阀门运行的结果。

优选的，还包括：

配置模块，用于针对一测试用例，预先配置测试配置文件，所述测试配 置文件包括用于选择业务阀门链以组装测试用业务管道的信息；预先配置测 试参数文件，所述测试参数文件包括针对每个业务阀门运行时所需的请求数 据。

优选的，所述测试用管道组装模块包括：

第一组装模块，用于根据当前测试用例的测试配置文件所需的第一业务 阀门集，和系统根据业务管道的配置信息进行初始化操作后得到的第二业务 阀门集中，选择第一业务阀门集和第二业务阀门集的交集中的业务阀门组成 业务阀门链，进而组装得到测试用业务管道。

优选的，所述业务管道包括用于形成测试用业务管道运行报告的结果集 阀门。

优选的，所述结果输出模块包括：

第一输出模块，用于通过所述结果集阀门提取所述第二对象中存储的各 业务阀门的结果数据，形成测试用业务管道的运行报告。

与现有技术相比，本申请包括以下优点：

一、由于本申请根据测试用例的测试配置文件从业务管道的各个初始化 后的业务阀门中，动态选择需求的业务阀门链组装测试用管道，然后再读取 该测试用例的测试参数文件，依次在测试用业务管道中运行各个业务阀门， 即可完成对测试用例的测试。那么无论对于哪个测试用例，只需配置各用例 相应的测试配置文件和测试参数文件，即可进行测试，不用对于每个用例重 复的对每个业务阀门编写完整的测试代码，减少了测试代码的重复性，减少 了技术人员的工作量，尤其对于业务管道配置改变的时候，只需该变业务管 道的配置文件即可，不需要针对新测试用例的业务管道重头开始编写代码。

二、本申请以自定义的展现形式输出各业务阀门运行的结果，即可以定 义输出任意业务阀门或者所有业务阀门的运行结果，那么在验证对某些业务 阀门具有依赖性的业务阀门时，如果测试结果出现问题或者用例失败，可根 据各种输出结果判断的每个业务阀门逻辑运行结果判断是哪个环节出现问 题，不用逐一再测试该业务阀门依赖的其他业务阀门的逻辑以进行排查。

三、各业务阀门测试数据可以集中管理，节省了数据管理成本。

四、由于只用针对测试用例配置相应的测试配置文件和测试参数文件， 具体的执行逻辑可以自动生成，即可简单的基于用例生成脚本。

总之，本申请具有代码重复性低，测试数据可统一管理，可维护性、可 扩展性高，可大大减少人力成本的优点。

附图说明

图1a是业务管道的架构示例图；

图1b是以授权功能为示例的业务管道；

图2是业务管道的具体示例；

图3本申请一种业务管道业务阀门测试方法的流程示意图；

图4是本申请一种业务管道业务阀门测试方法的底层实施架构示意图；

图5是本申请一种业务管道业务阀门测试装置的结构示意图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图 和具体实施方式对本申请作进一步详细的说明。

本申请的核心思想之一是，将业务管道的各种运行逻辑预先进行独立编 写，比如将各作为逻辑校验点的业务阀门的逻辑先独立编写好，然后在测试 时初始化至系统中，根据用户针对测试用例编写的测试配置文件从各业务阀 门中选择业务阀门链组装得到测试用业务管道，再读取当前测试用例的测试 参数文件，依次在测试用业务管道中运行各个业务阀门。在这个过程中，只 需编辑一遍各业务阀门的测试数据即可，有系统统一管理，对于各个业务阀 门的各种测试用例，只需配置相应测试配置文件和测试参数文件，无需针对 每个测试用例重新编辑完整的测试代码，大大减少了人工编译代码的成本，提 高了测试效率，并且对于各业务阀门的运行逻辑可集中管理，大大降低了维 护成本。

参照图3和图4，图3示出了本申请一种业务管道业务阀门测试方法的 流程示意图。而图4为了配合说明图3，其示出了本申请图1各个步骤具体 实施过程的示意图。

首先，对于本申请的系统，在构建时需要对业务管道的各个业务阀门进 行抽象，编辑各个业务阀门的具体的运行逻辑。其中所述业务管道是指长 流程业务的业务逻辑，所述业务阀门为业务管道中的逻辑拦截点。

然后，可由技术人员进行步骤100，针对一测试用例，预先配置测试配 置文件，所述测试配置文件包括用于选择业务阀门链以组装测试用业务管道 的信息；预先配置测试参数文件，所述测试参数文件包括针对每个业务阀门 运行时所需的请求数据。其中，请求数据可包括公用测试数据，比如用户名 和密码，还可包括各个业务阀门运行时需要的独立参数。

对于本申请的业务管道，其可能包括A-N总共n个业务阀门。而在实际 应用中，可能有些业务阀门不用，那么就需要根据业务管道需求预先配置业 务管道的配置信息，比如业务管道中哪些业务阀门打开，哪些业务阀门关闭， 比如各个业务阀门的属性(比如黑白名单校验业务阀门的属性可为具体的各 种黑白名单)。

对于每个测试用例，其用到的业务管道中的业务阀门可能也存在变动， 比如测试用例1用到A+B+C业务阀门，而测试用例2用到A+B+D+E业务 阀门，那么本申请只需针对每个测试用例配置相应的测试配置文件和测试参 数文件即可，所述测试配置文件包括测试用例用到的业务阀门链，所述测试 参数文件包括业务阀门链中各业务阀门运行时用到的请求数据。

基于上述构建和配置，本申请的测试过程具体可以包括：

步骤110，读取业务管道的配置信息，执行系统初始化操作；所述业务 管道是指长流程业务的业务逻辑，所述业务管道中包括多个作为逻辑拦截点 的业务阀门；

如前所述，在系统构建时，可能抽象了n个业务阀门，但具体应用中可 能只打开其中n-1个，并且每个业务阀门的属性可能变化。对于当前业务管 道本身的形式，需要读取当前业务管道的配置信息，进行系统初始化操作， 所述初始化操作包括加载需要打开的业务阀门，并将新配置的各业务阀门的 属性注入相应业务阀门。

步骤120，启动用于装载请求数据的第一对象和用于装载返回的结果数 据的第二对象，以实现测试的数据的流通；

本申请在业务阀门进行运行时，业务阀门需要获取请求数据，业务阀门 运行的结果数据也需要返回；并且业务阀门间的测试数据可能需要流通，比 如业务阀门链中，前一业务阀门的结果数据可能成为后一业务阀门的请求数 据，又比如测试结果数据需要输出；那么本步骤则启动用于装载请求数据的 第一对象和用于装载返回的结果数据的第二对象，以实现测试的数据的流 通。

相应的，参照图4，步骤110和步骤120主要对应驱动部分，本申请的 驱动程序，基于业务管道A业务阀门至N业务阀门的抽象，动态读取管道 设置(即读取业务管道的配置信息)，然后进行系统初始化，初始化 MockHttpRequest(第一对象)和MockHttpResponse(第二对象)两个对象， 并将各业务阀门的属性配个相应的业务阀门，即根据业务管道的配置信息给 图4中PipeConfigBean赋值。

步骤130，读取针对当前测试用例的测试配置文件，通过选择业务阀门 链，进而组装得到测试用业务管道；

如前所述，针对每个业务阀门进行测试时，需要构造相应的测试用例， 而对应该测试用例，则需要预先配置相应的测试配置文件，即配置包括使用 哪些业务阀门组成的业务阀门链，业务阀门链中各业务阀门运行时的请求数 据是什么的测试配置文件。

那么本步骤则读取测试配置文件，根据配置文件选择业务阀门链，进而 组装得到测试用业务管道。

其中，所述读取针对当前测试用例的测试配置文件，通过选择业务阀门 链，进而组装得到测试用业务管道包括：

根据当前测试用例的测试配置文件所需的第一业务阀门集，和系统根据 业务管道的配置信息进行初始化操作后得到的第二业务阀门集中，选择第一 业务阀门集和第二业务阀门集的交集中的业务阀门组成业务阀门链，进而组 装得到测试用业务管道。

比如系统针对业务管道抽象了A至N业务阀门，而业务管道的配置信 息只配置了A+B+D+E+F+G业务阀门，以及该6个业务阀门的属性；而测 试配置文件使用了A+B+C+E+F+G，以及该5个业务阀门运行时所需的请求 数据；那么在组装时只选择A+B+E+F+G业务阀门链组装测试用管道。当然， 在实际中，一般测试用例的业务阀门链从属于业务管道配置信息中的业务阀 门链。

相应的参照图4，在数据驱动池部分读取测试配置文件(即前述测试配 置文件)，然后在测试场景部分，进行组装测试管道(即前述测试用业务管 道)的过程，即选择根据当前测试用例的测试配置文件所需的第一业务阀门 集，和系统根据业务管道的配置信息进行初始化操作后得到的第二业务阀门 集中，选择第一业务阀门集和第二业务阀门集的交集中的业务阀门进行业务 阀门初始化，然后选择业务阀门链组装成测试用业务管道，即图4中测试场 景部分中的测试管道(即前述测试用业务管道)。

步骤140，读取针对当前测试用例的测试参数文件，依次在测试用业务 管道中运行各个业务阀门；其中，业务阀门运行所需的请求数据从所述第一 对象中获取，业务阀门运行后的结果数据存储到所述第二对象中；

在组装完测试用业务管道后，即可读取测试参数文件，依次在测试用业务 管道中运行各业务阀门，在运行每个业务阀门时，从第一对象中 (MockHttpRequest)获取请求数据进行运行，相应运行的结果数据则存储到所 述第二对象(MockHttpResponse)中。

相应的，对应图4，在测试场景部分，测试管道(即前述测试用业务管 道)组装完毕后，读取测试参数文件，第一对象(MockHttpRequest)则将 各业务阀门的请求数据进行装载，业务阀门运行时则从MockHttpRequest获 取请求数据执行，每个业务阀门运行结束后，则将结果数据存入 MockHttpResponse中。

步骤150，以自定义的展现形式输出各业务阀门运行的结果。

在本申请中，对于各业务阀门的运行结果，可自定义输出某个、某几个 或者全部的运行结果，并且可以xml格式或者json等方式输出。在本申请中， 默认输出所有运行的业务阀门的结果。

另外，在本身中，前述的业务管道包括用于形成测试用业务管道运行报 告的结果集阀门。

进一步的，所述以自定义的展现形式输出各业务阀门运行的结果包括：

步骤S151，通过所述结果集阀门提取所述第二对象中存储的各业务阀门 的结果数据，形成测试用业务管道的运行报告。

根据结果集阀门与各业务阀门的关联，可将各业务阀门返回给第二对象 的结果数据进行处理，形成测试用业务管道的运行报告。比如图4中的测试 用管道运行结果报告。

参照图5，其示出了本申请一种业务管道的业务阀门测试装置，包括：

业务管道初始化模块410，用于读取业务管道的配置信息，执行系统初 始化操作；所述业务管道是指长流程业务的业务逻辑，所述业务管道中包括 多个作为逻辑拦截点的业务阀门；

对象启动模块420，用于启动用于装载请求数据的第一对象和用于装载 返回的结果数据的第二对象，以实现测试的数据的流通；

测试用管道组装模块430，用于读取针对当前测试用例的测试配置文件， 通过选择业务阀门链，进而组装得到测试用业务管道；

测试用管道运行模块440，用于读取针对当前测试用例的测试参数文件， 依次在测试用业务管道中运行各个业务阀门；其中，业务阀门运行所需的请 求数据从所述第一对象中获取，业务阀门运行后的结果数据存储到所述第二 对象中；

结果输出模块450，用于以自定义的展现形式输出各业务阀门运行的结 果。

其中，还包括：

配置模块，用于针对一测试用例，预先配置测试配置文件，所述测试配 置文件包括用于选择业务阀门链以组装测试用业务管道的信息；预先配置测 试参数文件，所述测试参数文件包括针对每个业务阀门运行时所需的请求数 据。

其中，所述测试用管道组装模块包括：

第一组装模块，用于根据当前测试用例的测试配置文件所需的第一业务 阀门集，和系统根据业务管道的配置信息进行初始化操作后得到的第二业务 阀门集中，选择第一业务阀门集和第二业务阀门集的交集中的业务阀门组成 业务阀门链，进而组装得到测试用业务管道。

其中，所述业务管道包括用于形成测试用业务管道运行报告的结果集阀 门。

其中，所述结果输出模块包括：

第一输出模块，用于通过所述结果集阀门提取所述第二对象中存储的各 业务阀门的结果数据，形成测试用业务管道的运行报告。

针对上述方法和装置，本申请的具体实现实例可如下：

对于一个用于测试业务阀门的测试用例，为其编写一个测试类，比如， 对于一测试用例Url1的测试类CallBackUrlTest，其负责构造测试场景， CallBackUrlTest继承测试父类TestBaseCase，每个场景执行时，直接执行 TestBaseCase的doTest()方法。如此，代码简洁易读，且便于由用例直接生 成脚本。每个测试场景也即测试用例对应一套配置的文件(测试配置文件和 测试参数文件)，包括使用的阀门、每个阀门的请求数据(参数和期望结果)。

其中的逻辑如：

在本申请中，业务管道的配置信息(即业务阀门的集合)可用spring的 配置文件，或直接以list方式。如Spring(一个开源框架，一个轻量级的 控制反转(IoC)和面向切面(AOP)的容器框架)的配置文件如下：

在上述业务管道配置中，配置了哪些业务阀门打开，哪些业务阀门关闭， 各业务阀门的属性等。

对于测试父类(TestBaseCase)及其调用或者间接调用的类，其执行时 对应步骤110，120、130、140和150。

测试父类(TestBaseCase)的功能可包括四个重要作用：一是组装测试 业务阀门(Before)，二是引入公共的测试数据(比如用户名和密码等各阀门 均用到的数据)；三是进行业务阀门的初始化(Before)；四是执行测试 (doTest)。其可对应步骤110、120。

before方法中，可编写接口，动态读取管道配置(各个业务阀门的开关 和属性)，进行各业务阀门的初始化。

在doTest方法中，通过第一对象模拟http请求，调用valveHandler(业 务阀门处理器)的handleRequest(处理请求执行)方法，其中handleRequest 为后续业务阀门处理执行的步骤。doTest的示例如下：

对于被测试父类调用的valveHandler(业务阀门处理器)：包含init()和 handleRequest()。init()主要用来根据测试配置文件进行测试用例所需求的阀 门的加载，除了加载自定义的测试阀门外，还加载系统定义的结果集阀门 (ResultValve)，用于生成每个用例的测试结果，即形成管道运行报告。其对 应步骤130。

其handleRequest方法示例可如下：

其中，ClientValveInput为业务阀门输入模块，ClientValveInput实现业务 阀门输入接口，其功能为：针对每个当前运行的业务阀门读入参，其中调用 了模拟网页请求request的入参等。对于ClientValveInput input＝new ClientValveInput()；其用于获取数据驱动池的获取spring配置的文件。

valveHandler则调用valveManager(阀门管理器)，对于valveManager， 其准备阀门输入和输出(属于测试参数文件)，并迭代进行阀门处理，其具 体方法可如下：

其中，ClientValveResult业务阀门输出模块，可理解为对应前述第二对 象，其实现业务阀门输出接口。ClientValveResult功能可包括：设置和获取 是否跳出管道链，存储临时中间对象，存储运行结果，设置header、 outputstream、writer。

valveManager则进一步调用AppStatusValve阀门执行器。而对于 AppStatusValve，可先定义测试阀门接口(IValve)，每个具体的阀门都实现该 接口，如下：

其中doValve()主要包含该阀门的数据准备和校验逻辑。校验逻辑可包含 正常流和异常流，若需输出结果，可封装到ConsoleClientPipeResult的 setExport(Object object)方法中。

valveManager和App StatusValve则对应步骤140。

最后，AppStatusValve调用结果集阀门ResultValve，其可从 ConsoleClientPipeResult中得到Export的对象，转成String类型，再以j son或 xml的方式输出。ResultValve对应步骤150。

对于系统实施例而言，由于其与方法实施例基本相似，所以描述的比较 简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明 的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见 即可。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或 计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、 或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个 其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘 存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序 产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程 图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流 程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算 机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使 得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实 现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定 的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理 设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储 器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程 或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上， 使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现 的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程 图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的 步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了 基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权 利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

以上对本申请所提供的一种业务管道的业务阀门测试方法和装置，进行 了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐 述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时， 对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范 围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。