CN110708211B - 网络流量测试方法及系统 - Google Patents

Abstract

本申请公开了一种网络流量测试方法及系统，其中，网络流量测试方法包括获取用户访问网络站点的网络请求数据，确定网络请求数据的事务类型，并统计各个事务类型的数据量情况，基于各个事务类型的数据量情况生成用于供多个测试执行机执行的测试脚本，汇总多个测试执行机执行测试脚本的测试结果。上述方案，能够提高测试准确性。

Description

网络流量测试方法及系统

技术领域

本申请涉及信息技术领域，特别是涉及一种网络流量测试方法及系统。

背景技术

随着信息技术的发展，计算机、智能手机、平板电脑等电子产品与人们的日常生活、学习越来越密切相关。人们通过诸如此类的电子产品访问网络站点，以进行购物、游戏、社交等等。例如，对于网络游戏，海量用户通过计算机、智能手机、平板电脑等电子产品访问站点服务端，面对海量用户成千上万次访问，为了确保每个用户的访问都能够及时得到正确响应，对服务端的硬件和软件提出了非常高的要求，故此，有必要对服务端进行测试，以定位性能瓶颈。有鉴于此，如何提高测试准确性，以精确定位性能瓶颈成为亟待解决的问题。

发明内容

本申请主要解决的技术问题是提供一种网络流量测试方法及系统，能够提高测试准确性。

为了解决上述问题，本申请第一方面提供了一种网络流量测试方法，包括获取用户访问网络站点的网络请求数据，确定网络请求数据的事务类型，并统计各个事务类型的数据量情况，基于各个事务类型的数据量情况生成用于供多个测试执行机执行的测试脚本，汇总多个测试执行机执行测试脚本的测试结果。

为了解决上述问题，本申请第二方面提供了一种网络流量测试系统，包括多个测试执行机、流量获取设备和测试配置设备，流量获取设备用于获取用户访问网络站点的网络请求数据，测试配置设备用于确定网络请求数据的事务类型，并统计各个事务类型的数据量情况，以及基于数据量情况生成用于供多个测试执行机执行的测试脚本，并汇总多个测试执行机执行测试脚本的测试结果，其中，测试配置设备连接于流量获取设备与多个测试执行机之间。

上述方案，获取用户访问网络站点的网络请求数据，并确定网络请求数据的事务类型，统计各个事务类型的数据量情况，并基于各个事务类型的数据量情况生成用于供多个测试执行机执行的测试脚本，汇总多个测试执行机执行测试脚本的测试结果，从而可以基于用户访问网络站点的真实网络请求数据，生成对应的测试脚本，使得所生产的测试脚本能够真实反映用户访问网络站点的情况，进而提高测试准确性，有利于精确定位性能瓶颈。

附图说明

图1是本申请网络流量测试方法一实施例的流程示意图；

图2是本申请网络流量测试方法另一实施例的流程示意图；

图3是图2中步骤S25一实施例的流程示意图；

图4是本申请网络流量测试系统一实施例的框架示意图。

具体实施方式

下面结合说明书附图，对本申请实施例的方案进行详细说明。

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、接口、技术之类的具体细节，以便透彻理解本申请。

本文中术语“系统”和“网络”在本文中常被可互换使用。本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。此外，本文中的“多”表示两个或者多于两个。

请参阅图1，图1是本申请网络流量测试方法一实施例的流程示意图。具体而言，可以包括如下步骤：

步骤S11：获取用户访问网络站点的网络请求数据。

本实施例中，用户是真实正在访问网络站点的用户，具体数量本实施例在此不做限制。例如，对于网络游戏的网络站点，用户是正在访问网络游戏站点的玩家；对于电子商务的网络站点，用户是正在访问电商平台的消费者；对于网上银行的网络站点，用户是正在访问网银平台进行网上查询、转账等操作的客户，本实施例在此不再一一举例。

网络站点可以是基于分布式应用服务而搭建的，例如，采用分布式应用服务满足用户通过智能手机应用、平板电脑应用、计算机网页或客户端等多渠道访问网络站点的需求，并基于诸如Nginx(engine X)的http(HyperText Transfer Protocol,超文本传输协议)服务与分布式应用服务结合使得用户通过多个渠道均可顺利访问网络站点。在一个实施场景中，为了在系统边界提供给外部访问接口服务的统一入口，还可以设置一个应用程序编程接口网关(Application Programming Interface Gateway，API Gateway)，从而能够从应用程序编程接口网关获取到用户访问网络站点的网络请求数据。

网络请求数据是用户访问网络站点时向网络站点所发送的请求信息，网络请求数据的种类可以有多种，例如：查询、删除、确认等等。以网上购物为例，用户在想要购买商品A时，输入商品A的关键词进行搜索时，向网络站点发送一个关于请求获取与商品A的关键词相关的商品的网络请求数据；当用户获取点击获取到的多条与商品A的关键词相关的商品中的一个时，向网络站点发送一个关于用户所点击的商品的详细信息的网络请求数据；当用户将某一商品添加到购物车并结算时，向网络站点发送一个关于结算商品的网络请求数据，本实施例在此不再一一举例。

在一个实施场景中，为了更加精确地定位性能瓶颈，还可以根据网络站点的性质，设置获取用户访问网络站点的网络请求数据的获取时间段，从而在获取时间段获取用户访问网络站点的网络请求数据。例如，对于网络游戏的网络站点，由于网络游戏的用户一般为学生、上班族，故可以设置获取时间段为晚上，或周末；对于电子商务的网络站点，可以设置获取时间段为周末或优惠活动期间，本实施例在此不再一一举例。在另一个实施场景中，还可以统一设置获取时间段，例如，早上八点至十点，下午三点至五点，晚上八点至十点等等，从而在统一设置的获取时间段获取用户访问网络站点的网络请求数据。

本实施例通过获取用户访问网络站点的网络请求数据，可以得到用户真实访问网络站点的网络请求数据，从而使得后续进行的测试与现实更加贴近，更有利于定位性能瓶颈。

步骤S12：确定网络请求数据的事务类型，并统计各个事务类型的数据量情况。

例如，对于电子商务的网络站点，事务类型可以是：查询、下单、支付等等，从而统计得到在获取到的网络请求数据中对应于“查询”事务类型的网络请求数据量，对应于“下单”事务类型的网络请求数据量，对应于“支付”事务类型的网络请求数据量等等；或者，对于网上银行的网络站点，事务类型可以是：查询、转账、导出、绑定等等，从而可以统计到在获取到的网络请求数据中对应于“查询”事务类型的网络请求数据量，对应于“转账”事务类型的网络请求数据量，对应于“导出”事务类型的网络请求数据量，对应于“绑定”事务类型的网络请求数据量等等，对于其他类型的网络站点，可以以此类推，本实施例在此不再一一举例。

步骤S13：基于各个事务类型的数据量情况生成用于供多个测试执行机执行的测试脚本。

本实施例中，可以基于各个事务类型的数据量情况生成测试脚本，进而可以使得测试脚本能够真实模拟线上网络流量，提高测试准确性。在一个实施场景中，可以基于各个事务类型所占的比例生成测试脚本，在另一个实施场景中，为了使测试结果更加准确，还可以在滤除一些与测试无关的事务类型的网络请求数据之后，再基于各个事务类型的数据量情况生成测试脚本，本实施例在此不做具体限制。

测试执行机可以是分布式的主机，且主机上运行有测试工具，例如ApacheJmeter、LoadRunner、NeoLoad、Loadster等等，本实施例在此不做具体限制，从而使得测试执行机运行测试脚本，得到测试结果。关于Apache Jmeter、LoadRunner、NeoLoad、Loadster的技术细节为本领域的现有技术，本实施例在此不再赘述。

步骤S14：汇总多个测试执行机执行测试脚本的测试结果。

本实施例中，测试结果包括但不限于：平均响应时间、50％用户的响应时间、90％用户的响应时间、最小响应时间、最大响应时间、错误率、吞吐量等等，从而可以从多个角度根据测试结果评价性能，并定位性能瓶颈。

在一个实施场景中，在汇总多个测试执行机执行测试脚本的测试结果之后，还可以以预设输出格式输出测试结果，预设输出格式可以包括但不限于：图片、表格、文字等等。

上述方案，获取用户访问网络站点的网络请求数据，并确定网络请求数据的事务类型，统计各个事务类型的数据量情况，并基于各个事务类型的数据量情况生成用于供多个测试执行机执行的测试脚本，汇总多个测试执行机执行测试脚本的测试结果，从而可以基于用户访问网络站点的真实网络请求数据，生成对应的测试脚本，使得所生产的测试脚本能够真实反映用户访问网络站点的情况，进而提高测试准确性，有利于精确定位性能瓶颈。

请参阅图2，图2是本申请网络流量测试方法另一实施例的流程示意图。具体而言，可以包括如下步骤：

步骤S21：获取用户访问网络站点的网络请求数据。

具体请参阅上述实施例中的步骤S11。

在一个实施场景中，为了便于后续统计各种事务类型的网络请求数据的数据量情况，在获取到用户访问网络站点的网络请求数据之后，还可以对网络请求数据进行预处理，例如，将网络请求数据转换为Json、Yaml等数据格式，再缓存预处理后的网络请求数据，例如，将预处理后的网络请求数据缓存至Redis数据库，当然也可以缓存至MongoDB数据库，本实施例在此不做具体限制。关于Json、Yaml、Redis数据库、MongoDB数据库的具体技术细节为本领域的现有技术，本实施例在此不再赘述。

在一个实施场景中，为了保护用户隐私，对网络请求数据进行预处理的操作还可以包括基于预设脱敏规则对网络请求数据进行脱敏处理，而后再将脱敏处理后的网络请求数据的文件格式转换为预设文件格式。预设脱敏规则可以是可恢复性脱敏或不可恢复性脱敏，具体可以包括但不限于：名字脱敏处理、身份证号脱敏处理、电话号码脱敏处理、联系地址脱敏处理等等。例如，将名字“张三”脱敏处理为“张*”，将电话号码“13312345678”脱敏处理为“133******78”等等，本实施例在此不再一一举例，再将脱敏处理后的网络请求数据转换为预设文件格式，例如：Json、Yaml等等。

步骤S22：确定网络请求数据的事务类型。

具体请参阅上述实施例中的步骤S12。

在一个实施场景中，当网络请求数据经过上述预处理并缓存后，还可以将缓存的网络请求数据进行转译，从而确定网络请求数据的事务类型。

步骤S23：剔除事务类型为与网络流量测试无关的网络请求数据。

与网络流量测试无关的事务类型可以根据网络流量测试的测试对象和测试目的进行确定。例如，对服务端进行登录逻辑等的测试时，对于静态资源的访问请求可以认为是与网络流量测试无关的网络请求数据，其他应用场景下，与网络流量测试无关的事务类型可以以此类推，本实施例在此不再一一举例。

步骤S24：统计各个事务类型在剩余的网络请求数据中所占的数据量比例。

在剔除事务类型为与网络流量测试无关的网络请求数据之后，可以进一步统计各个事务类型在剩余的网络请求数据中所占的数据量比例。例如，统计得到事务类型为“查询”的网络请求数据在剩余的网络请求数据中所占的数据量比例为70％，而事务类型为“下单”的网络请求数据在剩余的网络请求数据中所占的数据量比例为30％，本实施例在此不做具体限制。

步骤S25：基于各个事务类型的数据量比例，确定测试脚本中与事务类型对应的测试线程的并发数量。

本实施例中，每个测试线程可以理解为每个用户访问网络站点的网络请求数据。由于服务端处理不同事务类型的网络请求数据所要消耗的资源也是不同的，故此，基于各个事务类型的数据量比例，通过在测试脚本中设置与事务类型对应的测试线程，可以真实模拟用户访问网络站点，从而更加精准地定位性能瓶颈。

具体而言，为了使测试线程能够真实模拟不同事务类型的网络请求数据对于服务端的资源开销，请结合参阅图3，图3是图2中步骤S25一实施例的流程示意图，可以包括如下步骤：

步骤S251：确定测试脚本中与每一事务类型的资源开销对应的测试线程。

在生成测试脚本时，为了使测试脚本能够真实反映服务端处理网络请求数据所要消耗的资源，需要确定测试脚本中与每一事务类型的资源开销相对应的测试线程。例如，针对资源开销较大的事务类型，相应地可以确定其所对应的测试线程为资源开销较大的测试线程，而针对资源开销较小的事务类型，相应地可以确定其所对应的测试线程为资源开销较小的测试线程。

步骤S252：基于每一事务类型的数据量比例、剩余的网络请求数据的第一数量以及测试执行机的第二数量，确定对应的测试线程的并发数量。

在确定测试脚本中与每一事务类型的资源开销对应的测试线程之后，还可以进一步基于每一事务类型的数据量比例，以及剔除与测试无关的网络请求数据之后的所剩余的网络请求数据的第一数量，以及测试执行机的第二数量，确定对应的测试线程的并发数量。具体地，可以将每一事务类型的数据量比例和剩余的网络请求数据的第一数量之积作为每一事务类型所对应的网络请求数据的第三数量，并将每一事务类型所对应的网络请求数据的第三数量与测试执行机的第二数量之商作为测试脚本中与事务类型对应的测试线程的并发数量。例如，在剔除与测试无关的网络请求数据之后，剩余的网络请求数据的第一数量为100条，且其中事务类型为“查询”的网络请求数据的数据量比例为70％，事务类型为“下单”的网络请求数据的数据量比例为30％，则相应地，可以计算得到事务类型为“查询”的网络请求数据的第三数量为70条，事务类型为“下单”的网络请求数据的第三数量为30条，且系统中测试执行机的第二数量为10台，则可以确定事务类型为“查询”的网络请求数据对应的测试线程的并发数量为7个，而事务类型为“下单”的网络请求数据对应的测试线程的并发数量为3个，当每一事务类型的数据量比例、第一数量、第二数量为其他值时，可以以此类推，本实施例在此不再一一举例。

步骤S26：汇总多个测试执行机执行测试脚本的测试结果。

将生成的测试脚本下发至每一个测试执行机后，收集、汇总多个测试执行机执行测试脚本的测试结果，测试结果可以包括但不限于：：平均响应时间、50％用户的响应时间、90％用户的响应时间、最小响应时间、最大响应时间、错误率、吞吐量等等，从而可以从多个角度根据测试结果评价性能。

具体请参阅上述实施例中的步骤S14。

请参阅图4，图4是本申请网络流量测试系统一实施例的框架示意图。网络流量测试系统包括多个测试执行机41、流量获取设备42、测试配置设备43，测试配置设备43连接于流量获取设备42与多个测试执行机41之间。本实施例中，流量获取设备42用于获取用户访问网络站点的网络请求数据，测试配置设备43用于确定网络请求数据的事务类型，并统计各个事务类型的数据量情况，以及基于数据量情况生成用于供多个测试执行机执行的测试脚本，并汇总多个测试执行机执行测试脚本的测试结果。本实施例中，测试执行机41的数量为多个，例如：2个、3个、4个、4个等等，本实施例在此不做具体限制。

在一个实施场景中，网络站点可以基于分布式应用服务而搭建的，例如，采用分布式应用服务满足用户通过智能手机应用、平板电脑应用、计算机网页或客户端等多渠道访问网络站点。请结合参阅图2，网络站点可以基于诸如Nginx(engine X)的http(HyperTextTransfer Protocol,超文本传输协议)服务器与分布式的多个应用服务器而搭建。为了在系统边界提供给外部访问接口服务的统一入口，还可以设置一个应用程序编程接口网关(Application Programming Interface Gateway，API Gateway)，从而流量获取设备42能够从应用程序编程接口网关获取到用户访问网络站点的网络请求数据。关于Nginx以及APIGateway的技术细节为本领域的现有技术，本实施例在此不再赘述。

测试执行机41可以是分布式的主机，且主机上运行有测试工具，例如ApacheJmeter、LoadRunner、NeoLoad、Loadster等等，本实施例在此不做具体限制，从而使得测试执行机运行测试脚本，得到测试结果。

上述方案，获取用户访问网络站点的网络请求数据，并确定网络请求数据的事务类型，统计各个事务类型的数据量情况，并基于各个事务类型的数据量情况生成用于供多个测试执行机执行的测试脚本，汇总多个测试执行机执行测试脚本的测试结果，从而可以基于用户访问网络站点的真实网络请求数据，生成对应的测试脚本，使得所生产的测试脚本能够真实反映用户访问网络站点的情况，进而提高测试准确性，有利于精确定位性能瓶颈。

此外，由于只需在线上增加流量获取设备42，并在线下(如图2中虚线框所示)部署多个测试执行机41和测试配置设备43，因此，在基于真实用户访问网络站点的网络请求数据进行测试的基础上，本申请无需对现有已部署的应用服务进行大幅调整，只需小幅微调即可实现，因此，大大降低了测试系统部署的复杂性。

请继续参阅图4，网络流量测试系统还包括第一数据缓存设备44，第一数据缓存设备44可以为运行有Redis数据库或MongoDB数据库的主机，本实施例在此不做具体限制，关于Redis数据库、MongoDB数据库的技术细节为本领域的现有技术，本实施例在此不再赘述。如图4所示，第一数据库缓存设备44连接于流量获取设备42和测试配置设备43之间。本实施例中，流量获取设备42还用于对网络请求数据进行预处理，并缓存预处理后的网络请求数据至第一数据缓存装置44。在一个实施场景中，流量获取设备42对网络请求数据进行预处理可以包括基于预设脱敏规则对网络请求数据进行脱敏处理，并将脱敏处理后的网络请求数据的文件格式转换为预设文件格式。预设脱敏规则可以是可恢复性脱敏或不可恢复性脱敏，具体可以包括但不限于：名字脱敏处理、身份证号脱敏处理、电话号码脱敏处理、联系地址脱敏处理等等，例如，将名字“张三”脱敏处理为“张*”，将电话号码“13312345678”脱敏处理为“133******78”等等，本实施例在此不再一一举例，再将脱敏处理后的网络请求数据转换为预设文件格式，例如：Json、Yaml等等，关于Json、Yaml的技术细节为本领域的现有技术，本实施例在此不再赘述。

请继续参阅图4，测试配置设备43从第一数据库缓存设备44中取出预设文件格式的网络请求数据后，还可以进一步转译网络请求数据，确定网络请求数据的事务类型。例如，对于电子商务的网络站点，事务类型可以是：查询、下单、支付等等；或者，对于网上银行的网络站点，事务类型可以是：查询、转账、导出、绑定等等，对于其他类型的网络站点，可以以此类推，本实施例在此不再一一举例。

请继续参阅图4，测试配置设备43还用于剔除事务类型为与网络流量测试无关的网络请求数据，测试配置设备43还用于统计各个事务类型在剩余的网络请求数据中所占的数据量比例，测试配置设备43还用于基于各个事务类型的数据量比例，确定测试脚本中与事务类型对应的测试线程的并发数量。在一个实施场景中，当测试执行机41为运行有slave模式下的Jmeter的主机时，测试配置设备43可以是运行有master模式下的Jmeter的主机。在另一个实施场景中，测试配置设备43还可以是相互连接的两台主机，一台用于转译网络请求数据，并剔除事务类型为与网络流量测试无关的网络请求数据，以及统计各个事务类型在剩余的网络请求数据中所占的数据量比例，另一台运行有master模式下的Jmeter，用于基于各个事务类型的数据量比例，确定测试脚本中与事务类型对应的测试线程的并发数量，从而将测试脚本下发至每一个测试执行机41。

请继续参阅图2，测试配置设备43还用于确定测试脚本中与每一事务类型的资源开销对应的测试线程，测试配置设备43还用于基于每一事务类型的数据量比例、剩余的网络请求数据的第一数量以及测试执行机的第二数量，确定对应的测试线程的并发数量。

具体地，测试配置设备43可以将每一事务类型的数据量比例和剩余的网络请求数据的第一数量之积作为每一事务类型所对应的网络请求数据的第三数量，测试配置设备43可以将每一事务类型所对应的网络请求数据的第三数量与测试执行机的第二数量之商作为测试脚本中与事务类型对应的测试线程的并发数量。例如，在剔除与测试无关的网络请求数据之后，剩余的网络请求数据的第一数量为100条，且其中事务类型为“查询”的网络请求数据的数据量比例为70％，事务类型为“下单”的网络请求数据的数据量比例为30％，则相应地，可以计算得到事务类型为“查询”的网络请求数据的第三数量为70条，事务类型为“下单”的网络请求数据的第三数量为30条，且系统中测试执行机的第二数量为10台，则可以确定事务类型为“查询”的网络请求数据对应的测试线程的并发数量为7个，而事务类型为“下单”的网络请求数据对应的测试线程的并发数量为3个，当每一事务类型的数据量比例、第一数量、第二数量为其他值时，可以以此类推，本实施例在此不再一一举例。

请继续参阅图4，网络流量测试系统还包括第二数据缓存设备45，测试配置设备43还用于缓存多个测试执行机41的测试结果至第二数据缓存装置45，直至所有测试执行机41执行完成测试脚本为止。在一个实施场景中，为了提高第二数据缓存设备45的兼容性，以提高网络流量测试系统的兼容性，当测试配置设备43为运行有master模式下的Jmeter的主机时，第二数据缓存设备45可以为运行有InfluxDB的主机，由于Jmeter本身支持InfluxDB的监听器，因此，两者连接时无需再进行额外的适配工作，减少了网络流量测试系统的搭建工作。关于InfluxDB的具体技术细节为本领域的现有技术，本实施例在此不再赘述。

请继续参阅图4，网络流量测试系统还包括数据输出设备46，数据输出设备46用于以预设输出格式输出缓存于第二数据缓存设备45中的测试结果。预设输出格式可以包括但不限于：图片、表格、文字等等。在一个实施场景中，数据输出设备46可以是运行有grafana的主机，grafana是一个跨平台的开源的度量分析和可视化工具，可以通过将采集的数据查询，然后可视化地展示，并及时通知，此外，grafana还支持数据源为InfluxDB的数据库，故可进一步提高网络流量测试系统的兼容性，从而实现测试结果的图形化展示。关于grafana的技术细节为本领域的现有技术，本实施例在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的方法和装置，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性、机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施方式方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (9)

1.一种网络流量测试方法，其特征在于，包括：

获取用户访问网络站点的网络请求数据；

确定所述网络请求数据的事务类型，剔除所述事务类型为与网络流量测试无关的网络请求数据，并统计各个所述事务类型在剩余的网络请求数据中所占的数据量比例；

基于各个所述事务类型的数据量情况生成用于供多个测试执行机执行的测试脚本，并基于各个所述事务类型的数据量比例，确定所述测试脚本中与所述事务类型对应的测试线程的并发数量；

汇总所述多个测试执行机执行所述测试脚本的测试结果；

其中，所述测试结果包括平均响应时间、50%用户的响应时间、90%用户的响应时间、最小响应时间、最大响应时间、错误率、吞吐量，所述测试结果均用于定位性能瓶颈。

2.根据权利要求1所述的网络流量测试方法，其特征在于，所述基于各个所述事务类型的数据量比例，确定所述测试脚本中与所述事务类型对应的测试线程的并发数量包括：

确定所述测试脚本中与每一所述事务类型的资源开销对应的测试线程；

基于每一所述事务类型的数据量比例、剩余的网络请求数据的第一数量以及所述测试执行机的第二数量，确定所述对应的测试线程的并发数量。

3.根据权利要求2所述的网络流量测试方法，其特征在于，所述基于每一所述事务类型的数据量比例、剩余的网络请求数据的第一数量以及所述测试执行机的第二数量，确定所述对应的测试线程的并发数量包括：

将每一所述事务类型的数据量比例和剩余的网络请求数据的第一数量之积作为每一所述事务类型所对应的网络请求数据的第三数量；

将每一所述事务类型所对应的网络请求数据的第三数量与所述测试执行机的第二数量之商作为所述测试脚本中与所述事务类型对应的测试线程的并发数量。

4.根据权利要求1所述的网络流量测试方法，其特征在于，所述确定所述网络请求数据的事务类型包括：

转译所述网络请求数据，确定所述网络请求数据的事务类型。

5.根据权利要求1所述的网络流量测试方法，其特征在于，所述获取用户访问网络站点的网络请求数据之后，且在所述确定所述网络请求数据的事务类型，剔除所述事务类型为与网络流量测试无关的网络请求数据，并统计各个所述事务类型在剩余的网络请求数据中所占的数据量比例之前，所述方法还包括：

对所述网络请求数据进行预处理；

缓存预处理后的网络请求数据。

6.根据权利要求5所述的网络流量测试方法，其特征在于，所述对所述网络请求数据进行预处理包括：

基于预设脱敏规则对所述网络请求数据进行脱敏处理；

将脱敏处理后的网络请求数据的文件格式转换为预设文件格式。

7.根据权利要求1所述的网络流量测试方法，其特征在于，所述汇总所述多个测试执行机执行所述测试脚本的测试结果包括：

缓存所述多个测试执行机的测试结果，直至所有测试执行机执行完成所述测试脚本；

所述汇总所述多个测试执行机执行所述测试脚本的测试结果之后，所述方法还包括：

以预设输出格式输出缓存的测试结果。

8.一种网络流量测试系统，其特征在于，包括多个测试执行机、流量获取设备、测试配置设备；

所述流量获取设备用于获取用户访问网络站点的网络请求数据；

所述测试配置设备用于确定所述网络请求数据的事务类型，剔除所述事务类型为与网络流量测试无关的网络请求数据，并统计各个所述事务类型在剩余的网络请求数据中所占的数据量比例，以及基于各个所述事务类型的数据量情况生成用于供所述多个测试执行机执行的测试脚本，并基于各个所述事务类型的数据量比例，确定所述测试脚本中与所述事务类型对应的测试线程的并发数量，并汇总所述多个测试执行机执行所述测试脚本的测试结果；

其中，所述测试配置设备连接于所述流量获取设备与所述多个测试执行机之间；

其中，所述测试结果包括平均响应时间、50%用户的响应时间、90%用户的响应时间、最小响应时间、最大响应时间、错误率、吞吐量，所述测试结果均用于定位性能瓶颈。

9.根据权利要求8所述的网络流量测试系统，其特征在于，所述流量获取设备还与所述网络站点的应用程序编程接口网关连接，以从所述应用程序编程接口网关获取所述网络请求数据。

Images