CN106021079A - 一种基于用户频繁访问序列模型的Web应用性能测试方法 - Google Patents

Abstract

本发明公开了一种基于用户频繁访问序列模型的Web应用性能测试方法，包括步骤：1)日志数据采集和预处理；2)用户访问序列挖掘；3)制定测试模型和相应测试场景；4)搭建测试环境和监控工具；5)进行性能测试并得到结果。本发明可直接应用于实际Web应用性能测试工程中，采用本发明中基于用户访问频繁序列模型的测试方法可提高Web应用性能测试的准确性，并能有效获取Web应用的实际表现及性能瓶颈。

Description

一种基于用户频繁访问序列模型的Web应用性能测试方法

技术领域

本发明涉及Web应用性能测试的技术领域，尤其是指一种基于用户频繁访问序列模型的Web应用性能测试方法。

背景技术

近年来，Web应用无论是在数量还是质量上都取得了迅速的发展，各式应用已经深入到了社会生活的方方面面。与此同时，Web应用的功能也变得越来越复杂，带来的用户数量和类型也越来越多，应用相关的数据量也越来越庞大，Web应用的性能需求所带来问题亦越发凸显。因此，如何开发出性能卓越且稳定的Web应用被放在了Web平台的重要的位置，成了Web项目公司和其开发者密切关注的问题。要想提高Web应用的性能，首先就需要对Web应用进行有效的性能测试，通过合理的测试方案设计和规范化的测试过程，发现和定位Web应用所存在的缺陷和瓶颈。

性能测试即是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。现有Web应用性能测试方法种类繁多，测试方案的思路也各不相同，一般来说的性能测试方案和其测试方法存在以下两个难点：

(1)繁杂的功能点在性能测试优先级上难以选择：随着Web技术的发展，Web应用的功能也变得更加强大，其自身的结构也变得越来越复杂，一个复杂的Web应用往往包含很多种功能各不相同的模块，因此设计测试方案时需要做出选择。是对所有的功能模块进行覆盖性测试，还是根据测试方案设计师对业务的调研和自身的经验来选择所需测试的功能业务模块？前者的执行必然需要耗费大量的时间和精力，大大增加了测试执行和分析的难度，而后者存在测试设计人员主观看法影响和经验不足的风险。此外，一个Web应用中的某些业务往往有很复杂的功能关系，各个功能往往不是彼此独立的，在对应业务中是相辅相成的，因此，一个Web应用需要有准确量化的参考指标作为测试方案设计的依据，测试结果的准确性和有效性才是可靠的。

(2)设计的测试场景难以模拟生产环境下的真实情况：一个Web应用往往有很多不同的用户，每位用户都有不同的使用目的和用户偏好，其对Web应用的访问和操作访问往往会表现出较大的差异性。在应用的使用过程中，一些用户可能对某些功能模块表现出特别的访问偏好，一些用户则对应用的访问较为松散，还有一些用户则会在较短的时间间隔内进行大量的访问。因此，不同用户即使从同一个页面作为入口进入Web应用，每个用户所产生的点击流却都会有所不同，在每个页面停留和思考的时间也比较难掌握，在性能测试的时候，需要把这些因素考虑进去，适当调整脚本的执行且进行有依据的虚拟用户数和用户Think Time等参数变化，方可使测试工具所模拟的测试场景能够有效地反应出真实的情况的。

发明内容

本发明的目的在于克服现有技术的不足，提供一种基于用户频繁访问序列模型的Web应用性能测试方法，结合用户频繁访问序列生成测试场景，解决现有Web应用性能测试方案存在的制定不准确、执行复杂、测试工作重复等问题。该方法操作简易，只需在规范的性能测试基础上提交一份Web应用日志就能提供一套完整的测试场景，为性能测试方案中的业务提取和场景设计提供可靠的依据。此外，使用Web应用用户访问日志构建的测试场景，使得测试所得到的结果能够最大限度地接近真实环境，再结合对测试环境的有效监控，有效地得到Web应用的性能结果和性能瓶颈。

为实现上述目的，本发明所提供的技术方案为：一种基于用户频繁访问序列模型的Web应用性能测试方法，包括以下步骤：

1)从Web应用服务器采集日志数据，并对其进行过滤、持久化、识别这些预处理工作；

2)对步骤1)得到的日志数据进行用户访问序列的挖掘，并结合业务序列出现的频繁程度，筛选出待测试的访问序列；

3)依据步骤2)所得待测试频繁序列结果，进行性能测试模型和其相应测试场景的制定；

4)参照Web应用生产环境架构和配置，进行Web应用测试环境的创建，并部署系统、中间件相关监控工具；

5)依据步骤3)所得性能测试场景，执行测试并得到测试结果和测试环境各服务器和中间件的监控结果，供性能分析和瓶颈分析。

步骤1)中，对获取Web日志数据进行预处理，具体包括以下步骤：

1.1)从服务器采集日志数据并对其进行过滤，删除或者标记无关的、错误的和无效的日志数据；

1.2)对步骤1.1)中得到的日志数据进行持久化存储处理，就用户IP地址、请求时间、用户请求方法、协议版本、请求URL、请求页面、引用URL、引用页面、状态返回码、发送字节数、请求所使用浏览器和终端字段进行有效存储；

1.3)提取步骤1.2)中未被过滤的用户识别关联字段和数据对用户进行识别，进而进行用户请求的划分，并将用户请求按照时间进行排序。

步骤2)中，包括以下步骤：

2.1)在用户请求划分的数据基础上，进行用户会话识别，采用会话时间长度阀值T₁和请求间隔长度阀值T₂相结合的方法来识别用户的会话；

2.2)在划分好的用户会话中，对用户会话序列进行补充，解决请求丢失、会话序列断开影响；

2.3)依据步骤2.1)和2.2)描述规则，进行用户访问序列的挖掘，运用用户会话识别和序列补充脚本，通过遍历预处理后的日志数据得到所需序列统计，并对各序列出现次数进行统计；

2.4)对步骤2.3)中得到的用户访问序列集合进行过滤和筛选，去掉无效的用户访问序列，进而依据Web应用具体的业务对应表，分析序列对应的具体业务，以序列出现次数作为参考，结合Web应用性能测试需求，得到待测试的用户访问序列集合。

步骤3)中，包括以下步骤：

3.1)使用HP公司负载测试工具LoadRunner进行待测试序列的脚本录制及对其基准测试，记录序列脚本运行时间，用于计算虚拟用户数；

3.2)构建待测试序列集合的通用性能测试场景模板，填入挖掘统计数据，制定性能测试场景；

3.3)根据需求做出压力调整，即通过调整各业务的TPS，从而增加该业务的并发虚拟用户数，对Web应用的压力也同比增加。

步骤4)中根据Web应用的生产环境架构和配置，包括分布式架构部署、服务器内存、CPU信息克隆一套测试环境，有效地进行生产环境和测试环境的比较测试和瓶颈分析，且在此基础上，根据服务器操作系统和职责的不同，按照实际所列监控内容表，对各服务器操作系统和中间件的性能进行监控；

在测试和监控环境部署完成的基础上，开展步骤5)，依据已经制定的性能测试场景，使用LoadRunner进行混合脚本的执行，得到性能测试结果以及各服务器和各中间件的性能表现，供Web应用性能和瓶颈分析。

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

1、通过对Web日志数据进行处理和挖掘，得到用户访问频繁序列，用于生成测试场景模型，从而对Web应用性能测试方案和测试场景的设计提供准确、有效的参考依据。

2、通过对高峰时段关键序列的出现次数进行整理和统计，并分析用户占比和Think Time，融入测试场景模型，提高性能测试场景的仿真程度。

3、参考生产环境搭建的测试环境测试，并对环境各服务器和中间件性能进行全面的监控，可为Web应用性能瓶颈的定位提供有效参考。

附图说明

图1为基于用户频繁访问序列模型的Web应用性能测试方法的流程图。

图2为对获取Web日志数据进行预处理的流程图。

图3为实施例Web应用的拓扑结构示意图。

图4为对日志数据进行用户访问序列的挖掘和待测试序列筛选的流程图。

图5为制定测试模型和其相应测试场景流程的示意图。

图6为Web应用性能测试监控内容(Windows服务器及其中间件)。

图7为Web应用性能测试监控内容(Linux服务器及其中间件)。

具体实施方式

下面结合具体实施例对本发明作进一步说明。

如图1所示，本实施例所述的基于用户频繁访问序列模型的Web应用性能测试方法，包括以下步骤：

1)从Web应用服务器采集日志数据，并对其进行过滤、持久化、识别等预处理工作；

2)对步骤1)得到的日志数据进行用户访问序列的挖掘，并结合业务序列出现的频繁程度，筛选出待测试的访问序列；

3)依据步骤2)所得待测试频繁序列结果，进行性能测试模型和其相应测试场景的制定；

4)参照Web应用生产环境架构和配置，进行Web应用测试环境的创建，并部署系统、中间件相关监控工具；

5)依据步骤3)所得性能测试场景，执行测试并得到测试结果和测试环境各服务器和中间件的监控结果，供性能分析和瓶颈分析。

如图2所示，在步骤1)中对获取Web日志数据进行预处理，细化步骤如下：

1.1)从服务器采集日志数据并对其进行过滤，删除(或者标记)无关的、错误的或者无效的日志数据。

该步骤中提到的服务器日志，主要是各客户端访问Web应用在服务器上产生的相应数据。本发明从Nginx服务器运行日志中获取样例日志数据，日志文件记录每个用户请求发起的详细请求信息。

由于网络环境的复杂性，Web应用功能的多样性以及用户偏好和环境的不可控性，Web日志中很多数据是不能使用、错误或者与本发明挖掘算法无关的数据，因此需要对获取的Web日志进行过滤。一过滤Web日志数据中的图片、视频、脚本等非用户的显式请求，如JPG，JPEG，GIF，CSS，JS等结尾的请求数据；二过滤返回状态为错误的请求，一般状态返回码为300-599指示的是各种不同类别的错误，需要过滤；三只保留以GET作为请求方法的数据，一般只有GET方法是表示为用户主动的访问行为；四依据Web应用具体情况，选择Web应用的高峰时段(高峰时段即各Web应用用户高峰访问时段)，如实施例Web应用用户访问高峰时段为下午7时至晚上9时，此步骤将过滤掉此时间段以外的日志数据。

如下表1所示，为本发明实施例的部分日志数据，最后一列标注了该行数据是否需要过滤或者删除。

表1：部分Nginx日志数据及其过滤(删除)选择

1.2)对步骤1.1)中得到的日志数据进行持久化存储处理，就用户IP地址、请求时间、用户请求方法、协议版本、请求URL、请求页面、引用URL、引用页面、状态返回码、发送字节数、请求所使用浏览器和终端等字段进行存储。本发明在此步骤中，同时利用图3的Web应用拓扑图得出并存储请求页面、引用页面两个额外字段(可根据具体Web应用结合请求URL和引用URL得出请求页面和引用页面)，用于后续步骤的表述和序列挖掘。存储容器选择可根据数据量大小和存储服务器部署情况而定，通过CSV文件、关系型数据库或者Nosql数据库进行存储。下表2为部分Nginx日志数据的持久化存储。

表2：部分Nginx日志数据的持久化存储

1.3)提取步骤1.2)所存储的用户识别关联数据对用户进行识别，然后进行用户请求的划分，并将用户请求按照时间进行排序(同时间则按照原先顺序)：

该步骤采用基于IP地址和代理结合的方法。首先从持久化数据中获取用户IP地址、代理、操作系统和终端信息；之后按照以下规则进行识别：判断如果用户IP地址不同，则认为是不同的用户；如果用户IP地址相同，判断操作系统(用户代理域)或终端信息(浏览器或者移动设备)不同，则认为是不同的用户；如果操作系统(用户代理域)或终端信息(浏览器或者移动设备信息)都相同，则根据Web应用页面拓扑结构判断该请求访问的页面能够从已访问所有页面到达，若不能则认为是不同的用户。下表3是按照以上原则，对用户识别和请求划分的结果样例。

表3：用户识别及请求划分后的部分日志数据

如图4所示，在步骤2)中对数据进行用户访问序列的挖掘，细化步骤如下：

2.1)在步骤1)中用户识别和请求划分的基础上，进行用户会话识别。

在时间较长的日志当中，用户可能多次访问Web应用，进行会话识别就是要将同一用户的同一次会话识别出来。本发明采用会话时间长度阀值T₁(一般Web应用设为30分钟，可根据应用具体情况做调整)和请求间隔长度阀值T₂(一般Web应用设为10分钟，可根据应用具体情况做修改)相结合的方法来识别用户的一次会话。会话初始请求时间t₀，之后该用户的其他请求时间t_i，t_i如果满足t_i-t₀<T1，且t_i–t_i-1<T₂的话，则认为ti和t₀是属于同一个会话。

2.2)在划分好的用户会话中，对用户会话序列进行补充。

当用户对Web应用进行操作的时候，会有几种情况是不会将请求记录在Web日志当中的，如在执行完成某个action(操作)之后，JSP页面即刻进行渲染而不会产生在日志中产生JSP请求，又如用户按下浏览器的“后退”按钮或者直接通过URL访问本地已经缓存了的页面，这些访问请求不会被送到服务器端，所以也不会在Web日志中被记录。

针对这类情况，本发明对用户会话序列进行了补充，根据网站的拓扑结构，将断开的用户会话序列补充完善。如果在用户的请求日志记录中有多个页面都包含与当前请求页的链接，则将请求时间最接近当前页的页面或者操作作为当前请求页的来源，从而补充其前一步的JSP作为序列的上一个页面。用户序列补充遵循一个原则就是在用户的一次会话的序列中，除了起始页面外，每个页面同它上一个页面存在链接关系，不应出现断开现象。

例如，电商Web应用系统查看购物车业务，存在homePage.jsp->login.jsp->myCart.jsp这样的用户会话序列，在Login操作结束后，应该会先跳转到主页后才会进行购物车的查看，此处应根据电商Web应用的拓扑结构进行序列补充，得到homePage.jsp->login.jsp->homePage.jsp–>myCart.jsp。又如图3实施例的Web应用拓扑结构图，有用户会话序列A->B->F->E->M，根据拓扑结构图补充为A->B->F->B->E->I->M。

2.3)进行用户访问序列的挖掘，并对各序列出现次数进行统计。

结合上述步骤2.1)、2.2)，本发明进行了用户会话识别和序列补充脚本的编写，通过遍历预处理后的日志数据，展开对用户访问序列的挖掘，进而可得结果样式如下表4，表4是实施例的部分用户会话的访问序列，和表3做出比较，用户1因为中途访问时间间隔较大，被拆分成了两次会话，用户3因为有出现请求链断开，故脚本对用户3的这次会话序列进行了补充。

表4：实施例的部分用户会话的访问序列

通过上述挖掘脚本的执行，得到了海量的序列集合，通过对序列集合的归纳整理，可得到表5结构的序列统计结果，表5中数据为样例结果，出现次数排序由多到少。需要说明的是，根据本发明中用户会话来挖掘序列，如果某序列x包含某序列y，x序列中的y序列的出现次数不会包含在序列x的出现次数中，即各自独立，此外，序列x和序列y的Think Time也各自独立，以反应真实情况。

表5：挖掘序列统计结果

2.4)对得到的用户访问序列集合进行过滤，再依据业务需求和序列频繁程度选择待测试的序列集合。工作细化如下：

对得到的用户访问序列集合进行筛选，去掉无效的用户访问序列(如不遵循用户会话序列进行补充原则的序列)，然后依据业务对应表，分析序列得到序列对应的具体业务，以序列出现次数作为参考，结合Web应用性能测试需求得到待测试的用户访问序列集合。

如图5所示，在步骤3)中进行性能测试场景的制定，该步骤细化步骤如下：

3.1)录制待测试序列的脚本及对其基准测试

本发明实用例使用的负载测试工具为HP公司开发的Loadrunner工具，LoadRunner是一种预测系统行为和性能的负载测试工具，通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找测试目标所存在的问题。

在此步骤中，本发明通过LoadRunner对待测试序列的操作脚本进行录制，并在录制好的脚本中加入统计好的Think Time，以单用户，单序列脚本执行作为基准测试场景，测出各序列脚本的基准执行时间(T₁,T₂,…,T_n)。

3.2)制定性能测试场景

性能测试中有以下两项公式，与本发明场景设计有关。

c.TPS_n＝N_n/(3600*hours)；——获得各序列在高峰时段的TPS

d.Vuser_n＝TPS_n*T_n——获得各序列并发虚拟用户数；

通过上述两个公式，结合在步骤2.3)中得到的各待测试序列出现次数N和步骤3.1)中得到的各序列脚本基准测试执行时间T，可制定出测试场景模型如下表6。

表6：制定出的测试场景模型

3.3)根据需求做出压力调整(可选择步骤)

通常步骤1)获取的Web应用日志是近期一段时间的用户访问记录，上述步骤3.2)中设计的测试场景是针对Web应用在现阶段用户数基础上的性能表现。如有计划对Web应用进行推广或者对某些业务开展一些活动，那么用户数增加随时可能会让Web应用的性能表现不佳，因此，根据本发明中提出的方法，调整各业务的TPS(如按照预计增大TPS倍数)，从而增加了该业务的并发虚拟用户数，对Web应用的压力也就增肌。通过这种方式可以评估推广或者活动开展后，Web应用的性能表现。

在步骤4)中参照Web应用生产环境，进行Web应用测试环境的创建，工作细化如下：为了避免性能测试所带来的压力影响生产环境的正常运维，本发明所进行的性能测试需要搭建一个有效的、具有参考价值的测试环境。根据Web应用生产环境架构和配置，包括分布式架构部署、服务器内存、CPU等信息克隆一套测试环境。如搭建测试环境时受到设备限制，可使用虚拟机代替物理机，使用虚拟机代替的前提为测试环境和生产环境的架构部署和网络部署都需要相同，以便于有效地进行生产环境和测试环境的比较测试和瓶颈分析。

在环境部署相同的基础上，对Web应用进行部署，其中需保证Web应用的源码，数据库内容，图片、视频等多媒体内容的一致性，测试结果才具有参考性。此外，根据服务器操作系统和职责的不同，需要对各服务器操作系统和中间件的性能监控做好准备，本发明实施例的Web应用性能测试监控内容如图6和图7所示，打勾项为该服务器需监控的内容。

在步骤5)中进行Web应用的性能测试并得到测试结果和测试环境各服务器和中间件的监控结果，工作细化如下：

按照步骤3)得到的测试场景，使用LoadRunner可以有效地构建测试场景和执行场景脚本，并能够得到全面的测试结果，在规范性能测试的基础上，有以下三点需要注意：一依据性能测试的场景设计，对序列中各个功能点的ThinkTime做出配置，起到最好的仿真效果；二做好脚本的参数化工作，如相同账号避免重复登陆，查询避免重复关键字等，可避免服务器或者本地缓存所带来的性能误差；三配置好脚本返回值的校验(即检查点设置)，以便监测在各压力下Web应用的事务的成功率。在测试结束后，得到LR性能测试结果以及各服务器和各中间件的性能表现，供Web应用性能和瓶颈分析。

以上所述实施例只为本发明之较佳实施例，并非以此限制本发明的实施范围，故凡依本发明之形状、原理所作的变化，均应涵盖在本发明的保护范围内。

Claims (5)

1.一种基于用户频繁访问序列模型的Web应用性能测试方法，其特征在于，包括以下步骤：

1)从Web应用服务器采集日志数据，并对其进行过滤、持久化、识别这些预处理工作；

2)对步骤1)得到的日志数据进行用户访问序列的挖掘，并结合业务序列出现的频繁程度，筛选出待测试的访问序列；

3)依据步骤2)所得待测试频繁序列结果，进行性能测试模型和其相应测试场景的制定；

4)参照Web应用生产环境架构和配置，进行Web应用测试环境的创建，并部署系统、中间件相关监控工具；

5)依据步骤3)所得性能测试场景，执行测试并得到测试结果和测试环境各服务器和中间件的监控结果，供性能分析和瓶颈分析。

2.根据权利要求1所述的一种基于用户频繁访问序列模型的Web应用性能测试方法，其特征在于，步骤1)中，对获取Web日志数据进行预处理，具体包括以下步骤：

1.1)从服务器采集日志数据并对其进行过滤，删除或者标记无关的、错误的和无效的日志数据；

1.2)对步骤1.1)中得到的日志数据进行持久化存储处理，就用户IP地址、请求时间、用户请求方法、协议版本、请求URL、请求页面、引用URL、引用页面、状态返回码、发送字节数、请求所使用浏览器和终端字段进行有效存储；

1.3)提取步骤1.2)中未被过滤的用户识别关联字段和数据对用户进行识别，进而进行用户请求的划分，并将用户请求按照时间进行排序。

3.根据权利要求1所述的一种基于用户频繁访问序列模型的Web应用性能测试方法，其特征在于，步骤2)中，包括以下步骤：

2.1)在用户请求划分的数据基础上，进行用户会话识别，采用会话时间长度阀值T₁和请求间隔长度阀值T₂相结合的方法来识别用户的会话；

2.2)在划分好的用户会话中，对用户会话序列进行补充，解决请求丢失、会话序列断开影响；

2.3)依据步骤2.1)和2.2)描述规则，进行用户访问序列的挖掘，运用用户会话识别和序列补充脚本，通过遍历预处理后的日志数据得到所需序列统计，并对各序列出现次数进行统计；

2.4)对步骤2.3)中得到的用户访问序列集合进行过滤和筛选，去掉无效的用户访问序列，进而依据Web应用具体的业务对应表，分析序列对应的具体业务，以序列出现次数作为参考，结合Web应用性能测试需求，得到待测试的用户访问序列集合。

4.根据权利要求1所述的一种基于用户频繁访问序列模型的Web应用性能测试方法，其特征在于，步骤3)中，包括以下步骤：

3.1)使用HP公司负载测试工具LoadRunner进行待测试序列的脚本录制及对其基准测试，记录序列脚本运行时间，用于计算虚拟用户数；

3.2)构建待测试序列集合的通用性能测试场景模板，填入挖掘统计数据，制定性能测试场景；

3.3)根据需求做出压力调整，即通过调整各业务的TPS，从而增加该业务的并发虚拟用户数，对Web应用的压力也同比增加。

5.根据权利要求1所述的一种基于用户频繁访问序列模型的Web应用性能测试方法，其特征在于：步骤4)中根据Web应用的生产环境架构和配置，包括分布式架构部署、服务器内存、CPU信息克隆一套测试环境，有效地进行生产环境和测试环境的比较测试和瓶颈分析，且在此基础上，根据服务器操作系统和职责的不同，按照实际所列监控内容表，对各服务器操作系统和中间件的性能进行监控；

在测试和监控环境部署完成的基础上，开展步骤5)，依据已经制定的性能测试场景，使用LoadRunner进行混合脚本的执行，得到性能测试结果以及各服务器和各中间件的性能表现，供Web应用性能和瓶颈分析。