LoadRunner性能测试巧匠训练营(实战)-第一章

性能术语与指标详解(1.3)

并发数

• 系统用户数：该系统的注册用户数。

例如，BestTest论坛里存在6666个注册用户，他们可以是活跃的，也可以是僵尸的。

• 在线用户数：即登录系统的用户。

例如，其中有666个用户的状态为在线，但在线用户并不一定都会对服务器产生压力，因为有的用户登录后什么都不干。

• 并发用户数：对服务器产生压力的用户。

并发的两种理解方式：
一种为所有用户在同一时刻做同一种操作，主要是为了验证程序或数据库对并发的处理能力；
另一种为多个用户对被测系统发起了多个请求，这些请求可以是同一种操作，也可以是不同的操作，类似于混合场景的概念。

响应时间

• 响应时间=网络传输（请求）时间+服务器处理（一层或多层）时间+网络传输（响应）时间+页面前端解析渲染时间

注意：前端页面的解析展示时间一般在做非前端性能测试中不太会关注，因为每个浏览器解析页面的方式不一样，时间也会不一样。

每秒通过事务数

• TPS：每秒通过事务数，是直接反映系统性能的指标。该值大时，系统性能会比较好，当然每个系统都有它的上限，不可能无限大。将它与平均事务响应时间进行对比，可以分析事务数量对响应时间的影响。

每秒点击数

• 每秒点击数：用户每秒向Web服务器提交的HTTP请求数。

注意：提交一个登录请求，对于用户来说感觉是一个请求，
但对于后端服务器来说也许是多个请求，所以点击一次不代表就是一个请求。
例如，点击一个链接，该操作返回的页面上有6张图片，因为下载每张图片都需要一个HTTP请求，所以这个页面下载完成之后的点击数应该是7。

每秒点击数从侧面可以反映客户端的状况，每秒点击数不正常，一般可能是网络问题或者脚本问题导致，需要进一步具体分析。

吞吐量

• 吞吐量：单位时间内系统处理的请求数量，能直接反映服务器承受的压力，是需要重点关注的指标。
• 吞吐率：一般指用户在给定的一秒内从服务器获得的数据量，简而言之就是服务器返回的数据量。

思考时间

• 情况一：用户进行操作时，每个请求或者操作之间的间隔时间，是为了更加真实地模拟用户的操作场景。因为在实际使用中不太可能会出现不断地发送请求，一般都是一个请求后，等待一段时间，然后发送下一个请求，恶意攻击除外。
• 情况二：满足业务的特定需求，如“两次发帖时间间隔不能小于15秒钟”。
• 0思考时间：如果想了解系统的最大承受能力或者极端情况下系统的性能表现，则可以设置为0思考时间。但如果是预估系统的性能，就应该最大可能地模拟真实思考时间。一般都会加上思考时间，只是在分析时要去掉思考时间。

资源利用率

• CPU：：它就像是人的大脑，主要是进行判断和处理，能反映出系统的繁忙程度，一般分为系统CPU与用户CPU。其中系统CPU是处理系统本身所占用的资源，用户CPU则是处理程序所占用的资源，对象不同。
• Load Average：指一段时间内CPU正在处理和等待CPU处理的任务，也就是CPU使用队列的长度的统计信息。
• Memory：它就像是人大脑的记忆区域，将各种信息收集起来存放。数据从内存中读取要比从磁盘上读取速度快，而内存经常发生内存泄露或内存溢出的现象，是需要重点留意的。不过这里需要注意，短时间的可用内存越来越少，不代表一定有内存泄露或溢出。
• 队列：可以理解成地铁进站的排队现象，队列长，说明处理能力可能达到了极限或者遇到了阻塞。
• IO：与磁盘的交互，重点关注交换频率和磁盘队列长度。
• 网络：重点关注网络的流量，看是否存在网络带宽的瓶颈。

性能测试分类详解(1.4)

性能测试的种类繁多，但是实际执行起来又很难严格区分，理解各种分类的特点和概念即可，没必要咬文嚼字。

基准测试

基准最简单的理解就是有基础的标准，这样能通过对比发现系统的不同点与变化。一般情况下，基准测试有以下几种应用场景。

1.可以在制定的标准下通过基准测试建立一个性能基准，这样以后当系统的环境、参数发生变化之后，再进行一次相同标准下的测试，即可看出变化对性能的影响。

例如，数据库的基准性能测试。

2.系统进行基准测试可以在较早的阶段发现性能问题。

例如，如果对BestTest网站进行10个用户并发测试时，系统出现了死机的现象，那么就没有必要进行后续的测试了。

3.某系统从来没有进行过任何性能测试，需要对该系统做一次性能评估作为后续开发调优的参考。

虽然基准测试不难理解，但实践起来常常被误解。
以对某个系统的数据搜索进行性能基准测试为例，这个系统的数据量会随着时间的增长而增长，所以必须频繁地进行基准测试，这样才能准确地把握数据量的增长对系统性能的影响。
但因为进行的基准测试又恰恰是在应用程序级别的，并不能客观地反映全局性的性能。所以，比较好的做法是每次只修改一个地方，这样就能准确地判断出哪个地方会对性能产生影响。

并发测试

很多的用户按照预定的场景并发请求某个业务或功能时是否出现并发问题。

例如，内存泄露、线程锁、资源争用等，几乎所有的性能测试都会涉及并发测试。

并发测试的主要目的是找出并发引起的问题。

1.并发数=PV / PV Time×页面连接次数×HTTP响应时间×因数/ Web服务器数量。

PV（page view）即页面浏览量。一个用户有可能创造十几个甚至更多的 PV。它是目前判断网站访问流量最常用的计算方式，也是反映一个网站受欢迎程度的重要指标之一。
PV Time是PV的统计时间，换算成秒，一天是86400s。
页面连接次数包括外部的JS、CSS、图片等，一般为10。
HTTP响应时间一般可为1s或更少。
因数一般为5。

假设，BestTest官网每天有6万PV，其余参数保持默认，那么推算出来的并发数大致为35。

2.著名的经典理论80-20原则。

3.参考段念老师在《软件性能测试过程详解与案例剖析》一书中提到的估算方法。

负载测试

确定所要测试的业务或系统的负载范围，然后对其进行测试。
它的主要目的是验证业务或系统在给定的负载条件下的处理性能。此外，还要关注响应时间、每秒通过事务数和其他相关指标。

从另一个角度理解，负载测试可以看作是性能测试的一部分，但它们两者的目的是不同的，负载测试是为了发现性能问题，而性能测试是为了获取性能指标。因为在性能测试过程中，也可以不调整负载，而是在同样负载情况下通过改变系统的结构、算法、硬件配置等来得到性能指标。

压力测试

没有预期的性能指标，不断地加压，看系统什么时候崩溃，以此来确定系统的瓶颈或者不能接受的性能拐点，以获得系统的最佳并发数、最大并发数。

压力测试就好比跑马拉松，看你到底能跑多久，什么时候就坚持不住了。

压力测试也可以看作是负载测试的一种，即高负载下的负载测试。通过压力测试，可以更快地发现内存泄漏问题，还可以更快地发现影响系统稳定性的问题。

例如，在正常负载情况下，某些功能可以正常使用或者出错的概率比较低，但在压力测试下可能很快就会出现，帮助我们提早发现性能问题。

注意
负载测试与压力测试的概念并非完全独立，读者大可不必纠结于文字概念。在实际应用中一般二者都是相互结合、相互补充的。

稳定性测试

要想知道系统稳定的情况，就需要长时间运行，在这段时间内观察系统的出错几率、性能变化趋势等。进而大大减少系统上线后的崩溃等现象。一般都会进行所谓的7×24小时的稳定性测试。

1.一般稳定性测试需要在系统成型后进行，并且没有严重的Bug存在。

2.场景的设计以模拟真实用户的实际操作为佳。

失效恢复测试

失效恢复测试重在关注系统出现问题后能否根据预先制定的策略恢复，且恢复后能否正常运行。

以跑马拉松为例，为了预防出现跑不动的情况，预先准备了一瓶红牛，当选手累得躺下后，拿出这瓶红牛一口气喝了，然后你有力量了，恢复了原来的状态，站起来继续跑。

不过失效恢复测试一般是对具有负载均衡的系统进行的，主要是为了测试当系统局部发生故障时，是否会对全局产生大的影响，产生的影响是否在可以接受的范围内，以及用户能否继续使用系统。

在实际应用过程中，可以模拟一台或几台负载均衡机器出现故障来进行失效恢复测试，但需要注意的是，不仅要关心失效后，用户是否可以正常访问或者恢复后系统是否可以正常工作，也要关注失效后，系统还能支持多少并发用户，以及采用哪些备选方案来快速响应。

现网性能测试

所谓现网性能测试，就是在实际网络、实际环境中进行测试，完全和真实用户一样。当然这样的测试有一定的风险，需要注意以下几点。

1.时间段的选择。
现网性能测试可能会影响正常用户，所以这样的时间段要尽量避开高峰期，选择半夜或者凌晨来进行。

2.垃圾数据处理。
如果现网性能测试涉及了写数据的操作，那么肯定会带来不少的垃圾数据，这些数据后期一定要清理，为了清理方便，前期数据的设计要有规律可循。

3.网络限制。
和在内网测试不同，现网的测试如果突然间产生大的数据量，可能会被网络带宽限制，甚至路由会认为是非法数据请求而产生拦截等。所以如果在现网进行性能测试，那么压力机需要和被测服务器部署在同一个网段机房内，这样可以避免网络限制，最后远程收集数据即可。

如果没有特殊情况，尽量不要进行现网的性能测试，风险比较大，如果非要进行，一定要事先充分评估风险以及应对的解决方案，这样出了问题可以快速响应，把影响控制到最小。

性能测试模型分析(1.5)

曲线拐点模型分析

1.X轴代表并发用户数，Y轴代表资源利用率、吞吐量、响应时间。X轴与Y轴区域从左往右分别是轻压力区、重压力区、拐点区。

2.响应时间
随着并发用户数的增加，在轻压力区的响应时间变化不大，比较平缓，进入重压力区后呈现增长的趋势，最后进入拐点区后倾斜率增大，响应时间急剧增加。

3.吞吐量
随着并发用户数的增加，吞吐量增加，进入重压力区后逐步平稳，到达拐点区后急剧下降，说明系统已经达到了处理极限，有点要扛不住的感觉。

4.资源利用率
随着并发用户数的增加，资源利用率逐步上升，最后达到饱和状态。

5.综合分析
随着并发用户数的增加，吞吐量与资源利用率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于比较好的状态。
但随着并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和，随后吞吐量急剧下降，造成响应时间急剧增长。
轻压力区与重压力区的交界点是系统的最佳并发用户数，因为各种资源都利用充分，响应也很快；而重压力区与拐点区的交界点就是系统的最大并发用户数，因为超过这个点，系统性能将会急剧下降甚至崩溃。

地铁模型分析

·某地铁站进站只有3个刷卡机。
·人少的情况下，每位乘客很快就可以刷卡进站，假设进站需要1s。
·乘客耐心有限，如果等待超过30min，就会暴躁、唠叨，甚至选择放弃。

按照上述的假设，最初会出现如下的场景。

• 场景一：
  只有1名乘客进站时，这名乘客可以在1s的时间内完成进站，且只利用了一台刷卡机，剩余2台等待着。
• 场景二：
  只有2名乘客进站时，2名乘客仍都可以在1s的时间内完成进站，且利用了2台刷卡机，剩余1台等待着。
• 场景三：
  只有3名乘客进站时，3名乘客还能在1s的时间内完成进站，且利用了3台刷卡机，资源得到充分利用。
• 场景四：
  A、B、C三名乘客进站，同时D、E、F乘客也要进站，因为A、B、C先到，所以D、E、F乘客需要排队，等A、B、C三名乘客进站完成后才行。那么，A、B、C乘客进站时间为1s，而D、E、F乘客必须等待1s，所以他们3位在进站的时间是2s。

通过上面这个场景可以发现，每秒能使3名乘客进站，第1s是A、B、C，第2s是D、E、F，但是对于乘客D、E、F来说，“响应时间”延长了。

• 场景五：
  假设这次进站一次来了9名乘客，这9名乘客中有3名的“响应时间”为1s，有3名的“响应时间”为2s（等待1s+进站1s），还有3名的“响应时间”为3s（等待2s+进站1s）。
• 场景六：
  假设这次进站一次来了10名乘客，根据上面的推算，必然存在1名乘客的“响应时间”为4s，如果随着大量的人流涌入进站，可想而知就会达到乘客的忍耐极限。
• 场景七：
  如果地铁正好在火车站，例如，著名的北京西站、北京站。每名乘客都拿着大小不同的包，有的乘客拿的包太大导致卡在刷卡机那（堵塞），这样每名乘客的进站时间就会又不一样。

很多地铁进站的刷卡机有加宽的和正常宽度的两种类型，那么拿大包的乘客可以通过加宽的刷卡机快速进站（增加带宽），这样就能避免场景七中的现象。

• 场景八：
  进站的乘客越来越多，3台刷卡机已经无法满足需求，于是为了减少人流的积压，需要再多开几个刷卡机，增加进站的人流与速度（提升TPS、增大连接数）。
• 场景九：
  终于到了上班高峰时间了，乘客数量上升太快，现有的进站措施已经无法满足，越来越多的人开始抱怨、拥挤，情况越来越糟。

单单增加刷卡机已经不行了，此时的乘客就相当于“请求”，乘客不是在地铁进站排队，就是在站台排队等车，已经造成严重的“堵塞”，那么增加发车频率（加快应用、数据库的处理速度）、增加车厢数量（增加内存、增大吞吐量）、增加线路（增加服务的线程）、限流、分流等多种措施便应需而生。