性能测试分类详解
1、基准测试
基准最简单的理解就是有基础的标准，这样能通过对比发现系统的不同点与变化，一般情况下，基准测试有以下几种应用场景。
1）可以在制定的标准下通过基准测试建立一个性能基准，这样以后当系统的环境、参数发生变化之后，再进行一次相同标准下的测试，即可以看出变化对性能的影响。例如：数据库的基准性能测试
2）系统进行基准测试可以在较早的阶段发现性能问题。例如，对某个系统进行10个用户并发测试时，系统出现了死机现象，那么就没必要进行后续的测试了
3）某系统从来没有进行过任何性能测试，需要对该系统做一次性能评估作为后续开发调优的参考。这是基准测试常见的一种场景，也是大部分没有做过性能测试的公司最需要的。
总结：虽然基准测试不难理解，但实践起来常常被误解。以对某个系统的数据搜索进行性能基准测试为例，这个系统的数据量会随着时间的增长而增长，所以必须频繁地进行基准测试，这样才能准确地把握数据量的增长对系统性能的影响。但因为进行的基准测试又恰恰时在应用程序级别的，并不能可观地反映全局性的性能，所以，比较好的做法是每次修改一个地方，这样就能准确地判断出哪个地方对性能产生影响。
2、并发测试
并发测试可以理解为很多用户按照预定并发请求某个业务或功能时是否出现并发问题。例如：内存泄漏、线程锁、资源争用等，几乎所有的性能测试都会涉及并发测试。并发测试的主要目的是找出并发引起的问题。
并发数计算方法：并发数 = PV / PV Time x 页面连接次数 x HTTP响应时间 x 因数 / web服务器数量
PV 即页面浏览量
PV Time 是 PV 统计时间，换算成秒，一天是 86400s。页面连接次数包括外部的 JS、CSS、图片等，一般为10。HTTP响应时间一般可为1s或更少。引述一般为5。
假设：某官网每天有 6 万 PV，其余参数保持默认，那么推算出来的并发数大致为35。
上面方法仅供阅读，需要根据实际系统特点、业务特点来衡量
3、负载测试
负载测试可以理解为：要测试的业务或系统逻辑的负载范围，然后对其进行测试。它的主要目的是验证业务或系统在给定的负载条件下的处理性能。此外，还要关注响应时间、每秒通过事物数和其他相关指标。
从另一个角度理解，负载测试可以看作是性能测试的一部分，但他们两者的目的是不同的，负载测试是为了发现性能问题，而性能测试是为了获取性能指标。
4、压力测试
可以理解为：没有预期的性能指标，不断加压，看系统什么时候崩溃，依次来确定系统的瓶颈或者不能接受的性能拐点，以获得系统的最佳并发数、最大并发数。例如：压力测试就好比跑马拉松，看你到底跑多久，什么时候坚持不住
压力测试也可以看作是负载测试的一种，即高负载下的负载测试。通过压力测试，可以更快地发现内存泄漏问题，还可以更快地发现影响稳定性的问题。例如在正常负载情况下，某些功能可以正常使用或出错的概率较低，但在压力测试下可能就会很快出现问题。
5、稳定性测试
稳定性测试系统需要长时间运行，在这段时间内观察系统的出错率、性能变化趋势等。进而大大减少系统上线后的崩溃现象。一般都会进行7x24小时的稳定性测试
稳定性测试需要在系统成型后进行，并且没有严重的bug存在
场景设计以模拟真实用户的实际操作为佳
6、失效恢复测试
失效恢复测试重点关注系统出现问题后能否根据预定的策略恢复，且恢复后能否正常运行。
失效恢复测试一般是对具有负载均衡的系统进行，主要为了测试当系统局部发生故障时，是否会对全局产生大的影响，产生的影响是否在可以接受的范围内，以及用户能否继续使用系统。
在实际应用过程中，可以模拟一台或几台负载均衡机器出现故障来进行失效恢复测试，需要注意的是，不仅要关心失效后，用户是否可以正常访问或者恢复后系统是否可以正常工作，也要关注失效后，系统还能支持多少并发用户，以及采用哪些备选方案来快速响应。
7、现网性能测试
所谓现网性能测试，就是在实际网络、实际环境中及进行测试，完全和真实用户一样。当然这样的测试有一定的风险，需要注意以下几点
1）时间段的选择，现网性能测试可能会影响正常用户，所以这样的时间段尽量避开高峰期，选择半夜或者凌晨来进行
2）垃圾数据清理，现网性能测试涉及数据的操作，肯定会带来不少的垃圾数据，这些数据后期一定要清理，为了清理方便，前期数据的设计要有规律可循
3）网络限制，和在内网测试不同，现网的测试如果突然间产生大的数据量，可能会被网络带宽显示，甚至路由会认为是非法数据请求而产生拦截， 所以如果在现网进行测试时，那么压力机需要和被测服务器部署在同一网段机房内，这样可以避免网络限制，最后远程收集数据即可
如果没有特殊情况，尽量不要进行现网测试，风险较大，如果非要进行，一定要事先充分评估风险以及应对的解决的方案，把影响控制到最小。