在性能测试的学习过程中，坚持思想与工具（分开）并行，当前面世面上的性能测试书籍大多把理论与loadrunner融为一体讲解，这样做是正确的，因为有一些性能名词概念也源于工具。但是，性能测试不是loadrunner，所有的作者也是这么认为的。但他们在讲性能测试的时候讲的就是loadrunner有，只是讲的多少不同罢啦。
你是否觉得我对loadrunner有仇？我之所以将其分开来学，只是希望自己在学习性能测试的时候不要被loadrunner局限了而已。只是觉得在做性能测试时不要带loadrunner的思维，这样更容易把握性能测试的本质。
-----------------------------------------------------
性能测试工具，从广义上讲，在性能测试过程中使用到的所有工具都可以称其为性能测试工具。从狭义上来讲，我们可以把性能测试工具分为服务器端性能测试工具与前段性能测试工具。
服务器端性能测试工具也我们测试人员通常所认为的性能测试工具。LoadRunner、JMeter、SilkPerformance、服务器端压力性能工具需要支持产生压力和负载，录制和生成脚本，设置和部署场景，产生并发用户和向系统施加持续的压力。
前端性能测试工具应用比较广泛，开发人员，前端开发人员、测试人员都会经常用到。Firebug 、fildder2、Yslow 、前端性能测试工具只需要关于心浏览器等客户端工具对具体需要展现的页面的处理过程。
服务器性能测试工具原理
性能测试工具的主要作用是通过模拟生产环境中的真实业务操作，对被测试系统实行压力负载测试，监视被 测试系统在不同业务、不同压力性能下的性能表现，找出潜在的性能瓶颈进行分析、优化。
客户端与服务器相当于两个人，通过信息来进行交流。由于初次见面不好意思直接交流，与是找来了中间传话人，客户端把信息告诉给传话人，由传话人来转达给服务器。那么服务器反馈的信息也由传话人转达给客户端。一般性能测试工具都需要录制或编写客户端行为脚本。
这样传达人就有了客户端的行为能力，从而假扮客户端来欺骗服务器，与之进行通信。有了客户端行为了传达人可以进行自我复制。从而变出N多个传达人对服务器进通信。---这个传达人的行为和能力也就是性能测试工具的基本特质。（突然觉得性能工具像第三者插足，而且是可以自我复制疯狂变态的第三者，哈哈！）
对于目前流行的性能测试工具，他们的基本工作原理都是一致的。在客户端通过多线程或多进程模拟虚拟用户访问，对服务器端施加压力，然后在过程中监控和收集性能数据。
性能测试工具应该具备什么的特质呢？
1、工具本身占用系统资源少，可扩展性好，可用性强。
2、能模拟真实业务事务操作，在并发时能真正产生业务压力。（这一点是核心）
3、对压力测试结果能很好地进行性能分析，快速找出被测试系统的瓶颈。
4、测试脚本的重复性强。
服务器性能测试工具的架构
用户行为生成部分
我为什么说的这么朦胧，对于熟悉loadrunner的朋友，我说成虚拟用户脚本生成器，你更容易理解，这个脚本，我们可以录制，也可以手工编写。你不要以为这是生成用户行为的唯一方式。因为在JMeter成中是添加各种组件，通过对组件的配置来完成用户行为的，当然也可以通过录制。而在相对简陋的性能测试工具curl_loader（linux环境下的运行的），他是通过编写配置文件的形式来描述用户形为的。
我前面也有提了，虽然性能测试工具由不同的形式来描述，但他们的原理是一样的，都是通过Proxy方式来实现，具体来说，Proxy作为客户端和服务器之间的中间人，接收客户端的数据包。
压力产生器
压力产生器用于根据脚本内容产生实际的负载，在性能测试工具中，压力产生器扮演着“产生负载”的角色。也就根用户的设置，进行自我复制来生成多个客户端向服务器发送请求。对于工具来说，每复制出来的一份就是一个进程或线程，进程和线程的运行是要占用系统资源的。所以，对一台压力测试机来说能运行的虚拟用户数也是有限的。根基测试机的配置而定。那么这个时候就要通过多台测试机合作，来模拟更多的虚拟用户向服务器发请求。
那么，对于性能测试来说，很重要的一点就是产生“并发”的请求，不然就不会对服务器产生压力。那多台机子如何产生“步调一致”的虚拟用户呢？使用“用户代理”
用户代理
用户代理是运行在负载机上的进程，该进程与产生负载压力的进程或线程协作，接收调度系统的命令，调度产生负载压力的进程或线程，从这个意义上看，用户代理也是压力产生器的一部分。
调度能力
我们在做复杂的性能测试时，常常会设计各种场景，不同的虚拟用户数，不同事务的用户比例，运行时间，设置同步点等，这个时候也需要我们的测试工具有压力调度能力。从而才能更真实的模拟我们所设计的运行场景。
监控系统
监控系统是性能测试工具直接与用户进行交互的主要部分，监控系统，主要用户在压力测试过程中对各种软硬件进行监控，如对数据库、应用服务器，服务器的主要性能表现情况进行监控。用于判断系统当前处于什么状态。
当然，监控系统不是性能工具必须的部分，可以通过软硬件系统自身的监控工具或者第三方监控工具进行监控。但是否有强大的性能计数器监控系统是衡量性能测试工具是否强大的指标之一。
压力结果分析
压力结果分析工具可以用来辅助进行测试结果的分析，性能测试工具一般都能将监控系统获取的性能技术数器值生成曲线图，折线图等各种图表。通过展现性能测试过程中的各种参数指标，来供测试人员进行分析。
但这里需要强调的是，压力结果分析工具本身不能代替分析者进行性能结果分析，而只是提供多种不同的数据揭示和呈现方法而已。对于这些数据进行分析必然要依靠测试工程师对系统性能分析的知识和经验。
-------------------------------------------------------
对上面介绍的性能测试工具架构的组成部分，不是第一个性能测试工具都具备，而所具备的强大程度也不相同。比如，有些性能测试工具不具备用户代理能，有些监控系统能监控的资源很有限或简陋，有些结果分析数据的呈现不够详尽等。
一：性能测试工具模型
广义地说，性能测试工具是指性能测试过程中使用到所有工具，但是我们习惯上把“性能测试工具”定位于LoadRunner、SilkPerformer一类的工具。
关于性能测试的几个误区：
1、认为性能测试就是使用性能测试工具进行测试。
性能测试工具只能帮助你实施性能测试，并不能帮助你完成性能测试的需求、设计和分析。
2、认为性能测试工具可以完成性能测试结果分析工作。
性能测试工具只是能够根据你的要求以各种方式提供报表，这些报表可以被您用来分析系统性能状况。
3、不清楚性能测试工具的录制/回放与功能测试工具的录制/回放的区别。
功能测试工具的录制/回放一般是针对GUI的操作录制，脚本中记录的是用户对控件的操作，例如按下了“确认”按钮或是在“姓名文本框”中输入了ABCD等内容，这时因为功能测试工具主要是通过操作和数据来验证功能的正确性，评价的主要标准是GUI的正确性（界面内容的正确性）。而性能测试工具录制的是服务端和应用之间的通信数据，而不是应用的GUI操作。^_^^_^理解了这一点，就不难明白为什么在进行性能测试脚本录制的时候，需要首先选择录制的协议了。
4、不清楚何时选择何种协议。
选择何种协议取决于应用和客户端之间的通信协议。
二：性能测试工具架构
1、虚拟用户脚本产生器（Virtual User Generator）：通过一个Proxy作为客户端和服务器之间的中间人。
2、压力产生器(Player)：压力器扮演着“产生负载”的角色。
3、用户代理(Agent)：运行在负载机(LoadMachine)上的进程，该进程于产生负载压力的进程或是线程写作完成“产生负载”的功能。如一台PC可以顺利运行200个左右的VU，但对需要1000个VU的情况显然很难指望一台PC，这时就需要通过多台及其进行协作，“用户代理“就帮助产生”步调一致“的VU。
4、压力调度和监控系统(Conductor)：直接与用户交互的主要内容，压力调度可以根据用户的场景要求，设置各种不同脚本的VU数量，设置同步点等，而监控系统则可以对各种数据库，应用服务器、服务器的主要性能计数器进行监控。
5、压力结果分析工具(Analysis)：用来辅助进行测试结果的分析。
三：性能测试脚本录制时的协议类型
^_^^_^不要想当然地根据开发语言来决定协议的选取，这样子极有可能导致录制后的脚本不能回放成功。
几点说明的内容：
1、使用Socket协议可以对任何类型的应用通信进行录制，但这种录制生成的脚本很可能没有任何意义。
2、在对应用间的通信进行录制生成脚本后，对脚本进行回放，有时会出现回放无法继续的情况（停留在某个步骤无法进行下去），此时应该考虑是否使用了合适的协议。
——————————————协议选择参考方案——————————————————————
1、Web应用：应用特点：采用J2EE或是dontNet结构，HTTP/HTTPS协议。
2、C/S应用：
a、客户端程序以ADO、OLEDB方式连接后台数据库，选择后台数据库类型选择相应的协议。
b、客户端程序以ODBC方式连接后台数据库，ODBC协议。
c、其他协议，根据具体协议类型进行分析。
3、组件：a、COM/DCOMcom/dcom协议。
b、EJB，EJB协议。
4、服务：
a、WebService，WebService协议。
b、Mail服务器，SMTP/POP3协议。
c、FTP服务器，FTP协议。
5、应用服务器：
a、OracleApplicationServer,OracleApplicationServer协议。
b、SAP，SAP协议。
c、Tuexdo,Tuexdo协议。
四：性能测试工具的选择与评估
这个问题通常会有两个层面的意义：第一，创建还是购买？第二，如果购买，如何选择一种商业工具？
1、创建还是购买？
总而言之，”购买“的方式可以以较低的总体成本快速获得可用的软件，但如果被测试对象本身有一定的特殊需求，最好使用”创建“的方式构建适合的测试工具。
2、测试工具的评估和选择过程。
（1）列出需要的工具功能列表
（2）工具比较
（3）成本分析