vlambda博客
学习文章列表

 文章 jinnining(宁京)   本文累计获得赞赏1次，赞赏金额5.20元

目录

开卷语

1. 第一章 基本概念与方法

1.1. 初识性能测试

1.2. 常用性能指标

1.3. 常用测试方法

1.4. 性能瓶颈

1.5. 什么是性能测试？

2. 第二章 实现原理、数据搜集与统计分析

2.1. 实现原理

2.2. 数据搜集与统计

2.2.1. 指标数值的获取和处理

2.2.2. 数值的计算

2.2.3. 统计原始数据

2.2.4. 常用图表的画法

2.3. 检查、修正、调整测试方法

2.4. 分析定位

2.4.1. 单台客户机和单台服务器的容量分析

2.4.2. 多台客户机和单台服务器的容量分析

2.4.3. 单台客户机多台服务器瓶颈分析和定位

2.4.4. 稳定性测试分析和问题定位

2.4.5. 可靠性测试分析和问题定位

3. 第三章 测试工具应用与开发

3.1. 常用性能测试工具介绍

3.1.1. HTTPLoad

3.1.2. 自研压测工具Beetle

3.2. 性能测试工具开发要点

4. 第四章 需求搜集与方案设计

4.1. 沟通矩阵

4.2. 了解背景

4.3. 需求分析和需求定义

4.4. 被测对象分析

4.5. 用例选择

4.6. 测试环境模拟

5. 第五章 性能测试模型与模板

5.1. 性能测试模型

5.1.1. 需求分析和方案计划

5.1.2. 环境准备

5.1.3. 测试执行

5.1.4. 文档报告

5.1.5. 回访总结

5.2. 性能测试模板

5.2.1. 需求分析和方案计划模板

5.2.2. 环境说明模板

5.2.3. 性能测试报告模版

5.2.4. 回访报告模版

5.3. 敏捷开发流程与性能测试

6. 结束语

 

---------------------这是割割线-------------------------

1.1. 初识性能测试

提到性能测试，不能不提到很多术语。为了让大家更容易理解，举个生活中的例子：

你中午去“谷湘楼”吃饭。

我们可以把“谷湘楼”这个酒楼看成一个被测系统。

你去吃饭，就是对这个被测系统发起请求，对这个系统造成了一定的负载。你带去的人越多，那么这个酒楼就越繁忙，可以说酒楼承受的负载就越大。

你开始点菜。这个时候你隔壁桌的人也开始点菜。那么你们两个对这个系统产生了并发的请求。同时，其他桌有的在吃菜，有的在等菜，这些都是并发进行的事务。一个完整的吃饭事务可以定义成包括：点菜，下单，上菜，买单四个步骤。对于一个C/S的系统来说，可以对应于：建立连接，发送请求，接受应答，断开连接。

影响一个餐馆生意好坏的一个重要原因是上菜速度。上菜速度体现在两个方面：

1.         一个顾客请求的处理耗时，从下单到上菜中间等待的时间，我们称之为响应时间。

2.         这个餐馆同时为多名顾客上菜的频率，我们称之为吞吐量。

很多因素会影响上菜速度，比如服务员的个数，厨师的个数。对于一个C/S的系统，服务员相当于是接入层，厨师相当于是后台服务。假如服务员太少，下单很慢，后面的厨师都闲着，那么上菜速度也快不了；假如服务员够多，下单足够快，但是厨师太少，下的单来不及做，同样上菜速度也很慢；如果服务员很多，厨师也很多，但是来的客人很少，那么大部分的服务员和厨师都闲着，资源全部浪费掉了。因此，接入层和后台服务进程个数、以及资源配比，都是需要根据实际情况进行调优的。

来多少顾客，这是酒楼自己无法控制的，但是酒楼的上菜速度、餐位多少都会制约客流量。一定有一个峰值客流量，当来的客人超过了这个峰值，那么这些客人就会等位，或者是上菜速度超慢让客人无法容忍。容量测试就是通过工具模拟足够多的顾客来吃饭的事务，希望找到这样一个客流量对酒楼产生一定的负载，这个时候酒楼既能接待最多的客户同时也能保证最短的等待时间。更多的，还可以对这个酒楼人员配置和餐位设置等进行调优，以期达到一个最理想的资源利用率和效率。

       客流量跟进来的客人多少有关，也跟餐馆的接待能力有关。单方面增加来就餐的顾客，遭到投诉的可能性就越大，上错菜的可能性也越大。

性能测试的概念主要包括两部分：一些测试方法，一些评价性能的指标。测试方法会告诉你用什么样的套路去执行测试；性能指标是告诉你如何用数值来描述你的测试对象的性能。

1.2. 常用性能指标

【吞吐量】 固定时间间隔内的处理完毕事务个数。通常是1秒内处理完毕的请求个数，单位：事务/秒（tps）。

【平均吞吐量】一段时间内吞吐量的平均值。无法体现吞吐量的瞬间变化。

【峰值吞吐量】一段时间内吞吐量的最大值。是用来评估系统容量的重要指标之一。

【最低吞吐量】一段时间内吞吐量的最小值。如果最小值接近0，说明系统有“卡”的现象。

【70%的吞吐量集中区间】通过统计15%和85%的吞吐量边界值，计算出70%的吞吐量集中区间。区间越集中，吞吐量越稳定。

【响应时间】一次事务的处理时间。通常指从一个请求发出，到服务器进行处理后返回，再到接收完毕应答数据的时间间隔，单位：毫秒。

【平均响应时间】 一段时间内响应时间的平均值。无法体现响应时间的波动情况。

【中间响应时间】一段时间内响应时间的中间值，50%响应时间，有一半的服务器响应时间低于该值而另一半高于该值。

【90%响应时间】一段时间内90%的事务响应时间比此数值要小。反应总体响应速度，和高于该值的10%超时率。是用来评估系统容量的重要指标之一。

【最小响应时间】响应时间的最小值。反映服务最快处理能力。

【最大响应时间】响应时间的最大值。反映服务器最慢处理能力。

【CPU占用率】1-CPU空闲率，表示CPU被使用情况，反映了系统资源利用情况。

1.3. 常用测试方法

【压力测试】一般提到性能测试，大家最常用到的代名词就是压力测试。实际上，压力测试分成两种：【暴力测试】和【稳定性测试】。

【暴力测试】对系统产生过载的压力，让系统产生一系列致命而无法提供服务的问题。目的是评估这个系统超负载后带来的风险。

【稳定性测试】系统负载未过载情况下的一种压力测试。分两种测试方法，一种是【可靠性测试】，主要是持续一定长的时间提供一定量的负载，暴露系统的缺陷。缺陷暴露的几率与负载的大小成正比。解决系统缺陷后，才能进行【容量测试】。另一种是【稳定性测试】，在稳定的负载下，看系统各个性能指标在一段时间内是否稳定。倘若系统性能不稳定，获得的数值则不适合用来做容量评估。

【基准测试】狭义的性能测试，获得系统在某种特定的条件下（包括特定的负载条件下）的性能指标数据。

【负载测试】通过不断增加对系统的负载，获得系统在不同负载下的性能指标。并发连接数取值一般以2的N次方为佳：1、2、4、8、16、32、64、128。如此取样得到的数据最有参考价值，测试效率也最高。记录每种负载情况下的系统性能，包括：吞吐量（平均值，峰值）、90%响应时间和资源利用率（CPU占用率）。

【容量测试】容量测试主要采用负载测试方法获取数值，继而分析评估系统容量。这个过程包括对系统性能瓶颈的定位，性能调优，使资源利用率最大化，给出系统最优情况下能承载的最佳性能指标。

【并发测试】可以按以上多种基本测试类型实现。【基准测试】：大量并发连接，看服务处理的响应时间是否正常；【稳定性测试】：被测系统在频繁建立和释放连接情况下系统是否能持续提供服务；【可靠性测试】：并发用户在一定高负载下同时访问临界数据，暴露系统缺陷；【暴力测试】：获取导致系统暴露缺陷的并发连接数。

1.4. 性能瓶颈

在理解什么是性能测试之前，我们必须理解什么是性能瓶颈。

有两种瓶颈：

1.         处理时间长的模块

2.         资源占用高导致处理能力受硬件限制无法继续提升的模块。

当一个系统出现第一种瓶颈的时候，只要提升瓶颈部分的性能，缩短服务处理时间，就能继续提升系统整体性能。

当一个系统出现第二种瓶颈的时候，需要对瓶颈部分做性能调优或者增加为该层服务分配的资源（比如：升级CPU、增加服务器台数、增加服务进程数，等），就能继续提升系统整体性能。

当一个瓶颈问题被解决，瓶颈必然转移到下一个地方。

当系统持续优化后，可以达到一个理想的状态，性能得以充分发挥，优化任何一个模块也无法对系统整体性能进行很大的提升。

对被测系统进行压测时，需要把瓶颈转移到被测服务上，这样可以产生最大的负载，在容量测试时能得到该服务最优的性能。

1.5. 什么是性能测试？

狭义的性能测试指的是基准测试，广义的性能测试把以上所有与性能相关的测试统称为性能测试。这些既是测试类型也是测试方法，也叫测试策略。一般提到性能测试，大家最常用到的代名词就是压力测试。大家理解的压力其实就是负载，负载就是压力。以上众多的测试方法无外乎是通过某种手段以某种规律改变系统负载然后记录系统的表现。

功能测试主要是寻找软件的缺陷，而性能测试的三大目的是让被测系统在一定的负载下：

1.         寻找系统的缺陷（重要，紧急）

2.         评估系统的性能（紧急，不重要）

3.         瓶颈分析与性能调优（重要，不紧急）

2.1. 实现原理

既然众多的测试方法无外乎是通过某种手段以某种规律改变系统负载然后记录系统的表现，那么如何改变被测系统的负载呢？

需要有一个测试工具。这个测试工具唯一的作用就是尽可能快的发出请求包。连续的两次请求操作中间没有Think Time，收到被测服务的响应后随即发送下一次请求。这样的结果就是被测服务处理多快，我们的测试工具就能请求多快。

当一个连接建立后，发送出去的一次请求在处理时，这个连接是处于一直等待中。这个时候吞吐量和响应时间是成倒数的。由于响应时间是被测服务处理能力决定的，那么吞吐量也就定了。因此，只有提高测试工具并发连接数，继而提高发包速度，才有可能达到调节被测服务负载的效果。

测试工具实现并发连接后最终效果一般是Ramp-Up的方式，即会有一段很明显的负载上升期，然后逐渐趋于稳定，测试结束时会有一段时间的负载缓慢下降。因为客户端并发请求间一点细小的时序差别，经过服务器处理后，往往会被放大。Flat方式是指同时并发发出请求，这样做的效果会是吞吐量曲线呈现如海浪般的波峰与波谷，然后趋于平缓。要想单台机器单个网卡从真正意义上实现Flat方式的并发访问比较困难，从微观上来看，数据包总是按顺序一个接一个发到远端的。更重要的是，这种Flat的访问方式并不符合一般真实的访问行为，不适合作为容量测试的测试手段，但可以作为可靠性测试暴露系统缺陷的手段，这种方法也叫峰谷测试。

2.2. 数据搜集与统计

2.2.1.    指标数值的获取和处理

最直接反应被测服务的处理性能，可以通过被测服务在每处理完一次请求后打印一行日志：精确到秒的时间戳|成功失败标志|处理耗时。有了这个原始的数据我们就能计算出每一秒该服务的处理请求数，这就是吞吐量。

有时候因为实现简便，往往在客户端对吞吐量进行统计。然而需要注意的是，在客户端统计的吞吐量是受到客户端自身处理性能以及网络情况等因素影响的，当这些因素影响不大时才可以通过客户端去统计吞吐量数值。

被测服务的处理耗时也属于响应时间。然而有时候我们更关心调用服务用户端的响应时间。这个响应时间包括：客户端发包处理耗时+发包网络传输耗时+被测服务处理时间+回包网络传输耗时+客户端收包处理耗时。这个响应时间就可以在客户端进行搜集和统计。

为了更精确的统计，需要丢弃测试开始ramp-up上升和测试结束吞吐量下降这两部分数据，只取得测试执行比较稳定后发包和回包相当随机时的数值。

在搜集数据时，同样的测试最好执行多次，简单一点就是取平均值，或者取某一次比较有代表性的数据。

当系统连续几次执行结果差别很大时，排除掉不应该引入的网路不稳定等因素，这个系统大多是存在缺陷的，这样的数据对于评估系统容量来说无太大参考价值，可以对其先做稳定性测试，排除掉导致系统不稳定的缺陷。

2.2.2.    数值的计算

90%响应时间：假设有100个不同大小的响应时间数值，把它们从小到大排序，那么第90个数值就是90%响应时间。如果把这个值设置为超时阀值，那么超时率就是10%。如果系统允许5%的超时率，那么就最好计算95%响应时间。表示的是有95%的几率在这个时间内返回。

70%的吞吐量集中区间：通过统计15%和85%的吞吐量边界值，计算出70%的吞吐量集中区间。这样计算可以排除掉+-15%的噪点。并且可以不需要绘制图表也能判断这段时间内的吞吐量是否稳定。

2.2.3.    统计原始数据

将搜集到的原始数据用表格方式统计出来。

原始数据统计表：

测试开始时间

测试结束时间

用例名称

发包总数

失败总数

最大吞吐量

最小

平均

通过统计15%和85%的吞吐量边界值，计算出70%的吞吐量集中区间

最大响应时间

最小

平均

90%

被测服务器cpu利用率

被测服务器iowait

测试机器cpu利用率

原始数据作为下一步分析的前提，是非常重要的，所以我们在测试过程中一定要保留完整和充分的数据。这样可以避免我们将来回头分析历史数据的时候，发现缺少必要的数据，就得重新回归测试。如果环境已经无法重现，那此次测试数据的参考价值就荡然无存。

       需要特别注意的是，我们必须把搜集到的日志、截图等，连同详细的说明一同记录到excel表格里，并且用第三人能看懂的方式汇总提炼和分类，方便日后其他对测试原始数据关注的人查阅和分析。

如表中所示，每一个字段都是根据经验精心挑选出来的，增一个则多减一个则少，对于一般的容量测试、可靠性测试，通过这些数据和黑盒测试方法能定位出大部分的性能问题。

2.2.4.    常用图表的画法

因为每种测试方法的执行方式不同，测试目的不同，所以测试结果的表述也会不同。我们会采用不同的图表，包含不同的性能指标数值去描述这次性能测试的结果。

好的图表可以清晰简明的表述系统情况。数值得全，以备后续分析，避免无谓的重新测试；但必须去掉任何没有价值的数据，数据太多了问题往往不能被轻易发现。

图表不是必须的，根据测试目的以及我们对原始数据的观察，提出我们的猜想，图表是用来作为论据证明我们的猜想是正确结论的。因此，若是绘制完的图表如果跟你的论点没有关系，请果断删除掉。

2.2.4.1.       性能曲线图表

数据表和图的配合可以方便我们执行容量测试时找到评估系统容量的数值。

2.2.4.2.       吞吐量曲线图

可以直观表示在不同负载下，系统处理性能的稳定性。稳定性测试，基准测试常用。

2.2.4.3.       响应时间分布图

可以直观表示响应时间的分布情况，容量测试、基准测试常用。

2.3. 检查、修正、调整测试方法

检查数据，我们可以从以下几点出发：

l  有没有失败的请求？先确保脚本的正确性：比如组的包内容正确吗？压测前你真的查看过日志保证这个包真的正确处理了吗？检查完确定不是脚本的问题后，就要评估失败率对测试结果的影响。失败率是否是预期结果，不是的话是否需要解决问题后修正数据？

l  有没有数据不全的情况？一般是测试脚本运行中有异常，导致测试终止，数据缺失。

l  测试运行的时间、发包总数是否与预期一致？这个是最基本的，如果这个都无法保证，这个数据谁还信呢？

l  有没有不符合正常规律的数值变化？这就需要有一定的经验积累了。

总而言之，我们检查数据的目的只有一个：排除掉任何可能因为测试方的原因导致的问题，保证测试数据充分、真实、有效。

当我们检查完数据，根据不同的情况，调整方法，补充和修正测试结果：

Ø  如果发现获取的数据量不够，需要补充测试用例继续测试；

Ø  如果发现客户机对服务器产生的负载不足以将其压满（服务器CPU空闲大于20%），且客户机空闲（CPU空闲大于20%），需要继续提高负载继续压测；

Ø  如果发现客户机自身处理能力已经饱和（CPU空闲小于10%），而服务器仍然空闲，需要采用多台客户机进行压测；

Ø  容量测试时，当相同条件下每次测试获取到的吞吐量平均值波动很大或者吞吐量集中区间很分散，需要对被测系统进行稳定性测试或可靠性测试。我们一般在测试需求沟通时就应该确定测试方法。有稳定性或可靠性问题的系统需要先解决缺陷或是缺陷在一定可以接受的范围内不影响系统可测性，才能进行容量测试；

Ø  负载测试获得的数据一定是平滑的，如果有明显的噪点（特别高或者特别低）都是由于系统不稳定导致的。当负载测试的结果用做容量评估时，需要在异常数据负载下多次测试直到取得最普通的情况；

Ø  如果发现被测服务参数设置不当，或者设置了过小的阀值，需要修改设置重新测试。

下面是一个被测系统设置不当的案例：

连接数	平均吞吐量	平均响应时间msecs	最大响应时间msecs	最小响应时间msecs	CPU占用率%
1	83	8.77	9000.48	0.61	3
2	83	18.82	9001.01	0.60	5
4	83	36.89	9004.78	0.61	9

这是一次负载测试结果。通过观察最大响应时间，我们发现，该服务的最大响应时间基本恒定，因此我们可以推测系统可能设置了超时阀值9秒。

在容量测试中，我们需要取消这样的阀值设置，然后根据我们测试出来的系统容量反过来去设置合理的阀值。比如在这个案例中，我们取消超时阀值设置后，如果被测业务允许10%的超时率，那么我们统计90%响应时间的值就可以作为参考的超时阀值。

当然，有时候我们已经明确上线后的超时阀值，不需要做性能调优，那我们的这次设置了阀值的测试结果仍然是有参考价值的，不需要取消阀值再测试。

下面是一个被测系统不稳定的一个案例：

这是一次负载测试结果绘制的系统曲线图，我们可以看到图中在64并发连接处有噪点数据，导致绘制的系统曲线图不平滑。

负载测试获得的数据一定是平滑的，如果有明显的噪点（特别高或者特别低）都是由于系统不稳定导致的。当负载测试的结果用做容量评估时，需要在异常数据负载下多次测试直到取得最普通的情况。

在这个案例中，我们需要在64个并发连接数负载下多次测试，取个普通值。

容量测试时，当相同条件下每次测试获取到的吞吐量平均值波动很大或者吞吐量集中区间很分散，需要对被测系统进行稳定性测试或可靠性测试。我们一般在测试需求沟通时就应该确定测试方法。有稳定性或可靠性问题的系统需要先解决缺陷，或是缺陷在一定可以接受的范围内不影响系统可测性，才能进行容量测试。

2.4. 分析定位

对数据的分析是需要大量实战经验的，因为你会发现每次做测试，都会遇到各种各样的系统性能特征数据。因此，我选择了几个典型的实例给大家一些思路。

分析前，需要了解一些基本的性能原理：

客户端压测工具是用来发送请求产生对被测系统压力的。被测系统接收到请求并处理，自身就会达到一定的负载。我们需要有一种方式去定量的评估当前系统的状态，最简单直接的是通过观察被测机器CPU占用率。只要被测服务代码一直在做有效的操作，那么CPU占用率越高就表示系统接收到的压力越大，系统当前承受的负载越高。

容量是指服务在满负载的情况下最优处理能力。处理能力一般我们使用吞吐量和响应时间去衡量。吞吐量就是每秒服务器所处理完成的请求数。响应时间就是完成每次请求耗时。当客户端与服务器只建立了一个网络连接的情况下，发送请求后就只能等待服务器处理完成后返回，那么响应时间与吞吐量必定互成倒数。因为服务器在完全空闲的情况下处理每个请求的净耗时是恒定的或者说是不可以控制的，那么要增加对服务器的压力，使服务器产生更高的负载，每秒处理的请求更多，只有一个办法，就是提高并发连接数。

2.4.1.单台客户机和单台服务器的容量分析

先给大家介绍一个最简单的测试系统。这个系统包括一台施压用的客户机和一台部署了被测服务的服务器。如下是一般情况下的负载测试数据：

开始时间	结束时间	并发连接数	请求总数	失败总数	平均吞吐量	90%响应时间(ms)	客户机CPU占用率(%)	服务器CPU占用率(%)
13:20	13:21	1	39081	0	651	0.72	17	52
13:22	13:23	2	58412	0	973	1.04	26	82
13:27	13:28	4	70332	0	1172	1.69	34	96
13:29	13:30	8	70402	0	1173	3.07	35	100
13:31	13:32	16	70615	0	1176	7.11	43	100
13:33	13:34	32	70569	0	1176	20.22	51	100
13:34	13:45	64	70433	0	1173	50.81	71	100

一般规律：

当测试模拟的负载从连接数1开始翻倍增加时，系统处于低负载区，吞吐量和资源利用率与负载同倍增加，响应时间在被测服务处理能力仍有很大空间的情况下应保持恒定，若系统处理能力一般响应时间随负载增加而微升也属于正常。如图表并发连接数1-4所示，此时系统状态特征为低负载；

当通过提高并发连接数继续提高对被测系统的负载时，平均吞吐量和资源利用率保持稳定，此时响应时间随负载同倍增加。如图表并发连接数4-16所示，此时系统状态特征表示为高负载。高负载时CPU占用率接近100%说明该系统资源利用率高，处理性能已经饱和；

此时继续提高对被测系统的负载，资源利用率与吞吐量一起下降（过多的竞争等待带来的性能耗损），响应时间以更快的速度增加，此时系统状态表现为超负载。

当系统从低负载进入高负载区的临界负载下，我们获取到的系统处理性能指标：平均/峰值吞吐量和90%响应时间，这个就是系统处理性能的最优值，我们把它定为该系统的容量。

整个过程中，客户机的资源利用率都小于80%，说明没有因为客户机自身处理性能受限而限制服务器达到最优的处理能力。

注意：

使用2N并发连接不一定就是使用N并发连接施压测试出来的服务器性能的2倍。

这个倍数是性能扩展系数。系数为2，是服务器性能的理想值。往往被测服务达不到如此理想的性能扩展系数，多少都会随着负载的上升因为资源竞争而对处理性能有更多的耗损。

2.4.2.多台客户机和单台服务器的容量分析

很多情况下服务器能处理的负载要比单台客户机能产生的负载要高，那么我们需要多台客户机去产生足够的压力来测试服务器的处理能力。

如下数据显示一台客户机因为自身处理性能受限而限制服务器达到最优处理能力：

并发连接数	平均吞吐量	90%响应时间（毫秒）	客户机CPU占用率（%）	服务器CPU占用率（%）
1（单台客户机）	5682	0.11	37	15
2（单台客户机）	8880	0.19	34	21
4（单台客户机）	14654	0.24	49	31
8（单台客户机）	18438	0.38	87	33
16（单台客户机）	23940	0.56	81	34
32（16*2台客户机）	45450	0.60	84	52
64（16*4台客户机）	61715	1.00	91	61

为了更有效的利用测试机资源，我们可以效仿对服务器容量的评估方法，尽量找到客户机的容量。一般达到CPU占用率90%足够了，再高就会导致压测程序自身处理不过来带来的延时误差，并降低发包速度，继而降低对被测系统产生的压力。

我们让两台客户机分别以自身最优的效率发出请求，产生压力。为了方便统计和对比，我们最好选取两台软硬件一致的机器。两台机器的平均吞吐量可以相加，平均响应时间可以求均值。这样可以平滑的模拟成一台两倍处理能力的客户机。

注意：

一台客户机使用2N并发连接和两台客户机分别使用N并发连接测试出来的服务器性能不一定相同。

当这两种情况下客户机对被测服务器造成的压力相当时，服务器表现出来的性能必定一致；如果不一致，则说明两种情况下的客户机对被测服务产生的压力不等。不等的原因就在于客户端测试工具自身性能从N到2N并发连接时，性能有衰减。这个倍数是性能扩展系数。系数为2，是性能扩展的理想值。我们可以通过这种方式，测试出测试工具自身的性能优劣。一般在CPU利用率大于10%的情况下，好的测试工具应保证性能扩展系数接近2.选择或者开发测试工具时需要注意提高工具自身的处理性能，这样可以减少客户机的台数，降低测试成本。

综上所述，在机器性能规律上，其实客户机和服务器并无区别；多台客户机对比单台客户机测试，在性能数据分析上需要考虑和区分客户机和服务器自身性能的因素对测试结果的影响，相对更加复杂。

2.4.3.单台客户机多台服务器瓶颈分析和定位

互联网应用大多数系统是分布式部署的，那么在被测系统中必定存在多台服务器。如何让多台服务器组成的系统能更高效的提供服务？我们要对多台服务器组成的系统进行性能分析，找出整个请求链路中制约性能的关键点所在并优化。当优化了这个关键点后，系统性能必定得到相应的提升，在整个请求链路中会出现新的制约性能的关键点，然后再优化，再寻找再优化。这里提到的所谓关键点就是系统的性能瓶颈。

举个例子：高速公路上的车辆以一定流量行驶到收费站时，需要等待一定的时间，这个收费站后面的车辆流量就相应少了，以后每过一个收费站，车的流量就减少一次。当我们提高某一个收费站收费速度或者干脆撤去，那么下一个收费站的车流量马上就增长了，又成为了新的瓶颈。

如下是某次测试结果：

客户机		服务器1		服务器2
CPU占用率(%)	磁盘利用率(%)	CPU占用率(%)	磁盘利用率(%)	CPU占用率(%)	磁盘利用率(%)
35	4	30	0	78	100

测试请求是顺序经过客户机和每台服务器的，每台服务器上部署了多个相同或者不同功能的服务。我们可以看到此系统，客户机很空闲，被测服务（服务器1）的CPU占用率只有30%，说明服务负载并不高。该系统瓶颈得往后分析，我们再看发现服务器2的磁盘利用率已经达到100%了，说明服务器2上的服务是该系统的瓶颈。我们可以采取减少磁盘IO的方法进行优化，但是服务器2的CPU占用率已经接近80%，没有太多的性能上升空间了。

2.4.4.稳定性测试分析和问题定位

2.4.4.1.       吞吐量稳定性分析

当相同条件下，每次测试我们获取到的吞吐量平均值波动很大或者吞吐量集中区间很分散，我们需要对被测系统进行稳定性测试。我们一般通过绘制系统高负载下的吞吐量曲线图来分析。为什么要高负载？负载越高，问题特征越明显。为什么不能过载？过载的系统必然稳定性很差。

在稳定性分析时，只要我们掌握了系统性能变化规律和本质，测试人员就能通过黑盒测试的方法帮助开发去定位问题。即使受到开发的挑战，也能有理有据坚持结论，始终保持严谨的工作态度。

我们先看一个真实的案例：

这是WAP页面压测的吞吐量曲线图：

根据曲线图，测试人员给出的结论是：

吞吐量最大波动为75%，系统性能不稳定，需关注和优化。

开发人员的挑战：

测试人员的测试方法是测试2分钟，按每秒钟的吞吐量来绘制吞吐量曲线。但是在我们的业务中，有少部分网页（不超过10%）需要即时下载，处理的时间相对会比较慢。从测试数据来看，最长的处理时间达到14s。因此在统计步长较短的情况下，这些奇点数据对单位时间的吞吐量会有较大的影响。从而吞吐量曲线有一定的波动。另外，发现64并发的吞吐量还高于128并发的。这里是否也存在数据污染的问题？从连接时间来看，这里正好是一个临界点。建议可以多分析一下。

测试人员针对开发的质疑给出了详细的分析：

1.少量网页（不超过10%）：稳定性测试的时候用的是256个并发连接，即使有10%需要下载，那吞吐量波动也只是10%而已，而且应是均值下降（每个连接随机需要下载）。现在的现象是全部连接突然下降70%，下载影响的原因不成立。

2.64并发高于128并发吞吐量：这个数据正好说明了被测系统存在不稳定性。此次统计的吞吐量数据是平均值，每次测试时间1分钟。正常情况下并发连接数增加时吞吐量应相应增加，但在系统不稳定的情况下，平均吞吐量波动较大，绘制的性能曲线不平滑。本次测试，我们只能通过多次测试找到平均值。

以上2点充分说明该系统的稳定性是不够的。

谜底揭晓：

系统确实存在不稳定因素，原因是JVM的垃圾回收机制。通过调整堆初始内存大小，有效地降低了吞吐量的波动。

以下是问题的定位分析和解决过程具体细节：

测试使用不需要即时下载的页面，重新测试的结果显示平均吞吐量有了10%的提升，但吞吐量仍然有60%的波动。这正好印证了之前10%页面下载时间长对性能曲线影响的分析。

排查后发现，这些瞬间的抖动是因为JVM频繁的Full GC 造成的。查询日志发现，2分钟测试期间一共发生了5次Full GC，每次0.5s左右。而Full GC会"stop the whole world",从而导致Full GC瞬间的吞吐量暴跌。检查Resin的启动参数，发现参数XMS（即初始堆大小）设置得比较小。由于这个页面的特点是会产生非常多的临时对象，导致新生代很快用完，从而触发Full GC。调整XMS参数到1400m后，再次启动压测，2分钟内基本上不会产生Full GC.

从上图可以看出，波动已经控制在+-15%以内，比以前有很大改善。由于micro GC也会导致服务暂停，因此小范围的波动是不可避免的。而且一般的micro GC时间都在0.1s以下，对业务的影响可以忽略不计。由于调大XMS可能会导致单次Full GC时间变长。后续会根据实际上线情况考虑是否改用CMS GC，牺牲吞吐量来保证业务的平滑性。

2.4.4.2.       内存稳定性分析

很多重要的后台服务可能存在内存泄露的问题，需要在高负载下长时间测试观察系统的内存情况来分析。

我们需要获取服务器启动前，服务启动后，服务运行中1分钟、10分钟、1小时、8小时、24小时。。。N天连续运行时的系统内存情况与服务所占内存情况。测试过程中需留意服务有没有被重启，coredown，等异常。

正常情况内存的变化情况是这样的：服务启动前，系统内存有个初始值；服务刚启动后，会瞬间改变系统内存占用情况；服务占用的内存随着时间的推移逐渐增大直到最后趋于稳定。这个平衡的过程所需的时间长短与系统负载大小有关，负载越大时间越短。

如果发现服务占用内存长时间内持续增加，我们需要测试出服务最终因为内存不足而终止的时间和表现。

获取系统内存情况可以使用TOP工具，使用M对程序占用内存大小排序监控当前系统最耗内存的进程运行情况。如下是汇总数据表范例（数据非真实）：

可以通过二级网管监控获取某台服务器长时间的内存使用情况：

2.4.5.可靠性测试分析和问题定位

可靠性测试也可归属于在系统高负载下的后台功能测试、系统测试。一般可靠性测试关注的主要有失败率和丢包率。大部分系统可靠性问题都能通过这两个数据暴露出来。

当被测系统出现失败的情况，我们如何用图表展示出系统的特征？请看某后台服务实例：

以下是1分钟失败率分析的报表：

如此我们就能让读者了解随着系统负载的上升服务失败率的变化情况。

失败率验证的是系统提供服务的正确性，是最容易被发现的。在系统高负载的情况下，某些系统会偷偷的丢弃了某些请求包，返回的结果往往都是正确处理的，因而容易被我们忽略。为了更准确高效一举定位系统丢包环节，我们需要在客户端和被测服务处理的关键环节输出日志，并汇总统计。比如像移动支付系统的丢包率分析，因为支付涉及到钱，需要严格保证所有请求都精准处理，包括对账日志需要正确，数据库记录也需要匹配。

3.1. 常用性能测试工具介绍

如下是业界一些常用的性能测试工具特性的汇总：

大家可以根据需要选择满足自己需求的工具进行测试。

3.1.1.HTTPLoad

网页容量测试的新手入门推荐使用HTTPLoad小工具。

优点：

1. 作为压力工具，简单易用，性能高。

2. 可以设定预期吞吐量，自动调节并发连接数，提供稳定的压力，来做稳定性压力测试最合适不过。

缺点：

1. 没有写日志，测试后无法获取每个请求的测试数据，并且自动报表统计的是平均值，无法统计客户端响应时间分布，无法统计吞吐量曲线图。

2. 被测对象只能通过链接来指定，无法进行复杂逻辑测试，不支持post数据。

支持两种模式：

l  -rate 是设定预期的吞吐量，自动调整并发连接，

l  -parallel 是设定并发连接数，测试吞吐量

-seconds 是设定执行多久

使用范例

用法一：./http_load -rate 100 -seconds 60 url.txt

用法二：./http_load -parallel 8 -seconds 60 url.txt

查看报表

格式如下：

5984 fetches, 34 max parallel, 1.4801e+07 bytes, in 60.0017 seconds

2473.44 mean bytes/connection

99.7305 fetches/sec, 246677 bytes/sec

msecs/connect: 56.0959 mean, 3054.97 max, 55.217 min

msecs/first-response: 94.9067 mean, 606.685 max, 55.861 min

HTTP response codes:

  code 200 -- 5966

  code 403 -- 18

3.1.2.自研压测工具Beetle

采用Apache MINA网络应用框架，打造了一个实测可以支持超过20000tps发包速度的性能测试框架Beetle。可以通过编辑Python脚本实现测试逻辑；支持动态调整发包内容；可以设置并发数，连接数，定额发送包，对发包速度进行流控，等。使用Python脚本调用Beetle提供的扩展库可以实现对多种协议收发包的支持，目前支持的协议有HTTP、TCP/UDP和WUP(TAF TCP/UDP)，基本覆盖无线业务系统各种业务后台性能测试的需求。

3.2. 性能测试工具开发要点

性能测试工具自身的性能是非常重要的，在计算响应时间的时候，测试工具自身的处理耗时也会被计算进去。之前提到过，测试工具唯一的作用就是尽可能快的发出请求包。连续的两次请求操作中间没有Think Time，收到被测服务的响应后随即发送下一次请求。这样的结果就是被测服务处理多快，我们的测试工具就能请求多快，且当服务无响应时，工具能迅速检测到。当工具请求速度不够快时，可能需要更多的机器并发的运行多个测试客户端，增加对资源的浪费。

需求搜集是开始一个性能测试任务的第一步，目的就是要充分沟通需求：什么是提测人真正关心的？什么是被测系统需要测试的？不是提测人提出来的需求都会成为被测项；也不是全部被测项都是提测人提出来的。只有对被测系统充分了解后，才能有针对性的选择被测对象，进行方案和用例的设计。

4.1. 沟通矩阵

需求搜集和方案设计是整个性能测试流程中最重要的一步。由于沟通不充分导致方案制定错误，白白浪费了测试时间，回头再来修改测试方案，这种情况是刚开始做性能测试的新手经常遇到的情况。最理想的情况就是一次就能完成充分的沟通，正确的理解系统，并制定出合理的方案。全部干系人凑在一起面谈需求，短时间内需要搜集的信息很多，这会使刚开始从事性能测试的新手茫然，不知从何下手。

如下的沟通矩阵可以帮助大家有个清晰的思路：

性能测试需求沟通矩阵

重点	明细	成果
了解背景	项目开发进度或重构优化的重点；测试最早开始日期，测试最晚完成日期；技术负责人	确定测试时间周期，项目干系人
需求搜集与定义	被测对象，测试类型，性能预期	用专业术语定义原始需求（对方的需求）
被测对象分析	被测模块在系统中的部署，组件类型，业务逻辑，与IO有关的操作	确定测试对象和测试类型（根据对系统的了解对对方的需求进行补充或裁减）
了解协议	测试接入点与被测服务通讯的协议	确定测试工具。
选择用例	根据被测对象的特性和测试类型列举用例，考虑时间成本和重要程度优先级选择用例	确定用例。明确每个参数在测试时具体值，固定值或随机值范围
模拟测试环境	可测性，测试数据准备，机器数量	确定机器到位和测试环境搭建期限，环境准备事项列表

       这几部分不是严格按照流程排序的，可以穿插进行。随着对被测系统的了解加深，逐步修正沟通成果，达成测试方案，根据测试方案制定测试计划。

沟通完毕后，根据沟通结果整理出接下来需要开发配合进行的环境准备事项列表。

如下是针对沟通重点的一些具体分析方法：

4.2. 了解背景

了解这个测试任务的紧急程度，为了合理安排测试时间。

了解被测模块的开发进度，性能测试需要在代码开发完成、功能测试与回归测试结束后，测试环境无其它人使用的情况下进行。不允许边开发边测试。

了解优化的重点，可以有针对性的设计用例。

了解干系人，知道什么事情跟什么人沟通，报告提交给谁。

4.3. 需求分析和需求定义

往往提需求的人对需求的描述是他自己的语言，我们需要用专业的指标来定义他的需求。原始需求常出现的关键字有：“并发量，日PV，并发用户数，性能测试，压力测试”，等。首先我们要清楚测试类型的定义及与其相关的指标，继而引导提需求的人定义需求。

日PV可以计算出平均每秒的处理请求数，得出平均吞吐量取值，其两倍值为峰值；并发用户数，对应测试请求中携带的用户标识个数，数据库或内存中保存的用户记录数，并发连接数；并发量，一般可以理解为吞吐量。

最常见的性能测试类型（或方法）有五种：容量测试，可靠性测试，稳定性测试，基准测试，并发测试。

l  容量测试：使用负载测试方法，通过逐步提高对被测系统负载，用峰值吞吐量和90%响应时间来评估系统容量。这个过程包括对系统性能瓶颈的定位，性能调优，使资源利用率最大化，给出系统最优情况下能承载的最佳性能指标。

l  可靠性测试：通常使系统达到稳定的高负载后，持续压测10分钟以上。评估点主要有：失败率、掉线率、丢包率、超时率，业务是否异常。

l  稳定性测试：通常使系统达到稳定的高负载后，持续压测10分钟以上，观察吞吐量曲线稳定性。

l  基准测试：获得系统在某种特定的条件下（包括特定的负载条件下）的性能指标数据。与容量测试不同的是，这个值不是系统容量。

l  并发测试：根据手段可以分为几种。【基准测试】：大量并发连接，看服务处理的响应时间是否正常；【稳定性测试】：被测系统在频繁建立和释放连接情况下系统是否能持续提供服务；【可靠性测试】：并发用户在一定高负载下同时访问临界数据，暴露系统缺陷；【暴力测试】：获取导致系统暴露缺陷的并发连接数。

这个几个测试类型执行的顺序：一般先做可靠性测试、稳定性测试、并发测试等，保证系统运行没有功能性缺陷后才进行容量测试和基准测试。

4.4. 被测对象分析

被测对象分析最关键的是要抓住一切与IO有关的操作。因为CPU的运算速度跟IO的存取速度不是一个数量级的。只要有严重的IO耗时都需要纳入到被测试对象的路径中被覆盖到。

文件读写

日志是同步还是异步的。日志级别需要设置成与正式环境一致。对账日志需要进行稳定性测试确保无误。

数据库读写

数据库类型：MYSQL，TDB，TAF DB。数据规模：数据长度与总记录数。查插删改操作的比例。查询需要准备一定规模的数据量和建索引，不能重复查询同样的数据。插入操作可以不准备测试数据，不能重复插入同样的数据。修改的性能直接由数据量和索引的多少决定。删除操作单独测试的很少。

网络调用

分布式服务以及测试客户端必须部署在同一网段内，避免网速成为瓶颈或导致结果不稳定。当大部分时间消耗在网络传输上时，需要的客户机资源也会相应增多。

缓存

缓存类型：MMAP，TAF DCache。增量或全量加载频率，回写策略。数据长度和数据量。数据访问算法。关注缓存的机制主要是为了判断是否要作为测试对象。如果有缺陷风险，需要测试稳定性。否则一般进行容量测试，测试全命中、不命中，或者指定命中率的容量。如果有全量加载的操作，可以考虑做基准测试，给出全量加载时用户的体验。

协议的长短连接

长连接要考虑一般情况下的并发连接数；短连接要考虑并发测试，测试大量连接建立和释放的稳定性，拒绝服务攻击等。

另外，还要注意有没有大内存排序等操作。

如果是成熟的组件，可以不作为重点测试对象。

4.5. 用例选择

根据测试类型的不同来选择测试用例。

容量测试一般在如下三种类型中分别只选择1个用例来测试：

1.         被调用频率最高的；

2.         覆盖业务逻辑最多、性能可能最差的；

3.         性能最优的。

这样可以根据测出来的基准值区间，接口调用比例，估算业务模型下的性能情况。

可靠性测试可以考虑最有运营特征的。

记住：不是所有接口都需要测试性能。性能测试的用例选择只跟性能有关系，一切与性能无关的东西都可以不考虑。

4.6. 测试环境模拟

做性能测试的理想环境就是与正式运营环境一摸一样。可惜的是，我们很少能够做到。唯一能做的就是尽可能的接近真实，以最小的代价来模拟。

环境检查表

测试数据准备完毕，数据库结构与正式环境一致，并建立了相关索引（可选）

被测接口经过自测且功能正常

测试环境没有连接到运营环境

测试环境连到网管系统（可选）

日志级别正确：测试环境日志级别须与正式环境一致

测试环境部署的服务版本及其配置必须与正式环境发布的一致

被测模块已经完成开发，且通过了功能测试

测试环境没有别人使用

客户机和服务器在同一网段内

容量测试必须准备与正式运营服务器硬件配置相同的测试机器

被测服务没有设置流控，最大并发数或其它影响性能的阀值限制

服务器与客户机台数

正常情况下同样的硬件配置部署服务的性能应该比部署压测工具的性能要好，最经常出现的是客户机压不满服务器的情况。因此当有多台对等的服务器通过负载均衡提供服务的时候，我们只需要在系统中部署一台同样功能的服务器即可。后期可以通过测试N台服务器的扩展性规律与基准值来预估系统扩容可以达到的容量。

可测性

在一个请求的处理链路中，途经的模块都可能成为瓶颈。容量测试时，我们需要让瓶颈出现在被测对象身上，而非被其调用的其它模块上，只有这样才能把被测对象“压满”。这种情况下，可以根据需要对其它模块进行模拟。容量测试时为了尽可能接近真实的系统，被模拟的模块往往只是一次空操作的调用；而可靠性测试时，可能需要模拟该模块的处理延时，以发现更多的问题。屏蔽与模拟一次空操作的区别就在于一次调用的开销，屏蔽实现起来简单，但需要直接修改被测模块的逻辑，如果被屏蔽的模块实际开销很大，不建议采用。

有时候为了使系统可测，必须对某些业务逻辑进行修改，比如强制不缓存。修改这部分逻辑来达到系统的可测性。

流控

很多服务框架都可以设置流控，在容量测试时，需要取消这个限制，否则测试结果可以直接根据流控参数计算出来，根本不需要多此一举。

测试数据准备

尽量与实际运营环境一致。主要考虑的是数据量对性能的影响。

Ø  沟通过程中，始终铭记在心的一点：提需求的人，必然是贪婪的。而我们只能在有限的时间内把最重要的事做好。

5.1. 性能测试模型

全新的性能测试流程，适应敏捷开发流程，比业界现有的性能测试模型更高效：

5.1.1.需求分析和方案计划

       性能测试任务可以在电子流程中进行管理。测试申请人提交的性能测试申请需要包含如下内容：

1.         项目开发进度或重构优化的重点；

2.         测试最早开始日期，测试最晚完成日期；

3.         被测对象，测试类型，预期；

4.         技术负责人

接口人接到测试申请后，指定测试人员安排测试。接受性能测试任务的测试人员找技术负责人做面对面的需求沟通。

需求沟通完毕后，测试人员根据《性能测试需求分析和方案计划模板》填写《XXXX项目性能测试需求分析和方案计划》初稿，推送给项目相关人员进行评审，主要关注：项目计划时间安排是否合理，方案是否可行，需求定义是否正确，以及接下来需要开发配合进行的环境准备事项列表。测试人员对有异议的地方进行修改并更新。

评审通过后，测试人员上传《XXXX项目性能测试需求分析和方案计划》到文档系统存档，邮件推送。邮件标题为“【性能测试需求分析和方案计划】XXX项目”，邮件主送申请人和项目组，抄送任务关注人。

为了尽可能详细的记录测试过程细节，最快的反馈进度和过程数据，建议由测试人员发起一篇在线更新工作帖，比如通过KM。工作帖开头的内容最好是《XXXX项目性能测试需求分析和方案计划》，推送链接方便评审，提高效率。

5.1.2.环境准备

测试人员把《性能测试环境说明模板》发给准备环境的责任人，进入测试环境准备阶段。

测试环境准备完成后，由准备环境的责任人上传《XXXX项目性能测试环境说明》到文档系统存档，邮件发送给测试人员，测试人员准备开始测试。

5.1.3.测试执行

性能测试过程中由测试人员实时在线更新工作帖的内容，可以即时反馈测试进度。

格式如下：

测试环境部署

测试日志与测试结果

按天分组，描述每天工作内容，遇到的问题和解决方法，与当天测试结果。

测试结论

汇总前期测试结果，分析得出结论。

性能测试操作步骤与文档输出：

1. 验证环境，调试接口，编写测试脚本或开发测试程序。调试接口、编写脚本或开发程序通常可以在开发环境上和环境准备并行；

2. 执行、结果搜集、统计。常用统计表格与图表范例请参考性能测试报告模板；

3. 分析，反馈，输出《XXXX项目性能测试简报》，格式见模板；

4. 回归测试，重复2-3步；测试过程中对系统的了解不断深入，应即时调整方案和计划，更新工作贴；

回归测试的粒度：每一次执行全部用例，除非遇到问题导致测试执行不下去为止。

如果测试过程中发现系统缺陷，测试人员需要及时跟开发人员确认问题，开发人员可以对帖子进行回复，内容包括：现象，分析，解决方法，解决计划。开发不能马上修改程序，需要等此次测试结束后对发现的问题进行总结并记录，统一修改，然后进行下一轮回归测试。在测试过程中如需要修改程序，容量测试过程中如需要修改系统配置参数，开发必须事先通知到测试人员，做好记录。

发送邮件测试简报的粒度：以一次或多次完整的回归测试结束为准。根据开发反馈的解决方式的工作量，能在1天内完成多次回归测试可以将当天几次的测试结果整理到一起发送简报。

5.1.4.文档报告

根据最新的测试方案和测试计划，汇总测试结果，撰写《XXX项目性能测试报告》。

测试人员将《XXX项目性能测试报告》上传文档管理系统归档。

邮件发送测试报告，正文摘要包括以下部分：

测试结论

已解决问题

遗留问题

感谢语

附件带上测试报告或者文档归档路径。

5.1.5.  回访总结

测试完成当天，新建标题为“【性能测试满意度调查】XXX项目名称”，详见《性能测试满意度调查模板》，通过RTX和邮件推送调查，主送测试申请人和项目组成员。

及时主动跟进调查反馈情况，搜集和统计调查数据。

在系统上线后的当天，一周，一个月，搜集性能测试效果：是否有性能测试没有发现的问题，如何处理的，为何当初性能测试没有发现，等。在相应KM工作帖里记录性能测试回访结果。

系统上线一个月后，完成《XXX项目性能测试回访报告》。

发送邮件，标题为“【性能测试回访报告】XXX项目名称”，邮件主送申请人和项目组，抄送任务关注人。详见《回访报告模板》。

       设置性能测试回访这个环节，目的是为了注重性能测试团队自身的知识积累与提高：

l  通过运营数据证明测试数据和方法是真实有效的；

l  通过满意度调查证明测试服务是让人满意的；

l  通过总结不断进步并分享让大家看到测试团队的成长；

5.2. 性能测试模板

5.2.1.需求分析和方案计划模板

{简要说明这是个啥项目，属于什么产品、业务，被测模块，当前开发进度，重构优化的重点，遇到什么性能问题，RDM测试任务链接，等。完成后请删除蓝色字。}

RDM测试任务请见：贴链接

1.1. 项目干系人

{列举项目干系人，包括：需求申请人，技术负责人，结果反馈对象，等。完成后请删除蓝色字。}

1.2. 测试时间范围

{测试最早开始时间，测试最晚结束时间，以及制约测试的重要事件比如开发完成时间和上线时间等说明。完成后请删除蓝色字。}

其他重要事件备注：

2.1. 需求定义

{范例：

被测对象：XXService；测试类型：容量测试；性能预期：吞吐量峰值大于xxx tps，90%响应时间小于xx ms

完成后请删除蓝色字。}

2.2. 被测对象与测试类型分析

{对被测项和测试类型的确定给出依据。描述被测模块在系统中的部署，组件类型，业务逻辑，与IO有关的操作等，据此给出相应的测试类型。对不被测试对象可能存在的风险进行评估。定稿前请将蓝色文字删除。}

2.3. 性能预期数据分析（可选）

{对以上性能预期指标的制定给出依据。如果业务已经运营，请对现有的业务的实际情况进行陈述，并给出业务将来的规模预期，推测出系统优化或重构后的预期。运营数据可包含：该业务的最近1月的PV、UV、流量，并计算峰值，平均值，至少1周；如果是新业务，请找一个有参照性的业务进行数据分析。定稿前请将蓝色文字删除。}

3.1. 测试工具

{说明测试接入的协议，选择测试工具。定稿前请将蓝色文字删除。}

3.2. 测试环境模拟方法

{为了保证系统的可测性，需要模拟相关服务（例如：扣费），屏蔽无关服务（例如：鉴权），修改代码逻辑（例如：强制不缓存），准备测试数据，等。每一项都必须描述因此导致的测试局限和风险，以及由于测试环境与正式环境的区别导致的测试结果差异该如何修正。定稿前请将蓝色文字删除。}

3.3. 测试用例

{简单列举你的用例，以及选此用例的原因和目的，测试逻辑，执行步骤。定稿前请将蓝色文字删除。}

{根据沟通确定该项目每个步骤的时间安排。完成后请删除蓝色字。}

{一般是安排5-10个工作日预留回归1-3天，参考时间：需求搜集、方案、计划与用例评审2天；开发测试程序3天；验证环境调试接口1天；自动化测试脚本编写1天；测试执行统计分析发出简报每5个接口需要1天；每一次回归需要1天；测试报告1天}

步骤	责任人	工作量（天）	开始日期	结束日期	输出物
需求分析、方案、计划与用例评审					《XXX项目性能测试需求分析和方案计划》、工作贴
机器到位（完成客户机和服务器机器申请、安装系统和软件）					提供1-2台客户机和N台服务器
测试环境搭建（部署服务，屏蔽或模拟服务，数据准备，打开和关闭日志，接口自测）					《XXX项目性能测试环境说明》
开发程序或编写脚本，调试接口与环境验证					可以执行的测试程序和脚本
一次测试（执行，简报）					阶段性测试简报（邮件形式通知到全项目组）；
回归测试（定位解决问题，执行，简报）		预留的时间			阶段性测试简报
测试报告					《XXX项目性能测试报告》

需要开发配合的环境准备事项列表：

{要模拟什么服务？要准备什么数据？要准备几台机器？协议文档，用例参数，等等。完成后请删除蓝色字。}

1.

2.

3.

5.2.2.环境说明模板

1.1.  测试环境部署图

{对系统架构图的每一个模块，以图的方式描述系统的测试环境部署，重点突出在机器的数量，IP，功能模块，模块间通讯的协议，测试接入点。定稿前请将蓝色文字和范例删除。范例：}

图1.1测试环境部署图

{如果正式环境和测试环境存在区别（比如机器数量），说明一下。定稿前请将蓝色文字和范例删除。范例：}

1.2.  机器信息表

{对测试环境部署图里的每一台机器，以单独的表格描述系统的测试环境部署，重点突出在机器的访问方式，部署在该机器上的模块，服务启停位置和方式，日志查看位置和方式。定稿前请将蓝色文字和范例删除。范例：}

客户机信息

服务器信息

SSH登陆IP	{SSH登陆IP}
模块或服务	IP和端口	服务启停方式	日志
{名称，基线版本，责任人}		{如果是数据库服务，请说明：数据库类型，数据库名，用户名和密码，数据表，等。以及数据库功能简单描述。}	{说明该模块日志内容，查看方法，日志类型是同步的还是异步的。是否滚动日志，测试过程中是否可以删除或清空，等。}

SSH登陆IP	{SSH登陆IP}
模块或服务	IP和端口	服务启停方式	日志
{名称，基线版本，责任人}		{如果是数据库服务，请说明：数据库类型，数据库名，用户名和密码，数据表，等。以及数据库功能简单描述。}	{说明该模块日志内容，查看方法，日志类型是同步的还是异步的。是否滚动日志，测试过程中是否可以删除或清空，等。}

{指定每个接口测试时参数的取值：定值或随机值取值范围。详细的协议文档放到附件中。范例：}

2.1.  接口名称

输入参数：

{int setUserAppData(int uin,AppData appData)

uin:用户QQ号，随机，但是要满足从5位QQ-10位后4位覆盖0-9999

appData.appId=1；业务的ID，固定值

{请根据检查项检查环境当前情况是否满足提交测试的需求。定稿前请删除蓝色文字}

检查内容	是■否□ 或不适用	如果选否请注明原因
测试环境已具备可测性： 模拟或屏蔽非被测模块； 修改业务逻辑（例如：强制不缓存）；	□
测试数据准备完毕，数据库结构与正式环境一致，并建立了相关索引（可选）	□
被测接口经过自测且功能正常	□
测试环境没有连接到运营环境	□
测试环境连到网管系统（可选）	□
日志级别正确： 测试环境日志级别须与正式环境一致	□
测试环境部署的服务版本及其配置必须与正式环境发布的一致	□
被测模块已经完成开发，且通过了功能测试	□
测试环境没有别人使用	□
客户机和服务器在同一网段内	□
容量测试必须准备与正式运营服务器硬件配置相同的测试机器	□
被测服务没有设置流控，最大并发数或其它影响性能的阀值限制	□

4.1.  参考协议文档

文件贴在此。

5.2.3.性能测试报告模版

5.2.3.1.       性能测试简报模板

即时反馈测试结果时通过邮件发送，内容要简单明了，强调迅速反馈。

以下是【XXX项目名称】XXX模块第N次测试性能测试简报。

过程详情请见：贴KM工作帖链接

项目背景（如果是回归测试则写前情概要）

项目背景。如果是回归测试，则简单说明前次测试的测试结果和遗留问题。

被测对象和性能预期

被测对象和性能预期。

测试结论

已解决问题

遗留问题

测试方案

测试用例与结果

数据图表

结果分析

测试计划OR下一步计划

初测写明测试步骤时间安排；回归测试写明下一步测试对象，测试步骤时间安排；遗留问题写明责任人和解决计划。

感谢语。

5.2.3.2.       性能测试报告模板

摘要

{简要说明该份文档的整体结构，项目名称，项目背景与结论，涉及人员。目的是看这份文档的人可以通过这个摘要明白该份文档的要旨和外部的联系。定稿前请将蓝色文字和范例删除。范例：} 该文所述为XXXXXX项目的性能测试结论与详细测试数据。 描述此项目为啥要做性能测试。 被测项和测试类型。 测试结果是否符合预期。 已解决了几个问题。 遗留了几个问题。 项目干系人：。。。。。 该文分为六部分。第一部分为总述，包括项目概述；第二部分为被测试结论，包括测试结果、测试发现的问题和测试遗留的问题；第三部分为性能需求，包括需求定义和被测对象与测试类型分析；第四部分为测试方案，包括测试工具盒测试环境模拟方法；第五部分为测试数据分析，包括每个测试用例的详细测试结果；第六部分为附件，包括术语表和原始测试结果数据文件，等。

1.1.  项目概述

{简要说明这是个啥项目，属于什么产品、业务，被测模块，当前开发进度，重构优化的重点，遇到什么性能问题，等。定稿前请将蓝色文字和范例删除。范例：}

描述这个是个虾米项目？此次项目为啥要做性能测试？

{重要数据摘要描述、分析及结论。容量测试只需要截取峰值数据。遗留问题需要确定后续解决计划。定稿前请将蓝色文字和范例删除。范例：}

详细测试过程请见：贴工作帖链接

2.1.  测试结果

被测试项	测试类型	预期	实测
XX接口	容量测试	满足90%响应时间小于200毫秒的情况下，页面请求处理的吞吐量峰值达到500个/秒以上；	70%吞吐量集中区间1850-2034tps，90%响应时间10.212ms；符合预期。
XX接口	并发测试	2000个并发连接情况下的连接建立和释放稳定；	并发超过400的时候系统无法建立连接；不符合预期。
XX接口	基准测试
XX接口	稳定性测试		测试10分钟，吞吐量摆动在10%范围内。符合预期。

其他结论：

2.2.  已解决问题

现象：

分析：

解决方法：

2.3.  遗留问题

现象：

解决计划：

3.1.  需求定义

{范例：

被测对象：XXService；测试类型：容量测试；性能预期：吞吐量峰值大于xxx tps，90%响应时间小于xx ms

完成后请删除蓝色字。}

3.2.  被测对象与测试类型分析

{对被测项和测试类型的确定给出依据。描述被测模块在系统中的部署，组件类型，业务逻辑，与IO有关的操作等，据此给出相应的测试类型。对不被测试对象可能存在的风险进行评估。定稿前请将蓝色文字删除。}

4.1.  测试工具

{说明测试接入的协议，选择测试工具。定稿前请将蓝色文字删除。}

4.2.  测试环境模拟方法

{为了保证系统的可测性，需要模拟相关服务（例如：扣费），屏蔽无关服务（例如：鉴权），修改代码逻辑（例如：强制不缓存），准备测试数据，等。每一项都必须描述因此导致的测试局限和风险，以及由于测试环境与正式环境的区别导致的测试结果差异该如何修正。定稿前请将蓝色文字删除。}

4.3.  测试环境部署

4.3.1.  测试环境部署图

{对系统架构图的每一个模块，以图的方式描述系统的测试环境部署，重点突出在机器的数量，IP，功能模块，模块间通讯的协议，测试接入点。可直接复制环境说明文档里的图。定稿前请将蓝色文字和范例删除。范例：}

图4.1测试环境部署图

4.3.2.  机器信息表

机器详细信息请查询：配置管理系统

设备类型与硬件配置对应关系请参阅：《运营设备分类技术指标》，最新版本请留意：无线资源管理门户首页的更新。

5.1.  被测项与用例速查表

被测项与用例速查表

5.2.  测试用例名称1

5.2.1.  测试用例描述

{测试功能点，选此用例的原因和目的；参数设置；测试数据准备和模拟方法；测试逻辑，执行步骤等。}

5.2.2.  测试结果

容量原始数据按如下表格来统计，只作为过程数据，不放在报告正文中。过程数据放到单独的结果统计excel数据文件中，贴到附件。

5.2.3.  测试结果分析

{根据以上数据进行分析，得出结论。}

5.2.4.回访报告模版

该文主要是对XXXXXX项目执行性能测试后对整个项目后期运行情况做的后续跟进反馈与总结。

1.1.  项目概述

{这是个啥项目，为什么要进行性能测试，希望测试什么模块，进行什么类型的测试。第一次测试时间，回归次数，测试完成时间。遗留问题，等。定稿前请将蓝色文字和范例删除。范例：}

这是个啥项目，为什么要进行性能测试，希望测试啥，进行什么类型的测试。

{搜集相应接口后台日志或者统计平台的数据，统计吞吐量和响应时间与PV和UV等业务常用指标，与之前的测试指标和结果做对比。争取能得出合理评估业务性能指标的公式。定稿前请将蓝色文字和范例删除。范例：}

被测试项	测试类型	预期	实测	运营
XX接口	容量测试
XX接口	并发测试
XX接口	基准测试
XX接口	稳定性测试

{找干系人搜集性能方面暴露的缺陷，分析是否属于不被测项，如果是被测项为何没有被测出，总结经验和方法。定稿前请将蓝色文字和范例删除。范例：}

现象	不被测试项 是■否□	问题原因	经验方法
描述问题现象	■	什么原因导致的问题，为什么没有被测试到	总结经验教训和方法
	□
	□

l 测试过程

遇到什么现象？怎么分析？如何解决？下一步情况如何？最终问题是什么？

l 有用的方法分享

此次测试在方法上有什么可以沉淀和分享的？

如何更好的进行团队合作？

更有效的进行测试？

5.1.  性能测试满意度调查统计表

被调查人数		有效问卷数		反馈率	%
被调查者名单
评价项目						人数、评价
您对本次性能测试效率感觉如何？
完成的很迅速，质量很高						0(0%)
跟计划时间基本相符，质量还不错						0(0%)
比计划延误了，完成的质量还可以继续改进						0(0%)
比计划延误了，有很多需求没有完成						0(0%)
做得太慢，延误了整个项目进度						0(0%)
本次测试结果正确程度如何？
全部真实有效						0(0%)
部分真实有效						0(0%)
与实际情况有很大差异，需要重新测试						0(0%)
您对性能测试人员与项目团队的合作，感觉如何？
很满意，沟通效果和态度都很好						0(0%)
一般，还可以改进						0(0%)
不满意，不想再合作了						0(0%)
对文档质量有什么看法？文档包括：测试计划，测试日志，测试简报，测试报告。
条理清晰，论点明确，论据充足，格式精美，理解起来很简单						0(0%)
一般，认真看能看懂						0(0%)
凑合，要仔细看才能看明白，还有些怎么也看不明白的						0(0%)
太乱了，看不懂						0(0%)
觉得这次测试哪里做得好？
哪里最需要改善？

5.3. 敏捷开发流程与性能测试

基于早先一份公司性能测试现状研究分析报告，性能测试需要在敏捷大潮下体现它的价值。数据表明：

性能测试角色意愿

Ø  测试人员是主要推动性能测试的角色，开发和架构师次之，领导、产品经理和QA关注度最低。

这可能是性能测试在公司推广起来困难的原因。

性能测试诉求

Ø  33%“为了提早发现因为性能瓶颈导致的系统缺陷”。

达到此测试目的主要依赖的是可靠性测试和稳定性测试，此类测试为性能测试的价值所在，并以此为目的推动开展性能测试能达到最好的效果。

Ø  重要性依次“为了提升系统性能，提高硬件资源利用率；系统重构后需要回归测试证明性能提升效果；实现了一个全新的架构对性能没底，或为今后扩容做参考”。

这些目的均属于容量测试的范畴，因此做好容量测试技能培训能够满足到大多数的性能测试任务需求。

拒绝做性能测试的原因

Ø  由于我们是互联网行业，公司又是敏捷迭代的开发，项目被开发周期延误导致测试时间被压缩，占用大量测试时间的性能测试被砍掉完全没有悬念。特别是“前期用户不多，先灰度发布，性能不够就加机器”更是屡屡受用。

在这种氛围下，容量测试必要性荡然无存。然而，当公司发展成熟，缩减成本便会成为提高利润的主要方式。只有在那时，容量测试才能体现它的价值。

可以看出，目前花大量人力和时间将某一个性能测试任务做成学术研究，进而产生性能小于10%的提升，对项目团队而言价值不大，但是对测试人员自身能力积累是非常重要的。我们更多的是要赶在项目上线前保证项目上线后没有因重大性能问题而引发运营事故。

用户导向，效率优先，让测试方案更合理、沟通更高效、测试过程更顺畅、结果更有价值，才能让我们的性能测试在敏捷大潮下体现它的价值。

为了做到以上几点，在性能测试流程每个阶段都有一些很好的经验可供大家参考：

l  需求搜集：流程优化减少沟通成本；沟通矩阵，事项列表；不要临时修改方案；

l  需求分析和方案设计： 合理选择测试对象、方法、用例；

l  测试场景模拟： 利用运营数据；有效的测试环境；

l  测试执行： 回归迭代清晰；完整的工作日志和原始数据；

l  数据分析：在获取数据前就考虑如何分析；

现在你已经进入性能测试圣殿的大堂了，领略了这个领域涉及的概念和方法。但是这也只是入门而已，要想真正开始动手做性能测试，光看完这篇文章是不行的。这篇文章诠释的是性能测试理论的精髓，需要在实战中去理解和运用。理解性能测试是一个思路，而学习则有另一套更快速的方法。

建议初学者按照“执行”、“统计”、“报告”、“分析”、“脚本编写和工具开发”、“需求沟通”、“方案设计”，这样的顺序去学习。

项目实践时，团队组建可以形成梯队。由初学者负责执行和统计。稍有经验者负责分析报告和指导测试流程。有多个项目分析报告经验者，可以开始参与需求沟通和方案设计。有开发经验者可以在学习执行的同时，尝试脚本编写和工具开发。有丰富经验者负责主导需求沟通和方案设计。

是不是迫不及待想尝试动手完成一个性能测试了？这里有Step-By-Step的实验材料，还有跟你同时学习的同学上传的作业，Enjoy it!

作者简介：

有六年以上性能测试项目和团队领导经验，总结了适合无线敏捷开发流程的性能测试流程规范、方法和理论并在实践中验证。

独立和带领团队完成60多个项目的测试任务。担任无线性能测试骨干、顾问，承担全BU 60人以上性能测试人才培养工作。负责无线性能测试团队建设和流程文档制定。