性能测试到底是什么，让我们一探究竟！

本篇文章主要讲述什么是性能测试，以及性能测试的指标，性能测试的类型，以及性能测试的流程！

常见的性能问题 

常见的性能问题包括：

• 资源泄露，内存泄漏
• CPU的使用率达到100%，系统被锁死
• 查询速度或者请求速度很慢，效率低下......

性能测试

什么是性能测试

测试人员借助性能测试工具，模拟系统在不同的情况下性能指标是否正常。简单来说就是 ，系统的基本功能已经完成，性能测试主要的方向就是在系统正常工作的前提下，效率如何，影响效率的因素又是哪些？

为什么进行软件性能测试

• 获取系统性能的指标，作为性能指标的基准
• 验证系统的性能指标是否达到要求（性能需求）
  • 应用程序是否能够满足系统要求的各种性能指标
  • 应用程序是否能处理预期的用户负载并有盈余能力
  • 应用程序是否能处理业务所需要的事务数量
  • 在预期和非预期的用户负载下，应用程序是否稳定
  • 是否能确保用户在真正使用软件时获得舒服的体验
• 发现系统的性能瓶颈，内存泄漏等问题。
• 系统正常工作的情况下的最大容量。
• 帮助系统运维部门能更好的规划硬件配置

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

功能测试：只是验证软件的特性是否完成

性能测试：保证软件在一些恶劣的环境能否正常使用

实际中，哪些方面体现出性能好与不好呢？

例如：

一个软件的两个版本：版本1登录需要3s登录成功；版本2登录需要3ms登录成功

此时就可以直观的感受出不同版本的性能好坏！

哪些因素会影响软件的性能

硬件：服务器CPU，服务器内核，内存，磁盘，网络等

软件：编程语言，算法等

用户数量：用户数量，用户操作频率

性能测试常见专业术语以及衡量指标

并发用户数

并发用户会对系统造成压力，首先对系统用户数，在线用户数，并发用户数做一个区分。
系统用户数：简单地说就是该系统的注册用户数。可以是活跃的，也可以是僵尸的。
业务层面的并发用户数：指的是同时向服务器发送请求的用户数量。
后端服务器层面的并发用户数：指的是同时向服务器发送请求的请求数量。

响应时间

有一个模型，客户端发送请求到服务端，服务端响应，连接数据库，然后返回响应

用户响应时间为：

用户从发起请求到用户接收请求花费的时间：N1 +A1 + N2 + A2 + N3 + A3 + N4

请求响应时间：

服务器接收请求到服务器发送请求这段时间：A1 + N2 + A2 + N3 + A3

响应时间会被各种因素影响！

响应时间越短证明性能越好

事务响应时间

每秒完成的事务数，通常指每秒成功的事务数，性能测试中重要的综合性性能指标。

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

每秒事务通过数（Transaction Per Second）

TPS 是指每秒系统能够处理的事务数。它是衡量系统处理能力的重要指标。

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

地铁检票机：

只有 10 台进站检票的机器， 1 台机器 1 秒能进 1 个人

并发用户数为 5 ，则 TPS 为 5

并发用户数为 10 ，则 TPS 为 10

并发用户数为 100 ，则 TPS 仍为 10

点击率 

每秒点击数代表用户每秒向 Web 服务器提交的 HTTP 请求数。点击率越大，服务器压力越大。

这里的点击并不是鼠标的一次点击，一次点击可能有多次 HTTP 请求

吞吐量

吞吐量指的是一次请求，用户和服务器之间数据传输量

吞吐量只是标志这次请求数据量大小，并不能表示效率的高低，吞吐率可以表示效率的高低

吞吐率

单位时间内系统处理的客户请求的数量，直接体现软件系统的性能承载能力，一般使用吞吐量/时间来计算。

吞吐量越小证明软件性能越好

吞吐量越大证明软件性能越不好

 思考时间（Think Time）

指模拟正式用户在实际操作时的停顿间隔时间，从业务的角度来讲，思考时间指的是用户在进行操作时，每个请求之间的间隔时间。

资源利用率

不同系统资源的使用情况。包含CPU，内存，硬盘，网络等。

性能测试模型

曲线拐点模型

1. X轴代表并发用户数，Y轴代表资源利用率、吞吐量、响应时间。X轴与Y轴区域从左往右分别是轻压力区、重压力区、拐点区。
2. 随着并发用户数的增加，在轻压力区的响应时间变化不大，比较平缓，进入重压力区后呈现增长的趋势，最后进入拐点区后倾斜率增大，响应时间急剧增加。
3. 接着看吞吐量，随着并发用户数的增加，吞吐量增加，进入重压力区后逐步平稳，到达拐点区后急剧下降，说明系统已经达到了处理极限，有点要扛不住的感觉。
4. 同理，随着并发用户数的增加，资源利用率逐步上升，最后达到饱和状态。
5. 最后，把所有指标融合到一起来分析，随着并发用户数的增加，吞吐量与资源利用率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于比较好的状态。但随着并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和，随后吞吐量急剧下降，造成响应时间急剧增长。轻压力区与重压力区的交界点是系统的最佳并发用户数，因为各种资源都利用充分，响应也很快；而重压力区与拐点区的交界点就是系统的最大并发用户数，因为超过这个点，系统性能将会急剧下降甚至崩溃。

性能测试的分类

基准测试

系统的第一个版本，研发团队团队也不清楚系统的性能能达到怎样的水平，这时进行的性能测试，其目标是获得系统标准配置下，有关的性能指标数据，作为将来性能改善的基准，这种测试称之为“ 性能基准测试。

负载测试

让系统背负一定的压力测试，看是否会出现性能拐点

压力测试

不断对系统施加压力，验证系统 长期处于临界饱和阶段的稳定性以及性能指标的变化.

系统可能就会出现崩溃，揭露高负载下系统的问题，例如资源竞争、同步问题、内存泄漏等；然后逐渐较少压力，观察瘫痪的系统是否可以自愈。

可靠性测试

验证系统在常规负载模式下长期运行的稳定性。

在一定的软硬件环境下，长时间运行一定的负载，确定系统在满足性能指标的前提下是否运行稳定。与压力测试不同的是系统的负载并不是处于极限的状态下。重点是满足性能要求的情况下，系统的稳定性，比如响应时间，TPS是否稳定。

性能测试如何展开

和功能测试流程相同：

需求分析 -> 测试计划 -> 测试开发 -> 测试执行 -> 测试评估

需求分析：分析的是性能需求

测试计划：确定一个性能测试工具，并且如何展开测试

测试开发：编写性能测试的脚本

测试执行：执行测试脚本

测试评估：编写测试报告，记录相关问题

在性能测试方面，发现的问题叫做性能瓶颈，解决问题称为优化