1.什么是性能测试?

概念:

​ 使用自动化的工具，模拟不同的场景，对软件的各项性能指标进行测试和评估。

软件的范围包括:

• 后台处理程序(开发写的代码)
• 中间件(应用服务器)、数据库、程序架构等等
• 服务器资源的消耗(CPU、内存、磁盘、网络)

性能测试的目的:

​ 1、评估当前的系统能力 验收第三方提供的软件获取关键的性能指标，与同类型的软件对比(例如:跑分)

​ 2、发现性能问题后，寻找性能瓶颈，优化性能(例如:12306春运时服务故障)

​ 3、评估软件能否满足未来的性能需要(例如:淘宝11在2020年的销售额)

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

• 焦点:
  • 功能:关注系统对用户需求规则的满足程度。关注点(正向、逆向)
  • 性能:关注系统对用户业务场景的满足程度。关注点(时间、资源)
• 关系:
  • 在一个项目中，功能测试和性能测试一般都有
  • 功能测试通过后，才进行性能测试

为什么要进行性能测试?

• 业务需求
  • 大量用户下，系统能否稳定运行(比较多的)
    用于硬件服务器的选型
    用于软件技术的选型
• 招聘需求

性能的关注点:

• 性能(即效率)

  时间特性:服务器处理用户请求的响应时间(卡/不卡)

  资源特性:软件在运行时，对于服务器资源的消耗情况

  ​ CPU、内存、磁盘等等

性能测试分类:

• 基准测试
• 负载测试
• 稳定性测试

基准测试:

狭义上讲:单个用户进行业务场景的测试，并统计性能的各项指标(为后续多用户性能测试做参考对
比)
广义上讲:在某一个时刻进行性能测试建立一个已知的性能水平，当软硬件发生变化时再测试，观察变
化对于性能产生的影响

负载测试

通过逐步增加系统负载量，测试系统性能的变化，在满足性能指标的前提下，系统所能够承受的最大负
载量的测试。

通过负载测试，一般能找到系统的最优负载和最大负载。
最大负载一般项目组内部知晓，不会对外公布。
普通用户看到的系统的最大能力，一般都是测试得到的最优负载。

稳定性测试:

在服务器稳定运行(业务正常的负载量)的情况下，进行长时间的测试，保证服务器能够正常运行。
长时间:1天、1周

其他分类:

并发测试:

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

压力测试:

测试系统在强负载的情况下，测试系统在峰值情况下的操作，是否具有良好的容错能力及错误的恢复能
力。
稳定性压力测试:在系统高负载的情况下(接近C点)，长时间运行(24小时)，查看系统的处理能 力，
破坏性压力测试:在系统极限负载的情况下(C-D点)，对系统进行压力测试，查看系统容错能力和错 误恢复能力。

容量测试:

关注系统在极限情况下的各种极限参数值。

性能测试的指标

指标

在性能测试的过程中，记录的一系列的数据值。用这些实际记录的数据值与需求中的性能要求做 对比，达成需求要求则无问题;未达到需求要求则说明是性能bug。

常见的性能指标:

• 响应时间
• 并发数
• 吞吐量
• 错误率
• 点击数
• 资源利用率

响应时间:

​ 客户端发送请求，到客户端收到服务器返回的响应，过程中所经历的全部时间，都是响应时间 响应时间 = 应用程序处理时间(A1+A2+A3) + 网络传输时间(N1+N2+N3+N4)

并发用户数:

系统用户数：系统注册的总用户数 （微信号称20亿用户）

在线用户数：某段时间内访问系统的用户数，这些用户不一定同时向系统提交请求 （每天日活1亿人）

并发用户数：在某一时刻向系统提交请求的用户数 （晚上11点整还在和对象你侬我侬的还有500w）

吞吐量:

​ 英文为Throughput，单位时间内，系统处理客户端请求的数量。衡量服务器性能好坏的直接指标。 从不同维度来描述:

• 业务维度: 业务数/秒，业务数/小时，业务数/天
• 网络维度:字节数/秒，字节数/小时，字节数/天
• 技术维度:TPS(每秒事务数)、QPS(每秒请求数)

QPS: 服务器每秒钟处理的接口请求数量。(一个服务器中有多个接口，QPS指的是所有接口在同一个单位时间内的接口处理数量之和)

TPS:服务器每秒钟处理的事务请求数量。 一个事务通常指的是界面上的一个操作。一个事务可以包含一个或者多个接口请求。）（

点击数:

​ 点击数不是指在页面上的一次点击。 指的是页面(html代码、图片、js。。。)加载时，向服务器发送的请求数量 可以用每秒点击数来衡量web服务器的处理能力。

错误率:

​ 错误率不是功能有错误或者bug 指的是在系统高负载的情况下，业务失败的次数/业务的总次数 * 100%

资源利用率:

​ 计算机各个硬件资源的使用情况

性能测试的流程:

需求分析:

• 熟悉被测系统
  • 熟悉系统的业务功能
  • 熟悉系统的技术架构
• 明确性能测试内容
  • 从业务角度，挑选核心业务进行测试
  • 从技术角度，挑选逻辑复杂度高、数据量大的业务进行测试
• 确定测试策略
  • 负载测试、稳定性
• 确定性能测试指标
  • 有需求:按照需求来测试
  • 没有需求:同类型软件对比，对未来数据进行预估

性能测试计划:

从模板内容来说，与功能测试基本一致，主要就是写清楚谁来做、怎么做。 主要内容:

1、项目背景 —— 简介

2、测试目的

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

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

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

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

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

性能测试用例:

要素:用例标题、用例编号、用例预制条件、用例步骤、用例预期结果、用例实际结果
(实际结果:需要监控的各项性能指标)

性能测试执行:

• 测试脚本的编写/录制
• 建立测试环境 ——竟可能与用户的环境一致 执行测试脚本
• 性能测试监控 —— 与测试脚本执行同时进行
• 性能分析和调优
  • 测试人员只需要确定是否存在性能bug，有bug则提缺陷报告
  • 问题分析和调优由开发人员来完成，测试人员配合验证调优结果(可能需要经过多轮验证)

性能测试报告:

1、性能测试的过程记录，性能测试发现的问题、分析

2、性能测试过程中的风险，当前是否存在风险

3、给出性能测试结论(通过/不通过)，经验和教训。