在企业中负责技术招聘的同学，肯定都有一个苦恼，那就是招一个合适的测试太难了！若要问起招哪种类型的测试最难时，相信很多人都会说出“性能测试”这个答案。

每当发布一个性能测试岗位，不一会就能收到上百份简历，其中不乏学历亮眼、背景出色、简历里各种高并发、大流量的项目经验。

但是进入面试环节后，却发现绝大多数的候选人，简历上所谓的性能测试经验，都是停留在工具使用、脚本编写的水平，通常都是把脚本放到压力机上跑一下，然后统计出数据就完了。

当你希望候选人讲一个项目中遇到的性能问题，以及如何分析定位时，却发现绝大多数根本没有遇到过性能问题。

也有少量候选人也测出过一些性能问题。然而追问其性能瓶颈的原因以及如何解决时，对方却回答说，把问题抛给开发后，由开发来解决，至于什么原因，后续并没有关注。

甚至面试了几个高级性能测试工程师，还是发现一旦涉及到性能分析调优，就开始左顾右盼、答非所问。

究其原因，大部分测试同学本身参与的性能测试项目就比较少，从而造成遇到的性能问题的概率就很低。即便是专职做性能测试的，如果你没有良好的追踪和总结问题的习惯，而是过度的依赖开发，那自然也不会有太多的积累。

不要说测试了，就算是开发，能有几个懂性能分析调优呢？性能难，难于上青天。企业希望能招到擅长性能分析的人。而广大测试小伙伴却根本没有实践机会，何来经验积累？这本身就是一个行业矛盾！

有时候我就在天真的想，如果能有人把自己的性能分析经验免费分享出来该多好啊！

有这样的人吗？有！那就是我哈哈哈

一、性能测试想做什么
二、性能测试的基本流程
三、性能测试的前期准备
四、性能测试的工具及相关学习建议（文末分享性能测试学习资源）

一、性能测试想做什么

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

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

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

二、性能测试的基本流程

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

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

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

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

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

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！qq群号：110685036

三、性能测试的前期准备

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

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

吞吐量：

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

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

-----自己思考-----

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

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

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

如果你还有许多困惑，那么我整理的视频资源和文档会是你的良师益友，或许可以给你带来一些实际性的帮助与突破。

点击文末小卡片关注我的gzh免费获取~

虚拟用户数：

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

性能测试结果：

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

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

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

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

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

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

1）基线测试，又叫基准测试：
测一下单个用户做主要业务流程的场景。其性能测试结果会作为比对依据。
2）性能测试：
逐步增加用户数，比如10个，20个，50个，80个，130个，得到不同用户数情况下的性能测试结果变化趋势图。这个图里常常可以发现性能瓶颈。比如用户数到某个值时突然性能指标下降了很多，错误率大幅上升了。那就需要进一步分析是软件的问题还是硬件的问题，还是环境的问题等。
3）压力测试：
使用超过系统设计的最大用户数，看看待测应用会不会崩溃，会怎么样，有没有隐患和风险等。
4）负载测试：
在比较高的用户数情况下，较长时间得执行测试，观察系统在较高负载较长时间下的稳定性。
5）根据性能测试的负载生成器所在位置，还可以分出本地同网络的测试和跨网络的测试。
6）还有当下比较时髦的全链路测试，其实就是把真实环境划出一块来做测试。这样来解决估算不准的问题。这块网上有一些资料，但不太多。