目的
性能测试更加关注系统的性能表现，也就是 How fast 和How much。而做性能测试就是排除系统瓶颈，使得它表现得更好、更霸气。可以从以下几个方面来理解。
1）评估当前系统。系统未做过任何性能测试，对系统的当前性能情况不了解，就好像没有体检过就不知道自己的身体状况一样。
2）寻找瓶颈，优化性能。常见的现象为，某业务操作响应时间很长、某系统上线一段时间后运行越来越慢，这些都需要逐步分析定位并调优。
3）预测未来性能。当用户数和业务量增加时能否及时应对？如何调整？是增加应用服务器，还是数据库服务器？还是要优化代码逻辑？这一系列问题都值得我们深思，这也是性能测试的目的所在。
解决一个性能瓶颈，往往又会出现另外的瓶颈或者其他问题，所以性能优化更加切实的目标是做到在一定范围内使系统的各项资源使用趋向合理和保持一定的平衡。
性能测试与系统的关系
现有的系统大致分为单机系统、C/S、B/S。这 3 类系统都应该进行性能测试，只是每个分类有各自特点，在实际测试中应该有不同策略进行应对。
一般 C/S 架构的应用程序更关注于系统资源使用情况、数据库性能以及运行的配置要求等。例如，内存、用户连接数、数据库死锁、数据库 cache 命中率、运行的最低配置等。
而对于 B/S 架构的应用程序，会关注 Web 服务器的相关指标，如每秒点击数、吞吐量、尝试连接数、事务成功率等。
性能测试关键指标
【系统指标】
并发用户数
1) 系统用户数：简单地说就是该系统的注册用户数。
2) 在线用户数：即登录系统的用户。在线用户并不一定都会对服务器产生压力，因为有的用户登录后什么都不干。
3) 并发用户数：是对服务器产生压力的用户。广义上指向服务器发出数据请求的用户，而不管请求是否为同一操作；狭义上指向服务器发出同一数据请求的用户。
平均并发用户数的计算：C=nL / T
说明：其中C是平均的并发用户数，n是平均每天访问用户数（login session），L是一天内用户从登录到退出的平均时间（login session的平均时间），T是考察时间长度（一天内多长时间有用户使用系统）。
并发用户数峰值计算：C^约等于C + 3*根号C。
其中C^是并发用户峰值，C是平均并发用户数，该公式遵循泊松分布理论。
响应时间
在没有缓存的情况下，一次完整响应的响应时间=N1+N2+N3+N4+T1+T2+T3+T4。其中包括发出请求、DNS解析、连接服务器、服务器响应、数据处理、页面渲染、网络传输时间等。
在有缓存的情况下，响应时间会相对减少很多，包括数据处理，页面渲染等。
响应时间的标准：2-5-10。
详见：http://www.cnblogs.com/snifferhu/p/4149072.html
思考时间
思考时间就是用户进行操作时，每个请求或者操作之间的间隔时间，是为了更加真实地模拟用户的操作场景。
0思考时间是否可取？答案是分场景而论，如果想了解系统的最大承受能力或者极端情况下系统的性能表现，则可以设置0思考时间。但如果是预估系统的性能，就应该最大可能地模拟真实思考时间。一般都会加上思考时间，只是在分析时要去掉思考时间。
TPS
TPS是每秒能够处理的事务数（事务：用户一步或者几步操作的集合）。直接反映系统性能的指标，该值大时，系统性能会比较好，当然每个系统都有它的上限，不可能无限大。
Hit/s 每秒点击数
每秒点击数代表用户每秒向 Web 服务器提交的 HTTP 请求数。
但这里需要注意的是提交一个登录请求，对于用户来说感觉是一个请求，但对于后端服务器来说也许是多个请求，所以点击一次不代表就是一个请求。例如，点击一个链接，该操作返回的页面上有 6 张图片，因为下载每张图片都需要一个 HTTP 请求，所以这个页面下载完成之后的点击数应该是 7。
每秒点击数从侧面可以反映客户端的状况，每秒点击数不正常，一般可能是网络问题或者脚本问题导致，需要进一步具体分析。
吞吐量
吞吐量指单位时间内系统处理用户的请求数。
当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：F=(Vu * R) / T；其中F为吞吐量，Vu表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间。
【资源指标】
CPU：http://blog.csdn.net/gzh0222/article/details/12505273
内存
数据从内存中读取要比从磁盘上读取速度快，而内存经常发生内存泄露或内存溢出的现象，是需要重点留意的。不过这里需要注意，短时间的可用内存越来越少，不代表一定有内存泄露或溢出。
I/O
与磁盘的交互，重点关注交换频率和磁盘队列长度。
网络
重点关注网络的流量，看是否存在网络带宽的瓶颈。