本文介绍一下性能测试的基础内容和一些学习经验，主要讲针对服务器端的性能测试。其他代码级性能测试、前端性能测试等属于比较细分的领域，建议大家有需要的时候针对性得去学。而对于服务器端的性能测试，即使是不做性能测试的人，最好也要有一点了解。我并不从事专职性能测试，只做过一些小项目的性能测试工作。很多公司会希望测试人员能在测功能之外兼顾一下性能测试，而不一定会雇一个专门的性能专家来做性能测试。

一、性能测试想做什么

首先，性能测试想做的事情，类似下图：

这是一个简化过的关于web应用的服务端的性能测试示意图，性能测试想要模拟真实业务场景。当一个应用上线，有很多用户通过客户端访问服务端。他们把请求通过用户界面发送给了服务端，于是在服务端接收到了大量的请求，如果用户数很多，那么服务端有可能承受不了这种压力，进而崩溃，严重的可能导致大量经济损失。

性能测试则是希望通过提前模拟这种压力，来发现系统中可能的瓶颈，提前修复这些bug，减少服务器宕机的风险。此外，性能测试还可以用来评估待测软件在不同负载下的运作状况，帮助管理层做一些决策。比如早期有的管理者会希望通过性能测试来评估需要买几台服务器。但，这种做法随着云计算的普及，已经过时。在云计算平台上，硬件资源可以弹性获取，自动调整。云计算也会对性能测试的方式产生影响，包括服务端资源监控在内的很多工作，未来都可以交给云计算平台了。大家也可以关注一下，云计算对传统测试工作的冲击。

二、性能测试的基本流程

下图表示了一个简单的性能测试的基本流程中，我们怎样得到性能测试的结果。

然后，这只是一轮性能测试的开始，得到性能测试的结果之后，还有很多工作：

可以说，这里的调优过程才是性能测试的技术含量所在。这可能也是性能专家这个角色存在的意义之一。而测试人员通过做性能测试，进阶成为性能专家，也是一种发展方向。但不得不说，这条路是比较难走的，限于我个人视野，我觉得DBA、运维、开发、这些角色都比测试更容易发展为性能专家。当然是否走这条路也要看个人兴趣了。

调优的话，主要看调优小组推测的瓶颈在哪里，比如推测瓶颈在数据库，可能让DBA调整一下数据库配置，然后再测一遍。推测瓶颈在第三方提供的设备上，那就咨询一下第三方的技术支持，然后调整一下配置再测一遍。这个调优过程，可能比较长。

从以上两图可以看出，在整个性能测试过程中，测试人员能做的工作其实并不多，且大多数属于第一阶段的低技术含量工作。主要集中在脚本录制或编写、性能监控器的配置和数据的收集上。后者还会受到云计算平台普及的冲击，很可能以后不用你做任何工作就能简单得收集到想要的资源使用情况数据。而在第二阶段调优时，性能调优小组的介入使测试人员存在感进一步下降。其中水平较低的测试人员将沦为脚本执行员和脚本修改操作员。

三、性能测试的前期准备

此外，还有一个性能测试还有一个前期准备阶段：

这里先补充一些名词解释，我只是根据自己理解写一下，并不精确。精确定义大家可以网上搜索，另外我最后会推荐一些参考资料。

吞吐量：

表示待测应用对业务的支持量，以TPS或QPS为单位，表示每秒钟能处理的请求数。需要分析业务场景来计算吞吐量。

请听题：小明办了一个电影网站，每天有2000个用户会上来看电影，假设每个人都只看一部电影，该电影网站每本电影需要播放两小时。每个用户每次看一本电影会向待测应用运行的服务器发送10个请求，其播放的电影数据存储和传输在第三方，本题中不需要考虑。每天晚上7点到9点为黄金时间，在每天的用户中会有一半人选择在这个时间点上来看电影。请计算该网站的平均吞吐量和峰值吞吐量。

平均吞吐量=总请求数/总时间 = 2000×10/（24×3600） 

峰值吞吐量=峰值请求数/峰值时间 = 2000*0.5*10/(2*3600)

具体数字就不算了，算出来你发现吞吐量很低很低。这是因为这些数据我是随便造的，并且我之前工作过的电影网站吞吐量确实也很低，没多少用户。然后除了这些，还有很多估算。比如故意夸大一点，乘以一个估算系数之类的。总得来说，算出来的吞吐量不一定很精确，对计算公式感兴趣的话，可以搜索一下，有很多人给出更具体的例子。

虚拟用户数：

性能测试要模拟的用户数量。

性能测试结果：

包括响应数据和性能指标。

响应数据相关的常见指标有：90%平均响应时间、错误率等

性能指标包括CPU,I/O,Memory,Network四个方面，每个方面都有几个指标。

关于这块，相信你能在网上找到相关文章教你的，我这里就不展开了。

测试策略，代表设计这些场景的依据，在这里主要有以下几种：

注意，这里的名字并不是全球统一的，不同的公司，不同的人可能对同一种测试策略有不同的叫法。

1）基线测试，又叫基准测试：

测一下单个用户做主要业务流程的场景。其性能测试结果会作为比对依据。

2）性能测试：

逐步增加用户数，比如10个，20个，50个，80个，130个，得到不同用户数情况下的性能测试结果变化趋势图。这个图里常常可以发现性能瓶颈。比如用户数到某个值时突然性能指标下降了很多，错误率大幅上升了。那就需要进一步分析是软件的问题还是硬件的问题，还是环境的问题等。

3）压力测试：

使用超过系统设计的最大用户数，看看待测应用会不会崩溃，会怎么样，有没有隐患和风险等。

4）负载测试：

在比较高的用户数情况下，较长时间得执行测试，观察系统在较高负载较长时间下的稳定性。

5）根据性能测试的负载生成器所在位置，还可以分出本地同网络的测试和跨网络的测试。

6）还有当下比较时髦的全链路测试，其实就是把真实环境划出一块来做测试。这样来解决估算不准的问题。这块网上有一些资料，但不太多。

关于分析生产环境和建立估算模型。可以去搜搜阿里研究员对全链路压测的演讲。或者去找其他资料。我也没估算过，不展开了。我只做过最简单的，在没上线的生产环境上做性能测试。但估算的问题很明显就是：很难估算准确。

其他在前期要做的事情，还有确定测试通过标准，比如吞吐量要达到多少，错误率低于多少，响应时间要多快，服务器CPU占用率要多少以下等等。

以及确定测试环境用什么设备，怎么搭建。等等。

四、性能测试的工具及相关学习建议

然后说到测试工具，再吐槽一下一上来就问工具的人。上面这么多原理你如果不了解的话，只会用工具是没什么用的。

现在的主流性能测试工具是：Jmeter

其次Grinder，Gatling，Locust，Loadrunner等等等等，此处排名不分先后。我也不知道哪个工具是第二流行的。

jmeter的学习主要通过官方用户手册。现在这个工具对我来说最大的问题就是图形界面用起来挺麻烦。后来的很多工具已支持纯脚本或代码方式描述测试场景。不过幸好我也不经常做性能测试。我的建议是大家都要学jmeter，其他工具可以选学，loadrunner除非真的你公司要用否则不用学。

而监控服务器指标方面，jmeter有插件支持。也可以用linux命令行工具做。也有人用商业工具做。总之要把服务器性能指标和请求响应时间两组数据的时间线对上，让我们可以看到什么时候发送了多少请求，响应时间多少，错误率多少，此时服务器负载又是多少。

作者：成风
链接：https://zhuanlan.zhihu.com/p/31080929