性能测试、负载测试、压力测试的区别

性能测试、负载测试、压⼒测试的区别
性能测试（Performance Testing）：是通过⾃动化的测试⼯具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进⾏测试。

负载测试和压⼒测试都属于性能测试。

通过负载测试，确定在各种⼯作负载下的系统的性能，⽬标是测试当负载逐渐增加时，系统各项性能指标的变化情况。

压⼒测试是通过确定⼀个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最⼤服务级别的测试。

负载测试（Load Testing）：是模拟实际软件所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟⽤户的数量）或其他加载⽅式来观察不同负载下系统的响应时间和数据吞吐量、系统占⽤的资源（CPU、内存等），以检验系统的⾏为和特性，以发现系统可能存在的性能瓶颈，内存泄漏，不能实时同步等问题，负载测试更多的体现了⼀种⽅法或⼀种技术。

压⼒测试（stress testing）：在强负载（⼤数据量、⼤量并发⽤户等）下的测试，查看应⽤系统在峰值使⽤情况下的操作⾏为，从⽽有效地发现系统的某项功能隐患，系统是否具有良好的容错能⼒和可恢复能⼒。

压⼒测试可分为⾼负载下的长时间（如24⼩时以上）的稳定性压⼒测试和极限负载情况下导致系统奔溃的破坏性压⼒测试。

三者的区别：从测试的⽬的出发，从⽤户的需求出发，就⽐较容易区分性能测试、负载测试和压⼒测试了。

性能测试是为了获得系统在某种特定的条件下（包括特定的负载条件下）的性能指标数据，⽽负载测试、压⼒测试是为了发现软件系统中所存在的问题，包括性能瓶颈、内存泄漏等。

通过负载测试，也是为了获得系统正常⼯作时所能承受的最⼤负载，这时的负载测试就成为了容量测试。

通过压⼒测试，可以知道在什么极限情况下系统会奔溃、系统是否具有⾃我恢复性等，但更多的是为了确定系统的稳定性。

性能测试⼯具（⽬前只是知道有这些⼯具，后期在使⽤过程中在总结它们的使⽤⽅法）：
(2) Load Runner
(3) QTP(Quick Test)
(4) Web Polygraph
性能测试不单单是熟悉测试⼯具，更要注意的是其中的测试思想，下⾯可以了解⼀下关于性能测试的三个观念：
精确和模糊
i.e. ⼀辆汽车开100公⾥需要多少汽油？
做假设（assumption），下⾯有3个阶段的假设：
a. 做了假设却不知道⾃⼰做了假设
有些⼈根据⾃⼰的切⾝体验来做测试，然后写测试报告给别⼈看，关键是你觉得⾃⼰的测试是正确的，但并不是所有⼈都是处于你所处的环境，做和你测试时做完全⼀样的事情，所以测试出来的结果只会误导到别⼈。

⽐如前⾯提到的那个耗油的问题，有⼈的做法是我开100公⾥看看，得出来多少就是多少。

b. 做了过多的假设
”当路⾯平坦，⼀路绿灯，风速5km/h,只有⼀名70kg的乘客，时速稳定在70km/h,良好驾驶习惯，… , 的情况下，油耗是7.1L/100km.“这样可能很严谨，但对于读你报告的读者，这样的数据没有多⼤的意义。

c. 做必要和合理的假设
⽣活中有些时候是需要⼀些妥协和折衷的，如果这些折衷是必要的和合理的。

因为跳出来看，我们的测试需要提供有价值的信息，所以为了这样有价值的信息，做出必要的合理的假设是可以接受的。

宏观与微观
这也是⼀个有趣的对⽴。

在做性能测试，特别是整个产品的性能测试的时候，我们看到的是产品的核⼼功能和主要的⼤的功能模块，⽐如、web服务器、核⼼的daemon等等。

在脑海⾥，我们有⼀个图，哪怕你没有把它画出来。

所以有时候，我们会想，性能测试对于产品的视⾓是宏观的，看⼤的组件，⽽不是具体的细节的东西。

果真是如此吗？看看下⾯的例⼦：
1. 把daemon的log级别改为debug （log_level从2改到5）之后，性能下降了差不多⼀半。

2. 关掉⼀个cache选项
3. 打开keepalive选项
4. 打开DNS反向查询
......
上⾯都是些细枝末节的设置，⼀个配置项⽽已，藏在DB的某张表或者某个ini⾥⾯。

但是改变之后，得到的性能结果可能⼤不相同。

这时候，其实要不要考虑细枝末节，主要是看他到底是否Critical。

⾄于怎样的才是⾄关重要的，这还需要在以后的⼯作中思考和总结。

项⽬和任务
性能测试本⾝肯定是⼀个任务，⽆论对于被安排去做这个的⼈，或者安排的⼈。

但是它有时候也像⼀个项⽬，对于去做这件事情的⼈。

为什么呢？
⾸先你需要和很多的⼈打交道。

产品经理或者客户：获取需求，设定⽬标。

QA manager/lead：讨论resource和schedule。

包括需要的机器，环境，软件，还有整个计划。

开发⼈员：查找问题和调优等。

功能测试的owner：性能测试⼈员可能不是什么功能都很懂。

Admin：Lab，⽹络，DB等等
其次，它是⼀个周期很长，跨度很⼤的⼯作。

特别是对于⼀个⽐较⼤的产品⽽⾔。

你需要准备详细的测试设计，包括⽬标、范围、可能的⽅法，以及上⾯提到的资源和时间计划；然后邀请很多⼈来评审这个计划；接下来要准备⼯具、环境和测试数据。

然后是执⾏，记录分析结果。

如果有问题还要反复的调整和regression。

最后要整理报告，回答疑问。

说它是⼀个项⽬⼀来是因为上⾯的原因导致⼯作的复杂性，还有⼀些原因是因为性能测试带有评测的性质，因为你是在试图去度量、衡量或者评价⼀个东西，⽽且带有⽐较绝对的结果。

这样导致性能测试不可避免的要引⼊⼀些权威性的问题，尽管你并不⼀定期望这样。

这使得很多的东西就像⼀个其他项⽬⼀样，有期望管理和良好的外部沟通和协调的需要。

所以有时候，更愿意把它作为⼀个⼩的项⽬来看待，这样或许可以做得更全⾯。

本⽂参考：。