CN113010432B - 基于流量时序回放的白盒仿真测试方法及系统 - Google Patents

Abstract

本发明提供了一种基于流量时序回放的白盒仿真测试方法及系统，包括：测试用例生成步骤：从业务系统中生成包含时序的用于白盒测试的仿真测试用例；测试用例执行步骤：根据所述仿真测试用例中的时序，与测试系统交互，完成白盒测试。基于对OUTER结果比对和INNER结果比对，以及时序冗余的设计和评价机制，同时完成了黑盒测试和白盒测试。极大的提高了白盒测试的效率，填补了这个领域的空白。

Description

基于流量时序回放的白盒仿真测试方法及系统

技术领域

本发明涉及软件测试领域，具体地，涉及一种基于流量时序回放的白盒仿真测试方法及系统。

背景技术

软件测试一直是软件开发过程的重要组成部分，其目的包括新功能验证、现有功能回归验证、系统集成验证、性能验证、压力下的可用性验证等等。测试系统和测试方法是个巨大的市场，有着广阔的商业场景。

当前的测试方法，都主要是针对被测系统入口的测试。概括来说，这是一种发送测试请求给被测系统入口，通过对比系统实际返回值与测试期望返回值，来对系统做验证的方法。图1是一个典型测试系统结构图。Portal为系统入口，它的请求来自于OUTER业务系统，处理过程可能需要调用一次或多次INNER业务系统提供的服务，然后完成对请求的处理，返回给OUTER系统。Portal和两侧的连接分别为接口I和接口II。假设Portal是被测试的系统(或者系统入口)，那么当前测试方法中，测试系统Tester，通过接口T发送请求给Portal，并获得响应。接口T其实等价于接口I。

近年来，在软件测试领域逐渐兴起一种称为“仿真测试”的测试方法，和传统测试通过手动编写测试用例后者脚本辅助生成测试用例不同，仿真测试主要是“捕获”业务系统中的真实交易，然后以回放的方式打回到测试系统或者声场系统，主要满足功能回归验证，系统集成验证、性能验证和压力下的可用性验证。捕获的方法主要是通过抓包、协议解码然，然后做交易关联已经回放。所以，以图1为例，当前传统测试方法和当前仿真测试方法，主要区别是测试用例的来源不同而已。

但这些方法都很难深入到系统内，去洞察在各种测试用例下，一个系统是否“真的”运行正确：譬如多个服务之间的处理时序是否和之前保持一致的，是否因为不同的异常返回了同样的响应，还是只是仅仅表面上的返回值上是一样而已。譬如“HTTP 200 OK”、“HTTP 404 NOT FOUND”和“HTTP 500 INTERNAL SERVER ERROR”是HTTP中最常见的正确和错误返回，但内部的实际逻辑可能千差万别。

某种程度上这需要一种“白盒”的测试方法。如果是基于单机的系统，那么没有通用的方法，只能在开发中添加相应机制，个例化进行处理。但目前的主流软件系统是以分布式、服务化、微服务化为特征的系统(可以简化成图1)。这类系统中，单个服务升级的情况频繁，因此如何对单个服务做完善的全面的自动化的测试，是保障和运维这类系统的重要环节。

专利文献CN202011368615公开了一种基于网络数据分析的仿真测试系统及方法，主要是针对入口的测试，没有多段关联成时序交易链，没有挡板方法，没有按时序回放的方法，是种黑盒测试。

发明内容

针对现有技术中的缺陷，本发明的目的是提供一种基于流量时序回放的白盒仿真测试方法及系统。

根据本发明提供的一种基于流量时序回放的白盒仿真测试方法，包括：

测试用例生成步骤：从业务系统中生成包含时序的用于白盒测试的仿真测试用例；

测试用例执行步骤：根据所述仿真测试用例中的时序，与测试系统交互，完成白盒测试。

优选地，所述测试用例生成步骤包括：

步骤1.1：同时采集被测试系统、INNER内部系统和OUTER外部系统的网络流量；

步骤1.2：各段做协议解码和交易关联，所述段指某个发起请求的客户端和进行响应的服务端构成的一请求和服务的逻辑段落；

步骤1.3：根据外部交易关联内部各段交易，形成时序交易链；

步骤1.4：生成测试用例；

步骤1.5：测试用例时序优化和挡板管理。

优选地，包括：

步骤1.5.1：对于时序要有引入配置，或进行定义，确定测试用例中的时序是否可接受的时间冗余范围；

步骤1.5.2：对于不同段的属性，设定不同的挡板方法，做响应用例处理；

步骤1.5.3：对包括错运行的异常、错误在内的情况记录。

步骤1.5.4：对于测试用例的段做预处理，以便在执行时，减少挡板的改动。

优选地，包括：

步骤2.1：读取测试用例，根据用例配置挡板系统；

步骤2.2：发送外部请求到被测试系统；

步骤2.3：按照测试用例的时序，测试系统与被测试系统通过接口进行交互通行；

步骤2.4：反复2.3的步骤，如果测试系统仿真的内部系统交互和实际测试一致，那么最终被测试系统通过接口T给出最后的响应；

步骤2.5：如果步骤2.3出现异常，按照异常处理方法来执行；

步骤2.6：测试用例运行之后，根据测试情况进行评价。

优选地，所述步骤2.6包括：

步骤2.6.1：如果步骤2.4结果一致，步骤2.3没有错误，那么测试用例黑盒测试正确，同时白盒测试正确；

步骤2.6.2：如果步骤2.4结果一致，步骤2.3有错误，那么测试用例黑盒测试正确，同时白盒测试存在问题，对照有错误的步骤，进一步诊断；

步骤2.6.3：如果步骤2.4结果不一致，步骤2.3没有错误，那么测试用例黑盒错误，同时认为发生在最后一个内部交互之后的处理段中；

步骤2.6.4：如果步骤2.4结果不一致，步骤2.3有错误，那么测试用例黑盒错误，同时认为需要优先诊断争端白盒测试中的问题。

根据本发明提供的一种基于流量时序回放的白盒仿真测试系统，包括：

测试用例生成模块：从业务系统中生成包含时序的用于白盒测试的仿真测试用例；

测试用例执行模块：根据所述仿真测试用例中的时序，与测试系统交互，完成白盒测试。

优选地，所述测试用例生成模块M包括：

模块M1.1：同时采集被测试系统、INNER内部系统和OUTER外部系统的网络流量；

模块M1.2：各段做协议解码和交易关联，所述段指某个发起请求的客户端和进行响应的服务端构成的一请求和服务的逻辑段落；

模块M1.3：根据外部交易关联内部各段交易，形成时序交易链；

模块M1.4：生成测试用例；

模块M1.5：测试用例时序优化和挡板管理。

优选地，包括：

模块M1.5.1：对于时序要有引入配置，或进行定义，确定测试用例中的时序是否可接受的时间冗余范围；

模块M1.5.2：对于不同段的属性，设定不同的挡板方法，做响应用例处理；

模块M1.5.3：对包括错运行的异常、错误在内的情况记录。

模块M1.5.4：对于测试用例的段做预处理，以便在执行时，减少挡板的改动。

优选地，包括：

模块M2.1：读取测试用例，根据用例配置挡板系统；

模块M2.2：发送外部请求到被测试系统；

模块M2.3：按照测试用例的时序，测试系统与被测试系统通过接口进行交互通行；

模块M2.4：反复2.3的模块M，如果测试系统仿真的内部系统交互和实际测试一致，那么最终被测试系统通过接口T给出最后的响应；

模块M2.5：如果模块M2.3出现异常，按照异常处理方法来执行；

模块M2.6：测试用例运行之后，根据测试情况进行评价。

优选地，所述模块M2.6包括：

模块M2.6.1：如果模块M2.4结果一致，模块M2.3没有错误，那么测试用例黑盒测试正确，同时白盒测试正确；

模块M2.6.2：如果模块M2.4结果一致，模块M2.3有错误，那么测试用例黑盒测试正确，同时白盒测试存在问题，对照有错误的模块M，进一步诊断；

模块M2.6.3：如果模块M2.4结果不一致，模块M2.3没有错误，那么测试用例黑盒错误，同时认为发生在最后一个内部交互之后的处理段中；

模块M2.6.4：如果模块M2.4结果不一致，模块M2.3有错误，那么测试用例黑盒错误，同时认为需要优先诊断争端白盒测试中的问题。

与现有技术相比，本发明具有如下的有益效果：

1)基于流量捕获、协议解码和多段交易关联，自动化的生成分布式网络系统的白盒测试用例；基于挡板设计和时序放回，可以将上述测试用自动化运行；因此是全自动化的测试生成和执行方法。

2)基于对OUTER结果比对和INNER结果比对，以及时序冗余的设计和评价机制，同时完成了黑盒测试和白盒测试。因此，本发明提出了一种全新的广泛使用分布式网络系统的自动化测试白盒方法，极大的提高了白盒测试的效率，填补了这个领域的空白。

3)这种白盒测试方法可以快速确认是否系统真的从表象和内部实际都是正确的，快速定位出内部问题的来源，以帮助进一步排查和修复；极大的提高了测试的有效性；从而保障系统质量。

附图说明

通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1为传统测试系统结构图；

图2为本发明流程图；

图3为本发明数据采集示意图；

图4为本发明测试系统结构示意图；

图5为本发明测试实施举例示意图。

具体实施方式

下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变化和改进。这些都属于本发明的保护范围。

本发明要解决的技术问题体现在以下几点：

1)扩展仿真测试的方法，通过数据包捕获、协议分析、交易关联，获得真实交易，但不仅仅获得外部系统的交易，同时获得内部系统的所有交易和时序；

2)通过但不限于配置、统计辅助配置和大数据发现等方法，将被测系统外部和内部的交易，做多段关联，整理成时序的交易链的测试用例；

3)针对测试用例，采用挡板方法，替代用例中使用到的交易的内部系统；

4)发送测试用例的请求给系统，等待系统对内部系统调用，按测试用例序进行响应，或主动请求，经过一次或多次与测试系统的交互，完成测试用例。

本发明提出了一种基于网络流量按时序回放的白盒仿真测试系统，参考图2，本方法包括如下步骤：

步骤1：测试用例生成，也就是如何从业务系统中生成包含时序的可以用于白盒测试的仿真测试用例。

步骤2：执行测试用例进行测试，也就是如何根据测试用例中的时序数据，与测试系统交互，完成白盒测试的过程。

其中，步骤1测试用例生成，包括如下步骤：

步骤1.1：内部系统和外部系统数据采集。图3是本发明的系统采集示意图。本方法需要同时采集被测试系统(图中的Portal系统入口)与INNER内部系统和OUTER外部系统的网络流量，也就是接口I和接口II上的流量。而传统(黑盒)仿真测试方法仅仅采集接口I流量。

数据采集是个成熟技术，可以但不限于使用SPAN和TAP等方法。如图所示，本方法使用接口C和接口CC分别对应接口I和接口II，将数据(复制)采集到Collector采集系统中。采集系统和被测系统没有通信或者交互。

步骤1.2：各段做协议解码和交易关联。这里“段”指某个发起请求的客户端和进行响应的服务端构成的一请求和服务的逻辑段落，它们的实际连接可能是通过多层交换机达成的，可以使用通信五元组(SourceIp、DestIp、SourcePort、DestPort和IpProtocolByte)来确定。同时，根据服务定义(通常是服务名称定义，也可以是服务IP和服务端口Port构成)，我们可以将上述通信对的流量都放到服务上去，从而由一个特定的服务和一类雷同的请求构成段。

协议解码和交易关联都是成熟技术，主要都在相同的段内展开。完成本周步骤后，可以获得带时间的构成交易的请求和响应，包括但不限于用如下方式表示：

<ts1,seg_id，trans_id,req,req内容>,

<ts2,seg_id，trans_id,resp,resp内容>。

其中ts1和ts2是时间戳；seg_id，表示是那一段，可以用系统编号，然后对应到段的属性(服务名称，服务IP和服务Port等)；trans_id是段内的交易标识，req和resp分别时表示请求和响应，然后附带各自内容。

trans_id一般是协议定义，交易中请求和响应都有的字段，例如交易号，事件号，流水号等，也可以是多个字段的组合。特殊的，对于同步协议(譬如基于TCP的协议)，因为总是一个请求对应一个响应的结构，可以并不需要显示的交易trans_id，采用系统编号即可，包括但不限于递增整数。

步骤1.3：根据外部交易关联内部各段交易，形成时序交易链。从测试的角度来说，交易要从OUTER系统发起请求，然后关联到INNER系统中的相关的各段的交易。

这种关联可以称为“多段关联”，是种层次递进的树状的展开。多段关联主要是找到业务上可用的从上一段到下一段的关键字，譬如上一段采用客户号，同时交易中有交易流水号，下一段A用客户号查询用户信息和权限，然后再一段B用交易流水号提交到其它系统等。

这种关联不限于信息出现在交易的请求或者响应中，不限于是段交易的交易关联字段或者其它字段。有些场景下两端之间可能不变化关联字段。某一个字段贯穿整个交易，或者交易的若干段，成为主要的关联字段。

基于关联关键字，多段关联可以采用但不限于这样一些方法：

1)通过配置的手段，定义两段之间的关联关键字；

2)基于字段统计信息方法，辅助配置来配置定义两段之间的关联关键字；

3)基于大数据学习的方法，或者人工智能的方法，来发现和配置定义两段之间的关联关键字；

多段关联层层展开，是一个交易关联树，但对于本方法而言，可仅仅需要与Portal相连的系统的段的关联，从而形成一个时序的交易链。如上述例中的服务展开如下：

<ts1,seg_OUTER，OUTER_trans_id,req,cust_id,seq_no,其它内容>，

<ts2,seg_A,A_trans_id,req,cust_id,其它内容>，

<ts3,seg_A，A_trans_id,resp,resp内容>，

<ts4,seg_B，seq_no,req,req内容>，

<ts5,seg_B，seq_no,resp,resp内容>，

<ts6,OUTER_trans_id,trans_outer_id,resp,resp内容>。

其中，ts1到ts6为递增的时间戳；seg_OUTER，seg_A和seg_B为三段的的标识；OUTER_trans_id,A_trans_id，seq_no分别为三段的段内交易标识；cust_id为客户号，包含在seg_OUTER的请求中和seg_A的请求中；seq_no为流水号，包含在seg_OUTER的请求中，并在seg_B作为交易标识

步骤1.4：通用测试用例管理。通用测试用例管理为一般从数据生成测用例的过程，包括但不仅限于：用例的编号，用例描述，用例的(等级、产品、所属等)分类，数据和脚本的拆分，敏感信息替换和脱敏，时间戳缩放，兴趣(需要对比的)字段标记和可忽略(不需要对比的)字段标记等等。当前的传统的测试用例和仿真测试用例都有同类功能。

步骤1.5：测试用例时序优化和挡板管理。这是本方法特有的。因为本方法需要有时序和段，而段对应了不同的服务，因此在实际测试时需要进行的管理和优化。

管理包括但不限于：

1.5.1：对于时序要有引入配置，或进行定义，确定测试用例中的时序是否可接受的时间冗余范围。

1.5.2：对于不同段的属性(服务名称，服务IP和服务Port等)，设定不同的挡板方法，做响应用例处理。(在步骤的挡板章节中详细说明)

1.5.3：可以带错运行的异常、错误等情况记录。

1.5.4：对于测试用例的段做预处理，以便在执行时，减少挡板的改动。

步骤2执行测试用例进行测试。图3是本发明的测试系统结构图。接口I断开，由接口T替代。Shield挡板系统使用接口SS与内部业务系统相连，用于控制来接口II接通INNER业务系统或者连接TT到测试系统Tester。

Shield挡板系统一般为INNER系统中的组件或服务，譬如域名服务器，譬如交换机或各系统路由设置等等。

Tester测试系统可以配置多个网卡，做不同设置：

模式1)有的网卡进行正常的Socket通信；例如接口T，接口TT。这样可以直接和被测试系统交互。

模式2)有的网卡设置成混杂模式，监听所有报文，处理特殊报文；例如接口TT。这样可以通过监听模式，获得被测试系统发出的请求或者回复的响应。

模式3)有的网卡可以网线直连到交换机，直接打流量；例如接口TT。这样可以发送请求或者响应到被测试系统，是其称为接收方。

因此根据实际场景，Shield挡板系统，需要采用不同的TT接口。例如：

测试用例类型1)如果全是服务名称的测试用例，修改DNS就可进行测试，那么TT接口配置成上述模式1)；可以通过DNS协议解码，是否掉用前都有DNS调用来来甄别。

测试用例类型2)如果涉及固定IP定义的测试用例，TT接口需要引入上模式2)和模式3)；

可以使用三种模式。

可以同时支持上述两种测试用例类型。

模式1)为2)和3)的优化方案，使用Socket通信，易于实现，并减少减少复杂性。因此测试用例类型1)是对测试用例类型2)的优化。

因此对应步骤1.5.2的管理中，

在采用优化的系统，测试用例类型1)需要转化成基于Socket的通信测试用例；同时忽略掉DNS相关流量。

对于测试用例类型2)需要转化成流量监听和流量回放的测试用例。否则全部转化流量监听和流量回放的测试系统。

步骤2包括如下步骤：

步骤2.1：读取测试用例，根据用例配置挡板系统。通过读取测试用例，测试系统知道被测试用例涉及哪几个内部系统的段——也就是服务。这时候需要设置挡板系统，使得测试系统和被测试系统可以交互。等待配置生效后，继续执行。

步骤2.2：发送外部请求到被测试系统。首先通过接口T发送的测试用例中OUTER段的请求到被测试系统。显然，起始时间基准是不同的，仅仅考虑相对关系。

步骤2.3：按时序与被测试系统交互。按照测试用例的时序，测试系统与被测试系统通过接口TT进行交互通行，完成但不限于如下交互操作：

1)收到被测试系统发给特定段的请求，比对测试用例中该段请求的时间，是否在冗余范围内(步骤1.5.1)符合要求：

a.对于符合要求的情况，按相应的时序做适当延迟(以模拟处理时间)，返回测试用例中内容；继续后续测试。

b.对于符合要求的情况，如果不需要响应，继续后续测试。

c.对于不符合要求的情况，包括超时，进入异常处理。

2)以事件触发(启动后的时延事件，或者收到特性请求事件，或者收到特定请求后的时延事件)主动发送特定请求给被测试系统

a.如果不需要响应，继续后续测试。

b.否则等待被测试系统的响应，比对测试用例中该响应的时间，是否在冗余范围内(步骤1.5.1)符合要求：

i.对于符合要求的情况，按相应的时序做适当延迟(以模拟处理时间)，返回测试用例中内容；继续后续测试。

ii.对于不符合要求的情况，包括超时，进入异常处理。

步骤2.4：接收到外部响应退出。反复2.3的步骤，如果测试系统仿真的内部系统交互和实际测试一致，那么最终被测试系统通过接口T给出最后的响应。步骤2.4的一种与否，主要体现了黑盒测试的结果。

步骤2.5：交互异常处理或退出。如果步骤2.3出现异常，需要按照异常处理方法来执行，包含但不限于：

1)参考1.4的配置，属于可以可忽略(不需要对比的)字段标记，不认为是错误，去除错误标记，记录信息，继续执行后续测试；

2)交易顺序乱了，但是参考1.5.1)的配置，时间可容忍范围内，不认为是错误，去除错误标记，记录信息，继续执行后续测试；

3)参考1.5.3，属于可带错执行的情况，记录错误，继续执行后续流程；

4)记录错误，退出；

步骤2.5是对步骤2.3错误的澄清和记录，其结果用于表征白盒测试是否检测到错误。

步骤2.6：测试结果评价。测试用例运行之后，根据测试情况评价：

2.6.1：如果2.4结果一致，2.3没有错误(譬如完全没有2.5信息，或者仅仅2.5的信息，没有错误)，那么测试用例黑盒测试正确，同时白盒测试正确。

2.6.2：如果2.4结果一致，2.3有错误(譬如2.5有记录到错误)，那么测试用例黑盒测试正确，同时白盒测试存在问题，对照有错误的步骤，进一步诊断。

2.6.3：如果2.4结果不一致，2.3没有错误(譬如完全没有2.5信息，或者仅仅2.5的信息，没有错误)，那么测试用例黑盒错误，同时可以认为发生在最后一个内部交互之后的处理段中。

2.6.4：如果2.4结果不一致，有错误(譬如2.5有记录到错误)，那么测试用例黑盒错误，同时认为需要优先诊断争端白盒测试中的问题。

实施例1

图5是一个系统的测试实施举例。图中Portal是被测试系统，业务场景中，请求来自于左侧接口I相连的BIZ业务网络，右侧接口II相连的是BUS总线，有服务A、B……X，都由DNS提供提供服务解析。

测试用例生成过程中：

步骤1.1，在接口I上采集Portal和BIZ的通信，在接口II上采集了Port和DNS、A、B……X的通信(DNS、A、B……X)的通信不需要采集。

步骤1.2，采用通用的解码，譬如ESB采用HTTP+XML+SOAP协议。段内交易关联采用同步协议方法即可。

步骤1.3，可以根据实际业务来，譬如也可能有全局统一的字段，gid。

步骤1.4，通用方法分解成测试用例。

步骤1.5，因为使用DNS，测试用例类型1)其中1.5.2配置为模式1。并去除DNS请求和响应。

得到如下包含如下时序交易链的测试用例，ts1-ts8为相对时间：

<ts1,outer，id1,req,gid,其它内容>，

<ts2,A,idA,req,gid,其它内容>，

<ts3,A，idA,resp,resp其它内容>，

<ts4,B，idB,req,gid,其它内容>，

<ts5,X，idX,req,gid,其它内容>，

<ts6,X，idX,resp,resp其它内容>，

<ts7,B，idB,resp,resp其它内容>，

<ts8,OUTER,id1,resp其它内容>。

测试用例执行过程中：

步骤2.1，将接口T和接口TT都配置成Socket通信模式。同时相关DNS配置发给DNS服务器。等待配置生效后继续执行。

步骤2.2，Tester在T接口上发送请求到Portal：

<ts1,outer，id1,req,gid,其它内容>。

步骤2.3，Tester按照测试用例预期时序预期顺序收到来自Portal的请求：

<ts2,A,idA,req,gid,其它内容>，

<ts4,B，idB,req,gid,其它内容>，

<ts5,X，idX,req,gid,其它内容>。

同时Tester按如下时序顺序回复响应：

<ts3,A，idA,resp,resp其它内容>，

<ts6,X，idX,resp,resp其它内容>，

<ts7,B，idB,resp,resp其它内容>。

步骤2.4，Tester在T接口上预期接收到来自Portal的如下请求：

<ts8,OUTER,id1,resp其它内容>。

步骤2.5，没有异常。

步骤2.6，根据实际情况按进行评价。

本领域技术人员知道，除了以纯计算机可读程序代码方式实现本发明提供的系统及其各个装置、模块、单元以外，完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统及其各个装置、模块、单元以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同功能。所以，本发明提供的系统及其各项装置、模块、单元可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置、模块、单元也可以视为硬件部件内的结构；也可以将用于实现各种功能的装置、模块、单元视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变化或修改，这并不影响本发明的实质内容。在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。

Claims (6)

1.一种基于流量时序回放的白盒仿真测试方法，其特征在于，包括：

测试用例生成步骤：从业务系统中生成包含时序的用于白盒测试的仿真测试用例；

测试用例执行步骤：根据所述仿真测试用例中的时序，与测试系统交互，完成白盒测试；

所述测试用例生成步骤包括：

步骤1.1：同时采集被测试系统、INNER内部系统和OUTER外部系统的网络流量；

步骤1.2：各段做协议解码和交易关联，所述段指某个发起请求的客户端和进行响应的服务端构成的一请求和服务的逻辑段落；

步骤1.3：根据外部交易关联内部各段交易，形成时序交易链；

步骤1.4：生成测试用例；

步骤1.5：测试用例时序优化和挡板管理；

所述步骤1.5包括：

步骤1.5.1：对于时序要有引入配置，或进行定义，确定测试用例中的时序是否可接受的时间冗余范围；

步骤1.5.2：对于不同段的属性，设定不同的挡板方法，做响应用例处理；

步骤1.5.3：对包括错运行的异常、错误在内的情况记录；

步骤1.5.4：对于测试用例的段做预处理，以便在执行时，减少挡板的改动。

2.根据权利要求1所述的基于流量时序回放的白盒仿真测试方法，其特征在于，所述测试用例执行步骤包括：

步骤2.1：读取测试用例，根据用例配置挡板系统；

步骤2.2：发送外部请求到被测试系统；

步骤2.3：按照测试用例的时序，测试系统与被测试系统通过接口TT进行交互通行；

步骤2.4：反复2.3的步骤，如果测试系统仿真的内部系统交互和实际测试一致，那么最终被测试系统通过接口T给出最后的响应；

步骤2.5：如果步骤2.3出现异常，按照异常处理方法来执行；

步骤2.6：测试用例运行之后，根据测试情况进行评价。

3.根据权利要求2所述的基于流量时序回放的白盒仿真测试方法，其特征在于，所述步骤2.6包括：

步骤2.6.1：如果步骤2.4结果一致，步骤2.3没有错误，那么测试用例黑盒测试正确，同时白盒测试正确；

步骤2.6.2：如果步骤2.4结果一致，步骤2.3有错误，那么测试用例黑盒测试正确，同时白盒测试存在问题，对照有错误的步骤，进一步诊断；

步骤2.6.3：如果步骤2.4结果不一致，步骤2.3没有错误，那么测试用例黑盒错误，同时认为发生在最后一个内部交互之后的处理段中；

步骤2.6.4：如果步骤2.4结果不一致，步骤2.3有错误，那么测试用例黑盒错误，同时认为需要优先诊断争端白盒测试中的问题。

4.一种基于流量时序回放的白盒仿真测试系统，其特征在于，包括：

测试用例生成模块：从业务系统中生成包含时序的用于白盒测试的仿真测试用例；

测试用例执行模块：根据所述仿真测试用例中的时序，与测试系统交互，完成白盒测试；

所述测试用例生成模块包括：

模块M1.1：同时采集被测试系统、INNER内部系统和OUTER外部系统的网络流量；

模块M1.2：各段做协议解码和交易关联，所述段指某个发起请求的客户端和进行响应的服务端构成的一请求和服务的逻辑段落；

模块M1.3：根据外部交易关联内部各段交易，形成时序交易链；

模块M1.4：生成测试用例；

模块M1.5：测试用例时序优化和挡板管理；

所述模块M1.5包括：

模块M1.5.1：对于时序要有引入配置，或进行定义，确定测试用例中的时序是否可接受的时间冗余范围；

模块M1.5.2：对于不同段的属性，设定不同的挡板方法，做响应用例处理；

模块M1.5.3：对包括错运行的异常、错误在内的情况记录；

模块M1.5.4：对于测试用例的段做预处理，以便在执行时，减少挡板的改动。

5.根据权利要求4所述的基于流量时序回放的白盒仿真测试系统，其特征在于，所述测试用例执行模块包括：

模块M2.1：读取测试用例，根据用例配置挡板系统；

模块M2.2：发送外部请求到被测试系统；

模块M2.3：按照测试用例的时序，测试系统与被测试系统通过接口TT进行交互通行；

模块M2.4：反复2.3的模块M，如果测试系统仿真的内部系统交互和实际测试一致，那么最终被测试系统通过接口T给出最后的响应；

模块M2.5：如果模块M2.3出现异常，按照异常处理方法来执行；

模块M2.6：测试用例运行之后，根据测试情况进行评价。

6.根据权利要求5所述的基于流量时序回放的白盒仿真测试系统，其特征在于，所述模块M2.6包括：

模块M2.6.1：如果模块M2.4结果一致，模块M2.3没有错误，那么测试用例黑盒测试正确，同时白盒测试正确；

模块M2.6.2：如果模块M2.4结果一致，模块M2.3有错误，那么测试用例黑盒测试正确，同时白盒测试存在问题，对照有错误的模块M，进一步诊断；

模块M2.6.3：如果模块M2.4结果不一致，模块M2.3没有错误，那么测试用例黑盒错误，同时认为发生在最后一个内部交互之后的处理段中；

模块M2.6.4：如果模块M2.4结果不一致，模块M2.3有错误，那么测试用例黑盒错误，同时认为需要优先诊断争端白盒测试中的问题。