性能测试篇——性能测试的基础理论

例如：

电子商务网站促销活动：一家大型电子商务网站可能会在黑色星期五或网络星期一等大型促销活动前进行负载测试，以确保网站能够处理大量用户的访问和交易。

在线车辆市场：一个在线车辆销售平台可能会进行负载测试，以确保在高流量时段，如新车型发布时，网站能够稳定运行并处理大量的用户请求。

5.3稳定性测试

在服务器稳定运行（业务正常的负载量）的情况下，进行 长时间 的测试，保证服务器能够正常运行。时长一般为 1 天、一周等。

5.4并发测试

系统在短时间内同时处理大量请求，查看系统的并发处理能力。

并发性可以从两个不同的角度来理解：

业务层面的并发：指多个用户在同一时间点进行相同的操作，导致同一业务接口被同时请求。

系统层面的并发：指多个用户在同一时间点访问系统，但每个用户执行不同的操作，涉及到访问不同的系统接口。

5.5压力测试

简单来说，压力测试就是看看应用程序在极端繁忙的情况下能否撑得住，并且在出现问题时能否快速恢复。

测试包括两种：

一种是长时间（比如连续24小时以上）的高负载测试，看应用程序能不能稳定运行；
另一种是极限测试，就是看在极端的负载下，应用程序会不会崩溃。

5.6容量测试

关注软件的极限压力下的各个极限参数值，如：最大TPS，最大连接数，最大并发数，最多数据条数等。

六、性能测试关注的指标

6.1响应时间

客户端发送请求，到客户端收到服务器返回的响应，过程中所经历的全部时间，都是响应时间

响应时间 = 应用程序处理时间（ A1+A2+A3 ） + 网络传输时间（ N1+N2+N3+N4 ）

6.2并发数

说明：并发测试的用户数

扩展：

系统用户数：系统注册的总用户数据

在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求

并发用户数：某一物理时刻同时向系统提交请求的用户数

举个简单的例子：

比如在京东：

注册用户数为50亿——系统用户数
当前登录的用户数为2亿——在线用户数
当前正在使用的用户数为600万——并发用户数

6.3吞吐量

说明：吞吐量（ Throughput ）指的是单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力

注意：

1. 业务角度：吞吐量也可以用 “ 业务数 / 小时 ” 、 “ 业务数 / 天 ” 、 “ 访问人数 / 天 ” 、 “ 页面访问量 / 天 ” 来衡量

2. 网络角度：还可以用 “ 字节数 / 小时 ” 、 “ 字节数 / 天 ” 等来衡量网络的流量

3. 技术指标：可以用每秒事务数（ TPS ）和每秒查询数/请求数（ QPS ）来衡量服务器具体性能处理能力

6.3.1QPS

服务器每秒钟处理的接口请求数量。

（一个服务器中有多个接口， QPS 指的是所有接口在同一个单位时间内的接口处理数量之和）

6.3.2TPS

服务器每秒钟处理的事务请求数量。

一个事务通常指的是界面上的一个操作。一个事务可以包含一个或者多个接口请求。

比如：

支付操作：查询用户余额请求+支付安全校验+支付——支付事务就对应了三个接口请求
登录操作：发送一个登录请求——登录事务就对应了一个接口请求。

6.3.3QPS与TPS

对于登录事务而言，当TPS为10时，服务器的QPS也是10
对于支付事务而言，当TPS为10时，服务器的QPS就是30

6.4点击数

点击数是衡量Web服务器处理能力的一个重要指标。

提示：

1. 点击数不是通常一般人认为的访问一个页面就是１次点击数，点击数是该页面包含的元素（图片、链接、框架等）向 Web 服务器发出的请求数量。

2. 通常我们也用每秒点击次数（ Hits per Second ）指标来衡量 Web 服务器的处理能力。

注意：只有 web 项目才有此指标。

6.5错误率

错误率指系统在负载情况下，失败业务的概率。错误率＝ ( 失败业务数 / 业务总数 )*100% 。

提示：

1. 不同系统对错误率要求不同，但一般不超过千分之五；

2. 稳定性较好的系统，其错误率应该由超时引起，即为超时率。

6.6资源利用率

是指系统各种资源的使用情况，一般用 “ 资源的使用量 / 总的资源可用量 ×100%” 形成资源利用率的数据。

提示：通常，没有特殊需求的话

1). 建议 CPU 不高于 80%(±5)——电脑里的所有请求，包括操作系统运行、软件程序、磁盘拷贝等，都由CPU完成。

2). 内存不高于 80%——所有程序在运行时要消耗的空间。

3). 磁盘不高于 90%——存储本地数据文件。

4). 网络不高于 80%——影响数据在网络中的传输速度。

七、性能测试的流程

7.1功能测试的流程

需求分析
编写测试计划和方案
编写测试用例，并评审
执行测试用例并提交缺陷
编写测试报告

7.2 性能测试的流程

性能测试需求分析
测试计划及方案
测试用例
测试脚本编写/录制
建立测试环境
执行测试脚本
性能测试监控
性能分析与调优
性能测试报告总结

7.2.1需求分析

熟悉被测系统

熟悉系统的业务功能
熟悉系统的技术架构

明确性能测试内容

从业务角度，挑选核心业务进行测试。如：用户使用频率较高的业务功能
从技术角度，挑选逻辑复杂度高、数据量大的业务进行测试

确定测试策略

负载测试、稳定性等

确定性能测试指标

有需求：按照需求来测试。如：下订单业务并发20个用户、平均响应时间要小于等于3s、事务成功率为100%、CPU使用率小于等于85% 。
没有需求：同类型软件对比，对未来数据进行预估

7.2.2性能测试计划及方案

从模板内容来说，与功能测试基本一致。

主要内容：

1 、项目背景 —— 简介

2 、测试目的

3 、测试范围 —— 对于需求分析中的性能测试内容

4 、测试策略 —— 对应于需求分析中的测试策略

5 、风险控制 —— 技术风险、人力风险

6 、交付清单 —— 每个阶段的产出物

7 、进度和分工 —— 谁在什么时候做什么事

7.2.3性能测试用例的编写

几大要素：用例标题、用例编号、用例前置条件、用例步骤、用例预期结果、用例实际结果

7.2.4性能测试执行

测试脚本的编写 / 录制

建立测试环境 —— 可能与用户的环境一致

执行测试脚本

性能测试监控 —— 与测试脚本执行同时进行；性能监控就是监控服务器的各项性能指标。例如：监控 CPU 、内存、网络、 TPS 、磁盘 IO 等

性能分析和调优

测试人员只需要确定是否存在性能bug，有bug则提缺陷报告
问题分析和调优由开发人员来完成，测试人员配合验证调优结果【可能需要经过多轮验证】