LoadRunnerMILY: 宋体; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">的基本原理这边不详细介绍了，估计大家都很清楚了。这里强调一点：LoadRunner不关心服务器内部的处理，所以有时在javascript:tagshow(event, '%B2%E2%CA%D4');" href="javascript:;" target=_self>测试时可能会发现，我们对系统施加了很大压力时，所有虚拟用户都测试通过了，但请求响应时间不正常的短，那一般来说，系统测试有问题，这就是因为LoadRunner没有去验证是否服务器真的处理了请求。
下面介绍一下我使用Loadrunner测试时的一些心得、经验与教训。
一、性能测试步骤
使用LoadRunner进行性能测试的步骤：测试计划-》设计测试用例-》录制测试脚本-》执行测试-》分析测试结果，这个测试步骤和常规的测试过程很类似。
测试计划
•分析应用系统
•计划LoadRunner执行过程
——》
设计测试用例
•分析测试需求
•确定测试负载
•确定用例细节
——》
录制测试脚本
在编辑脚本时，要注意几点：
•录制基本的虚拟用户脚本
•优化脚本（设置Run-Time属性；参数化；设置事务集合点；脚本回放等）
•配置Run-Time属性
•在单机模式运行测试脚本
•将虚拟用户脚本合并到测试场景中
——》
执行测试
在执行测试场景时，要注意几点：
•运行一个完整的测试场景
•控制虚拟用户组
•控制独立的虚拟用户
•手工从集合点释放虚拟用户
•手工向一个执行的场景增加虚拟用户
在监控测试场景时，要注意几点：
•开始监控器
•打开在线监控器图表
•服务器资源监控
•设置监控器属性
——》
分析测试结果
因为分析测试结果部分涉及的东西比较多，所以这里先暂时只给出个例子。
估计性能测试总工作量：
因为在编写材料时，有同事提出比较关心性能测试的工作量，所以我将这个例子项目的性能测试工作量进行了统计。
某移动知识管理系统在系统初验前，项目总工作量是49.06人月，测试总工作量是8.644人月（即186人日），测试占项目总工作量的17.62%。其中，性能测试占测试总工作量的14.3%，与前面介绍的性能测试估算比例9%相比大出很多。这是因为参与这个项目的测试组没有性能测试经验，并且这个项目性能需求比较多，客户对系统性能要求比较高。单单到客户处进行性能测试，就不下10次，这还需要包括前期的实施准备工作。因为移动的机房和我们测试客户机不在同一个地方，所以，每次进行性能测试之前，都需要很多人的协助。所以，从工具学习、到脚本问题处理、沟通、测试执行上，这个项目都花了不少时间。后面另一个项目因为有了前面项目的经验积累，整个性能测试工作的工作量占整个项目性能测试工作量的8.2%。
下面我使用该项目的一个性能测试点对脚本的录制这块介绍。
场景介绍：
[-o!mC)L0培训考试在线考试，要求能够实现500个人同时在线考试。
*[&Gi:l8Lb!E9O0关键点：ITPUB个人空间j l)Y9]v ],K f
每个人登陆系统后，不能再次登陆系统
4? I+AD+@| R0500人同时提交试卷时，并发性要求很大
E#dXn D0
因为没有系统，先大致给大家描述一下界面。
由于录制脚本是整个性能测试的一个基础，所以，这里先主要讲脚本的录制。
假设：并发性最大的情况是考试时间到时，系统自动提交试卷的这一时刻。
这里主要强调几点：
1.参数化的几个注意点：
1)空格问题
2)参数设置方式
3)16进制的参数化（多用几个用户录制脚本，对比脚本不同的地方）
——》
二、测试经验
6D5B)u Z X s0tfx02.我们不可能对所有的系统功能都进行性能测试。
n7{^5f*v _ EcM(N0在测试设计时需要结合当时的实际系统，先分析软件可能存在的瓶颈，此时可依据80/20原则（帕雷托原则）分析，再依此制定性能测试的方案：ITPUB个人空间E:[7QY2p;M q
1）对系统资源的利用；
T$B.})qj02）数据大量传输；ITPUB个人空间y o v"Tx$u\N
3）数据转换（获取其它库表中数据转换为XML格式，或二进制）；
0^dO9VU2VOB04）使用的频度（分析用户习惯）
对可能成为瓶颈的模块要细分，同时又要分析用户行为习惯，用户行为习惯是很重要的。有些模块可能开发人员认为并发会很多，但实际上，可能可能一天只用一次。
3.不要丢弃原来旧的测试结果
~0J2@9MP\01）可以量化开发产生的影响
3~`9H/J/n Y*I02）可以把现在和以前的性能进行对比
)w3F*kyY\I03.不要把测试脚本复杂化
T&i$}7C qO3p f04.使系统的think-time时间更贴近实际情况。ITPUB个人空间t+r]i |p;J ]
5.对于B/S架构的系统 ，在录制脚本之前，将浏览器的cache和cookie清空。ITPUB个人空间vx1~ h7T5v-Z
三、教训
l 在现场录制脚本，临时碰到问题，导致花了很长时间调试脚本
解释：我第一次在移动培训室里现场录制脚本时，却临时碰到问题，花了很长时间修改脚本，并且还好那时是有微软服务的人现场指导，否则可能那天的测试都没法进行了。
应对：
1)在公司要多试，并将脚本调通，并记下录制步骤，及注意事项
2)在计划测试前，到客户处将脚本录制好
3)测试工具的选择应恰当。刚开始选择微软VS.net里自带的ACT进行测试，但是因为该工具有些东西不是很稳定。导致测试的多次延误，后面选择使用LoadRunner进行测试了。
l 执行测试时开始没有注意脚本执行情况和测试客户机、服务器资源情况
解释：执行测试时发现脚本执行时报错，还有就是服务器、测试客户机资源不够的情况，如果碰到这些情况时，要停止测试，分析原因。如果是测试脚本执行出错，需要对脚本进行调整；如果遇到服务器资源不够，那么要减少对本机的负载；如果是服务器资源不够，那么需要减少对服务器的负载。因此，在执行测试时，不是让脚本自己跑，而要时刻关心执行情况，避免测试结果误差过大。因为当出现异常时，响应时间会异常的短，这时的测试结果很不准确。
l 测试前没有记录测试机器名、机器位置、机器配置
解释：结果没有唯一的标识，收集、分析结果很混乱。因为分析结果时需要参考机器配置。
l 没有准备安装光盘
解释：不要只在带过去的笔记本上有安装程序。两个原因：1)增加安装客户端的速度。因为安装程序时，要从本机上进行安装，避免从网络安装，这样每台机器都要进行拷贝安装程序，然后再安装，速度很慢。
2)万一带过去的笔记本无法连到测试环境内时，那就很麻烦了。
l 在执行测试时，才发现测试工具安装有问题
解释：测试客户机测试工具和测试脚本能否正确运行要提前确认，不可等到所有准备工作做好了，要开始执行测试时才发现问题。因为曾经碰到过这样的例子，那时使用ACT进行测试，那时到客户处进行测试时，才发现同样方式下安装的ACT，有部分机器就无法正确运行脚本，导致测试整整推迟了2小时。而这个项目的性能测试大部分时候需要在凌晨时才能进行的，推迟2小时意味着可能在用户上班前无法完成测试。如果是借同事的机器进行测试，推迟测试完成时间意味着将影响其他同事的工作。
l 所有测试客户机与服务器时间不一致
解释：两方面考虑：
1) 数据整理时，如果时间不一样，数据合并会有问题
2) 因为使用的版本问题，需要有较多的测试客户机，一个人要操作很多台机器，通常需要设置场景的开始运行时间，如果机器时间不一致，那很难达到并发的效果。
文章来源于领测软件测试网 https://www.ltesting.net/
