*本文转自虫师的博客：http://www.cnblogs.com/fnng/archive/2011/11/15/2250445.html

本文仅用于收藏学习，如有侵权。立删~

最近群里来了很多新朋友，大都是新做测试或准备做测试工作的，见好多新来上来就问关于LoadRunner的使用上的问题。对性能测试的理解也不是太清楚。公司说让他们对系统做个性能测试，他们听说LoadRunner是做性能测试的，在网上找了点了LoadRunner的使用说明就开始对系统下刀了。对于一些大公司的专业性能测试人员来说，这个很可笑，但这是种情况是存在的，我当初也到公司时也这么干的。

那时还真把性能测报告给整出来了，现在看来那报告没有任何意义。虽然，虽然对现在的我来说性能测试也只是只懂皮毛。但还是希望通过我这篇文章能让那些新手们对于性能测试有个入门的了解。

----//理发店模式

关于理解性能，记得我那时是看了“《LoadRunner没有告诉你的》之三—理发店模式”不管你有没有看过，我这重提一下理发店模式。

前提：

1. 一个理发店有三位理发师傅

2. 每位理发师傅理一个发需要一小时

3. 顾客都很忙，从进理发店起最多只等三小时（等待时间+理发时间），如果三小时后还没轮到自己理发，立马走人。

   思考：

   这里我们来理解“最佳用户数”和“最大用户数”。

最佳用户数：

    理发店的最佳状态，理发店收入最多（理发师傅没有休息时间，一直在理发），顾客满意度最高（顾客随时到随时理，无需要等待）。在一个时间点来说，三个理发师傅服务于三位顾客，那么这个最佳用户数是三。

最大用户数：

理发店的最大承受状态，理发店收入最多（理发师傅没有休息时间，一直在理发），顾客的最大忍耐度（来的顾客等待+理发需要等上三个小时）。

假如理发店生意非常好，早上一开门一下子来了一群顾客（很多），A、B、C三位顾客先理，D、E、F顾客需要等待一小时才能得到理发师傅的服务，G、H、I三位顾客等待了两小时才得到服务，后面排队的J、K、L…..等顾客，已经等了三小时还没得到服务，因为这已经得达到了他们等待的极限，所以后他们气愤和无奈离开。

当然，理发店还会不断的来新的顾客，不断有等了三小时而没有得到服务的顾客离开，但对于理发店而言，他们在一个时间点上，能服务的最大用户数是九（三位正在接受服务、三位已经等待一小时，三们已经等待两小时）。

对于最大用户数，需要注意的两点：

1. 在理发店里很大，可以容纳很多位顾客（大于9），总有一部分在这里等待了三小时而没有得到服务离开，不要把等待了三小而没有得到服务的顾客纳入最大用户数里。

2. 假如理发店很小，最多只能容纳六位顾客，当第七个顾客来时，虽然，我们知道他只需要等待两小时就可得到服务（这个时间是他可以接受的等待时间），但由于理发店容量有量，这第七个顾客只有改天再来了。

关于理发店原理，详细请浏览http://www.cnblogs.com/jackei/archive/2006/11/20/565527.html 

     不知道通过上面对理发店的分析，你对性能有了一些眉目。假如理发店相当于我们的系统的话，顾客就我们向服务器所发送的请求，最佳用户数和最大用户数是我们衡量一个系统的处理能力的一种方法。

----//要帐的模式

注：上图是自己找来修改的，凑合着看吧！呵呵

这个是我在给一朋友说浏览器与服务器之间交流时用到的例子，感觉比容易理解，所以拿来分享一下。

   假设：

  1.  A、B、C三个人。

  2.  C欠A钱（这里不考虑多少）

  3.  B是专门要账

   思考：

浏览器与服务器的信息传递次数：

   A对B说，C欠我钱，你帮我去要。B接到指令后就去找C要钱。

   B对C说，给我20块钱。

   C说，没有。

   B对C说，给我10块钱。

   C说，没有。

   B对C说，给我5块钱。

   ………

   最后，B回来对A说，哎呀妈呀，C那丫的忒抠门了，一分钱没有。

   对于A来讲，只是来说，它只是让B问C要钱，具体的B与C之间交互了几次，A是不知道的，它所知道的就是B返回给它的结果，C一分钱没有。

   浏览器与服务器传递数据的大小：

   还是上面的过程，A对B说，C欠我钱，你帮我去要。B接到指令后就去找C要钱。

   B对C说，给我20万块钱。

   C说，没问题，没支票，只有1元硬币。

   ……….

   B终于把钱拿回来给A。A很纳闷，怎么去了那么久，B委屈的说，丫的，C给我整了一堆硬币，太重了，路上走的慢，都快累死我了。

   对于A来讲，只是来说，它只是让B问C要钱，谁知道C给的是支票还是硬币。所以，B去要钱消耗的时间就很长。

   所以，要想提高浏览器对服务器的访问速度，应该减少数据传递次数与数据传递的大小。

这样就很自然的引出了浏览器的cookie 

   A在C哪里存了5毛钱。

   A对B说，我在C哪里存了5毛钱，你去拿来我看看。B跑去问C要了5毛钱回来给A看。

  过了一会，A又对B说，我在C哪里存了5毛钱，你去拿来我看看。B跑去问C要了5毛钱回来给A看。

  过了一会，A又对B说，我在C哪里存了5毛钱，你去拿来我看看。这次C烦了，对B说，你把钱放自己口袋里吧，等A要的时候，你来问我5毛的人民币有没有改版，没有改版的话，你就直接把口袋里的5毛钱给A看就行了。

  在这里A就相当于我们用户，B相当于浏览器，C是服务器。而cookie就是B的口袋，当然了cookie的用处还很多。比如我们登陆一个系统，提示我们是否保存密码（有的还有期限比如，一个星期或一个月），如果我们保存了，下次再访问登陆时，浏览器就已经帮我们填写好了账户密码或直接帮我们登陆。那这个账户密码就放在我们浏览器的cookie中。

   为什么要说上面的例子呢？因为我们大部分的一部分性能测试是基于B/S架构系统的，理解了浏览器与服务器之间的数据传递，有助于我们理解性能测试。

----//在开始性能测试之前，我们需要知道什么?

     当客户或老板把你叫来，对你说，去给我们系统做个性能测试，千万别傻傻的说“好！”然后，就走了，我以前这么干过（那时不懂，打肿了脸充胖子），回到座位后，不知从何下手了。

   那么，我们需要知道什么呢？

 1. 性能测试的目的

  首先要知道客户的要求。

  我把性能测试按目的分以下几种

   1）客户有明确要求

   这是一个好的结果，这说明客户对性能测试有一定的了解，知道他们需要的系统要达到一个什么样的标准。如：系统要求同时满足100用户登陆，平均每个用户登陆时间不能超过5秒。这个需求很明确，当然也不排除一些不懂装懂的用户，提一些不现实的要求。

   不管怎么说，用户提要求了，这个比较容易，你可以对现系统做一次性能测试，至于，是通过优化系统还是增加硬件设备才能达到要求。就不是我们考虑的问题了。

   2）只是想知道目前系统性能（容量测试）

   可以把我们的目的就是求得最大用户数和最佳用户数。但是，这仍然是比较含糊的一个需求，我们需要对系统做出分析，找出系统的压力点。

   3）找出系统性能瓶颈

   这个同样需要分析可能对系统造成瓶颈的逻辑业务，然后才能进行性能测试。

   4）了系统在长时间的压力下性能状况（强度测试）

   这个一般验证系统的稳定性，因为系统一旦上线，就有可能会长期处在大用户的访问状态，可能以前没发现的一些问题就会暴漏出来。比较典型的就是内存溢出。

 2. 性能测试的环境

  确定了我们的测试目的，当然需要测试环境。这里的环境，我们需要考虑一下几点

  1）硬件环境

我们需要了解被测服务器硬件配置，用于加压客户端的机子配置，CPU 内存  等

  2）软件环境

   我们需要了解被测系统的架构，前端、中间件、服务器（这里指运行系统软件服务器，如tomcat）、数据库，以及他们的部署位置。

   用于加压的客户端采用什么性能测试工具进行加压。

  3）网络环境

   网络环境很重要。在上面的几个目的中，除了找出系统性能瓶颈可以在广域网进行，因为这个目的可以不用设置太多的虚拟用户，只要找出系统哪个地方影响了整个系统的性能就行。 

   其他目的的测试都需要在，局域网进行，不然你压力工具所发送的请求都会卡死在网络的传输过程中。

  3. 寻找系统的压力点

  我们需要对系统的哪个页面或业务进行加压。这个不是自己想出来的，需要与开发人员的沟通。系统的首页？系统的登录？还是系统的交易过程？各个业务的用户比例是多少？

  只有获得有效的性能需求，才容易寻找和定位压力点。

  获得有效的需求：http://www.cnblogs.com/jackei/archive/2006/12/12/589473.html

如果上面的几点，你都很清晰了，那么打开你的性能测试工具开始录制（或编写）你的性能测试脚本吧！

 学习链接：

《LoadRunner 没有告诉你的》之一——描述性统计与性能结果分析

《LoadRunner 没有告诉你的》之二——描述性统计与性能结果分析（续）

《LoadRunner 没有告诉你的》之三——理发店模型

《LoadRunner 没有告诉你的》之四——理解性能

《LoadRunner 没有告诉你的》之五——无所不在的性能测试 (已完稿)

《LoadRunner没有告诉你的》之六——获取有效的性能需求