【2023最全教程】性能测试基础知识学习路线（建议收藏）

最新推荐文章于 2024-10-06 21:33:09 发布

测试界的彭于晏

最新推荐文章于 2024-10-06 21:33:09 发布

阅读量1.7k

点赞数 4

分类专栏：技术分享软件测试自动化测试文章标签：职场和发展自动化测试测试工程师软件测试性能测试

本文链接：https://blog.csdn.net/IT_LanTian/article/details/129637092

版权

技术分享同时被 3 个专栏收录

1681 篇文章 57 订阅

订阅专栏

自动化测试

1632 篇文章 75 订阅

订阅专栏

软件测试

1439 篇文章 116 订阅

订阅专栏

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

很多公司会希望测试人员能在测功能之外兼顾一下性能测试，而不一定会雇一个专门的性能专家来做性能测试。

本文将围绕4个方面来介绍性能测试

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

一、性能测试想做什么

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

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

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

二、性能测试的基本流程

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

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

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

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

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

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

三、性能测试的前期准备

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

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

吞吐量：

表示待测应用对业务的支持量，以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）还有当下比较时髦的全链路测试，其实就是把真实环境划出一块来做测试。这样来解决估算不准的问题。这块网上有一些资料，但不太多。