CN106598870A - 一种跨组件交易一致性测试方法及系统 - Google Patents

Abstract

本申请公开了一种跨组件交易一致性测试方法及系统，所述跨组件交易一致性测试方法首先通过对多个组件提供的服务进行过滤，获得目标服务列表，将不会产生交易状态不一致的服务排除在目标服务列表之外；然后获取目标服务列表中的每个服务的交易路径并针对目标服务列表中的每个服务的交易路径中的每个节点设计测试案例；最后利用转发器进行超时模拟，以为所有测试案例的执行提供前提，在所有的测试案例执行完毕后，判断交易系统是否满足跨组件交易一致性要求。通过上述流程发现，跨组件交易一致性测试方法不需要测试工程师针对单一服务单一组件人工模拟系统故障的操作，大大降低了测试工程师的测试工作量，并且提高了跨组件交易一致性测试的效率。

Description

一种跨组件交易一致性测试方法及系统

技术领域

本申请涉及跨组件交易一致性测试技术领域，更具体地说，涉及一种跨组件交易一致性测试方法及系统。

背景技术

在当前软件系统开发趋势下，为了降低系统内多个组件间的耦合关系，一般采取面向服务的体系结构(SOA)，SOA是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。在SOA中通常利用一个服务目录进行组件之间的交互，具体地，SOA中的组件将自身的地址通过所述服务目录的客户端注册在所述服务目录的服务器上，当某一组件需要调用另一组件的服务时，可以通过所述服务目录进行服务寻址，以获取所需调用组件的地址，从而实现对这一组件的调用。

在许多基于SOA的交易系统中，许多交易是需要多个组件共同完成的，当A组件需要调用B组件时，如果A和B之间的网络发生故障，或组件B所在系统发生异常宕机的情况，组件A就无法收到组件B的响应，无法判断请求是否达到组件B，亦无法判断组件B是否已经完成来自组件B的交易请求的处理，那么组件B和组件A之间的交易状态就可能存在不一致状态，这种交易状态的不一致可能会使得所述交易系统中出现单边账的情况，对客户或企业造成不必要的麻烦或损失。此时，组件A需要采取交易一致性事中保证手段，例如冲正或异步冲正等来使得组件A和组件B的交易状态一致。在交易系统上线之前，测试工程师需要采用一定的测试方法来验证该交易系统交易一致性事中保证手段的完整性和有效性，以判断所述交易系统是否满足跨组件交易一致性要求。

现有技术中测试工程师在对所述交易系统进行跨组件交易一致性测试时，需要人工模拟系统故障，比如将某一组件所在的系统进行宕机或切断网络等，来判断某一交易过程涉及的组件是否能够采取有效的交易一致性事中保证手段来保证各组件之间的交易状态的一致性。但是人工模拟系统故障对所述交易系统进行跨组件交易一致性测试的过程比较繁琐，需要测试工程师针对不同类型的交易多次人工模拟系统故障，并且单一交易有可能涉及多个组件，这样测试工程师需要在对这一交易进行跨组件交易一致性测试过程中进行多次人工模拟系统故障的操作，极大地增加了测试工程师的测试工作量，并且极大地降低了跨组件交易一致性测试的效率。

发明内容

为解决上述技术问题，本发明提供了一种跨组件交易一致性测试方法及系统，以降低测试工程师对交易系统进行跨组件交易一致性测试的测试工作量，并提高测试效率。

为实现上述技术目的，本发明实施例提供了如下技术方案：

一种跨组件交易一致性测试方法，应用于包括服务目录、转发器和多个组件的交易系统，所述跨组件交易一致性测试方法包括：

对所述多个组件提供的服务进行过滤，获得目标服务列表；

获取所述目标服务列表中的每个服务的交易路径；

对所述目标服务列表中的每个服务的交易路径中的每个节点设计测试案例，所述测试案例包括服务名称、交易路径、测试点和预期结果；

利用所述转发器进行超时模拟，以执行所有的所述测试案例；

在所有的所述测试案例执行完毕后，根据所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态判断所述交易系统是否满足跨组件交易一致性要求。

可选的，所述利用所述转发器进行超时模拟包括：

启动所述转发器的转发端口的监听线程，所述监听线程用于将所述测试点的交易请求转发至交易请求接收节点；

对所述转发器进行配置，将所述目标服务列表中的每个服务的交易路径中的每个节点在所述服务目录中注册的地址更换为所述转发器的地址和所述转发端口地址；

将所述转发器的响应延时设置为预设时间。

可选的，所述预设时间大于所述目标服务列表中的每个服务的交易路径中的每个节点的请求超时时间。

可选的，所述预设时间的取值大于10秒。

可选的，所述根据所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态判断所述交易系统是否满足跨组件交易一致性要求包括：

获取所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态；

判断所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态是否一致，如果是，则判断所述交易系统满足跨组件交易一致性要求，如果否，则判断所述交易系统不满足跨组件交易一致性要求，并将存在交易状态不一致节点的交易路径对应的服务进行显示。

一种跨组件交易一致性测试系统，应用于包括服务目录、转发器和多个组件的交易系统，所述跨组件交易一致性测试系统包括：

服务过滤模块，用于对所述多个组件提供的服务进行过滤，获得目标服务列表；

路径获取模块，用于获取所述目标服务列表中的每个服务的交易路径；

案例设计模块，用于对所述目标服务列表中的每个服务的交易路径中的每个节点设计测试案例，所述测试案例包括服务名称、交易路径、测试点和预期结果；

超时模拟模块，用于利用所述转发器进行超时模拟，以执行所有的所述测试案例；

判断模块，用于在所有的所述测试案例执行完毕后，根据所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态判断所述交易系统是否满足跨组件交易一致性要求。

可选的，所述超时模拟模块包括：

线程启动单元，用于启动所述转发器的转发端口的监听线程，所述监听线程用于将所述测试点的交易请求转发至交易请求接收节点；

配置单元，用于对所述转发器进行配置，将所述目标服务列表中的每个服务的交易路径中的每个节点在所述服务目录中注册的地址更换为所述转发器的地址和所述转发端口地址；

时间设定单元，用于将所述转发器的响应延时设置为预设时间。

可选的，所述预设时间大于所述目标服务列表中的每个服务的交易路径中的每个节点的请求超时时间。

可选的，所述预设时间的取值大于10秒。

可选的，所述判断模块包括：

状态获取单元，用于在所有的所述测试案例执行完毕后，获取所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态；

一致性判断单元，用于判断所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态是否一致，如果是，则判断所述交易系统满足跨组件交易一致性要求，如果否，则判断所述交易系统不满足跨组件交易一致性要求，并将存在交易状态不一致节点的交易路径对应的服务进行显示。

从上述技术方案可以看出，本发明实施例提供了一种跨组件交易一致性测试方法及系统，其中，所述跨组件交易一致性测试方法首先通过对所述多个组件提供的服务进行过滤，获得目标服务列表，将不会产生交易状态不一致的服务排除在所述目标服务列表之外，以提升跨组件交易一致性测试的效率；然后获取所述目标服务列表中的每个服务的交易路径，并针对所述目标服务列表中的每个服务的交易路径中的每个节点设计测试案例；最后利用所述转发器进行超时模拟，以为所有所述测试案例的执行提供前提，在所有的所述测试案例执行完毕后，判断所述交易系统是否满足跨组件交易一致性要求。通过上述流程发现，所述跨组件交易一致性测试方法通过利用所述转发器进行超时模拟的手段为所述交易系统的跨组件交易一致性测试提供故障模拟，而不需要测试工程师针对单一服务单一组件人工模拟系统故障的操作，大大降低了测试工程师的测试工作量，并且提高了跨组件交易一致性测试的效率。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请的一个实施例提供的一种跨组件交易一致性测试方法的流程示意图；

图2为本申请的另一个实施例提供的一种跨组件交易一致性测试方法的流程示意图；

图3为本申请的一个实施例提供的一种跨组件交易一致性测试系统的结构示意图；

图4为本申请的另一个实施例提供的一种跨组件交易一致性测试系统的结构示意图；

图5为本申请的又一个实施例提供的一种跨组件交易一致性测试系统的结构示意图。

具体实施方式

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

本申请实施例提供了一种跨组件交易一致性测试方法，如图1所示，应用于包括服务目录、转发器和多个组件的交易系统，所述跨组件交易一致性测试方法包括：

S101：对所述多个组件提供的服务进行过滤，获得目标服务列表。

需要说明的是，并不是所有的交易类型涉及的组件间发生系统故障(例如系统宕机或网络故障)，例如当组件A调用组件B的查询服务时，查询超时或其他失败情况，并不会发生数据状态的变更，也就不会导致组件A和组件B之间的交易状态的不一致，此时组件A再次发起查询即可。

对所述多个组件提供的服务进行过滤的目的是过滤掉查询交易或穿透交易等不会引起组件之间交易状态不一致的服务，保留当发生系统宕机或网络故障时有可能引起多个组件之间的交易状态不一致的状态的服务，比如取款服务、存款服务等，所有这类服务构成所述目标服务列表。

以取款服务为例，假设取款服务涉及到组件C和组件D，取款过程中，组件C调用组件D进行一笔客户扣款，并在扣款成功完成后，更新组件C数据库中客户缴款状态；若组件D未正确返回扣款结果至组件C，则组件C无法判断扣款是否成功。

在这种状况下，组件C需要采取一定的技术手段及时对交易系统的不一致状态进行纠正，这种技术手段即为交易一致性事中保证手段。常见的交易一致性事中保证手段为异步冲正，组件C发送冲正请求至组件D，请求组件D返还金额至客户账户，并在冲正请求成功返回后，组件C更新自身数据库客户缴款状态。那么在对这一服务进行跨组件交易一致性测试时，需要判断在交易一致性事中保证手段执行完毕后，组件C和组件D的交易状态是否一致，即是否会出现组件C的数据库中客户账户中进行了本次交易的扣款，而组件D中的数据库中客户账户中不存在本次交易扣款的情况。

S102：获取所述目标服务列表中的每个服务的交易路径。

交易路径是指在一项服务的业务请求发起后，系统内部各个组件间协作的流程和顺序，各个组件及其有序的调用关系即构成该服务的交易路径。

S103：对所述目标服务列表中的每个服务的交易路径中的每个节点设计测试案例，所述测试案例包括服务名称、交易路径、测试点和预期结果。

由于所述交易路径中的每个节点均有可能发生系统故障，因此需要针对每个服务的交易路径中的每个节点分别设计测试案例。所述预期结果为当所述交易路径上的其他节点发生故障时，是否存在交易一致性事中保证手段以及时纠正系统出现的交易不一致的状态。预期结果的判断依据主要包括系统日志、数据库表与字段值等。

S104：利用所述转发器进行超时模拟，以执行所有的所述测试案例。

需要说明的是，所述转发器具有转发交易请求，并对响应结果进行延时的功能，可以将所述转发器的延时时间进行适当的设置，从而进行超时模拟，进而通过各个组件的交易状态判断所述交易系统是否满足跨组件交易一致性的要求。

S105：在所有的所述测试案例执行完毕后，根据所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态判断所述交易系统是否满足跨组件交易一致性要求。

在上述实施例的基础上，在本申请的一个实施例中，如图2所示，所述利用所述转发器进行超时模拟包括：

S1041：启动所述转发器的转发端口的监听线程，所述监听线程用于将所述测试点的交易请求转发至交易请求接收节点；

S1042：对所述转发器进行配置，将所述目标服务列表中的每个服务的交易路径中的每个节点在所述服务目录中注册的地址更换为所述转发器的地址和所述转发端口地址；

S1043：将所述转发器的响应延时设置为预设时间。

需要说明的是，所述转发器的所有端口都可以作为所述转发端口，例如端口10401。启动的所述监听线程用于将所述测试点的交易请求转发至交易请求接收节点。所述测试点可以是每个服务的交易路径的任意节点，即进行测试的目标节点，所述交易请求接收节点是指在交易路径中，完成该项服务中的节点中的下一个节点。

假设某一服务需要组件A和组件B完成，那么在进行超时模拟时，指定所述转发器的某一端口例如10401负责接收组件A对组件B的访问请求，接下来将服务目录中的组件B的地址修改为转发器的地址与10401端口地址，同时转发器的10401端口的监听线程启动，此监听线程用于把接收到的组件A的业务请求转发至组件B。在完成上述设置后，当组件A发起对组件B的交易请求时，首先通过服务寻址获取组件B的地址，而此时组件B的地址已经被替换为转发器的地址和10401端口地址，故转发器将收到此交易请求，而后端口10401的监听线程将此交易请求转发至组件B。

在HTTP协议中，所述监听线程首选读取HTTP请求报文，而后可做预处理或直接转发至组件B的服务地址。在Java平台中，所述监听线程使用JDK自带的网络函数库即可实现交易请求的转发。

当组件B完成组件A发送的业务请求处理并返回响应至转发器后，转发器根据设置的响应延时时间进行延时操作，所述预设时间设置大于组件A的请求超时时间，即可造成组件A请求超时异常，从而能够观察并验证组件A是否能够及时进行交易一致性事中保证手段。

转发器的延时功能可以采用线程的睡眠手段实现，例如对于Java平台，使用Thread.Sleep(time)，即可造成time毫秒的延时效果。

那么，相应的，我们只要将所述预设时间的取值设置为大于所述目标服务列表中的每个服务的交易路径中的每个节点的请求超时时间即可实现对所述交易系统中的所述目标服务列表中的每个服务的交易路径中的每个节点的跨组件交易一致性的测试。

一般而言，节点的请求超时时间一般为5s-10s，因此，在本申请的一个具体实施例中，所述预设时间的取值大于10秒。

在上述实施例的基础上，在本申请的又一个实施例中，所述根据所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态判断所述交易系统是否满足跨组件交易一致性要求包括：

获取所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态；

判断所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态是否一致，如果是，则判断所述交易系统满足跨组件交易一致性要求，如果否，则判断所述交易系统不满足跨组件交易一致性要求，并将存在交易状态不一致节点的交易路径对应的服务进行显示。

相应的，本申请实施例还提供了一种跨组件交易一致性测试系统，如图3所示，应用于包括服务目录、转发器和多个组件的交易系统，所述跨组件交易一致性测试系统包括：

服务过滤模块100，用于对所述多个组件提供的服务进行过滤，获得目标服务列表；

路径获取模块200，用于获取所述目标服务列表中的每个服务的交易路径；

案例设计模块300，用于对所述目标服务列表中的每个服务的交易路径中的每个节点设计测试案例，所述测试案例包括服务名称、交易路径、测试点和预期结果；

超时模拟模块400，用于利用所述转发器进行超时模拟，以执行所有的所述测试案例；

判断模块500，用于在所有的所述测试案例执行完毕后，根据所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态判断所述交易系统是否满足跨组件交易一致性要求。

需要说明的是，并不是所有的交易类型涉及的组件间发生系统故障(例如系统宕机或网络故障)，例如当组件A调用组件B的查询服务时，查询超时或其他失败情况，并不会发生数据状态的变更，也就不会导致组件A和组件B之间的交易状态的不一致，此时组件A再次发起查询即可。

对所述多个组件提供的服务进行过滤的目的是过滤掉查询交易或穿透交易等不会引起组件之间交易状态不一致的服务，保留当发生系统宕机或网络故障时有可能引起多个组件之间的交易状态不一致的状态的服务，比如取款服务、存款服务等，所有这类服务构成所述目标服务列表。

以取款服务为例，假设取款服务涉及到组件C和组件D，取款过程中，组件C调用组件D进行一笔客户扣款，并在扣款成功完成后，更新组件C数据库中客户缴款状态；若组件D未正确返回扣款结果至组件C，则组件C无法判断扣款是否成功。

在这种状况下，组件C需要采取一定的技术手段及时对交易系统的不一致状态进行纠正，这种技术手段即为交易一致性事中保证手段。常见的交易一致性事中保证手段为异步冲正，组件C发送冲正请求至组件D，请求组件D返还金额至客户账户，并在冲正请求成功返回后，组件C更新自身数据库客户缴款状态。那么在对这一服务进行跨组件交易一致性测试时，需要判断在交易一致性事中保证手段执行完毕后，组件C和组件D的交易状态是否一致，即是否会出现组件C的数据库中客户账户中进行了本次交易的扣款，而组件D中的数据库中客户账户中不存在本次交易扣款的情况。

交易路径是指在一项服务的业务请求发起后，系统内部各个组件间协作的流程和顺序，各个组件及其有序的调用关系即构成该服务的交易路径。

由于所述交易路径中的每个节点均有可能发生系统故障，因此需要针对每个服务的交易路径中的每个节点分别设计测试案例。所述预期结果为当所述交易路径上的其他节点发生故障时，是否存在交易一致性事中保证手段以及时纠正系统出现的交易不一致的状态。预期结果的判断依据主要包括系统日志、数据库表与字段值等。

还需要说明的是，所述转发器具有转发交易请求，并对响应结果进行延时的功能，可以将所述转发器的延时时间进行适当的设置，从而进行超时模拟，进而通过各个组件的交易状态判断所述交易系统是否满足跨组件交易一致性的要求。

在上述实施例的基础上，在本申请的一个实施例中，如图4所示，所述超时模拟模块400包括：

线程启动单元410，用于启动所述转发器的转发端口的监听线程，所述监听线程用于将所述测试点的交易请求转发至交易请求接收节点；

配置单元420，用于对所述转发器进行配置，将所述目标服务列表中的每个服务的交易路径中的每个节点在所述服务目录中注册的地址更换为所述转发器的地址和所述转发端口地址；

时间设定单元430，用于将所述转发器的响应延时设置为预设时间。

需要说明的是，所述转发器的所有端口都可以作为所述转发端口，例如端口10401。启动的所述监听线程用于将所述测试点的交易请求转发至交易请求接收节点。所述测试点可以是每个服务的交易路径的任意节点，即进行测试的目标节点，所述交易请求接收节点是指在交易路径中，完成该项服务中的节点中的下一个节点。

假设某一服务需要组件A和组件B完成，那么在进行超时模拟时，指定所述转发器的某一端口例如10401负责接收组件A对组件B的访问请求，接下来将服务目录中的组件B的地址修改为转发器的地址与10401端口地址，同时转发器的10401端口的监听线程启动，此监听线程用于把接收到的组件A的业务请求转发至组件B。在完成上述设置后，当组件A发起对组件B的交易请求时，首先通过服务寻址获取组件B的地址，而此时组件B的地址已经被替换为转发器的地址和10401端口地址，故转发器将收到此交易请求，而后端口10401的监听线程将此交易请求转发至组件B。

在HTTP协议中，所述监听线程首选读取HTTP请求报文，而后可做预处理或直接转发至组件B的服务地址。在Java平台中，所述监听线程使用JDK自带的网络函数库即可实现交易请求的转发。

当组件B完成组件A发送的业务请求处理并返回响应至转发器后，转发器根据设置的响应延时时间进行延时操作，所述预设时间设置大于组件A的请求超时时间，即可造成组件A请求超时异常，从而能够观察并验证组件A是否能够及时进行交易一致性事中保证手段。

转发器的延时功能可以采用线程的睡眠手段实现，例如对于Java平台，使用Thread.Sleep(time)，即可造成time毫秒的延时效果。

那么，相应的，我们只要将所述预设时间的取值设置为大于所述目标服务列表中的每个服务的交易路径中的每个节点的请求超时时间即可实现对所述交易系统中的所述目标服务列表中的每个服务的交易路径中的每个节点的跨组件交易一致性的测试。

一般而言，节点的请求超时时间一般为5s-10s，因此，在本申请的一个具体实施例中，所述预设时间的取值大于10秒。

在上述实施例的基础上，在本申请的又一个实施例中，如图5所示，所述判断模块500包括：

状态获取单元510，用于在所有的所述测试案例执行完毕后，获取所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态；

一致性判断单元520，用于判断所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态是否一致，如果是，则判断所述交易系统满足跨组件交易一致性要求，如果否，则判断所述交易系统不满足跨组件交易一致性要求，并将存在交易状态不一致节点的交易路径对应的服务进行显示。

综上所述，本申请实施例提供了一种跨组件交易一致性测试方法及系统，其中，所述跨组件交易一致性测试方法首先通过对所述多个组件提供的服务进行过滤，获得目标服务列表，将不会产生交易状态不一致的服务排除在所述目标服务列表之外，以提升跨组件交易一致性测试的效率；然后获取所述目标服务列表中的每个服务的交易路径，并针对所述目标服务列表中的每个服务的交易路径中的每个节点设计测试案例；最后利用所述转发器进行超时模拟，以为所有所述测试案例的执行提供前提，在所有的所述测试案例执行完毕后，判断所述交易系统是否满足跨组件交易一致性要求。通过上述流程发现，所述跨组件交易一致性测试方法通过利用所述转发器进行超时模拟的手段为所述交易系统的跨组件交易一致性测试提供故障模拟，而不需要测试工程师针对单一服务单一组件人工模拟系统故障的操作，大大降低了测试工程师的测试工作量，并且提高了跨组件交易一致性测试的效率。

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

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种跨组件交易一致性测试方法，其特征在于，应用于包括服务目录、转发器和多个组件的交易系统，所述跨组件交易一致性测试方法包括：

对所述多个组件提供的服务进行过滤，获得目标服务列表；

获取所述目标服务列表中的每个服务的交易路径；

对所述目标服务列表中的每个服务的交易路径中的每个节点设计测试案例，所述测试案例包括服务名称、交易路径、测试点和预期结果；

利用所述转发器进行超时模拟，以执行所有的所述测试案例；

在所有的所述测试案例执行完毕后，根据所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态判断所述交易系统是否满足跨组件交易一致性要求。

2.根据权利要求1所述的跨组件交易一致性测试方法，其特征在于，所述利用所述转发器进行超时模拟包括：

启动所述转发器的转发端口的监听线程，所述监听线程用于将所述测试点的交易请求转发至交易请求接收节点；

对所述转发器进行配置，将所述目标服务列表中的每个服务的交易路径中的每个节点在所述服务目录中注册的地址更换为所述转发器的地址和所述转发端口地址；

将所述转发器的响应延时设置为预设时间。

3.根据权利要求2所述的跨组件交易一致性测试方法，其特征在于，所述预设时间大于所述目标服务列表中的每个服务的交易路径中的每个节点的请求超时时间。

4.根据权利要求3所述的跨组件交易一致性测试方法，其特征在于，所述预设时间的取值大于10秒。

5.根据权利要求1所述的跨组件交易一致性测试方法，其特征在于，所述根据所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态判断所述交易系统是否满足跨组件交易一致性要求包括：

获取所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态；

判断所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态是否一致，如果是，则判断所述交易系统满足跨组件交易一致性要求，如果否，则判断所述交易系统不满足跨组件交易一致性要求，并将存在交易状态不一致节点的交易路径对应的服务进行显示。

6.一种跨组件交易一致性测试系统，其特征在于，应用于包括服务目录、转发器和多个组件的交易系统，所述跨组件交易一致性测试系统包括：

服务过滤模块，用于对所述多个组件提供的服务进行过滤，获得目标服务列表；

路径获取模块，用于获取所述目标服务列表中的每个服务的交易路径；

案例设计模块，用于对所述目标服务列表中的每个服务的交易路径中的每个节点设计测试案例，所述测试案例包括服务名称、交易路径、测试点和预期结果；

超时模拟模块，用于利用所述转发器进行超时模拟，以执行所有的所述测试案例；

判断模块，用于在所有的所述测试案例执行完毕后，根据所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态判断所述交易系统是否满足跨组件交易一致性要求。

7.根据权利要求6所述的跨组件交易一致性测试系统，其特征在于，所述超时模拟模块包括：

线程启动单元，用于启动所述转发器的转发端口的监听线程，所述监听线程用于将所述测试点的交易请求转发至交易请求接收节点；

配置单元，用于对所述转发器进行配置，将所述目标服务列表中的每个服务的交易路径中的每个节点在所述服务目录中注册的地址更换为所述转发器的地址和所述转发端口地址；

时间设定单元，用于将所述转发器的响应延时设置为预设时间。

8.根据权利要求7所述的跨组件交易一致性测试系统，其特征在于，所述预设时间大于所述目标服务列表中的每个服务的交易路径中的每个节点的请求超时时间。

9.根据权利要求8所述的跨组件交易一致性测试方法，其特征在于，所述预设时间的取值大于10秒。

10.根据权利要求6所述的跨组件交易一致性测试方法，其特征在于，所述判断模块包括：

状态获取单元，用于在所有的所述测试案例执行完毕后，获取所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态；

一致性判断单元，用于判断所述目标服务列表中的每个服务的交易路径中的每个节点的交易状态是否一致，如果是，则判断所述交易系统满足跨组件交易一致性要求，如果否，则判断所述交易系统不满足跨组件交易一致性要求，并将存在交易状态不一致节点的交易路径对应的服务进行显示。