一种多服务器交互业务的测试方法及系统与流程

文档序号:12006027阅读:171来源:国知局
一种多服务器交互业务的测试方法及系统与流程
本申请涉及测试技术,特别是涉及一种多服务器交互业务的测试方法及系统。

背景技术:
随着互联网的发展,网络上的业务往往是由多个系统共同完成的,所述系统可能分属于不同的企业,因此在对该业务进行测试时,通常都是企业各自针对自己的系统进行测试。使用时,单个系统的内部业务可能都是正常的,但是在系统间的业务交互却可能出现错误,而目前没有一种方法能够对该业务的整个流程进行测试。例如,某一企业的内部系统是一个开放式的平台,内部服务器通过接口与外部服务器协同交互来处理业务。业务的处理流程是第一外部服务器发送业务请求到内部服务器,内部服务器创建业务并发送业务数据到第二外部服务器,然后根据接收的第二外部服务器的返回数据进行相应的处理。现有技术是针对所述内部服务器的内部流程进行测试的,主要是测试其内部流程是否存在异常。首先,内部服务器接收业务请求并生成业务,然后通过接口发送业务数据到外部服务器,并根据接收的返回数据执行后续的处理操作。但测试中不会真实与调用外部服务器交互,而是预先模拟出与外部服务器交互的接口,并模拟好所述接口的返回数据,因此当调用接口来发送业务数据时,直接接收对应模拟好的返回数据,而没有与外部服务器进行交互。上述内部服务器的内部流程测试中,并没有真实的涉及到外部服务器的参与,因而也没有模拟出多服务器的交互行为,所以不能测试出多服务器在交互处理业务中是否存在异常问题。

技术实现要素:
本申请提供一种多服务器交互业务的测试方法及系统,以解决现有技术中无法测试多服务器交互业务整个流程的问题。为了解决上述问题,本申请公开了一种多服务器交互业务的测试方法,其特征在于,包括:创建模拟服务器,所述模拟服务器用于模拟与内部服务器进行真实交互的外部服务器;内部服务器根据接收的业务请求生成业务,并将对应的业务数据发送至模拟服务器,其中业务状态为创建中;若在预置的时间内接收到模拟服务器处理的返回数据,则根据不同的返回数据执行不同的处理操作;若在预置的时间内未接收到模拟服务器处理的返回数据,则重新发送业务数据至模拟服务器;若上述所有过程都执行正常,则多服务器交互业务的测试通过。相应的,本申请还公开了一种多服务器交互业务的测试系统,其特征在于,包括内部服务器和模拟服务器,其中,所述模拟服务器用于模拟与内部服务器进行交互的外部服务器,所述内部服务器包括:创建模块,用于根据接收的业务请求创建业务;第一发送模块,用于将对应的业务数据发送至模拟服务器;处理模块,用于若在预置的时间内接收到模拟服务器处理的返回数据,则根据不同的返回数据执行不同的处理操作;第二发送模块,用于若在预置的时间内未接收到模拟服务器处理的返回数据,则重新发送业务数据至模拟服务器。与现有技术相比,本申请包括以下优点:首先,本申请所述的方法模拟出了业务处理中内部服务器与外部服务器的交互过程,最初创建模拟服务器,所述模拟服务器用于模拟与内部服务器进行交互的外部服务器,内部服务器根据接收的业务请求生成业务,并将所述业务数据发送至模拟服务器,其中,业务状态为创建中。真实服务器若在预置的时间内接收到模拟服务器处理的返回数据,则根据不同的返回数据执行不同的处理操作;真实服务器若在预置的时间内未接收到模拟服务器处理的返回数据,则重新发送业务数据至模拟服务器。本申请在测试中会调用模拟服务器,并且针对模拟服务器处理后的返回数据,真实服务器可以执行相应的处理措施。本申请模拟出了多服务器的交互行为,能够测试出多服务器在交互处理业务中是否存在异常问题,从而可以使多服务器交互业务更加完善,使业务的处理更加流畅并且有保障。其次,本申请充分的测试出了业务交互过程中的各种可能性。模拟服务器会根据业务数据的不同情况,发送不同的返回数据,而真实服务器会根据模拟服务器的不同返回数据执行不同的操作,使得业务的整个流程的测试更加丰富,测试场景更加全面。再次,本申请中模拟了真实业务处理中的场景,设立了消息重发机制,但在业务处理中消息不是无限次重发的,因此,当发送业务数据的次数超过预置的范围时,会标识业务状态为创建失败,更加符合真实业务处理操作,并且综合考虑了业务流程中的各种可能性,更加接近于真实的业务处理场景。附图说明图1是本申请实施例所述一种多服务器交互业务的测试方法流程图;图2是本申请实施例所述一种多服务器交互业务的测试方法第一种交互示意图;图3是本申请实施例所述一种多服务器交互业务的测试方法第二种交互示意图;图4是本申请实施例所述一种多服务器交互业务的测试方法第三种交互示意图;图5是本申请优选实施例所述一种多服务器交互业务的测试方法流程图;图6是本申请实施例所述一种多服务器交互业务的测试系统结构图。具体实施方式为使本申请的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本申请作进一步详细的说明。业务的处理流程是第一外部服务器发送业务请求到内部服务器,内部服务器创建业务并发送业务数据到第二外部服务器,然后根据接收的第二外部服务器的返回数据进行相应的处理。现有技术是针对所述内部服务器的内部流程进行测试的,主要是测试其内部流程是否存在异常。测试中不会真实与调用外部服务器交互,而是预先模拟出与外部服务器交互的接口,并模拟好所述接口的返回数据,因此当调用接口来发送业务数据时,直接接收对应模拟好的返回数据,而没有与外部服务器进行交互。本申请提供了一种多服务器交互业务的测试方法,本申请在测试中会调用模拟服务器,并且针对模拟服务器处理后的返回数据,真实服务器可以执行相应的处理措施。本申请模拟出了多服务器的交互行为,能够测试出多服务器在交互处理业务中是否存在异常问题,从而可以使多服务器交互业务更加完善,使业务的处理更加流畅并且有保障。参照图1,其给出了本申请实施例所述一种多服务器交互业务的测试方法流程图。步骤11,创建模拟服务器,所述模拟服务器用于模拟与内部服务器进行真实交互的外部服务器;由于内部服务器是一个开放式的平台,其通过接口与不同企业的外部服务器协同交互来处理业务。测试中不能调用真实的外部服务器,因此本申请首先创建模拟服务器,所述模拟服务器用于模拟与内部服务器进行真实交互的外部服务器。所述模拟服务器可以采用JETTY服务器,因此可以在测试脚本中嵌入所述JETTY服务器,则测试中当内部服务器通过接口调用外部服务器进行交互时,就会调用模拟服务器模拟该交互。所述JETTY服务器是一个开源的JAVA服务器,JETTY是一个开源的servlet容器,是基于Java的web内容。步骤12,内部服务器根据接收的业务请求生成业务,并将对应的业务数据发送至模拟服务器,其中业务状态为创建中;测试脚本启动时会同时启动模拟服务器,测试脚本调用内部服务器的接口生成业务请求,并传输给内部服务器。内部服务器接收业务请求,并根据业务请求生成业务,然后将对应的业务数据发送至模拟服务器,初始时,将业务状态标识为创建中。步骤13,判断在预置的时间内是否接收到模拟服务器处理的返回数据;内部服务器会判断在预置的时间内,是否接收到了模拟服务器处理的返回数据。若是,则执行步骤14,若否,则执行步骤15。其中,内部服务器的处理过程是异步的,例如在发送完业务B的业务数据后,可以继续处理关于业务C的业务请求,或处理关于业务A的返回数据,于此同时针对业务B判断在预置的时间内,内部服务器是否接收到模拟服务器处理的返回数据。步骤14,根据不同的返回数据执行不同的处理操作;模拟服务器在接收到内部服务器的业务数据后,会根据业务数据的不同,执行不同的处理并返回不同的返回数据。内部服务器在预置的时间内接收到模拟服务器处理的返回数据后,可以根据不同的返回数据执行不同的处理操作。步骤15,重新发送业务数据至模拟服务器。优选的,若发送业务数据的次数达到预置的范围后,仍未收到模拟服务器处理的返回数据,则标识业务状态为创建失败。若内部服务器在预置的时间内未接收到模拟服务器处理的返回数据,则所述内部服务器会重新发送业务数据至模拟服务器。但是针对某个业务,内部服务器不能一直重复发送业务数据,因此在内部服务器中预置了某一范围,若发送业务数据的次数达到预置的范围后,仍未收到模拟服务器处理的返回数据,则不会再从新发送业务数据,而是标识业务状态为创建失败。业务在处理中可能会出现阻塞的问题,因此有些业务数据发送后可能丢失或不能及时处理,针对此种情况在内部服务器中设置了业务数据的重发机制。本申请为了模拟此种情况,本申请为模拟服务器设置了睡眠状态及睡眠状态的持续时间,一旦模拟服务器处于睡眠状态时就不能接受业务数据,直到模拟服务器恢复正常状态。例如,设置内部服务器的重发时间为2s,模拟服务器睡眠状态的持续时间为10s,服务器发送业务B的业务数据,此时模拟服务器刚好处于睡眠状态。若内部服务器的重发次数为3次(包含首次发送业务数据),则当内部服务器第3次发送数据给模拟服务器时,模拟服务器依然处于睡眠状态不能处理业务,2s后内部服务器仍然没有接收到模拟服务器的返回数据,此时会标识业务状态为创建失败。若内部服务器的重发次数为6次(包含首次发送业务数据),则当内部服务器第6次发送数据给模拟服务器时,模拟服务器处于正常状态,则可以正常的接收并处理业务数据。若上述所有过程都执行正常,则多服务器交互业务的测试通过。若某个过程执行异常,则多服务器交互业务的测试中存在异常情况,需要进行调试直到所有过程都执行正常,多服务器交互业务的测试通过为止。在本申请中,内部服务器发送业务数据到模拟服务器,模拟服务器接收到业务数据后的处理步骤包括:若模拟服务器接收到不完整的业务数据,则返回数据为系统错误;若模拟服务器接收到完整的业务数据,但所述业务数据无效,则返回数据为业务处理失败;若模拟服务器接收到完整的业务数据,且所述业务数据有效,则返回数据为业务处理成功。其中,当所述业务数据存在业务性的错误时,所述业务数据是无效的,其中,所述业务的ID和数据与已有的业务的ID和数据重复,仓库编码错误或密码错误等均为业务性的错误。若所述业务数据不包含上述业务性的错误,则可认为该业务数据有效。例如,内部服务器发送的业务数据是一个XML格式的数据,所述数据的格式如<request><id>100</id><name>铅笔</name></request>。若模拟服务器接收到的业务数据为<request><id>100</id>,则该数据为不完整的业务数据,此时业务数据出现异常,模拟服务器会将所述异常数据直接抛出,然后返回数据给内部服务器,所述返回数据为系统错误。若模拟服务器接收到的业务数据为<request><id>100</id><name>铅笔</name></request>,则该数据是完整的业务数据,此时会判断该数据在业务上是否是有效的,例如,若模拟服务器发现该业务的ID和数据,与已有的业务的ID和数据重复,则此时模拟服务器会返回数据告知内部服务器该业务无法处理,其中所述返回数据为业务处理失败。所述返回数据也可以采用XML格式数据表示。若模拟服务器接收到的业务数据为<request><id>100</id><name>铅笔</name></request>,则该数据是完整的业务数据,并且所述业务数据有效。模拟服务器会执行相应的处理,并发送返回数据给内部服务器,所述返回数据为业务处理成功。对应模拟服务器处理的返回数据,内部服务器的处理步骤包括:若在预置的时间内接收到模拟服务器处理的返回数据为系统错误,则不执行任何操作;若在预置的时间内接收到模拟服务器处理的返回数据为业务处理失败,则将业务状态标识为创建失败;若在预置的时间内接收到模拟服务器处理的返回数据为业务处理成功,则将业务状态标识为创建成功。其中,若所述业务创建失败,内部服务器可以将接返回错误数据给测试脚本,告知其业务创建失败。参照图2,其给出了本申请实施例所述一种多服务器交互业务的测试方法第一种交互示意图。内部服务器与模拟服务器交互业务的第一种处理过程包括:1.内部服务器接收业务请求,并生成业务;2.内部服务器发送业务数据到模拟服务器;3.模拟服务器处理业务数据;4.模拟服务器处理完业务数据并生成返回数据后,发送返回数据给内部服务器;5.内部服务器针对不同的返回数据,执行不同的处理操作。参照图3,其给出了本申请实施例所述一种多服务器交互业务的测试方法第二种交互示意图。内部服务器与模拟服务器交互业务的第二种处理过程包括:1.内部服务器接收业务请求,并生成业务;2.内部服务器发送业务数据到模拟服务器;此时模拟服务器处于睡眠状态,不能接收并处理业务数据;3.超过预定的时间,内部服务器未接收到模拟服务器处理的返回数据,此时会重新发送业务数据到模拟服务器;4.当业务数据发送的次数达到预置的范围,并且认为未收到返回数据,此时内部服务器标识业务处理状态为处理失败。参照图4,其给出了本申请实施例所述一种多服务器交互业务的测试方法第三种交互示意图。内部服务器与模拟服务器交互业务的第三种处理过程包括:1.内部服务器接收业务请求,并生成业务;2.内部服务器发送业务数据到模拟服务器;此时模拟服务器处于睡眠状态,不能接收并处理业务数据;3.超过预定的时间,内部服务器未接收到模拟服务器处理的返回数据,此时会重新发送业务数据到模拟服务器;4.模拟服务器的睡眠状态结束,恢复正常状态,此时模拟服务器正常处理业务数据;5.模拟服务器处理完业务数据并生成返回数据后,发送返回数据给内部服务器;6.内部服务器针对不同的返回数据,执行不同的处理操作。随着互联网的发展,网络上的业务往往是由多个系统共同完成的,下面举例论述所述业务的流程测试。例如,内部服务器为物流系统服务器,模拟服务器为模拟的仓库系统服务器。物流系统会接收订单后,会创建订单并发送订单到仓库系统服务器,具体流程如下:参照图5,其给出了本申请优选实施例所述一种多服务器交互业务的测试方法流程图。步骤21,创建模拟的仓库系统服务器,所述模拟的仓库系统服务器用于模拟与物流系统服务器进行真实交互的仓库系统服务器;步骤22,物流系统服务器根据接收的订单创建请求创建订单,并将对应的订单数据发送至模拟的仓库系统服务器,其中订单状态为创建中;其中,模拟的仓库系统服务器接收到订单数据后的处理步骤包括:若模拟的仓库系统服务器接收到不完整的订单数据,则返回数据为系统错误;若模拟的仓库系统服务器接收到完整的订单数据,但所述订单数据无效,则返回数据为业务处理失败;若模拟的仓库系统服务器接收到完整的订单数据,且所述订单数据有效,则返回数据为业务处理成功。步骤23,判断在预置的时间内是否接收到模拟的仓库系统服务器处理的返回数据;若是,则执行步骤24,若否,则执行步骤25。步骤24,判断返回数据的类型;若所返回数据为系统错误,则执行步骤26;若返回数据业务处理失败,则执行步骤27;若返回数据业务处理成功,则执行步骤28;步骤25,模拟的仓库系统服务器出现阻塞的情况,此时重新发送订单数据发送至模拟的仓库系统服务器。步骤26,不执行任何操作;步骤27,将业务状态标识为创建失败;步骤28,将业务状态标识为创建成功。步骤29,若发送业务数据的次数达到预置的范围后,仍未收到模拟服务器处理的返回数据,则标识业务状态为创建失败。若上述所有过程都执行正常,则多服务器交互业务的测试通过。实际在处理中还可以创建一个模拟的ERP服务器,通过所述模拟的ERP服务器发送订单创建请求给物流系统服务器,然后物流服务器再创建订单。若测试中订单创建失败,物流系统服务器可以直接发送错误数据给模拟的ERP服务器,告知其订单创建失败的事件。综上所述,首先本申请所述的方法模拟出了业务处理中内部服务器与外部服务器的交互过程,最初创建模拟服务器,所述模拟服务器用于模拟与内部服务器进行交互的外部服务器,内部服务器根据接收的业务请求生成业务,并将所述业务数据发送至模拟服务器,其中业务状态为创建中。真实服务器若在预置的时间内接收到模拟服务器处理的返回数据,则根据不同的返回数据执行不同的处理操作;真实服务器若在预置的时间内未接收到模拟服务器处理的返回数据,则重新发送业务数据至模拟服务器。本申请在测试中会调用模拟服务器,并且针对模拟服务器处理后的返回数据,真实服务器可以执行相应的处理措施。本申请模拟出了多服务器的交互行为,能够测试出多服务器在交互处理业务中是否存在异常问题,从而可以使多服务器交互业务更加完善,使业务的处理更加流畅并且有保障。其次,本申请充分的测试出了业务交互过程中的各种可能性。模拟服务器会根据业务数据的不同情况,发送不同的返回数据,而真实服务器会根据模拟服务器的不同返回数据执行不同的操作,使得业务的整个流程的测试更加丰富,测试场景更加全面。再次,本申请中模拟了真实业务处理中的场景,设立了消息重发机制,但在业务处理中消息不是无限次重发的,因此当发送业务数据的次数超过预置的范围时,会标识业务状态为创建失败,更加符合真实业务处理操作,并且综合考虑了业务流程中的各种可能性,更加接近于真实的业务处理场景。参照图6,其给出了本申请实施例所述一种多服务器交互业务的测试系统结构图。相应的,本申请还提供了一种多服务器交互业务的测试系统,包括内部服务器11和模拟服务器12,其中,所述模拟服务器12用于模拟与内部服务器11进行交互的外部服务器。所述内部服务器11包括:创建模块111,用于根据接收的业务请求创建业务;第一发送模块112,用于将对应的业务数据发送至模拟服务器;此时,业务状态为创建中。处理模块113,用于若在预置的时间内接收到模拟服务器处理的返回数据,则根据不同的返回数据执行不同的处理操作;第二发送模块114,用于若在预置的时间内未接收到模拟服务器处理的返回数据,则重新发送业务数据至模拟服务器。所述模拟服务器12包括:第一返回模块121,用于若模拟服务器接收到不完整的业务数据,则返回数据为系统错误;第二返回模块122,用于若模拟服务器接收到完整的业务数据,但所述业务数据无效,则返回数据为业务处理失败;第三返回模块123,用于若模拟服务器接收到完整的业务数据,且所述业务数据有效,则返回数据为业务处理成功。优选的,所述处理模块包括:第一处理单元,用于若在预置的时间内接收到模拟服务器处理的返回数据为系统错误,则不执行任何操作;第二处理单元,用于若在预置的时间内接收到模拟服务器处理的返回数据业务处理失败,则将业务状态标识为创建失败;第三处理单元,若在预置的时间内接收到模拟服务器处理的返回数据业务处理成功,则将业务状态标识为创建成功。优选的,第二发送模块114,还用于若发送业务数据的次数达到预置的范围后,仍未收到模拟服务器处理的返回数据,则标识业务状态为创建失败。对于系统实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。以上对本申请所提供的一种多服务器交互业务的测试方法及系统,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。
当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1