测开 (性能测试)

目录

前言

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

2、性能好与不好的表现

3、性能测试衡量指标 && 名称解释

指标一：并发用户数

指标二：响应时间 / 平均响应时间

指标三：事务

指标四：点击率（Hit Per Second）

指标五：吞吐量（Throughput）

指标六：思考时间（Think Time）

指标七：资源利用率（Think Time）

常识普及

4、性能测试分类

一般性能测试

负载测试

压力测试

阶段小结

稳定性测试

失效恢复测试

配置测试

---

前言

首先，我们要明白 性能测试的范围很大！！！！

压力测试，负载测试，稳定性测试。。。。它们都属于 性能测试

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

我们在这里先来了解一下 设计测试用例的万能公式：【功能测试 + 界面测试 + 性能测试 + 兼容性测试 + 易用性测试 + 安全性测试 +（容错性测试）】
 
如果将来，各位读者面试测开岗位时，面试官给了我们 “被测物品”（人事物），让你们现场对其进行测试用例的编写，我们就可以按照 万能公式 给出的方向 作为参考，进行编写。
 
切回正题：
功能测试：验证产品功能有没有 满足（实现） 用户的功能需求。
 
但是！还存在一个问题：功能是实现了，但是质量怎么样，就不能保证了。
这个时候，就需要引入 性能测试了。
 
性能测试：也就是验证 产品的质量 是否达到 用户的期望。

2、性能好与不好的表现

这个很好理解！
我们买一台高配的电脑，玩起游戏一点都不卡。
那些低配置电脑，玩什么都卡。
 
这就是 性能差距，当然此处的差距主要体现在 硬件上。
我们更关注的是 “软件”上的 性能。
比如：
我们晚上玩LOL的时候，尤其是 一区，总是需要排队。
这里就是一个性能的问题。
服务器处理登录请求的速度，跟不上玩家登录请求发送的速度。
所以，我们才会进行排队。
 
生活中还有很多的事例：
双十二抢特价商品，进不了购物页面
某某明星报出新闻，微博直接炸裂
。。。。
这里我们就不再赘述。
 
总的来说：
性能好不好，取决于服务器处理信息的速度快不快！能不能承受高并发请求！！！
影响性能的因素： 硬件配置，代码算法，代码结构。。
 
另外，可以告诉你们的一点是：
你们难道就不好奇为什么所有软件会有验证环节？

美名曰是提高用户的安全性，其实就是拖延你发送登录请求的时间点，避开与其它用户发送的请求时间点 冲突（相同）。
从而缓解 服务器 的 高并发 压力。
用专业术语来说：
通过 “降低 ” 产品的易用性 来换取 产品的性能。

3、性能测试衡量指标 && 名称解释

如何衡量性能好坏:

通过数据来进行展示，借助 工具所监控 和 收集的各项指标 来分析系统的性能、

---

 

指标一：并发用户数

先理解一下，并发的意思：

在某一个时间点，服务器接收到了多个请求。

 
并发用户【同时发送请求的用户们】会对系统造成压力，首先对系统用户数，在线用户数，并发用户数做一个区分.
 
系统用户数：简单地说就是该系统的注册用户数。

例如： BestTest论坛里存在 6666 个注册用户，它们可以是活跃的，也可以是 “僵尸” 的。

 
在线用户数：登录了系统，或者说正在使用系统的用户数量。
 
并发用户数：一起向服务器发送带有压力，或者对服务有影响操作的用户数量。

 
业务层面的并发用户数：

指的是同时向服务器发送请求的用户数量。

 
后端服务器层面的并发用户数：

指的是同时向服务器发送请求的请求数量。

---

 

指标二：响应时间 / 平均响应时间

站在用户的角度来说：

从 请求发出 直到 看到响应结果 的这段时间，就是响应时间。

 
站在服务器的角度来说：

从服务器接收到请求的那一刻开始，到返回响应的这段时间，就是响应时间。
该响应时间又称 请求响应时间。

 
响应时间的长短，跟多个方面都有关系：

1、用户的带宽
2、运营商（我们所有的请求都是通过运营商的服务器进行传递的）
3、服务端的带宽（服务器的带宽）
4、网络环境（网速）
。。。。。。。

 
平均响应时间：

就是把每一次响应的时间累加，然后取平均值（平均时间）。
 
平均值，一般是做为参考值来使用。
就好像一个班考完试，老师都会公布平均值，让我们看看自己的成绩是否过了平均值。

---

 

指标三：事务

简单来说：事务，就是指完成一件事所需所有操作。

比如：吃饭
我们吃饭，要拿碗，拿筷子，还要盛饭，夹菜。
最后一口饭，一口菜的形式，吃完饭。
 
吃饭，看似是一件事。
但是想要完成它，我们需要完成一些其它必要的操作。
事务也是如此，如果缺少某个操作（条件），事务就无法执行成功。【原子性】

 
事务响应时间：

处理请求对应的事务的时间。
说白了，就是实现一个业务功能所需要的时间。

 
每秒事务通过数：TPS >> Transaction Per Second

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

---

 

指标四：点击率（Hit Per Second）

假如说我们向 web 页面进行了点击，点击率代表用户每秒向 web服务器 提交的 HTTP 请求数。

比如：淘宝秒杀活动，我们对着购买按钮就是一顿狂戳。
点击率 == 点击次数 / 点击持续时间（秒）

需要注意的是：一次点击，并不是只有一条请求。
【经典：重定向，一次点击，发送两个请求】
你们可以在准备访问一个页面的时候，开启浏览器的开发者工具来观察一次点击，触发了多少个请求。

---

 

指标五：吞吐量（Throughput）

这里的吞吐量以单位时间为度量衡量。
 
单位时间内系统处理的客户请求的数量，直接体现软件系统的性能承载能力。
 
一般来说用
Requests【请求数】 / Second【时间秒】，
Pages【页数】 / Second【时间秒】，
Bytes【字节数】 / Second【时间秒】。
 
从业务的角度，也可以用访问人数 / 天或是处理的业务数 / 小时来衡量
从网络设置的角度来说，也可以用 字节数/天 来衡量

---

 

指标六：思考时间（Think Time）

指模拟正式用户在实际操作时的停顿间隔时间。
 
从业务的角度来说：

思考时间指的是用户在进行操作时，每个请求之间的间隔时间【前后两个操作间隔的时间】。

思考时间越短越好。

---

 

指标七：资源利用率（Think Time）

不同系统资源【包含 CPU，内存，硬盘，网络等。。。】的使用情况。
利用率越高越好。【用最少的资源做最多的事】

---

 

常识普及

通常我们所认为的兆（M） 等于 1024kb。
但是运营商对于兆的定值是不一样的，是以 bit 为单位。
也就是说：运营商的 1M 网速，等于 128 kb/s 的传输效率。
如果是 100M，也就是 12.5M/s

---

 

4、性能测试分类

常见的测试种类：
一般性能测试
负载测试
压力测试
稳定性测试
基准测试
。。。。。。。
在这里我们主要以一般性能，负载，压力，稳定性测试 为主。

---

 

一般性能测试

验证软件在 良好环境下【网络稳定，低并发，空间充足】 是否满足性能指标。

---

 

负载测试

验证系统在一定高并发压力下的运行时间，直到系统性能出现“拐点”。

拐点：就是系统的性能出现不稳定波动情况。

---

 

压力测试

验证系统在已经处于极限负载的情况下，或者说达到某种极限指标，已经处于“饱和”状态下，系统的表现。
需要注意的是：
压力测试往往会把系统弄崩溃。

---

 

阶段小结

稳定性测试

稳定性测试，有点类似于 运动员举杠铃。

“杠铃” 举重运动员举起杠铃之后，需要举过头顶停留3s之后放下才算挑战成功。

说白了：就是让系统在 特定的环境（正常情况，高并发，网络波动等。。） 下，运行一段时间，看看系统的性能输出是否稳定【就是看看能否正常工作】。

---

 

失效恢复测试

针对有备份和负载均衡的系统设计的，这种测试方法可以用来检验如果系统局部发生故障，用户能否继续使用系统，用户操作将会受到多大影响。

需要注意的是：
  不是所有的系统都需要进行这种类型的测试，尤其是并没有明确给出系统需要持续运行指标的系统。

---

 

配置测试

通过被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到各项资源的最优分配原则。

例如:
在测试执行时更换、扩充硬件设备，调整网络环境、调整服务器和数据库的参数设置，将每次测试结果进行对比，从而确定各个因素对系统性能的影响程度。