ITPub博客

首页 > Linux操作系统 > Linux操作系统 > Loadrunner测试时的一些心得

Loadrunner测试时的一些心得

原创 Linux操作系统 作者:idba 时间:2009-10-02 17:36:16 0 删除 编辑

一、性能测试步骤
        使用LoadRunner进行性能测试的步骤:测试计划-》设计测试用例-》录制测试脚本-》执行测试-》分析测试结果,这个测试步骤和常规的测试过程很类似。

测试计划

•分析应用系统

•定义性能测试目标(确定需求对应的度量指标)

•计划LoadRunner执行过程

——》

设计测试用例

•分析测试需求

•确定测试负载

•确定用例细节

1

——》

录制测试脚本

 在编辑脚本时,要注意几点:

•录制基本的虚拟用户脚本

•优化脚本(设置Run-Time属性;参数化;设置事务集合点;脚本回放等)

•配置Run-Time属性

•在单机模式运行测试脚本

•将虚拟用户脚本合并到测试场景中

——》

执行测试

  在执行测试场景时,要注意几点:

•运行一个完整的测试场景

•控制虚拟用户组

•控制独立的虚拟用户

•手工从集合点释放虚拟用户

•手工向一个执行的场景增加虚拟用户

在监控测试场景时,要注意几点:

•开始监控器

•打开在线监控器图表

•服务器资源监控

•设置监控器属性

——》

分析测试结果

因为分析测试结果部分涉及的东西比较多,所以这里先暂时只给出个例子。

11

估计性能测试总工作量:

        因为在编写材料时,有同事提出比较关心性能测试的工作量,所以我将这个例子项目的性能测试工作量进行了统计。

        某移动知识管理系统在系统初验前,项目总工作量是49.06人月,测试总工作量是8.644人月(即186人日),测试占项目总工作量的17.62%。其中,性能测试占测试总工作量的14.3%,与前面介绍的性能测试估算比例9%相比大出很多。这是因为参与这个项目的测试组没有性能测试经验,并且这个项目性能需求比较多,客户对系统性能要求比较高。单单到客户处进行性能测试,就不下10次,这还需要包括前期的实施准备工作。因为移动的机房和我们测试客户机不在同一个地方,所以,每次进行性能测试之前,都需要很多人的协助。所以,从工具学习、到脚本问题处理、沟通、测试执行上,这个项目都花了不少时间。后面另一个项目因为有了前面项目的经验积累,整个性能测试工作的工作量占整个项目性能测试工作量的8.2%。

        下面我使用该项目的一个性能测试点对脚本的录制这块介绍。

场景介绍:
培训考试在线考试,要求能够实现500个人同时在线考试。
关键点:
每个人登陆系统后,不能再次登陆系统
500人同时提交试卷时,并发性要求很大


        因为没有系统,先大致给大家描述一下界面。

111

由于录制脚本是整个性能测试的一个基础,所以,这里先主要讲脚本的录制。

        假设:并发性最大的情况是考试时间到时,系统自动提交试卷的这一时刻。

        这里主要强调几点:

1.参数化的几个注意点:

1)空格问题

2)参数设置方式

3)16进制的参数化(多用几个用户录制脚本,对比脚本不同的地方)

——》

 二、测试经验
1.应该尽早的进行性能测试,不建议上线后做性能测试
2.我们不可能对所有的系统功能都进行性能测试。
        在测试设计时需要结合当时的实际系统,先分析软件可能存在的瓶颈,此时可依据80/20原则(帕雷托原则)分析,再依此制定性能测试的方案:

1)对系统资源的利用;
2)数据大量传输;

3)数据转换(获取其它库表中数据转换为XML格式,或二进制);
使用的频度(分析用户习惯)

        对可能成为瓶颈的模块要细分,同时又要分析用户行为习惯,用户行为习惯是很重要的。有些模块可能开发人员认为并发会很多,但实际上,可能可能一天只用一次。

3.不要丢弃原来旧的测试结果
1)可以量化开发产生的影响

2)可以把现在和以前的性能进行对比
3.不要把测试脚本复杂化
4.使系统的think-time时间更贴近实际情况。
5.对于B/S架构的系统 ,在录制脚本之前,将浏览器的cache和cookie清空。

三、教训
        在现场录制脚本,临时碰到问题,导致花了很长时间调试脚本

        解释:我第一次在移动培训室里现场录制脚本时,却临时碰到问题,花了很长时间修改脚本,并且还好那时是有微软服务的人现场指导,否则可能那天的测试都没法进行了。

应对:

1)在公司要多试,并将脚本调通,并记下录制步骤,及注意事项

2)在计划测试前,到客户处将脚本录制好

3)测试工具的选择应恰当。刚开始选择微软VS.net里自带的ACT进行测试,但是因为该工具有些东西不是很稳定。导致测试的多次延误,后面选择使用LoadRunner进行测试了。

        执行测试时开始没有注意脚本执行情况和测试客户机、服务器资源情况

        解释:执行测试时发现脚本执行时报错,还有就是服务器、测试客户机资源不够的情况,如果碰到这些情况时,要停止测试,分析原因。如果是测试脚本执行出错,需要对脚本进行调整;如果遇到服务器资源不够,那么要减少对本机的负载;如果是服务器资源不够,那么需要减少对服务器的负载。因此,在执行测试时,不是让脚本自己跑,而要时刻关心执行情况,避免测试结果误差过大。因为当出现异常时,响应时间会异常的短,这时的测试结果很不准确。

        测试前没有记录测试机器名、机器位置、机器配置

解释:结果没有唯一的标识,收集、分析结果很混乱。因为分析结果时需要参考机器配置。

        没有准备安装光盘

解释:不要只在带过去的笔记本上有安装程序。两个原因:1)增加安装客户端的速度。因为安装程序时,要从本机上进行安装,避免从网络安装,这样每台机器都要进行拷贝安装程序,然后再安装,速度很慢。

2)万一带过去的笔记本无法连到测试环境内时,那就很麻烦了。

        在执行测试时,才发现测试工具安装有问题

        解释:测试客户机测试工具和测试脚本能否正确运行要提前确认,不可等到所有准备工作做好了,要开始执行测试时才发现问题。因为曾经碰到过这样的例子,那时使用ACT进行测试,那时到客户处进行测试时,才发现同样方式下安装的ACT,有部分机器就无法正确运行脚本,导致测试整整推迟了2小时。而这个项目的性能测试大部分时候需要在凌晨时才能进行的,推迟2小时意味着可能在用户上班前无法完成测试。如果是借同事的机器进行测试,推迟测试完成时间意味着将影响其他同事的工作。

        所有测试客户机与服务器时间不一致

解释:两方面考虑:

        数据整理时,如果时间不一样,数据合并会有问题

        因为使用的版本问题,需要有较多的测试客户机,一个人要操作很多台机器,通常需要设置场景的开始运行时间,如果机器时间不一致,那很难达到并发的效果。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/1384/viewspace-615953/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-03-25

  • 博文量
    210
  • 访问量
    392428