1.基准测试算法
基准最简单的理解就是有基础的标准，这样能经过对比发现系统的不一样点与变化。通常状况下，基准测试有如下几种应用场景。数据库
1）能够在制定的标准下经过基准测试创建一个性能基准，这样之后当系统的环境、参数发生变化以后，再进行一次相同标准下的测试，便可看出变化对性能的影响。例如，数据库的基准性能测试。服务器
2）系统进行基准测试能够在较早的阶段发现性能问题。例如，若是对BestTest网站进行10个用户并发测试时，系统出现了死机的现象，那么就没有必要进行后续的测试了。网络
3）某系统历来没有进行过任何性能测试，须要对该系统作一次性能评估做为后续开发调优的参考。这是基准测试常见的一种场景，也是大部分没有作过性能测试的公司最须要的。并发
虽然基准测试不难理解，但实践起来经常被误解。以对某个系统的数据搜索进行性能基准测试为例，这个系统的数据量会随着时间的增加而增加，因此必须频繁地进行基准测试，这样才能准确地把握数据量的增加对系统性能的影响。但由于进行的基准测试又偏偏是在应用程序级别的，并不能客观地反映全局性的性能。因此，比较好的作法是每次只修改一个地方，这样就能准确地判断出哪一个地方会对性能产生影响。负载均衡
2.并发测试性能
并发测试能够理解为不少的用户按照预约的场景并发请求某个业务或功能时是否出现并发问题。例如，内存泄露、线程锁、资源争用等，几乎全部的性能测试都会涉及并发测试。并发测试的主要目的是找出并发引发的问题。测试
那并发数又如何肯定呢？小白经过查找资料得知，通常能够经过如下几种方法推算须要的并发数。网站
1）并发数=PV / PV Time×页面链接次数×HTTP响应时间×因数/ Web服务器数量。线程
其中，PV Time是PV的统计时间，换算成秒，一天是86 400s。页面链接次数包括外部的JS、CSS、图片等，通常为10。HTTP响应时间通常可为1s或更少。因数通常为5。
假设，BestTest官网天天有6万PV，其他参数保持默认，那么推算出来的并发数大体为35。
PV（page view）即页面浏览量。一个用户有可能创造十几个甚至更多的 PV。它是目前判断网站访问流量最经常使用的计算方式，也是反映一个网站受欢迎程度的重要指标之一。
2）著名的经典理论80-20原则。
3）参考段念老师在《软件性能测试过程详解与案例剖析》一书中提到的估算方法。
固然，上面的方法仅供参考，须要根据实际的系统特色、业务特色来衡量。
3.负载测试
负载测试能够理解为肯定所要测试的业务或系统的负载范围，而后对其进行测试。它的主要目的是验证业务或系统在给定的负载条件下的处理性能。此外，还要关注响应时间、每秒经过事务数和其余相关指标。
从另外一个角度理解，负载测试能够看做是性能测试的一部分，但它们二者的目的是不一样的，负载测试是为了发现性能问题，而性能测试是为了获取性能指标。由于在性能测试过程当中，也能够不调整负载，而是在一样负载状况下经过改变系统的结构、算法、硬件配置等来获得性能指标。
4.压力测试
压力测试能够理解为没有预期的性能指标，不断地加压，看系统何时崩溃，以此来肯定系统的瓶颈或者不能接受的性能拐点，以得到系统的最佳并发数、最大并发数。仍然以生活中的例子来讲明，压力测试就比如跑马拉松，看你到底能跑多久，何时就坚持不住了。
压力测试也能够看做是负载测试的一种，即高负载下的负载测试。经过压力测试，能够更快地发现内存泄漏问题，还能够更快地发现影响系统稳定性的问题。例如，在正常负载状况下，某些功能能够正常使用或者出错的几率比较低，但在压力测试下可能很快就会出现，帮助咱们提前发现性能问题。
小白想起，公司以前有个网站，在用户少的时候没有什么问题，但在用户多时就暴露出了一些问题，常常会有异常报错产生。看来公司的网站真的须要进行性能测试来评估了，小白内心暗想。
负载测试与压力测试的概念并不是彻底独立，读者大可没必要纠结于文字概念。在实际应用中通常两者都是相互结合、相互补充的。
5.稳定性测试
稳定性测试顾名思义重点在于“稳定”二字，要想知道系统稳定的状况，就须要长时间运行，在这段时间内观察系统的出错概率、性能变化趋势等。进而大大减小系统上线后的崩溃等现象。通常都会进行所谓的7×24小时的稳定性测试。
但稳定性测试也有和其余分类不同的地方，这里须要强调如下两点。
1）通常稳定性测试须要在系统成型后进行，而且没有严重的Bug存在。
2）场景的设计以模拟真实用户的实际操做为佳。
6.失效恢复测试
失效恢复测试重在关注系统出现问题后可否根据预先制定的策略恢复，且恢复后可否正常运行。怎么理解呢？很简单，以跑马拉松为例，为了预防出现跑不动的状况，预先准备了一瓶红牛（应该给我广告费），当选手累得躺下后，拿出这瓶红牛一口气喝了，而后你有力量了，恢复了原来的状态，站起来继续跑。这下理解了吧。
不过失效恢复测试通常是对具备负载均衡的系统进行的，主要是为了测试当系统局部发生故障时，是否会对全局产生大的影响，产生的影响是否在能够接受的范围内，以及用户可否继续使用系统。
在实际应用过程当中，能够模拟一台或几台负载均衡机器出现故障来进行失效恢复测试，但须要注意的是，不只要关心失效后，用户是否能够正常访问或者恢复后系统是否能够正常工做，也要关注失效后，系统还能支持多少并发用户，以及采用哪些备选方案来快速响应。
小白学到这里也明白了原来性能测试中须要关注许多点，既要有对某个点的思考，也要有扩展点的思考，不然容易遗漏或得出片面的结论，而不能从根本上来预防解决问题。
7.现网性能测试
所谓现网性能测试，就是在实际网络、实际环境中进行测试，彻底和真实用户同样。固然这样的测试有必定的风险，须要注意如下几点。
1）时间段的选择。现网性能测试可能会影响正经常使用户，因此这样的时间段要尽可能避开高峰期，选择半夜或者凌晨来进行。
2）垃圾数据处理。若是现网性能测试涉及了写数据的操做，那么确定会带来很多的垃圾数据，这些数据后期必定要清理，为了清理方便，前期数据的设计要有规律可循。
3）网络限制。和在内网测试不一样，现网的测试若是忽然间产生大的数据量，可能会被网络带宽限制，甚至路由会认为是非法数据请求而产生拦截等。因此若是在现网进行性能测试，那么压力机须要和被测服务器部署在同一个网段机房内，这样能够避免网络限制，最后远程收集数据便可。
若是没有特殊状况，尽可能不要进行现网的性能测试，风险比较大，若是非要进行，必定要事先充分评估风险以及应对的解决方案，这样出了问题能够快速响应，把影响控制到最小。
转至：http://book.51cto.com/art/201502/465236.htm