前言
1.不断提升自身技能，并明确职业发展方向对所有人来说就显得非常重要了。（性能测试技术方向）
2.目前性能测试一直处于一个只能发现问题而无法定位并给出解决方案的状态。（定位问题是测试迫切需要掌握的技能）
第1章 与性能测试的亲密接触
1.一般C/S架构的应用程序更关注于系统资源使用情况、数据库性能以及运行的配置要求等。例如，内存、用户连接数、数据库死锁、数据库cache命中率、运行的最低配置等。
而对于B/S架构的应用程序，会关注Web服务器的相关指标，如每秒点击数、吞吐量、尝试连接数、事务成功率等。
2.很多第一次接触性能测试的人都会把功能测试的思绪带入，造成思维的局限。其实性能测试还是与功能测试有所不同的。性能测试更加关注系统的性能表现，也就是How fast和How much。而做性能测试就是排除系统瓶颈。
3.只有并发用户数才对系统产生真正的压力。
4.常用服务器日志分析工具：AWStats、Webalizer、Analog、Deep Log Analyzer等。
5.并发的概念，一般有两种理解方式：一种为所有用户在同一时刻做同一种操作，主要是未了验证程序或数据库对并发的处理能力；另一种为多个用户对被测系统发起了多个请求，这些请求可以是同一种操作，也可以是不同的操作，类似于混合场景的概念。
6.响应时间=网络传输（请求）时间+服务器处理（一层或多层）时间+网络传输（响应）时间+页面前端解析渲染时间。
注意：前端页面的解析展示时间一般在做非前端性能测试中不太会关注，因为每个浏览器解析页面的方式不一样，时间也会不一样。
7.性能术语：并发数、响应时间、每秒通过事务数（TPS）、每秒点击数、吞吐量、思考时间、资源利用率。
一、每秒通过事务数
TPS是指每秒通过事务数，是直接反映系统性能的指标，该值大时，系统性能会比较好。将它与平均事务响应时间进行对比，可以分析事务数量对响应时间的影响。
例如，当压力加大时，TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈了。如果环境没有发生大的变化，对于同一系统会存在一个最大处理事务能力，它并不随着并发用户的多少而改变。就好像传说中的北京五道口地铁检票机一样，只有两台进站检票的机器，一次一台机器只能通过一个人，不论是来10个人，还是100个人。
二、每秒点击数
每秒点击数代表用户每秒向Web服务器提交的HTTP请求数。但这里需要注意的是提交一个登录请求，对于用户来说感觉是一个请求，但对于后端服务器来说也许是多个请求，所以点击一次不代表就是一个请求。例如，点击一个链接，该操作返回的页面上有6张图片，因为下载每张图片都需要一个HTTP请求，所以这个页面下载完成之后的点击数应该是7。
每秒点击数从侧面可以反映客户端的状况，每秒点击数不正常，一般可能是网络问题或者脚本问题导致，需要进一步具体分析。
三、吞吐量与吞吐率
吞吐量是指单位时间内系统处理的请求数量，能直接反映服务器承受的压力，是需要重点关注的指标。
吞吐率一般指用户在给定的一秒内从服务器获得的数据量，简而言之就是服务器返回的数据量。（吞吐率=吞吐量/时间）
四、思考时间
如果想了解系统的最大承受能力或者极端情况下系统的性能表现，则可以设置为0思考时间。但如果是预估系统的性能，就应该最大可能地模拟真实思考时间。一般都会加上思考时间，只是在分析时要去掉思考时间。
五、资源利用率
（1）CPU：反映系统的繁忙程度，分为系统CPU和用户CPU。系统CPU是处理系统本身所占用的资源，用户CPU是处理程序所占用的资源。
（2）Load Average：指一段时间内CPU正在处理和等待CPU处理的任务，也就是CPU使用队列的长度的统计信息。这里的Load Average值就好像地铁里等待进站上车的乘客，越多则Load Average值也越大。
（3）Memory：数据从内存中读取要比从磁盘上读取速度快，而内存经常发生内存泄露或内存溢出的现象，是需要重点留意的。不过这里需要注意，短时间的可用内存越来越少，不代表一定有内存泄露或溢出。
（4）队列：队列长，说明处理能力可能达到了极限或者遇到了阻塞。
（5）IO：与磁盘的交互，重点关注交换频率和磁盘队列长度。
（6）网络：重点关注网络的流量，看是否存在网络带宽的瓶颈。
8.性能测试分类：基准测试、并发测试、负载测试、压力测试、稳定性测试、失效恢复测试、现网性能测试
一、基准测试
最简单的的理解就是有基础的标准，这样能通过对比发现系统的不同点与变化。一般情况下，基准测试有以下几种应用场景：
（1）可以在制定的标准下通过基准测试建立一个性能基准，这样以后当系统的环境、参数发生变化之后，再进行一次相同标准下的测试，即可看出变化对性能的影响。六日，数据库的基准性能测试。
（2）系统进行基准测试可以在较早的阶段发现性能问题。例如，如果对BestTest网站进行10个用户并发测试时，系统出现了死机的现象，那么就没有必要进行后续的测试了。
（3）某系统从来没有进行过任何性能测试，需要对该系统做一次性能评估作为后续开发调优的参考。这是基准测试常见的一种场景，也是大部分没有做过性能测试的公司最需要的。
虽然基准测试不难理解，但实践起来常常被误解。以对某个系统的数据搜索进行性能基准测试为例，这个系统的数据量会随着实践的增长而增长，所以必须频繁地进行基准测试，这样才能准确地把握数据量的增长对系统性能的影响。但因为进行的基准测试又恰恰是在应用程序级别的，并不能客观地反映全局性的性能。所以，比较好的做法是每次只修改一个地方，这样就能准确地判断出哪个地方会对性能产生影响。
二、并发测试
并发测试可以理解为很多的用户按照预定的场景并发请求某个业务或功能时是否出现并发问题。例如，内存泄露、线程锁、资源争用等。
并发数可以通过下面的公式基本换算得出：并发数=PV/PV Time*页面连接次数*HTTP响应时间*因数/Web服务器数量。
PV Time是PV的统计时间，换算成秒，一天是86400s。
页面连接次数包括外部的JS、CSS、图片等，一般为10.
HTTP响应时间一般可为1s或更少。
因数一般为5。
PV（page view）即页面浏览量，是目前判断网站访问流量最常用的计算方式，也是反映一个网站受欢迎程度的重要指标之一。
三、负载测试
负载测试可以理解为确定所要测试的业务或系统的负载范围，然后对其进行测试。它的主要目的是验证业务或系统在给定的负载条件下的处理性能。此外，还要关注响应时间、每秒通过事务数和其他相关指标。
从另一个角度理解，负载测试可以看作是性能测试的一部分，但它们两者的目的是不同的，负载测试是为了发现性能问题，而性能测试是为了获取性能指标。因为在性能测试过程中，也可以不调整负载，而是在同样负载情况下通过改变系统的结构、算法、硬件配置等来得到性能指标。
四、压力测试
压力测试可以理解为没有预期的性能指标，不断地加压，看系统什么时候崩溃，以此来确定系统的瓶颈或者不能接受的性能拐点，以获得最佳并发数、最大并发数。
压力测试也可以看做是负载测试的一种，即高负载下的负载测试。通过压力测试，可以更快地发现内存泄漏问题，还可以更快地发现影响系统稳定性的问题。例如，在正常负载情况下，某些功能可以正常使用或者出错的概率比较低，但在压力测试下可能很快就会出现，帮助我们提早发现性能问题。
注意：负载测试与压力测试的概念并非完全独立，大可不必纠结于文字概念。在实际应用中一般二者都是相互结合、相互补充的。
五、稳定性测试
要想知道系统稳定的情况，就需要长时间运行，在这段时间内观察系统的出错几率、性能变化趋势等。进而大大减少系统上线后的崩溃等现象。一般都会进行所谓的7*24小时的稳定性测试。但稳定性测试也有和其他分类不一样的地方，这里需要强调以下两点：
（1）一般稳定性测试需要在系统成型后运行，并且没有严重的Bug存在。
（2）场景的设计以模拟真实用户的实际操作为佳。
六、失效恢复测试
失效恢复测试重在关注系统出现问题后能否根据预先制定的策略恢复，且恢复后能否正常运行。
不过失效恢复测试一般是对具有负载均衡的系统进行的，主要是为了测试当系统局部发生故障时，是否会对全局产生大的影响，产生的影响是否在可以接受的范围内，以及用户能否继续使用系统。
在实际应用过程中，可以模拟一台或几台负载均衡机器出现故障来进行失效恢复测试，但需要注意的是，不仅要关心失效后，用户是否可以正常访问或者恢复后系统是否可以正常工作，也要关注失效后，系统还能支持多少并发用户，以及采用哪些备选方案来快速响应。
9.曲线拐点模型分析
随着并发用户数的增加，吞吐量与资源利用率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于比较好的状态。但随着并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和，随后吞吐量急剧下降，造成响应时间急剧增长。轻压力区与重压力区的交界点是系统的最佳并发用户数，因为各种资源都利用充分，响应也很快；而重压力区与拐点区的交界点就是系统的最大并发用户数，因为超过这个点，系统性能将会急剧下降甚至崩溃。