性能
性能： 就是软件质量属性中的“效率”特性
- 时间特性： 指服务器处理用户请求的响应时间
- 时间效率高->不卡
- 时间效率低->卡
- 资源特性： 软件在运行时，对于服务器资源的消耗情况
- CPU
- 内存
- 磁盘等（磁盘的写入Input和读取Output， 简称IO）
一、性能测试概述
概念： 使用自动化工具， 模拟不同的场景， 对软件各项性能指标进行测试和评估的过程
后台处理程序的性能（代码性能）
应用服务器、数据库、架构设计等是否存在瓶颈
服务器资源的消耗（CPU、内存、磁盘、网络）
目的：
->评估当前系统能力
• 根据需求文档,是否满足需求文档
• 获取关键的性能指标， 与其他竞品进行比较（例如：跑分）
->寻找性能瓶颈， 优化性能（例如：12306春运时服务故障）
->评估软件是否能够满足未来的需要（例如：淘宝11在2022年的销售额）
性能与功能测试区别与关联
• 功能测试：验证软件系统对用户需求规则的满足程度，主要焦点在功能(正向、 逆向)
• 性能测试：验证软件系统是否满足业务需求场景，主要焦点是业务场景的满足(时间、 资源)
• 关联->先功能测试通过后， 再进行性能测试
二、性能测试类型
基准测试
狭义：就是单个用户进行业务场景的测试.并统计性能的各项指标（为后续多用户性能测试做参考对比）
广义：建立一个基准线，当系统的软硬件发生变化时再次进行基准测试，观察变化对于性能产生的影响
作用:
为多用户并发测试和综合场景测试等性能分析提供参考依据
为系统或环境的配置,系统优化前后的性能提升/下降提供参考指标
基准测试不会单独存在
负载测试
通过逐步增加系统负载（请求、用户、压力），在满足系统的性能指标情况下， 找到系统的最优负载量和最大负载量的测试
作用:系统最大负载量达到用户要求时，系统才能正式上线使用
稳定性测试是指， 在服务器稳定运行（用户正常的业务负载下） 的情况下进行长时间测试， 并最终保证服务器能满足线上业务需求
时长一般为1天、 一周等
作用:系统在用户要求的业务负载下运行达到规定的时间时，系统才能正式上线使用
并发测试
是指在极短的时间内，发送多个请求，来验证服务器对并发的处理能力
特定活动场景，如：抢红包、秒杀、抢购等
压力测试
测试系统在强负载的情况下，测试系统在峰值情况下的操作，是否具有良好的容错能力及错误的恢复能力
• 稳定性压力测试：在系统高负载的情况下（接近C点），长时间运行（24小时），查看系统的处理能力
• 破坏性压力测试：在系统极限负载的情况下（C-D点），对系统进行压力测试，查看系统容错能力和错误恢复能力
一句话总结->高负载下，查看系统在峰值情况下的容错能力和可恢复能力
三、性能测试的指标
目的:对性能测试结果进行量化衡量
响应时间
指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的结果，整个过程所耗费的时间
响应时间 = 应用程序处理时间（A1+A2+A3） + 网络传输时间（N1+N2+N3+N4）
并发数
某一时刻同时向服务器发送请求的用户数
• 系统用户数： 系统注册的总用户数据
• 在线用户数： 某段时间内访问系统的用户数， 这些用户并不一定同时向系统提交请求
• 并发用户数： 某一物理时刻同时向系统提交请求的用户数
系统用户数 >= 在线用户数 >= 并发用户数
吞吐量
吞吐量（Throughput） 指的是单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力
单位从不同维度来描述：
业务维度：业务数/秒，业务数/小时，业务数/天
网络维度：字节数/秒，字节数/小时，字节数/天
技术维度：TPS（每秒事务数）、QPS（每秒请求数）
TPS
Transactions Per Second， 每秒查询数 控制服务器每秒处理的指定请求的数量
事务： 一个事务通常指的是界面上的一个操作。一个事务可以包含一个或者多个接口请求
如支付请求，包括服务器查询用户余额，支付安全校验等多个操作。
一个业务请求发送给服务器后，最终会定位到服务器对应的业务请求的代码， 既有可能是一段代码也有可能是多段代码
QPS
QPS(Query Per Second)每秒请求数，控制服务器每秒处理指定请求数
注意:一个服务器中有多个接口，QPS指的是所有接口在同一个单位时间内的接口处理数量之和
点击数
点击数是该页面加载时包含的所有元素 (图片、 链接、 框架等、html代码、js等）
点击数是向Web服务器发出的请求数量,不是页面上的一次点击
通常我们也用每秒点击次数（Hits per Second） 指标来衡量Web服务器的处理能力
注意： 只有web项目才有此指标
错误率
指系统在负载情况下， 失败业务的概率
大多系统都会要求错误率无限接近于0
注意:
错误率是一个性能指标，是负载下的失败业务的概率,不是功能上的随机bug
随机Bug是功能Bug,先解决随机Bug才能进行性能测试
错误率＝(失败业务数/业务总数)*100%（错误率不是功能有错误或者bug）
资源利用率
是指系统各种资源的使用情况， 一般用“资源的使用量/总的资源可用量×100%”形成资源利用率的数据
提示：通常，没有特殊需求的话
1). 建议CPU不高于80%(±5)
2). 内存不高于80%
3). 磁盘不高于90%
4). 网络不高于80%
四、性能测试流程
性能测试需求分析
熟悉被测系统
• 熟悉系统的业务功能
• 熟悉系统的技术架构
明确性能测试内容
• 从业务角度，挑选核心业务进行测试
• 从技术角度，挑选逻辑复杂度高、数据量大的业务进行测试
确定测试策略
• 负载测试、稳定性、并发等
确定性能测试指标
• 有需求：按照需求来测试
• 没有需求：同竞品软件对比，对未来数据进行预估
2. 性能测试计划及方案
说明： 性能测试实施第一份文档， 也是最重要的一份文档。
主要内容：
测什么:项目背景->测试目的->测试范围
谁来测:进度与分工->交付清单
怎么测:测试策略
提示:
要了解测的是个什么项目,测这个能解决什么问题,测试范围涵盖那些比如:要测他的稳定性和压力等等
测得时候是你自己测还是有其他小伙伴和你一起测的,分工要明确;最终再确定测试的方法
3. 性能测试用例
要素：用例标题、用例编号、用例预制条件、用例步骤、用例预期结果、用例实际结果（实际结果：需要监控的各项性能指标） 负载测试模板
4、测试执行
建立测试环境
->搭建性能测试环境，包括硬件环境、软件环境、网络环境
->提示：一般情况下可以要求运维和开发工程师协助完成
测试脚本编写
->按照性能测试用例的需要，使用性能测试工具进行编写测试脚本
->提示：脚本可以自己编写，也可以使用工具来录制
性能测试监控
->在脚本执行前，配置各项性能的监控指标
->如：响应时间、TPS、错误率、资源使用率（CPU、内存、磁盘等）
执行测试脚本
->设置性能运行场景，执行性能测试，并同步收集各项性能指标
->提示：执行性能测试脚本前，保证脚本都调试通
性能分析和调优
->性能测试分析人员经过对结果的分析以后，如果不符合性能需求，则会提出性能bug，然后由开发人员进行后续的调优
提示：
->调优人员(开发人员、 数据库管理员、 系统管理员、 网络管理员、 性能测试分析人员)相关人员对系统进行调整
->验证-性能测试人员继续进行第二轮、 第三轮……的测试，与以前的测试结果进行对比， 从而确定经过调整以后系统的性能是否有提升
系统调优由易到难的先后顺序如下：
->硬件问题
->网络问题
->应用服务器、数据库等配置问题
->源代码、数据库脚本问题
->系统构架问题
5.性能测试报告总结
测试报告是对性能测试工作的总结，为软件后续验收和交付打下基础
->性能测试工作的过程记录,发行的问题和分析
->性能测试过程中的风险,当前是否存在风险
->给出性能测试的结果(用例通过的和不通过的),经验和改进
