一、概念
1.性能测试：使用自动化工具，模拟不同场景，对软件各项性能指标进行测试和评估的过程
2.包括：a.后台处理程序的性能；b.应用服务器、数据库、架构设计是否存在瓶颈；c.服务器资源消耗(CPU、内存、磁盘、网络）
3.性能关注两方面：a.时间：系统处理用户请求的响应时间；b.资源：系统运行过程中，系统资源的消耗情况
4.性能测试的目的：a.评估当前系统能力；b.寻找性能瓶颈，优化性能；c.评估软件是否能满足未来的需要。
二、性能测试的策略
(一）基准测试
狭义：单用户测试。测试环境确定后，对业务模型中的重要业务做单独的测试，获取单用户运行时的各项性能指标。
第1次：用户输入正确用户名密码，登录成功，耗时10ms
第2次：用户输入正确用户名密码，登录成功，耗时9ms
第3次：用户输入正确用户名密码，登录成功，耗时8.5ms
...
第100次：用户输入正确用户名密码，登录成功，耗时10ms基准测试数据:单用户输入正确用户名密码，登录成功，性能耗时9.9ms（取多次的平均值）
广义：是一种测量和评估软件性能指标的活动。可以在某个时刻通过基准测试建立一个已知的性能基准线，当系统的软硬件环境发生变化之后再进行一次基准测试以确定变化对性能的影响。
基准测试：
商成v1.0版本，模拟5w用户在硬件服务器(8CPU16G内存)运行，接口响应时间为3s.
测试场景：
c1:商成v1.0版本，模拟5w用户在硬件服务器(8CPU32G内存)运行，接口响应时间为2.5s.
c2:商成v1.0版本，模拟10w用户在硬件服务器(8CPU16G内存)运行，接口响应时间为4s.
c2:商成v1.1版本，模拟5w用户在硬件服务器(8CPU16G内存)运行，接口响应时间为2.5s.
基准测试的用途：
1.不会单独存在;2.为多用户并发测试和综合场景测试等提供参考依据;3.为系统、环境配置、系统优化前后的性能提升或下降提供参考指标
(二）负载测试
概念：通过逐步增加系统负载，确定在满足系统的性能指标情况下(如响应时间等)，找出系统所能够承受的最大负载量的测试。
作用：系统最大负载量达到用户要求时，系统才能正式上线使用。
(三）稳定性测试
概念：在服务器稳定运行（用户正常的业务负载下）的情况下进行长时间测试（1天-1周等），并最终保证服务器能满足线上业务需求。
作用：系统在用户要求的业务负载下运行达到规定的时间时，系统才能正式上线使用。
(四）压力测试
在强负载下的测试，查看系统在峰值情况下是否有功能隐患、系统是否具有良好的容错能力和可恢复能力。
分类：1.极限负载情况下导致系统崩溃的破坏性压力测试；2.高负载下的长时间的稳定性压力测试
如图所示，C-D为极限负载，B-C为高负载
A-B范围内，增加系统的在线用户数，系统的处理能力（负载量）会增大（轻压力区）
B-C范围内，增加系统的在线用户数，系统的处理能力（负载量）不变（重压力区）
C-D范围内，增加系统的在线用户数，系统的处理能力（负载量）会减小（崩溃区）
(五）并发测试
概念：并发测试(绝对开发):在极短时间内，发送多个请求，来验证服务器对并发的处理能力。
应用场景：抢红包、秒杀、抢购。
三、性能测试的指标
响应时间、并发数、吞吐量、点击数、错误率、资源利用率
（一）响应时间
概念：指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的结果，整个过程所耗费的时间
注意：1.通过HTTP接口请求消息来测试；2.不包括 发消息时前端页面的处理时间 和 收到消息后前端页面的渲染显示时间
（二）并发数
概念：某一时刻同时向服务器发送请求的用户数。
（三）吞吐量
概念：单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力。
分类：
A.业务角度看：单位是"业务数/小时"、"业务数/天"、"访问人数/天"、"页面访问量/天"
B.网络角度看：“字节数/小时”、“字节数/天”
C.技术角度看：每秒事务数(TPS)、每秒查询数(QPS)
TPS: Transactions Per Second
每秒事务数：即控制服务器每秒处理的事务请求的数量
事务：即业务，页面上的一个操作，可能对于1个/多个请求。
（四）点击数
概念：指客户端向服务器发送请求时，所有的页面资源元素(如：图片、链接、框架CSS、js等)的请求总数量
注意：1.只有web项目才有这个指标； 2.点击数不是页面上的一次点击
如图所示，百度上点击一个查询按钮，F12看到点击数为 23 requests.
（五）错误率
概念：系统在负载情况下，失败业务的概率。错误率=（失败业务数/业务总数）*100%
注意：1.大多数系统会要求错误率无限接近于0； 2.错误率是一个性能指标，不是功能上的随机bug.
3.随机bug是功能bug,先解决随机bug才能进行性能测试
（六）资源使用率
概念：指系统各种资源的使用情况，一般用"资源的使用量/总的资源可用量*100%"形成资源利用率的数据。
资源指标通常要求：
1.CPU不高于75%-85%
2.内存不高于80%
3.磁盘IO不高于90%
4.网络不高于80%
前两者看利用率。后两者看读写速度。
四、性能测试的流程
==流程==
1.性能测试需求分析：熟悉需求，获取性能需求指标
2.性能测试计划及方案：测什么，谁来测，怎么测
3.性能测试用例设计：用来验证系统是否符合需求
4.性能测试执行：建立测试环境、编写测试脚本、性能测试监控、执行测试脚本
5.性能分析和调优：分析性能结果，针对性能bug调优
6.性能测试报告总结：测试结果总结
（一）性能测试的需求分析
1.明确被测系统
熟悉被测系统的业务功能、技术架构
2.明确测试内容
业务角度:用户使用频率较高的关键业务功能
技术角度：a.逻辑复杂度高的业务 b.数据量大的业务
3.明确测试策略
如负载测试、稳定性测试、并发测试等等
4.明确测试指标
a.有明确需求指标：执行结果与预期指标进行对比
b.无明确需求指标（分析指标）：查找资料；类似的系统对比；对未来流量的预告
（二）性能测试计划和方案
1.测什么：项目背景、测试目的、测试范围
2.谁来测：进度与分工、交付清单
3.怎么测：测试策略
总结：性能测试的目的和范围；测试人员和分工；测试时间安排；测试的方法
（三）性能测试用例
（四）性能测试执行
1.建立测试环境
搭建性能测试环境，包括硬件、软件、网络环境
提示：一般情况下可以要求运维和开发协助完成
2.编写测试脚本
按性能测试用例的要求，使用性能测试工具进行编写测试用例脚本
提示：脚本可以自己编写，录制的话很多无关数据还得筛选，不推荐录制的方法
3.性能测试监控
在脚本执行前，配置各项性能的监控指标
如：响应时间、TPS、错误率、资源使用率(CPU 内存 磁盘等)
4.执行测试脚本
设置性能运行场景，执行性能测试，并同步收集各项性能指标
提示：执行性能测试脚本前，保证脚本都调试通过
（五）性能分析和调优
说明：性能测试分析人员经过对结果的分析以后，如果不符合性能要求，则会提出性能bug，然后由开发人员进行后续的调优。
提示：
1.调优：开发人员主导；其他参与配合进行的人员有数据库管理员，系统管理员，网络管理员、性能分析人员
2.验证：性能测试人员继续进行第二轮、第三轮...的测试，与以前的结果进行比对，从而确定经过调整以后系统的性能是否提升
总结：测试人员负责针对性能的测试结果进行分析是否存在bug，由开发人员进行问题分析和调优。在性能测试的回归过程中，可能需要多轮测试
（六）性能测试报告总结
主要内容包括： 测试工作的经过回顾；缺陷分析和调优；风险评估；性能测试结果；测试工作总结与改进
