目录：导读
前言
性能测试流程
1、性能测试接口文档准入
1）系统架构设计文档（系统基础架构图、业务架构图、数据流图）。
2）非功能性需求文档（性能测试指标如：PV、用户数、TPS、并发、响应时间、系统峰值CPU、内存消耗…等等）。
3）资源动作分解表（申请压测环境，包含硬件配置及数量信息）。
4）测试场景（核心业务）。
2、准备系统环境
1）生产环境
生产环境衡量的精准度更高，但是需要删除测试生成的日志等测试数据,同时要保证数据删除的完整性，基础数据的构造参考后续数据量部分。
生产环境压测时，尽量挑选低峰期进行，避免对生产业务产生影响。
2）测试环境
风险可控，但是环境构建比较复杂，规模和生产一致的成本是最高的。
理想状态下的比例是测试：生产=1：2或测试测试：生产1：4。（这里的比例是整体架构的数量或者硬件配置，但基础架构不能改变）
但是当现实条件不满足时，也可以在生产部分应用独立部署测试集群、数据库共用进行测试。
如若搭建压测环境，在环境搭建完成之后，需要从生产脱敏导入基础数据，一般存量数据为三年、测试用例数据查询类交易至少准备5w条，提交类每条数据应不重复，nas等存储数据需准备三年业务量。（如若业务量的归档时间小于三年，则按照归档时间准备）
3、测试计划
测试计划尽量简洁明了，并将每个任务的具体负责人交代清楚。划分任务时，条理要清晰，按照整个性能测试的流程的进行划分。
一般持续迭代的项目按一周作为项目周期，以一周后为结束时间，向前推。 新项目的时间一般为两到三周，具体时间具体对待。
4、测试方案
通过前期的接口文档中得到的信息，编写测试方案，其中包括本次测试的背景、目的、指标、测试范围、系统架构…等等信息。
出测试方案时，不是简单的登记信息就完了，还需要理解系统的整体架构，核心业务流程等等。只有这样，在面对可能出现的性能问题时或其他问题时，才会得心应手，无所畏惧。
5、测试执行
1）测试脚本
测试脚本分两种。一种是录制脚本，主要针对业务系统。另一种是接口类脚本，根据研发提供的接口文档编写对应得脚本。
脚本的部分没啥好说的，与研发积极沟通，把脚本调通就完了。
2）场景执行
场景分为 基准、单场景、混合场景、极限场景、稳定性场景。
执行时，业务方面关注三个点：事务成功率、TPS、响应时间。
系统方面关注五个点：CPU消耗、内存消耗、网络IO、磁盘IO、Swap。
如果某项指标不达标，以链路为线路，由前至后进行跟踪。
以常见的系统架构为例：F5>Nginx集群>F5>微服务集群>Redis>Mysql
首先排查F5是否性能瓶颈，再检查Nginx的配置…等等，逐级排查，确保没有遗漏。
6、测试报告
测试完成以后，根据测试结果，整理出相应的测试报告。
测试范围、测试指标、实际指标、资源消耗、性能瓶颈、调优记录等等信息。
负载测试，并发测试，压力测试区别
1、负载测试
1）定义
负载测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。
2）目的
不把系统搞挂的测试，使系统能够在最大的压力下可以正常运行。从而获取系统指标。
3）方法
不断增加请求压力，直到服务器某个资源项达到饱和（比如CPU使用率达到90%+）或某个指标达到安全临界值（比如运维的监控告警阈值or拐点）。
系统负载压力包含并发用户数、持续运行时间、数据量等。其中并发用户数是负载压力的重要指标。
2、并发测试
1）定义
检查系统是否有并发问题，例如内存泄漏、线程锁、资源争用等问题。
2）目的
确定用户并发数，必须知道系统所承载的在线用户数。然后在单位时间内(S)同时发起一定量的请求。
3）确定并发用户数的方法
例如：
公司OA系统账号或者总用户有2000人；
最高峰在线500人；
但是这500人并不是作为并发用户存在的概念。即并不表示服务器实际承载的压力；有可能40%关注的是首页新闻公告板之类（注意看新闻这个阶段是不能造成服务器的压力）；
20%用户在查询资料或者操作表格；20%用户在发呆；20%在页面之间跳转；在这种情况下，只有真正20%用户在对服务器造成实质的影响。
我们将这个查询、操作表格作为一个业务范畴来说；直接将这部分业务并发用户称为并发用户数：
计算平均并发用户数：C=NL/T；
并发用户峰值数：C’ ≈ C+3根号C；
公式1中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。
公式2则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式1中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。
假设有一个OA系统，该系统有3000个用户，（可以看注册信息）平均每天大约有400个用户要访问该系统，（日志文件查看）对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。
则根据公式1和公式2，可以得到：
C = 4004/8 = 200
C’≈200+3根号200 = 242
但是一般的做法是把每天访问系统用户数的10%作为平均的并发用户数。最大的并发用户数乘上一个值，2或者3。
假如说用户要求系统每秒最大可以处理100个登陆请求，10/25/50/75/100 个并发用户来执行登陆操作，然后观察系统在不同负载下的响应时间和每秒事务数。如果用户数在100的时候，响应时间还在允许范围呢，就要加大用户数，例如120 等 。
个人理解这个用户数就是我们经常说的等价类和边界值法来设定。
3、压力测试
1）定义
是给软件不断加压，强制其在极限的情况下运行，观察它可以运行到何种程度，从而发现性能缺陷。
2）目的
把系统搞挂的测试。
3）方法
以负载测试或者并发测试为依据，给软件不断加压，强制其在极限的情况下运行，观察它可以运行到何种程度，从而发现性能缺陷。
| 下面是我整理的2023年最全的软件测试工程师学习知识架构体系图 |
一、Python编程入门到精通
二、接口自动化项目实战
三、Web自动化项目实战
四、App自动化项目实战
五、一线大厂简历
六、测试开发DevOps体系
七、常用自动化测试工具
八、JMeter性能测试
九、总结（尾部小惊喜）
追逐梦想，无畏风雨，踏上征程，砥砺前行。心怀勇气，坚持奋斗，才能创造属于自己的辉煌，让生命绽放出绚烂的光芒。相信自己，努力拼搏，成功将与你不期而遇。
每一次努力都是一次积累，每一次奋斗都是一次成长。坚持不懈，超越自我，才能在人生的舞台上演绎出绚丽的篇章。相信自己的力量，追逐梦想，创造属于自己的辉煌人生。
燃烧心中的激情，踏上征程的脚步，即使路途坎坷，也要坚持不懈地追求梦想。相信自己的能力，勇往直前，只有这样，才能创造出属于自己的辉煌人生。