（2）脚本分割。LR的脚本分割具有更强的灵活性，如果有一段内容需要经常被使用到，那么就可以把他单独拎出来，放在一个函数，也就是在Script. View左边Action导航中Create New Action即可。这样就可以随用随调了。

　　脚本处理好以后在VUGen中回放时，默认是按照RunTime-Setting -> Run Logic -> Run下面的action顺序执行的，这个时候就会出现问题。比如Run下面有4个action：login()、start()、sendMsg()（调用start()）、logout()，其中只需要在sendMsg的时候调用一次start就可以了，按照目前的顺序回放的话，start()就被多执行了一次。要解决这个问题，只需要将start()从RunTime-Setting -> Run Logic -> Run中删除即可。回到Script. View左边Action导航可以看到start()的图标变成了半透明状，类似“只读”状态，事实上是可以编辑的。这又是一个行之有效的小窍门。

　　（3）脚本参数化。以前只拘泥于选择file文件类型对脚本进行参数化，后来发现file类型太麻烦了，特别是大数据量的时候，如果不是必须用的话，建议选择其他的类型。比如说XXX项目中，对Server的参数化就是选择在server0、server1还是server2上执行，先前都是采用file类型，因为最多要有1500个用户并发，所以要在file中准备1500条数据，这样就是一个比较大的工作量，尽管用excel拖曳一下也蛮方便的。事实上，我只需要对0、1、2做参数化就行了，所以使用Random Number类型就更方便啦，而且通过压力测试发现，这种参数处理方式可以使各台服务器的负载更加均衡。强调这一点并不是说file类型不好，而是说在进行参数化的时候要结合实际，做最有效的处理。其实对于参数化已经讲了不止一次了，每次都有新的内容，关键是要用，在用的过程中才能做到“融会贯通，游刃有余”。

　　（4）脚本关联方式。脚本的关联是在脚本处理过程中经常用到的，他可以自动关联，也可以手动关联。可以参考鄙人以前写的《在LoadRunner中用web_reg_save_param()做关联》，除了该文档中编写的方法外，鄙人还发现一个查找关联点的方法，那就是在脚本回放的时候选择打开浏览器Tools->General Options->Display->Show browser during replay，这样就会将新一轮的回放结果显示在浏览器中，很明了的就可以查看了。如果对系统比较熟悉，关联就会变得非常简单了。

　　3、场景设计。场景设计是非常重要的，这个更多的依赖于性能需求，想要什么样的结果就做什么样的设计。在此次的测试过程中发现，场景开始执行时如果同时有100个用户并发操作，就会出现大量的连接超时，服务器无法响应，或者连接被过早的关闭等错误，这个时候就需要寻求最佳的并发用户数量，因为有多台客户端，所以在设计场景时就需要仔细计算每个客户端的并发用户数量，并且需要保证每次接收和发送消息的并发用户数量是相同的。

　　4、Run-tXXXe Setting设置。因为要保证每个用户都必须成功登录，所以在登录脚本中做了条件判断，如果用户的ID和应用ID等不为空，就表示登录成功了，如果为空就重新登录，这个时候Miscellaneous的Continue on error选项就需要被勾选，这样就可以保证每个用户都能成功登录了。

　　Preferences -> Options里面，step timeout caused by resources is a warning设置为yes，这样资源下载失败了就会显示为一个警告，就不会在场景中出现大量的error。

　　Preferences -> Options里面，step download timeout (sec)可以设置的时间长一点，比如说300s，这样就保证了资源下载的时间，资源下载失败的现象也会减少。

　　同时需要在场景的Tools -> Options -> Timeout做一些超时时间限制的调整。

　　如果基本上知道结果输出可能的情况，就可以General->Log设置Send messages only when an errors occurs，也就是仅在错误时候输出日志。如果需要查看所有的日志输出，可以选择Always send messages。

　　5、场景定时运行。有时候可能并不需要场景设置好了马上就执行，而是希望在某个时间点开始。这个时候可以选择场景中的Edit Schedule -> Scenario Start Time，设置为At (HH:MM:SS) on (yyyy-mm-dd)执行。此时需要注意的是，一定要点Start Scenario

　　6、结果文件的命名和保存。场景执行后势必会产生结果文件，结果文件的命名需要规范易于分辨。如上第4点，如果选择Always send messages，那么光日志文件就可能占据很大的空间，把结果文件制作成HTML Report的形式就会节省很大的空间。在Analysis中整理好所需要的结果图表，选择Analysis -> Reports -> HTML Report即可。

　　7、使用多台客户端作为Load Generators。为保证每台机器都能正常连接，各客户端的LoadRunner Agent Process都是开启的，然后在场景开始之前需要先Connect每台客户端。

　　多台客户端机器作为Load Generators时，除了主控机，也就是执行场景的机器，LoadRunner会在各个客户端机器的临时文件夹中生成很大的文件，有的多大10几个G，文件的大小跟场景执行时间成正比。因此场景开始之前，一定要保证各客户机的磁盘空间充足。

　　（三）结果分析

　　个人认为结果分析是一个长期的过程，更应该是一个集体合作的结晶。由于个人知识结构的限制，分析的难免不到位，附上测试报告，仅供分享。

　　此次测试，主要关注了事务的响应时间、吞吐量和服务器的资源占用率等几个方面的指标。

　　1、事务正常运行的时候，如果响应时间曲线持续上升，点击率和吞吐量曲线都在下降，可能表明系统的处理能力在下降。引起该现象的原因可能有：（1）用户数连接未做限制，导致请求数不断上升，响应时间不断变长。（2）出现内存泄露。

　　2、CPU的使用率不断上升，内存的使用率也是不断上升，其他一切都很正常，表明系统中可能产生资源争用。

　　3、 所有的事务响应时间、cpu等指标都很正常，大量的业务失败，可能是由于数据库死锁造成的，也就是说，你在操作一张表或一条记录，别人就不能使用，即数据存在互斥性，当数据量大时，就会出现数据错乱的情况。

　　（四）相关知识

　　性能测试真是一个考验所有相关人员，尤其是测试人员各方面能力的活计。做好性能测试需要具备各方面的知识，不一定全部精通，但至少都要懂一点。专业的测试技能、软件编程能力、网络知识、操作系统、数据库、中间件、行业知识、个人素养等等。

　　在网络方面，测试人员应该掌握基本的网络协议以及网络工作原理。尤其要掌握一些网络环境的配置知识，这些都是测试工作中经常用到的知识。

　　操作系统和中间件方面，应该掌握基本的使用、安装及配置等技能。例如，很多应用系统都是基于Unix、Linux来运行的，这就要求测试人员掌握其基本的操作命令以及相关工具软件的使用。而WebLogic、Websphere等中间件的安装与配置方法也需要掌握一些。

　　数据库知识则是更应该掌握的基础知识。现在的应用系统几乎离不开数据库。因此，不但要掌握基本的安装、配置，还要掌握SQL。测试人员至少应该掌握Mysql、MS SqlServer、Oracle等常见数据库的使用。

　　作为一名优秀的测试工程师，首先要对测试工作有兴趣，因为测试工作在很多时候多少显得有些枯燥。因此，先要热爱测试工作，才能做好测试工作。在个人素养方面，除了具备必须的专业技能和行业知识外，测试人员还应该具有一些基本的品质：专心+细心+耐心+责任心+自信心 ，统称为“五心”。

　　如此看来，要真正的做好性能测试，还有很大一段距离，有差距才有动力，有动力才有进步的空间，加油！

　　尾声：终于接近尾声了，希望这篇文章能给大家带来一点点的帮助。

版权声明：原创作品，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。本文出自qicyt1812的51Testing软件测试博客：http://www.51testing.com/?113838