做测试一年多来，虽然平时的工作都能很好的完成，但最近突然发现自己在关于测试的整体知识体系上面的了解很是欠缺，所以，在工作之余也做了一些测试方面的知识的补充。不足之处，还请大家多多交流，互相学习。
现在看来，虽然平时工作中，所涉及虽然的是自动化测试，但更多的是功能测试，今天了解了一下性能测试。文章源自玩技e族-https://www.playezu.com/378179.html
同时，我也清楚的意识到，对于测试工具而言，会不会或者熟悉不熟悉是迟早的事，只要你经常用，但掌握测试的基础知识，了解一些测试思想和观念，更能让我们受益无穷。文章源自玩技e族-https://www.playezu.com/378179.html
下面总结一下我所学习到的性能测试：文章源自玩技e族-https://www.playezu.com/378179.html
性能测试（Performance Testing）：是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试。通过负载测试，确定在各种工作负载下的系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。文章源自玩技e族-https://www.playezu.com/378179.html
负载测试（Load Testing）：是模拟实际软件所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其他加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（CPU、内存等），以检验系统的行为和特性，以发现系统可能存在的性能瓶颈，内存泄漏，不能实时同步等问题，负载测试更多的体现了一种方法或一种技术。文章源自玩技e族-https://www.playezu.com/378179.html
压力测试（stress testing）：在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下的操作行为，从而有效地发现系统的某项功能隐患，系统是否具有良好的容错能力和可恢复能力。压力测试可分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统奔溃的破坏性压力测试。文章源自玩技e族-https://www.playezu.com/378179.html
三者的区别： 从测试的目的出发，从用户的需求出发，就比较容易区分性能测试、负载测试和压力测试了。性能测试是为了获得系统在某种特定的条件下（包括特定的负载条件下）的性能指标数据，而负载测试、压力测试是为了发现软件系统中所存在的问题，包括性能瓶颈、内存泄漏等。通过负载测试，也是为了获得系统正常工作时所能承受的最大负载，这时的负载测试就成为了容量测试。通过压力测试，可以知道在什么极限情况下系统会奔溃、系统是否具有自我恢复性等，但更多的是为了确定系统的稳定性。文章源自玩技e族-https://www.playezu.com/378179.html
性能测试工具（目前只是知道有这些工具，后期在使用过程中在总结它们的使用方法）：文章源自玩技e族-https://www.playezu.com/378179.html
(1) ApacheJmeter: 用户手册 Apache JMeter - User's Manual文章源自玩技e族-https://www.playezu.com/378179.html
(2) Load Runner
(3)QTP(Quick Test)
(4)WebPolygraph
性能测试不单单是熟悉测试工具，更要注意的是其中的测试思想，下面可以了解一下关于性能测试的三个观念：
·精确和模糊
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。最后要整理报告，回答疑问。
说它是一个项目一来是因为上面的原因导致工作的复杂性，还有一些原因是因为性能测试带有评测的性质，因为你是在试图去度量、衡量或者评价一个东西，而且带有比较绝对的结果。这样导致性能测试不可避免的要引入一些权威性的问题，尽管你并不一定期望这样。这使得很多的东西就像一个其他项目一样，有期望管理和良好的外部沟通和协调的需要。所以有时候，更愿意把它作为一个小的项目来看待，这样或许可以做得更全面。