性能测试理论知识
1. 学习目标
1.理解性能测试的定义和目的；
2.理解性能测试中常见的测试策略；
3.理解性能测试中常见的性能指标；
4.理解性能测试的流程。
2. 性能测试概述
2.1. 为什么要进行性能测试？
2.1.1. 业务需求
- 大量用户下，系统能否稳定运行（比较多的）
- 用于硬件服务器的选型
- 用于软件技术的选型
2.1.2. 招聘需求
面试：会性能测试吗？
招聘信息：要求会使用性能测试工具Jmeter、LoadRunner提示：要解决以上问题，必须要进行相关性能测试
2.2. 什么是性能？
这的性能通常意义上都是说的服务器的性能，如果是app性能，还需关注手机的内存、CPU、电量、流量、流畅度等情况。
2.3. 性能的关注点（即效率）
- 时间特性：服务器处理用户请求的响应时间（卡/不卡）；
- 资源特性：软件在运行时，对于服务器资源的消耗情况（CPU、内存、磁盘IO等等）。
2.4. 什么是性能测试？
概念：使用自动化的工具，模拟不同的场景，对软件的各项性能指标进行测试和评估。
软件的范围包括：
- 后台处理程序（开发写的代码）；
- 中间件（应用服务器）、数据库、MQ（消息队列）、Ridis（缓存）、程序架构等等；
- 服务器资源的消耗（CPU、内存、磁盘、网络）。
2.5. 性能测试的目的
- 评估当前的系统能力；
- 验收第三方提供的软件（如：第三方软件测试）；
- 获取关键的性能指标，与同类型的软件对比（例如：跑分）。
- 发现性能问题后，寻找性能瓶颈，优化性能（例如：12306春运时服务故障）；
- 评估软件能否满足未来的性能需要（例如：淘宝11在2020年的销售额）。
2.6. 性能测试和功能测试
2.6.1. 焦点
- 功能：关注系统对用户需求规则的满足程度。关注点（正向、逆向）；
- 性能：关注系统对用户业务场景的满足程度。关注点（时间、资源）。
2.6.2. 关系
- 在一个项目中，功能测试和性能测试一般都有；
- 功能测试通过后，才进行性能测试。
3. 性能测试分类
- 基准测试
- 负载测试
- 稳定性测试
- 其他：并发测试、压力测试、容量测试等
3.1. 基准测试
狭义上讲：单个用户进行业务场景的测试，并统计性能的各项指标（为后续多用户性能测试做参考对比）
广义上讲：在某一个时刻进行性能测试建立一个已知的性能水平，当软硬件发生变化时再测试，观察变化对于性能产生的影响
3.2. 负载测试
通过逐步增加系统负载量，测试系统性能的变化，在满足性能指标的前提下，系统所能够承受的最大负载量的测试。
通过负载测试，一般能找到系统的最优负载和最大负载。
最大负载一般项目组内部知晓，不会对外公布。
普通用户看到的系统的最大能力，一般都是测试得到的最优负载。
3.3. 稳定性测试
在服务器稳定运行（业务正常的负载量）的情况下，进行长时间的测试，保证服务器能够正常运行。
长时间：1天、1周
提示
稳定性测试的三个阶段
第一个阶段：恒定压力阶段
目标是为了检验在恒定的大压力下，系统的服务是否稳定，比如是否存在吞吐量TPS指标的波动，响应延迟的抖动、毛刺等。波动情况必须在恒定的压力下进行验证，如果是波动的压力，出现吞吐量波动或者响应延迟的长尾现象会难以捕捉分析，难以区分是业务的问题还是服务的问题，为性能问题定位带来较大难度。
第二个阶段：基于一定的产品压力模型的，已上线产品
我们不难观察产品线上的典型业务及业务比例，那么在过去的七天或者一个月的时间内，产品每天的业务模型是什么样的？根据线上监控及统计不难得出。这个阶段就是为了模拟线上的这种业务模型下，也即是存在峰谷变化的压力、典型的一些Web产品每天的压力模型是比较固定的，比如每天早上9点，下午4点，晚上10点都会存在压力峰值。这种方式的模拟会为系统的稳定性带来一定的压力，如用户量突增等情况，会不会导致错误或宕机等。
第三个阶段：是在恒定压力下，引入异常干扰，注入异常用例
如CPU波动、网络延迟、主节点挂掉或重启等异常情况的出现，来充分拷打产品的稳定性和可靠性。在google的测试之道中也有提及这种模式，虽然没有更多细节暴漏出来，不过在这方面还是值得探索的。
3.4. 其他分类
3.4.1. 并发测试
系统在短时间内同时处理大量请求，查看系统的并发处理能力。如：抢红包、抢购、秒杀活动等。
3.4.2. 压力测试（重要）
测试系统在强负载的情况下，测试系统在峰值情况下的操作，是否具有良好的容错能力及错误的恢复能力。
- 稳定性压力测试：在系统高负载的情况下（接近C点），长时间运行（24小时），查看系统的处理能力，
- 破坏性压力测试：在系统极限负载的情况下（C-D点），对系统进行压力测试，查看系统容错能力和错误恢复能力。
3.4.3. 容量测试
关注系统在极限情况下的各种极限参数值，例如：最大TPS，最大连接数，最大并发数，最多数据条数等。
4. 性能测试的指标
指标：在性能测试的过程中，记录的一系列的数据值。用这些实际记录的数据值与需求中的性能要求做对比，达成需求要求则无问题；未达到需求要求则说明是性能bug。
常见的性能指标：
响应时间、并发数、吞吐量（TPS、QPS）、错误率、点击数、资源利用率。
4.1. 响应时间
客户端发送请求，到客户端收到服务器返回的响应，过程中所经历的全部时间，都是响应时间。
响应时间 = 应用程序处理时间（A1+A2+A3） + 网络传输时间（N1+N2+N3+N4）
4.2. 并发用户数
说明：某一物理时刻同时向系统提交请求的用户数。
扩展：
- 系统用户数：系统注册的总用户数据；（如淘宝注册用户数：10亿）
- 在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求；（如淘宝当前登录用户数：1亿）
- 并发用户数：某一物理时刻同时向系统提交请求的用户数。（如淘宝当前正在使用系统的用户数：500万）
4.3. 吞吐量
英文为Throughput，单位时间内，系统处理客户端请求的数量。衡量服务器性能好坏的直接指标。
从不同维度来衡量吞吐量：
- 业务维度：业务数/秒，业务数/小时，业务数/天
- 网络维度：字节数/秒，字节数/小时，字节数/天；
- 技术维度：TPS（每秒事务数）、QPS（每秒请求数）。
4.3.1. QPS
服务器每秒钟处理的接口请求数量。
一个服务器中有多个接口，QPS指的是所有接口在同一个单位时间内的接口处理数量之和。
4.3.2. TPS
服务器每秒钟处理的事务请求数量。
一个事务通常指的是界面上的一个操作。一个事务可以包含一个或者多个接口请求。
对于登录事务而言，当TPS为10时，服务器的QPS也是10；
对于支付事务而言，当TPS为10时，服务器的QPS就是30。
4.4. 点击数
点击数不是指在页面上的一次点击，指的是页面（html代码、图片、js...）加载时，向服务器发送的请求数量，可以用每秒点击数来衡量web服务器的处理能力。
提示
- 点击数是衡量Web服务器处理能力的一个重要指标。
- 只有web项目才有此指标。
4.5. 错误率
错误率不是功能有错误或者bug，指的是在系统高负载的情况下，失败业务的概率。
错误率 = （业务失败的次数 / 业务的总次数） * 100%。
::: 提示
- 不同系统对错误率要求不同，但一般不超过千分之五；
- 稳定性较好的系统，其错误率应该由超时引起，即为超时率。
:::
4.6. 资源利用率
资源利用率 = (资源的使用量 / 总的资源可用量) * 100%
通常，没有特殊需求的话。
建议CPU不高于88%（±5）；
在电脑里的所有处理请求（操作系统运行、软件程序、磁盘拷贝等） 都由CPU完成。
内存不高于80% ；
所有程序在运行时要消耗的空间，（存储程序运行的数据）。
磁盘不高于90%；
需预留空间存储本地数据文件。
网络不高于80%；
影响数据在网络中的传输速度。
5. 性能测试的流程
5.1. 需求分析
说明
性能需求分析是整个性能测试工作开展的基础，性能需求分析做的好不好直接影响到性能测试的结果。
熟悉被测系统；
- 熟悉系统的业务功能；
- 熟悉系统的技术架构。
明确性能测试内容；
从业务角度，挑选核心业务进行测试；
确定关键业务。即：用户使用频率较高的业务功能。
从技术角度，挑选逻辑复杂度高、数据量大的业务进行测试。
通常逻辑复杂度较高的业务也是CPU密集运算较大的地方，考量服务器CPU在预定性能指标下是否达标；
通常数据量较大的业务很占用系统内存，考量服务器内存在预定性能指标下是否达标。
确定测试策略；
- 负载测试、稳定性测试、并发测试等
确定性能测试指标。
- 有需求：按照需求来测试，只需要根据执行分析结果与预期指标做对比，如果有不满足的，就需要分析问题所在例如，类似如下指标：
- 下订单业务并发20个用户；
- 平均响应时间要小于等于3s；
- 事务成功率为100%；
- CPU使用率小于等于85%。
- 没有需求：同类型软件对比，对未来流量、数据进行预估，确定性能测试需求的指标。
- 有需求：按照需求来测试，只需要根据执行分析结果与预期指标做对比，如果有不满足的，就需要分析问题所在例如，类似如下指标：
5.2. 性能测试计划
从模板内容来说，与功能测试基本一致，主要就是写清楚谁来做、怎么做。
主要内容：
- 项目背景 —— 简介
- 测试目的
- 测试范围 —— 对于需求分析中的性能测试内容
- 测试策略 —— 对应于需求分析中的测试策略
- 风险控制 —— 技术风险、人力风险
- 交付清单 —— 每个阶段的产出物
- 进度和分工 —— 谁在什么时候做什么事
说明
性能测试计划是性能测试实施第一份文档，也是最重要的一份文档。
5.3. 性能测试用例
编写测试用例要素：1.用例标题、2.用例编号、3.用例预制条件、4.用例步骤、5.用例预期结果、6.用例实际结果
注意
- 缺一个测试目的，对应用例描述。
- 实际结果：需要监控的各项性能指标
5.4. 测试脚本编写**/**录制
性能测试用例编写完成以后，接下来就需要结合用例的需要，进行测试脚本的编写工作。
提示
录制或编写，根据不同的工具要注意代码冗余。
5.5. 建立测试环境
在进行性能则试之前，需要先完成性能测试环境的搭建工作，测试环境一般包括硬件环境、软件环境及网络环境，尽可能与用户的环境一致。
提示
一般情况下可以要求运维和开发工程师协助完成。
5.6. 执行测试脚本
首先要保证脚本调试通过之后，才能进入正式压测阶段。
执行测试脚本时，要先进行性能运行场景的设置，再运行脚本。
5.7. 性能测试监控
监控服务器的各项性能指标。例如：监控CPU、内存、网络、TPS、磁盘IO等的使用情况。
提示
性能测试监控与测试脚本的执行是同时进行的。
5.8. 性能分析和调优
性能测试分析人员经过对结果的分析以后，有可能提出系统存在性能瓶颈。
- 测试人员只需要确定是否存在性能bug，有bug则提缺陷报告；
- 问题分析和调优由相关人员（开发人员、数据库管理员、系统管理员、网络管理员、性能测试分析人员）来完成，测试人员配合验证调优结果（可能需要经过多轮验证，从而确定经过调整以后系统的性能是否有提升）。
5.9. 性能测试报告
性能测试总结要包含以下内容：
- 性能测试需求覆盖情况，测试过程回顾，及测试中出现的问题（如何去分析、调优、解决的）---基本要求；
- 性能测试过程中遇到各类风险是如何控制的，目前是否还有其他的性能风险存在；
- 给出性能测试结论（通过/不通过），经过该项目性能测试后，有那些经验和教训等内容。