性能测试工具的主要作用是通过模拟生产环境中的真实业务操作，对被测试系统实行压力负载测试，监视被 测试系统在不同业务、不同压力性能下的性能表现，找出潜在的性能瓶颈进行分析、优化。 客户端与服务器相当于两个人，通过信息来进行交流。由于初次见面不好意思直接交流，与是找来了中间传话人，客户端把信息告诉给传话人，由传话人来转达给服务器。那么服务器反馈的信息也由传话人转达给客户端。一般性能测试工具都需要录制或编写客户端行为脚本。 这样传达人就有了客户端的行为能力，从而假扮客户端来欺骗服务器，与之进行通信。有了客户端行为了传达人可以进行自我复制。从而变出N多个传达人对服务器进通信。—这个传达人的行为和能力也就是性能测试工具的基本特质。（突然觉得性能工具像第三者插足，而且是可以自我复制疯狂变态的第三者，哈哈！） 对于目前流行的性能测试工具，他们的基本工作原理都是一致的。在客户端通过多线程或多进程模拟虚拟用户访问，对服务器端施加压力，然后在过程中监控和收集性能数据。
性能测试工具应该具备的特质： 1、工具本身占用系统资源少，可扩展性好，可用性强。 2、能模拟真实业务事务操作，在并发时能真正产生业务压力。（这一点是核心） 3、对压力测试结果能很好地进行性能分析，快速找出被测试系统的瓶颈。 4、测试脚本的重复性强。
前后端对比： Web应用的基础是超文本传输协议（HTTP）和超文本标记语言（HTML），HTTP协议本身是一种面向非连接的协议，HTML语言则是一种用于制作超文本文档资料的简单标记语言。 对于一个页面而言，“请求”和“返回数据”都可能是多次发生的。这个我在《在做性能测试之前需要知道什么》一文中举了一个简单的例子来讲解。由于HTTP对浏览器下载资源并发请求数量、Cache等方面都进行定义和限制，以及浏览器对于HTML的处理过程。完全可以说，用户所以感受的响应时间中的相当大的一部分并不完全取决于应用的后台处理所需要的时间，而取决于web应用的前端。在yahoo中，到少50个团队通过纯粹的前端性能相关的技巧，将最终用户的响应时间减少了25%以上。 HTTP是一个属于应用层的面向对象的协议，用于传送WWW方式的数据，采用请求\响应模型，客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本，以及包含请求修饰符、客户信息和内容的类似于HTML的消息结构。服务器以一个状态行作为响应，响应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息，实体元信息以及可能的实体内容。 HTML是一种用于制作超文本文档资料的简单标记语言，用HTML编写的超文本文档能够独立于各种操作系统平台。从诞生开始，HTML语言就一直被用于描述web页面格式设计，使用HTML语言描述的文件需要通过WWW浏览器显示效果。
下面用两种方式来对比较两种测试响应时间的差别 Apache benchmark 简称ab ，是非常有名又小巧的压力测试工具。 下载安装apache web server 安装或解压之后，在bin\目录下有个ab执行文件。 打开运行–cmd 打开命令提示符，定位到bin\目录下。 基本用法： ab -c [并发用户数] -n [发送请求数] [被测试页面的URL] 设置一个用户一个请求，对百度首页加压：
从上表中我们可以看到请求的总字节数为8024字节；响应时间为0.173 秒，也就是下面显示的173.010毫秒。
Firebug非常有名的debug工具，firefox浏览器最得意的集成工具。 在firefox浏览菜单栏“工具”—添加组件—搜索firebug下载安装重启浏览器。 同样对百度首页的访问：
从上面图中看到请求的大小为10KB；响应时间1.4秒。清楚的发现这数据可以远远大于ab工具所得到的数据。仔细观察发现，firebug给出的数据，访问 网址时，客户端（浏览器）和应用之间的数据交互并非1次，而是5次。 我们再分析其中的一个请求，firefox给出的的图形中，有红色和蓝色两种颜色的线条。蓝色表示到此刻发生了DOMContentLoaded事件。红色线条表示onload事件被触发。DOMContentLoaded事件W3C推荐的标准事件，它发生在页面的DOM树建成时，而onload则发生在页面所有的资源（图片文件、CSS文件、js文件等）都被下载完成后。 从上图的右下角，我们会得到两个响应时间，1.41秒是onload事件被触发的时间，前面的1.4秒则是页面的所有请求都返回所需要的总时间。那么哪个时间才是用户感受到的响应时间呢？准确的说，两个都不是。用户的感受是个不确定的状态，取决于页面本身的类型以及呈现手段。如果某页面仅为用户提供阅读信息，一旦页面上开始出现可供阅读的内容，用户就开始阅读了。那么，用户认为响应时间就是发出请求到页面上出现可阅读信息。如果页面存在大量的交互内容，需要用户填写或在页面上进行拖拽等操作，在这种情况下，只有当页面的所有元素都被下正确的呈现出来，所有的js文件都已经执行完成后，用户才会感受到这个页面已经就绪。 Web前端性能的研究并不是为了准确地得到一个响应时间数据，实际上，根据friebug图表的结果，web性能一部分取决于web服务器和应用服务器（建立连接，下载连接），别一部分取决于浏览器的实现机制、web页面上的js的执行等。取决于web服务器和应用服务器的响应时间与服务器的负载、压力等相关；而取决于浏览器实现机制与js文件执行所需要的时间则几乎与服务器端的负载和压力无关。那么web端的响应时间也是总响应时间的一部分，那么有必要web端的性能进行了解。 那么前端性能这么见效，为什么还要去做后端性能测试呢？因为他们关注点不同，前端性能关注单个用户的感受。后端性能关注是更多用户访问系统时，服务器能更稳定、更快的处理用户发来的请求。一个强大的后台是前台的基础。
前端:
性能测试一直是 Web 应用中非常受关注的部分。目前大多数人对性能的关注还主要集中在服务端，大部分人在说到“性能测试”的时候，都会把重点放到服务端的性能测试和调优，也就是通过各种方法找到服务端的性能瓶颈并尝试对其进行调优。但实际上，对于 web 应用来说，除了考虑服务端在足够短的时间内返回页面数据之外，还可以从页面 前端 的角度来考虑性能测试和性能调优。
在线网站类： WebPageTest 说明： 在线的站点性能评测网站，地址 补充： 其实这网站也是个开源项目，所以支持自己搭建一个内部的测试站点
我知道有一种爱情，叫做与你白头，有一种幸福，叫做和你相伴。
