一、性能测试分类
1、 负载测试load testing：测试系统能达到的峰值指标；
2、 压力测试stress testing：强调在极端条件下系统的稳定性，确定什么条件下系统性能处于失效状态；
3、 容量测试volume testing：数据库最佳容量、最大容量，服务器连接能力等；
4、 配置测试configuration testing：获得不同配置下的性能指标；
5、 基准测试benchmark testing：基于配置测试的调优测试；
6、 并发测试concurrency testing
备注：负载测试、压力测试的区别，举例“
百度查询的响应时间不超过5秒。
负载测试：确认当查询的响应时间不超过5秒时，系统支持的最大并发用户数；
压力测试：确认当系统的最大并发用户数超过多少时，查询的响应时间不可接受（如1分钟）
二、性能测试指标
1、 响应时间：通过事务函数来统计响应时间
2、 吞吐量TPS transaction per second：每秒处理事务/请求/单位数据的数量
3、服务器资源占用：cpu占用率、内存使用率、查询Cache命中率
4、点击数：向webservice发起的http请求书（鼠标点击一次可发多个请求）
三、怎样定性能指标
http://my.oschina.net/dlpinghailinfeng/blog/186161
1、80～20原理：每个工作日中80％业务在20％的时间内完成
2、 估算并发数的公示：
(1) 计算平均的并发用户数： C = nL/T
(2) 并发用户数峰值： C’ ≈ C+3根号C
公式(1)中，C是平均的并发用户数;n是login session的数量;L是login session的平均长度;T指考察的时间段长度泊松分布估算系统的性能目标
一般的做法是把每天访问系统用户数的10%作为平均的并发用户数。最大的并发用户数乘上一个值，2或者3
3、响应时间：
在互联网上对于用户响应时间，有一个普遍的标准。2/5/10秒原则。 也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验。在5秒之内响应客户被认为“比较不错”的用户体验，在10秒内给用户响应被认为“糟糕”的用户体验。如果超过10秒还没有得到响应，那么大多用户会认为这次请求是失败的
另：标准可参考国外的3/5/10原则：
（1）在3秒钟之内，页面给予用户响应并有所显示，可认为是“很不错的”；
（2）在3~5秒钟内，页面给予用户响应并有所显示，可认为是“好的”；
（3）在5~10秒钟内，页面给予用户响应并有所显示，可认为是“勉强接受的”；
（4）超过10秒就让人有点不耐烦了，用户很可能不会继续等待下去；
指标 |
说明 |
| ProcessorTime | 服务器CPU占用率，一般平均达到70%时，服务就接近饱和 |
| Memory Available Mbyte | 可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重 |
| Physicsdisk Time | 物理磁盘读写时间情况 |
Web服务器指标
指标 |
说明 |
| Requests Per Second（Avg Rps） | 平均每秒钟响应次数＝总请求时间 / 秒数 |
| Avg time to last byte per terstion （mstes） | 平均每秒业务脚本的迭代次数 ,有人会把上面那个混淆 |
| Successful Rounds | 成功的请求 |
| Failed Requests | 失败的请求 |
| Successful Hits | 成功的点击次数 |
| Failed Hits | 失败的点击次数 |
| Hits Per Second | 每秒点击次数 |
| Successful Hits Per Second | 每秒成功的点击次数 |
| Failed Hits Per Second | 每秒失败的点击次数 |
| Attempted Connections | 尝试链接数 |
数据库服务器性能指标
指标 |
说明 |
| User 0 Connections | 用户连接数，也就是数据库的连接数量 |
| Number of deadlocks | 数据库死锁 |
| Butter Cache hit | 数据库Cache的命中情况 |
系统的瓶颈定义
性能项 |
命令 |
指标 |
| CPU限制 | vmstat | 当%user+%sys超过80%时 |
| 磁盘I/O限制 | Vmstat | 当%iowait超过40%(AIX4.3.3或更高版本)时 |
| 应用磁盘限制 | Iostat | 当%tm_act超过70%时 |
| 虚存空间少 | Lsps，-a | 当分页空间的活动率超过70%时 |
| 换页限制 | Iostat, stat | 虚存逻辑卷%tm_act超过I/O(iostat)的30%，激活的虚存率超过CPU数量(vmstat)的10倍时 |
| 系统失效 | Vmstat, sar | 页交换增大、CPU等待并运行队列 |
稳定系统的资源状态
性能项 |
资源 |
评价 |
| CPU占用率 | 70% | 好 |
| 85% | 坏 | |
| 90%+ | 很差 | |
| 磁盘I/0 | <30% | 好 |
| <40% | 坏 | |
| <50%+ | 很差 | |
| 网络 | <30%带宽 | 好 |
| 运行队列 | <2*CPU数量 | 好 |
| 内存 | 没有页交换 | 好 |
| 每个CPU每秒10个页交换 | 坏 | |
| 更多的页交换 | 很差 |
四、TPS、响应时间、吞吐量的理解
TPS是衡量服务处理能力的指标；
事务的概念是一个过程中各个环节组成的过程的整体；
用事务的概念来看TPS中的T，一次网络访问中从服务接收到请求（起），到服务完成响应（止）的整个过程就是一个事务；
在这个过程中，可能会包含很多环节，例如服务还需要从另外的数据库服务中获取数据，从其他中间件、网络中获取资源，服务内部的程序逻辑需要做数据处理、计算等等，但无论怎样，这些过程都会包含在请求和响应之间；
服务完成客户端的这样的一个过程就是完成一次事务，单位时间内（通常用秒）服务能完成多少个这样的事务就是TPS，就是衡量服务处理能力的指标。
响应时间可以理解为是用于衡量单次事务所花费的时间，但是也不绝对如此，不同的场景下也会用于衡量单次请求的时间……不论如何都是衡量都是统计单次的。既然是单次的这就有个问题，对于同一个过程，单次的时间也可能不同，所以响应时间又会衍生出最大响应时间，最小响应时间，平均响应时间，90%响应时间等等；
很多时候，吞吐量和TPS可以看做是等价的，都是单位时间里完成任务的数量。但在特定的场景的概念定义又会有些小差别。不同的工具的叫法也不同，Jmeter里就是吞吐量Throughput，貌似没有TPS。
很多概念背后的本质是相同的，只是定义得角度不同，关注得细节不同。山就是那座山，远看成岭侧成峰，人站的位置不同看到的景色也不同。