【软件测试】性能测试 —— 基础概念篇

🥰🥰🥰来都来了，不妨点个关注叭！
👉博客主页：欢迎各位大佬!👈

本期内容主要介绍性能测试相关知识，首先我们需要了解性能测试是什么，本期内容主要介绍性能测试基础概念

1. 性能测试是什么？

1.1 引入

想一想在生活中有没有遇到过软件的性能问题呢？

比如说在日常生活中，想去看演唱会或者是音乐节，很多时候抢票，app或者网站会崩溃，导致无法抢票，不少人首先是检查自己的网络问题，5G 和 WiFi 来回切换，还是有问题，一询问，都有这个问题，原来是服务器崩溃了！ 在生活中，还有很多这样的场景！

1.2 性能测试定义

那么性能测试到底是什么呢？
性能测试是：测试人员借助性能测试工具，模拟系统在不同场景下，对应的性能指标是否达到预期
（不是人工完成，需要借助工具！）

听着是不是还是有一点疑惑呢~

这里的性能测试工具指的是 —— 比如 LoadRunner、Jmeter、还有一些第三方的软件~
这里的不同场景指的是 —— 比如在流量高峰期，或者软件持续运行一段时间，以及对应的性能指标是否达到预期等等

1.3 性能测试与功能测试区别

性能测试和功能测试的区别

• 从定义来说：功能测试依靠人工，性能测试依靠工具
• 从场景来看：功能测试是看软件是否实现需求，即不管在什么场景下，只要能够正常运行，性能测试是看软件在一些极端的情况下，是不是能正常运行

1.4 软件性能好坏表现

那么什么样的表现属于软件性能好的表现，什么样的表现属于软件性能不好的表现？

【举例一】举这样一个例子，比如有两个手机，下了不同的软件~

【举例二】还有比如说软件的用户日活跃度，在双十一的时候，可以对比淘宝、京东、拼多多等用户日活跃度，用户日活跃度越高的，在同一时间承载的压力更大，其软件性能表现是更好的

【举例三】那性能不好的表现，比如说 12306 春运抢票，服务器经常会崩溃，并发量太大了~
（如何解决呢？服务器升级？ 服务器升级太贵了，要掏钱！还有什么呢？ 比如在登录前有一个验证，避免机器人抢票，较少用户数量，减少并发数，还可以软件算法优化等等手段）

1.5 影响软件性能的因素

影响软件性能的因素有哪些呢？

• 硬件方面：服务器CPU利用率、 内存、磁盘操作频率、CPU核心、带宽
• 软件方面：算法、编程语言
• 用户方面： 用户数量（并发数）、用户使用时长、用户访问频率

2. 为什么要做性能测试？

我们来想一下，一个软件开发出来了，是不是会希望更多的用户来使用呢~ 一旦使用的用户变多，流量就高了，既然流量高了，那软件能不能承受这个高的流量呢？

那么到底为什么要做性能测试呢？ 以下是做性能测试原因：

1. 可以获取系统性能的指标，作为性能指标的基准
   为什么要作基准呢？ 比如说一开始发布的软件，我们做性能测试，进行摸底，作为性能指标的基准，之后软件升级时，与这个基准进行对比~比如有一款软件登录耗时 30ms，之后升级后，登录耗时 50ms，这显然是不好的！
2. 可以验证系统的性能指标是否达到要求的性能需求

比如说有这一些性能需求：

• 应用程序是否能够满足系统要求的各种性能指标
• 应用程序是否能处理预期的用户负载并有盈余能力
• 应用程序是否能处理业务所需要的事务数量
• 在预期和非预期的用户负载下，应用程序是否稳定
• 是否能确保用户在真正使用软件时获得舒服的体验

3. 发现系统的性能瓶颈，或者是内存泄漏等问题，及时优化与解决
4. 可以知道系统正常工作的情况下的最大容量
5. 有利于帮助系统运维部门能更好的规划硬件配置

3. 性能测试有哪些衡量指标？

3.1 并发用户数

1）什么是并发呢？

举这样三个场景，如下：
第一种情况：1个用户访问某个网站
第二种情况：100万个用户每隔10s访问某个网站
第三种情况：100万个用户同时访问某个网站
（注意两个条件：大量用户、“同时对系统请求”）

答案很显然，并发是第三种情况
并行和并发的定义，可以参考往期内容：【多线程】进程与线程

2）什么是用户数呢？

这里有 3 种用户数：

• 系统用户数：系统注册用户
• 在线用户数：成功登录系统用户数
• 并发用户数：大量的用户访问系统，此时访问的用户数，就是并发用户数量
  (一般来说，系统用户数 > 在线用户数 > 并发用户数)

!!!注意区分业务层面和后端服务器层面的并发用户数
【业务层面的并发用户数】指的是同时向服务器发送请求的用户数量
【后端服务器层面的并发用户数】指的是同时向服务器发送请求的请求数量

比如说我打开了一个网页，这里是一个业务层面的用户数量，数量是1，但可以看到后端服务器同时向服务器发送的请求数量是 23 次，这两个是不一样的!!!

3.2 响应时间

1）用户响应时间

从图中可以看到，用户响应时间是一整个过程，用户响应时间是：N1+A1+N2+A2+N3+A3+N4

2）请求响应时间

从图中可以看到，请求响应时间是达到服务器后的时间，请求响应时间是：A1+N2+A2+N3+A3

3）影响一个软件响应时间的因素

• 网络带宽
• 数据库性能
• 服务器处理性能
• 软件算法、逻辑
• 用户设备

3.3 事务响应时间

比如一个点餐软件，流程：订单 ——> 支付 ——> 权益（是否为会员、券等）

这里的一个事务是一个业务度量单位，是指一组密切相关的子操作的组合。比如，一笔电子支付操作，
后台处理的时候可能需要经过会员系统，账务系统，支付系统，银行系统等，这就是是一个关于支付事
务里面包含的操作。而对于用户，往往也只关注整个支付花费了多长时间。

3.4 每秒事务通过数（TPS）

每秒事务通过数量 = 处理的事务数量/ 事务花费时间

每秒事务通过的数量越多，自然而然说明软件的性能越好！

TPS 是指每秒系统能够处理的事务数，它是衡量系统处理能力的重要指标，当压力加大时，TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈了，如果环境没有发生大的变化，对于同一系统会存在一个最大处理事务能力，它并不随着并发用户的增减而改变

3.5 点击率

【点击量】用户点击数量
【点击率】点击量/ 时间

3.6 吞吐率

【吞吐量】用户一次请求和服务器之间的数据交互量

A服务处理 100M 数据，花费时间 2 s
B服务处理 10M 数据，花费时间 1s

因此，不能以吞吐量为性能衡量标准，以吞吐率为衡量指标

【吞吐率】吞吐量/时间

3.7 思考时间

【思考时间】用户在对软件进行操作的时候，每一个操作中间间隔的时间

3.8 资源利用率

【资源利用率】不同系统资源的使用情况，包含 CPU、内存、硬盘、网络等

4. 性能测试有哪些分类？

这里介绍常见的 4 种性能测试分类~

4.1 基准性能测试

让系统在正常情况下运行，观察软件性能指标

应用场景：软件刚上线需要进行性能摸底

4.2 负载性能测试

验证软件在一定的压力情况下运行，观察性能指标是否出现了拐点

4.3 压力性能测试

系统处于饱和情况下（这个饱和情况下，往往会把系统弄崩溃），观察系统性能指标

可以看到这个瓶子，下面一整个是基准性能，上面的漏斗是负载性能测试，水都满了，再给水，就是压力测试~ 这个图非常形象！

4.4 可靠性测试

验证系统在一个持续的时间段内运行，在这个运行时间段，观察系统各项性能指标是否正常！
（持续 1 天 ——> 持续运行一周 ——> 持续运行 1 个月 ——> 一个季度 ——> 一年）

5. 性能测试执行流程是怎么样的？

功能测试执行流程：需求分析 ——> 测试计划 ——> 测试设计 ——> 测试执行 ——> 测试评估 （测试报告） ——> 上线
性能测试执行流程：需求分析 ——> 测试计划 ——> 选择一款性能测试工具 ——> 性能测试脚本 ——> 执行性能测试脚本 ——> 产出一个性能测试报告

【注意】性能测试出现不符合预期的情况，不叫它 BUG，它叫性能瓶颈，在性能测试中，出现了性能瓶颈，开发修复的过程，叫它优化

比如要做一个基准性能测试，这里举一个例子，

需求分析：摸底 page 接口可以容纳的用户数量
工具： Loadrunner 针对需求编写脚本
项目名称：xxx 性能摸底测试
测试人员：xxx 测试时间：2025年4月6日（一定是完成了功能测试的）
性能指标截图：
结论：page 接口容纳的人太少，测试不通过
解决方案：page 查询接口加缓存

💛💛💛本期内容回顾💛💛💛

✨✨✨本期内容到此结束啦~