loadrunner应用实例.docVIP

LoadRunner应用实例 LoadRunner简介 LoadRunner是一种预测系统行为和性能的工业标准级负载测试工具。通过模拟多个用户实施并发负载及实时性能监测的方式来确认和查找问题。 它主要分3部分： VU Generator能够生成虚拟用户，以虚拟用户的方式模拟真实用户的业务操作行为。 Controller生成运行虚拟用户的场景，并可以根据需要进行细致的运行设置，加载并运行虚拟用户。提供实时监测器，实时显示交易性能数据（如响应时间）和其它系统组件包括application server, web server，网路设备和数据库等的实时性能。 Analyser是分析和报告工具，在场景运行完成后，收集汇总所有的测试数据，以便迅速查找到性能问题并追溯原由。 LoadRunner主要适用于测试系统中通过协议进行交互的操作。如B/S,C/S结构客户端向服务端的请求。本应用实例就是对LoadRunner这3部分的一个综合应用。 本次应用所使用的LoadRunner软件为LoadRunner 7试用版，最大并发用户25，试用期14天。 使用过程 问题描述 公司现在使用的工程管理数据库，在使用中发现其中的工程配置查询界面打开缓慢，本次任务的目的是找出查询界面打开时的瓶颈，并在不改变程序架构和数据库结构的情况下进行优化。 软件结构 工程管理数据库采用C/S结构，后台使用WIN2000SERVER+SQL2000，前端使用Access＋VBA开发，其中主要包括数据库文件、用户管理文件、执行程序文件、执行程序引导文件。 使用环境 服务器为公司内部服务器。客户端为公司内部所有机器。网络环境为公司内部局域网。 测试方案 服务器为实际使用中的公司内部服务器。客户端为P4 2.8/512M/win2000pro。网络环境为公司内部局域网。因此测试时，不存在服务器端和网络差异影响。 客户端软件响应时间可分为2部分：本地处理时间＋后台数据处理时间。经与测试提交人交流得知，本地处理时间有限，主要是后台数据处理消耗时间。因此本次测试重点为后台数据处理性能。 经讨论确定基本数据量为当前数据库数据量（主要工作表的容量为50000条记录左右），最大并发用户数为100，其中70％为查询操作，其余30％中15％为添加配置，10％为修改配置，5％为删除配置。根据以上情况，确定2个测试用例如下： 在当前数据库存储的数据量下，单个用户打开配置查询新界面，进行查询操作，记录响应时间。 在当前数据库存储的数据量下，由1个用户开始，每次增加一个用户直到有事务失败出现，100％打开查询配置界面并查询。 执行过程 用VU Generator录制打开该界面的脚本，选择ODBC协议。 编辑该脚本，定义所需的事务。运行通过。 在Controller中生成新场景，加载所需脚本，并配置并发数，添加监视资源。 在Controller中设置运行场景，并运行该场景。 在Analyser中查看并分析结果。 结果分析 响应时间 第一次执行测试用例1中，打开配置查询界面结果如下： Transaction Name Minimum Average Maximum 90Percent dkpzcxwin 54.849 54.849 54.849 54.849 Lhcx1 26.671 26.671 26.671 26.671 Lhcx2 27.865 27.865 27.865 27.865 单位：秒 各栏自左向右依次分别为：响应时间最小值，平均值，最大值，90％操作的响应时间。 dkpzcxwin：打开配置查询界面时进行的后台数据处理时间。 Lhcx1，lhcx2：dkpzcxwin事务中2个最主要的联合查询。 从上表的结果可以看出dkpzcxwin事务耗时近一分钟。从录制的脚本中对dkpzcxwin进行细分，将dkpzcxwin事务中2个最主要的联合查询分为Lhcx1事务和lhcx2事务。执行结果很明显，2个联合查询的时间长导致配置查询界面时间过长。所以确定对联合查询Lhcx1和lhcx2进行优化。 对打开配置查询界面，在不改变程序框架和数据库表结构内容的前提下，采取的优化措施如下： 优化查询。将2个联合查询优化为一条sql语句后，执行打开配置查询界面测试的结果如下： Transaction Name Minimum Average Maximum 90Percent dkpzcxwin 26.659 26.659 26.659 26.659 dcpzcx 26.448 26.448 26.448 26.448 单位：秒 各栏自左向右依次分别为：响应时间最小值，平均值，最大值，90％操作的响应时间。 dkpzcxwin：打开配置查询界面时进行的后台数据处理时间。 Dkpzcx：dkpz