基于LoadRunner的性能测试研究

２０１５年第２期　Ｎｏ．２，２０１５　九江学院学报（自然科学版）　（总第１０９期）　Ｊｏｕｒｎａｌ　ｏｆｊｉ￣ｉａｎｇ　Ｕｎｉｗ￣ｒｓｉｔｙ（ｎａｔｕｒａｌ　ｓｃｉｅｎｃｅｓ）　（Ｓｕｍ　Ｎｏ．１０９）　

基于ＬｏａｄＲｕｎｎｅｒ　的性能测试研究术　

陈佳丽　（龙岩学院数学与计算机科学学院福建龙岩３６４０１２）　摘要：本文介绍了性能测试的相关概念，并利用ＬｏａｄＲｕｎｎｅｒ测试工具，针对具体实　例给出了性能测试的实施步骤与方案，结合测试结果分析了该实例在性能方面可能存在的　瓶颈，最后提出了性能测试在互联网应用领域、移动应用领域及敏捷开发模式中进行测试　时所面临的挑战。　关键词：性能测试，软件测试，ＬｏａｄＲｕｎｎｅｒ　中图分类号：ＴＰ　３９３文献标识码：Ａ文章编号：１６７４—９５４５（２０１５）０２—００２１一（０５）　

近年来，随着互联网、移动应用、物联网、　云计算等各种信息技术的日趋成熟　Ｊ，软件测试　的地位也日趋重要。同时，伴随着ＩＴ领域中“大　数据集中”时代的到来，测试领域中的性能测试　显得尤为重要，引起了人们的广泛关注。不同的　应用系统都有其特定的性能或效率指标，可理解　为该系统在特定负载和不同环境配置下应具备的　响应时间和吞吐量。当前信息系统的结构越来越　庞大，使得性能测试不论是在技术方面，还是在　人员、时间及资源等方面都面临着巨大的挑战。　本文在已有研究的基础之上，着重分析了性能测　试的相关概念，包括其定义、原理及常见术语，　并利用ＬｏａｄＲｕｎｎｅｒ测试工具结合实例给出了性能　测试的实施步骤与方案，结合测试结果分析了该　实例在性能方面可能存在的瓶颈，最后提出了性　能测试在互联网应用测试领域、移动应用测试领　域及敏捷开发模式中进行测试时所面临的挑战。　ｌ性能测试简介　１．１性能测试的定义　软件系统的性能是一个宽泛的概念，通常包　含系统的执行效率、资源占用、稳定性、安全性、　兼容性、可靠性及可扩展性等　Ｊ。系统的性能测　试则是为了描述测试对象的性能特征而实施和执　一基金项目：龙岩学院第三批教学改革项目成果。　收稿日期：２０１４—１０—２０　通讯作者：陈佳丽。ｃｈｅｎｊｉａｌｉｅｊ１４２５＠１６３．ｔｏｍ。　行的一类测试－３　Ｊ。性能测试的合理实施，一方面　可以验证目标系统是否符合用户性能指标；另一　方面可得到相关的性能数据，为目标系统的优化　提供参考。组件测试（Ｃｏｍｐｏｎｅｎｔ　ｔｅｓｔｉｎｇ）、负载　测试（Ｌｏａｄ　ｔｅｓｔｉｎｇ）、压力测试（Ｓｔｒｅｓｓ　ｔｅｓｔｉｎｇ）　及容量测试（Ｖｏｌｕｍｅ　ｔｅｓｔｉｎｇ）等都属于性能测试　的范畴　Ｊ。　１．２性能测试的原理　系统性能测试以多进程／多线程（Ｍｕｌｔｉｐｌｅ　ｐｒｏｃｅｓｓｅｓ／ｔｈｒｅａｄｓ）的方式进行，其主要原理是通　过性能测试工具来模拟成千上万用户同时向后台　发送请求（该请求可理解为客户端与服务器端之　间的通讯包或协议），每个请求以测试脚本的形式　存在，以进程／线程形式运行，从而达到产生巨大　压力或指定压力的目的，同时监控后台系统资源　消耗情况以及用户端的请求处理时间。在典型的　信息系统三层架构中，若设ｔｌ、ｔ２、ｔ３分别为网　络延迟时间、应用服务器处理时间、数据库处理　时间，则用户端总的处理时间Ｔ＝ｔｌ＋ｔ２＋ｔ３。性　能测试的目的之一就在于通过测试找到合适的解　决方案尽量降低ｔｌ、ｔ２及ｔ３的值，从而降低Ｔ的　值，如图ｌ所示。　・２２・　九江学院学报（自然科学版）　２０１５年第２期　闻　图１信息系统三层架构中用户请求处理时间分解　１．３性能测试常见术语　性能测试领域常见的术语有如下几个：　（１）请求响应时间。请求响应时间是指从客　户端发出请求到得到响应的整个时间，一般包括　网络延迟时间和服务器处理时间（如图１中的　Ｔ）。　（２）并发用户数。是指同一时刻与同一服务　器进行交互的在线用户数。　（３）吞吐率。吞吐率是衡量网络性能的主要　指标，表示单位时间在网络上传输（从服务器发　送给客户端）的数据量。　（４）点击率。是指每ｓ发送的Ｈｔｔｐ请求数，　其值越大，该服务器上的压力更大。　（５）基线。基线可理解为对被测试系统所提　供的一个标准，性能测试需要有一个测试的基线　或标准，以此来判断被测试系统在不同环境中的　性能。　１．４性能测试工具Ｉ￣ａｄＲｕｎｎｅｒ简介　随着计算机处理速度越来越快，要想考察系　统的某项功能，如业务处理速度是否达到要求，　采用手工方式来记录处理时间，是不现实也不明　智的。同时，当需要模拟大量用户访问系统时，　例如要监测某个论坛是否能承受１Ｏ万个终端用户　的同时访问，要在同一时刻寻找１０万个人、ｌ０万　台电脑登录该网站的做法也是不现实的。因此，　执行性能测试时必须有专门的测试工具的帮助。　ＬｏａｄＲｕｎｎｅｒ是目前应用最多的测试工具之一，可　适用于各类不同构架的应用，主要包括：脚本录　制开发工具（ＶｕＧｅｎ）、集中控制器（ＬＲ　Ｃｏｎｔｒｏｌ－　ｌｅｒ）、结果分析器（ＬＲ　Ａｎａｌｙｓｉｓ）及压力机（Ｌｏａｄ　Ｇｅｎｅｒａｔｏｒ）等４个组件【‘】，其基本结构框架如图２　所示。　

国～一　…国　一　

一　一一一一　白　～～～　～～～　岫　

图２　ＬｏａｄＲｕｎｎｅｒ的结构组成　２性能测试实施　性能测试的实施流程是测试中的一个关键问　题，需要在测试前做好充足的准备。其基本实施　流程如图３所示。　

分析需求，构建环境　

照睡磋　｝…　张葡磊　一　．　…～　…　～…一……　…　

设计测试用例　创建测试用例脚本　

＿＿。一　、　、　

ｌ　蔓　］　霞　＿ｉ真插　分析测试结果　

图３性能测试实施流程　本节以下内容将结合《某酒店预订系统》，利　用ＬｏａｄＲｕｎｎｅｒ测试工具，按上述实施流程，分析　性能测试的具体实施步骤。　２．１性能测试需求分析　该“酒店预订系统”是Ｂ／Ｓ架构模式，采用　Ｊ２ＥＥ开发。主要实现两个核心的功能：①查询检　索功能，即查询出符合用户输入条件的酒店列表；　②预订功能，即能正常预订用户所选定的某一酒　店。该酒店预订系统的性能测试需求如表１所示。　表１酒店预订系统的性能需求　需求内容　详细描述　需求１　检索功能支持１０００个并发用户　需求２　预订功能支持１２０个并发用户　需求３　检索响应时间在３ｓ以内　

需求５　系统要连续稳定运行７２ｈ　２．２测试环境构建　根据２．１节对酒店预定系统功能的描述和表１　对该系统性能测试需求的描述，构建该系统的测　第２期　陈佳丽：基于ＬｏａｄＲｕｎｎｅｚ’的性能测试研究　・２３・　试环境，如表２所示。　表２酒店预订系统性能测试环境　

２．３测试用例设计　针对同一个性能测试需求，有多种不同的测试　方法。在确定了性能测试需求之后，可将用户业务　操作形成更详细的测试用例描述，据此设计如表３　所示的测试用例。　表３酒店预订系统性能需求对应的测试用例　

２．４创建测试脚本　

设计完测试用例之后，接下来的工作是结合用　例的内容，进行测试脚本的创建与编写工作，该工　作主要在ｌ＿￣ａｄＲｕｎｎｅｒ的脚本录制开发工具（Ｖｕ．　Ｇｅｎ）中完成，启动ＶｕＧｅｎ应用（如基于Ｂ／Ｓ结构　的酒店预订系统），选择合适的录制协议（如Ｗｅｂ　（ＨｒＩｑ＇Ｐ／ＨＴＭＬ）协议），打开被测应用的客户端程　序，按照预期的操作步骤即可进行录制　Ｊ。　录制完后的每个Ｖｕｓｅｒ脚本都至少包含以下３　个部分的内容：　（１）ｖｕｓｅｒ＿ｉｎｉｔ，记录登录到服务器上的活动，　在脚本启动时运行，运行次数为１次；　（２）Ａｃｔｉｏｎ，脚本的主体内容，记录客户端的　活动，运行次数由Ｒｕｎ　Ｔｉｍｅ　Ｓｅｔｔｉｎｇ决定；　（３）ｖｕｓｅＥ　ｅｎｄ，记录注销服务器活动的过程，　在脚本退出时运行，运行次数为１次。　２．５测试场景设计　性能测试场景的设计是以所设计的性能测试用　例、所编写的测试脚本为基础而进行的。结合表１　和表３，可确定该系统中的几个典型的测试场景，　如表４所示。　

表４酒店预订系统典型的测试场景　名称　描述　指标　性能计数器　

。　…。　主兰行　耄　．　①应用服务器ｃＰｕ使用情况　竺　竺模块　长　：　加　页面响应时间≤３　内存　黥　４佣户…　…一　～……一　

⑤迭代时间间隔：３０ｓ　…………　・２４・　九江学院学报（自然科学版）　２０１５年第２期　黻垂　……一３ｓ　

………＝，　、　①　ｃ　使用　定性测试场（。　暨模　型场景　；．处否　；　内存　景　要　

：倍…　…”…～　～……。　

②测试持续时间：７２ｈ　力也无明显改变　……　…一　

２．６执行场景　执行测试场景是关系到测试结果是否准确的一　个重要过程，该过程相对简单。当单击运行页面中　的“Ｓｔａｒｔ　Ｓｃｅｎａｒｉｏ”按钮时，ＬＲ控制器会自动开始　运行场景，并在场景状态中显示运行时的信息。在　时间充裕的情况下，同样一个测试用例最好能执行　至少３次，然后再分析结果，若结果相接近，才能　初步证明此次的测试是成功的。因而从场景执行到　测试结果的分析是一个循环的过程。　２．７分析测试结果　根据上述分析步骤，对该系统执行负载测试，　结果如下表５所示。　表５酒店预订系统服务器资源利用情况测试结果　

上述结果表明，对检索功能而言，当并发用　户数达到１　０００时，系统检索的平均响应时间为　３．８ｓ，不满足检索响应时间在３ｓ以内的要求，因　而该项测试结果不满足性能指标；当检索并发用　户数达到１　２００时，系统检索的平均响应时间为　６．６ｓ，超出了３．６ｓ，但此时的并发用户数是ｌ　２００　人，故可看作是满足性能指标。就系统测试而言，　当查询功能模块并发用户数为１　ｏｏｏ，预订功能模　块为１２０时，系统ＣＰＵ平均的占用率为８８％，不　满足ＣＰＵ利用率≤８５％的性能指标，因而该项测　试结果不满足要求；而当查询功能模块并发用户　数为１２００，预订功能模块为１４０时，系统ＣＰＵ平　均的占用率为９３％，同前分析，也可看作是满足　性能要求。　综上，当并发用户数超过一定数量时，系统　检索响应时间和ＣＰＵ的占用率都不能满足需求，　因而该系统的性能暂时无法达到预期的结果。其　存在的瓶颈可能包含以下几个方面：①系统没有　采用合适的并发／并行策略；②数据库设计和优化　不充分；③服务器的网络带宽不足；④服务器的　ＣＰＵ性能不够等。后续的解决方案是针对这些可　能的瓶颈，尽快对其进行改进，使其性能尽可能　达到预期的要求。　３性能测试面临的挑战　３．１互联网应用测试　与测试传统系统一样，在针对互联网的应用　系统进行测试时，同样必须在程序部署到互联网　之前就暴露其中的错误。互联网用户往往需要的　是能即时得到响应的页面，他们不会长时间地等　待页面加载，几秒的延时都可能导致客户的离开，　较差的性能也会导致客户怀疑网站的可靠性。再　加上基于互联网的应用系统越来越复杂，各部件　之间紧密耦合，对数据的准确性和安全性提出了　更高的要求，使得对其进行性能测试的难度也越