性能测试顾名思义，测试服务（web服务，数据库服务，其他网络应用服务，本地服务）的性能如何？如何衡量性能？表面的无非是看能支撑多少个用户同时使用该服务。且关注用户使用过程中的用户体验。

　　Transactions per Second（每秒通过事务数）

　　“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。

　　将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。

　　例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。

　　Average Transaciton Response Time（事务平均响应时间）

　　“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。

　　例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。

　　通常web服务还需要关心如下点：

　　Hits per Second（每秒点击次数）

　　“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。

　　通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。

　　性能测试工具一般都会根据实际测试的场景和结果，画出tps，average response time，点击率等曲线图表。 同时还会算出其他一些非常参考意义的数值和图表。

　　1、当压力加大时，TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。

　　解析：tps曲线为什么会变平坦？因为系统处理事务的线程数往往是固定的一个数值。（一般是由程序设定或者服务器配置决定），假设响应时间是固定的一个值时，那么每秒中系统能够处理的事务数是固定的数值。不会因为压力的增大，TPS也会一直增大。实际上，响应时间并不是一个固定的值，而是随着压力变大，响应时间往往会增加。那么，实际上，系统大的TPS值，往往会比根据基准值估算出来的TPS要小。

　　2、当压力加大时，点击率曲线变化缓慢或者平坦，很有可能是服务器开始出现瓶颈。

　　解析：在web服务测试当中，点击率和模拟的用户数是能够反映出服务压力的大小。当压力变大时，事务的响应时间变长，则导致点击率会受到响应时间的影响，不会因为用户增多，而增加。点击率在服务器出现瓶颈时，压力的增加不会增加点击率。

　　3、事务平均响应时间增长

　　解析：事务平均响应时间增加，必然是指服务器性能有所下降。服务器压力的加大，是主要原因。

　　a）压力增大到每秒钟事务的请求数，超过了系统每秒处理事务占用的线程数。这时，一些事务开始排队。排队的事务请求的响应时间必然大于之前的平均响应时间。