一种基于案例模板的流量回放方法

摘要

本发明属于软件开发和软件测试技术领域，公开了一种基于案例模板的流量回放方法，包括以下步骤，步骤1：接口映射编号；步骤2：流量录制；步骤3：准备流量回放案例模板；步骤4：流量回放。本发明解决了在长链路多系统的环境里，如果出现数据冲突，需要在多个系统里进行数据清理才能回放，严重降低回放便捷性的技术问题。

说明书

技术领域

本发明属于软件开发和软件测试技术领域，具体涉及一种基于案例模板的流量回放方法。

背景技术

流量回放是指通过将录制的系统请求，通过一定的方法重新在测试或者生产环境回放进行功能验证。

当前的方案主要将通过录制的流量，直接在测试环境或者其他环境进行回放，该方式需要保证测试环境存量数据不存在或者录制的流量数据与存量数据没有冲突的情况。

如果有冲突，在回放的时候才能够发现，然后再进行处理，就会造成效率低下。另外，如果回放流量是在一个由多个系统组成的测试环境，那就需要在每个系统处理有冲突的数据，这也会造成效率低下。

发明内容

基于以上问题，本发明提供一种基于案例模板的流量回放方法，解决了在长链路多系统的环境里，如果出现数据冲突，需要在多个系统里进行数据清理才能回放，严重降低回放便捷性的技术问题。

为解决技术问题，本发明所采用的技术方案是：

一种基于案例模板的流量回放方法，包括以下步骤，

步骤1：接口映射编号，将被录制系统所有的接口名进行映射编号，对每个不同的接口名进行唯一性短码编号，用于快速标识接口名；

步骤2：流量录制，流量录制服务器按照自定义的模板格式，将与流量相关的元素按照设定的流量保存模型保存到流量录制数据库中，同时对录制的每一个接口依据步骤1里的短编码进行标识并保存；

步骤3：准备流量回放案例模板，组成案例模板，将案例模板对应的请求接口，及请求参数进行数据分离，将录制元素里面不能多次反复使用的数据，进行随机或者序列化方式进行生成，保证每次具有唯一性，并标识为不可替换，其他的请求参数标识为可替换；

步骤4：流量回放，启动多线程反复的回放测试模板，以案例模板的接口调用顺序将录制的流量数据全部进行回放，将所有被测系统的接口元素标识为可替换与不可替换，对不可替换的数据，通过进行随机或者序列化方式进行生成，保证每次运行都具有唯一性，实现可以重复回放，可替换数据使用流量录制数据，实现应用流量录制数据，直到所有的流量数据库中所有录制的流量都被标识为已完成后，停止流量回放功能模块。

在本发明一实施例中，上述步骤2具体包括如下：

步骤2.1：通过tcpcopy监控需要录制流量的服务器端口；

步骤2.2：将tcpcopy获得的tcp协议请求数据复制一份到流量录制服务器；

步骤2.3：流量录制服务器通过tcp解析服务，将流量解析为http协议，并按照自定义的模板格式，将各种与流量相关的元素按照设定的流量保存模型保存到流量录制数据库中，同时对录制的每一个接口依据步骤1里的短编码进行标识并保存。

进一步的，在步骤2.2中，与流量相关的元素包括请求头，请求路径，请求参数，响应返回。

在本发明一实施例中，上述步骤3具体包括如下：

步骤3.1：将需要回放的测试场景及被测系统所有接口组成若干案例模板；

步骤3.2：将案例模板对应的请求接口，及请求参数进行数据分离；

步骤3.3：将录制元素里面不能多次反复使用的数据，进行随机或者序列化方式进行生成，保证每次具有唯一性，并标识为不可替换，其他的请求参数标识为可替换。

进一步的，对案例模板中有授信验证要求的接口，加入授信步骤，具体为：进行授信获取。

进一步的，在步骤3.3中，录制元素里面不能多次反复使用的数据包括请求头、请求路径、请求参数。

在本发明一实施例中，上述步骤4具体包括如下：

步骤4.1：启动流量回放功能模块，通过分布式多线程调用，同时启动若干步骤3里已定义好的流量回放案例模板，流量回放模块通过接收流量回放案例模板推送过来的步骤1定义好的接口名短编码，从流量录制数据库中的流量数据起点开始，寻找同接口短编码名字一致，且未被标识为流量回放已完成的流量数据；

步骤4.2：将接口短编码一致的流量接口数据从流量保存数据库中取出，并对数据进行锁定，并标识为流量回放中；将取出的流量数据进行格式解析，并使用各种录制元素，替换模板案例里面的标识为可进行替换的元素；

步骤4.3：将完成替换后的案例模板接口进行回放，并比对结果，当完成接口回放以后，将该接口在流量数据库中对该数据进行解锁，并标识为流量回放完成；通过反复的运行流量回放案例模板，直到所有的流量数据库中所有录制的流量都被标识为已完成后，停止流量回放功能模块。

进一步的，在步骤4.2中，用于替换模板案例里元素的录制元素为录制的请求头、请求录制、请求参数。

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

本发明通过将被测系统的所有接口进行案例模板化形成若干测试场景,通过启动多线程，反复的回放测试模板，以案例模板的接口调用顺序而不是录制的流量的调用顺序，将录制的流量数据全部进行回放。

本发明将所有被测系统的接口元素标识为可替换与不可替换。对不可替换的数据，通过进行随机或者序列化等方式进行生成，保证每次运行都具有唯一性，实现可以重复回放；可替换数据使用流量录制数据，实现应用流量录制数据。

通过上述技术手段，本发明能够解决由于权限未录制，造成不可回放场景的技术问题；本发明也能够解决由于数据录制一次性，不可重复使用数据，造成不能回放场景的技术问题；本发明还能够解决长链路多系统环境里，由于数据冲突，需要在多个系统里进行数据清理才能回放，继而产生严重降低回放便捷性的技术问题。

具体实施方式

下面结合实施例对本发明作进一步的描述，所描述的实施例仅仅是本发明一部分实施例，并不是全部的实施例。基于本发明中的实施例，本领域的普通技术人员在没有做出创造性劳动前提下所获得的其他所用实施例，都属于本发明的保护范围。

为了更清楚地说明本说明书实施例的技术方案，下面将对实施例作简单的介绍。显而易见地，下面描述中仅仅是本说明书的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以将本说明书应用于其它类似情景。

本发明的一种基于案例模板的流量回放方法。

该方案包含以下几个主要步骤。

步骤1：对接口进行映射编号。

具体为将被录制系统所有的接口名进行映射编号。对每个不同的接口名进行唯一性短码编号，用于快速标识接口名。

如：

步骤2：录制流量。

步骤2可拆分成以下三个步骤。

步骤2.1：通过tcpcopy监控需要录制流量的服务器端口。

步骤2.2：将tcpcopy获得的tcp协议请求数据复制一份到流量录制服务器

步骤2.3：流量录制服务器通过tcp解析服务，将流量解析为http协议，并按照自定义的模板格式，将请求头，请求路径，请求参数，响应返回等各种与流量相关的元素按照设定的流量保存模型保存到流量录制数据库中，同时对录制的每一个接口依据步骤1里的短编码进行标识并保存。

如：

步骤3：流量回放案例模板准备。

本步骤包括如下步骤：

步骤3.1：将需要回放的测试场景及被测系统所有接口组成若干案例模板。

步骤3.2：将案例模板对应的请求接口，及请求参数进行数据分离。

步骤3.3：将请求头、请求路径、请求参数等录制元素里面不能多次反复使用的数据，进行随机或者序列化等方式进行生成，保证每次具有唯一性，并标识为不可替换，其他的请求参数标识为可替换。

步骤3.4：对案例模板中有授信验证要求的接口，加入授信步骤，具体为：进行授信获取。

如案例文件：

Given 发送通用HTTP请求“ReXXX000001”，并使用模板数据

Given 发送通用HTTP请求“ReXXX000002”，并使用模板数据

如模板数据文件：

ReXXX000001：

Type: post

api: getInformation

protocol: http

request:

phone: volatile, mock()

name: fixed, getFromeRecords()

age: fixed, getFromeRecords()

步骤4：流量回放。

本步骤包括如下步骤：

步骤4.1：启动流量回放功能模块，通过分布式多线程调用，同时启动若干步骤3里已定义好的流量回放案例模板。流量回放模块通过接收流量回放案例模板推送过来的步骤1定义好的接口名短编码，从流量录制数据库中的流量数据起点开始，寻找同接口短编码名字一致，且未被标识为流量回放已完成的流量数据。

步骤4.2：将接口短编码一致的流量接口数据从流量保存数据库中取出，并对数据进行锁定，并标识为流量回放中。将取出的流量数据进行格式解析，并使用录制的请求头，请求录制，请求参数等各种录制元素，替换模板案例里面的标识为可进行替换的元素。

步骤4.3：将完成替换后的案例模板接口进行回放，并比对结果，当完成接口回放以后，将该接口在流量数据库中对该数据进行解锁，并标识为流量回放完成。

步骤4.4：通过反复的运行流量回放案例模板，直到所有的流量数据库中所有录制的流量都被标识为已完成后，停止流量回放功能模块。

如录制数据被使用，会被标识: 0:已使用、1：正在使用、2：未使用、3：异常数据

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本说明书的限定。虽然此处并没有明确说明，本领域技术人员可能会对本说明书进行各种修改、改进和修正。该类修改、改进和修正在本说明书中被建议，所以该类修改、改进、修正仍属于本说明书示范实施例的精神和范围。

同时，本说明书使用了特定词语来描述本说明书的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本说明书至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一个替代性实施例”并不一定是指同一实施例。此外，本说明书的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

此外，除非权利要求中明确说明，本说明书所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本说明书流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本说明书实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本说明书披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本说明书实施例的描述中，有时会将多种特征归并至一个实施例或对其的描述中。但是，这种披露方法并不意味着本说明书对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

最后，应当理解的是，本说明书中所述实施例仅用以说明本说明书实施例的原则。其他的变形也可能属于本说明书的范围。因此，作为示例而非限制，本说明书实施例的替代配置可视为与本说明书的教导一致。相应地，本说明书的实施例不仅限于本说明书明确介绍和描述的实施例。