2015年第2期 No.2,2015 九江学院学报(自然科学版) (总第109期) Journal ofji ̄iang Uniw ̄rsity(natural sciences) (Sum No.109)
基于LoadRunner 的性能测试研究术
陈佳丽 (龙岩学院数学与计算机科学学院福建龙岩364012) 摘要:本文介绍了性能测试的相关概念,并利用LoadRunner测试工具,针对具体实 例给出了性能测试的实施步骤与方案,结合测试结果分析了该实例在性能方面可能存在的 瓶颈,最后提出了性能测试在互联网应用领域、移动应用领域及敏捷开发模式中进行测试 时所面临的挑战。 关键词:性能测试,软件测试,LoadRunner 中图分类号:TP 393文献标识码:A文章编号:1674—9545(2015)02—0021一(05)
近年来,随着互联网、移动应用、物联网、 云计算等各种信息技术的日趋成熟 J,软件测试 的地位也日趋重要。同时,伴随着IT领域中“大 数据集中”时代的到来,测试领域中的性能测试 显得尤为重要,引起了人们的广泛关注。不同的 应用系统都有其特定的性能或效率指标,可理解 为该系统在特定负载和不同环境配置下应具备的 响应时间和吞吐量。当前信息系统的结构越来越 庞大,使得性能测试不论是在技术方面,还是在 人员、时间及资源等方面都面临着巨大的挑战。 本文在已有研究的基础之上,着重分析了性能测 试的相关概念,包括其定义、原理及常见术语, 并利用LoadRunner测试工具结合实例给出了性能 测试的实施步骤与方案,结合测试结果分析了该 实例在性能方面可能存在的瓶颈,最后提出了性 能测试在互联网应用测试领域、移动应用测试领 域及敏捷开发模式中进行测试时所面临的挑战。 l性能测试简介 1.1性能测试的定义 软件系统的性能是一个宽泛的概念,通常包 含系统的执行效率、资源占用、稳定性、安全性、 兼容性、可靠性及可扩展性等 J。系统的性能测 试则是为了描述测试对象的性能特征而实施和执 一基金项目:龙岩学院第三批教学改革项目成果。 收稿日期:2014—10—20 通讯作者:陈佳丽。chenjialiej1425@163.tom。 行的一类测试-3 J。性能测试的合理实施,一方面 可以验证目标系统是否符合用户性能指标;另一 方面可得到相关的性能数据,为目标系统的优化 提供参考。组件测试(Component testing)、负载 测试(Load testing)、压力测试(Stress testing) 及容量测试(Volume testing)等都属于性能测试 的范畴 J。 1.2性能测试的原理 系统性能测试以多进程/多线程(Multiple processes/threads)的方式进行,其主要原理是通 过性能测试工具来模拟成千上万用户同时向后台 发送请求(该请求可理解为客户端与服务器端之 间的通讯包或协议),每个请求以测试脚本的形式 存在,以进程/线程形式运行,从而达到产生巨大 压力或指定压力的目的,同时监控后台系统资源 消耗情况以及用户端的请求处理时间。在典型的 信息系统三层架构中,若设tl、t2、t3分别为网 络延迟时间、应用服务器处理时间、数据库处理 时间,则用户端总的处理时间T=tl+t2+t3。性 能测试的目的之一就在于通过测试找到合适的解 决方案尽量降低tl、t2及t3的值,从而降低T的 值,如图l所示。 ・22・ 九江学院学报(自然科学版) 2015年第2期 闻 图1信息系统三层架构中用户请求处理时间分解 1.3性能测试常见术语 性能测试领域常见的术语有如下几个: (1)请求响应时间。请求响应时间是指从客 户端发出请求到得到响应的整个时间,一般包括 网络延迟时间和服务器处理时间(如图1中的 T)。 (2)并发用户数。是指同一时刻与同一服务 器进行交互的在线用户数。 (3)吞吐率。吞吐率是衡量网络性能的主要 指标,表示单位时间在网络上传输(从服务器发 送给客户端)的数据量。 (4)点击率。是指每s发送的Http请求数, 其值越大,该服务器上的压力更大。 (5)基线。基线可理解为对被测试系统所提 供的一个标准,性能测试需要有一个测试的基线 或标准,以此来判断被测试系统在不同环境中的 性能。 1.4性能测试工具I ̄adRunner简介 随着计算机处理速度越来越快,要想考察系 统的某项功能,如业务处理速度是否达到要求, 采用手工方式来记录处理时间,是不现实也不明 智的。同时,当需要模拟大量用户访问系统时, 例如要监测某个论坛是否能承受1O万个终端用户 的同时访问,要在同一时刻寻找10万个人、l0万 台电脑登录该网站的做法也是不现实的。因此, 执行性能测试时必须有专门的测试工具的帮助。 LoadRunner是目前应用最多的测试工具之一,可 适用于各类不同构架的应用,主要包括:脚本录 制开发工具(VuGen)、集中控制器(LR Control- ler)、结果分析器(LR Analysis)及压力机(Load Generator)等4个组件【‘】,其基本结构框架如图2 所示。
国~一 …国 一
一 一一一一 白 ~~~ ~~~ 岫
图2 LoadRunner的结构组成 2性能测试实施 性能测试的实施流程是测试中的一个关键问 题,需要在测试前做好充足的准备。其基本实施 流程如图3所示。
分析需求,构建环境
照睡磋 }… 张葡磊 一 . …~ … ~…一…… …
设计测试用例 创建测试用例脚本
__。一 、 、
l 蔓 ] 霞 _i真插 分析测试结果
图3性能测试实施流程 本节以下内容将结合《某酒店预订系统》,利 用LoadRunner测试工具,按上述实施流程,分析 性能测试的具体实施步骤。 2.1性能测试需求分析 该“酒店预订系统”是B/S架构模式,采用 J2EE开发。主要实现两个核心的功能:①查询检 索功能,即查询出符合用户输入条件的酒店列表; ②预订功能,即能正常预订用户所选定的某一酒 店。该酒店预订系统的性能测试需求如表1所示。 表1酒店预订系统的性能需求 需求内容 详细描述 需求1 检索功能支持1000个并发用户 需求2 预订功能支持120个并发用户 需求3 检索响应时间在3s以内
需求5 系统要连续稳定运行72h 2.2测试环境构建 根据2.1节对酒店预定系统功能的描述和表1 对该系统性能测试需求的描述,构建该系统的测 第2期 陈佳丽:基于LoadRunnez’的性能测试研究 ・23・ 试环境,如表2所示。 表2酒店预订系统性能测试环境
2.3测试用例设计 针对同一个性能测试需求,有多种不同的测试 方法。在确定了性能测试需求之后,可将用户业务 操作形成更详细的测试用例描述,据此设计如表3 所示的测试用例。 表3酒店预订系统性能需求对应的测试用例
2.4创建测试脚本
设计完测试用例之后,接下来的工作是结合用 例的内容,进行测试脚本的创建与编写工作,该工 作主要在l_ ̄adRunner的脚本录制开发工具(Vu. Gen)中完成,启动VuGen应用(如基于B/S结构 的酒店预订系统),选择合适的录制协议(如Web (HrIq'P/HTML)协议),打开被测应用的客户端程 序,按照预期的操作步骤即可进行录制 J。 录制完后的每个Vuser脚本都至少包含以下3 个部分的内容: (1)vuser_init,记录登录到服务器上的活动, 在脚本启动时运行,运行次数为1次; (2)Action,脚本的主体内容,记录客户端的 活动,运行次数由Run Time Setting决定; (3)vuseE end,记录注销服务器活动的过程, 在脚本退出时运行,运行次数为1次。 2.5测试场景设计 性能测试场景的设计是以所设计的性能测试用 例、所编写的测试脚本为基础而进行的。结合表1 和表3,可确定该系统中的几个典型的测试场景, 如表4所示。
表4酒店预订系统典型的测试场景 名称 描述 指标 性能计数器
。 …。 主兰行 耄 . ①应用服务器cPu使用情况 竺 竺模块 长 : 加 页面响应时间≤3 内存 黥 4佣户… …一 ~……一
⑤迭代时间间隔:30s ………… ・24・ 九江学院学报(自然科学版) 2015年第2期 黻垂 ……一3s
………=, 、 ① c 使用 定性测试场(。 暨模 型场景 ;.处否 ; 内存 景 要
:倍… …”…~ ~……。
②测试持续时间:72h 力也无明显改变 …… …一
2.6执行场景 执行测试场景是关系到测试结果是否准确的一 个重要过程,该过程相对简单。当单击运行页面中 的“Start Scenario”按钮时,LR控制器会自动开始 运行场景,并在场景状态中显示运行时的信息。在 时间充裕的情况下,同样一个测试用例最好能执行 至少3次,然后再分析结果,若结果相接近,才能 初步证明此次的测试是成功的。因而从场景执行到 测试结果的分析是一个循环的过程。 2.7分析测试结果 根据上述分析步骤,对该系统执行负载测试, 结果如下表5所示。 表5酒店预订系统服务器资源利用情况测试结果
上述结果表明,对检索功能而言,当并发用 户数达到1 000时,系统检索的平均响应时间为 3.8s,不满足检索响应时间在3s以内的要求,因 而该项测试结果不满足性能指标;当检索并发用 户数达到1 200时,系统检索的平均响应时间为 6.6s,超出了3.6s,但此时的并发用户数是l 200 人,故可看作是满足性能指标。就系统测试而言, 当查询功能模块并发用户数为1 ooo,预订功能模 块为120时,系统CPU平均的占用率为88%,不 满足CPU利用率≤85%的性能指标,因而该项测 试结果不满足要求;而当查询功能模块并发用户 数为1200,预订功能模块为140时,系统CPU平 均的占用率为93%,同前分析,也可看作是满足 性能要求。 综上,当并发用户数超过一定数量时,系统 检索响应时间和CPU的占用率都不能满足需求, 因而该系统的性能暂时无法达到预期的结果。其 存在的瓶颈可能包含以下几个方面:①系统没有 采用合适的并发/并行策略;②数据库设计和优化 不充分;③服务器的网络带宽不足;④服务器的 CPU性能不够等。后续的解决方案是针对这些可 能的瓶颈,尽快对其进行改进,使其性能尽可能 达到预期的要求。 3性能测试面临的挑战 3.1互联网应用测试 与测试传统系统一样,在针对互联网的应用 系统进行测试时,同样必须在程序部署到互联网 之前就暴露其中的错误。互联网用户往往需要的 是能即时得到响应的页面,他们不会长时间地等 待页面加载,几秒的延时都可能导致客户的离开, 较差的性能也会导致客户怀疑网站的可靠性。再 加上基于互联网的应用系统越来越复杂,各部件 之间紧密耦合,对数据的准确性和安全性提出了 更高的要求,使得对其进行性能测试的难度也越