一、性能测试的流程（重重点）
1、性能测试需求分析
熟悉性能需求，获取性能需求指标，以及产品的性能达到什么要的效果
2、性能测试计划及方案
测什么，谁来测，以及用什么样的环境和工具来测，以及什么的时间点测什么到什么样的进度
3、性能测试用例设计
编写我们的测试用例，以及检查我们的测试用例是否满足，我们对应的需求。
4、性能测试执行
把编写完的测试用例，进行编写对应的脚本，执行我们的测试用例 ，并进行我们的性能测试指标的收集。
5、性能分析和调优
把收集好的性能指标，进行对比，分析出性能结果，然后进行优化我们的性能指标。
6、性能测试报告总结最后写出一份性能测试报告
二、性能测试需求分析
性能测试最开始的需求分析工作细致与否，与后面的性能测试结果息息相关。需求分析是一个繁杂的过程，它并非我们想象的那么简单。做需求分析除了要对系统的业务非常了解，还需要有深厚的性能测试知识，这样才能够挖掘分析出真正的性能测试需求。
很多时候，性能测试的需求是比较模糊的，需要性能测试工程师去挖掘和分析。在工作中，经常被问到的一个问题是:应该设置多少个JMeter线程去压测？还有不懂技术的客户提出想要做性能测试，但是没有提供指标，只说系统支持100万用户。这些都是我们日常工作中司空见惯的泛泛的需求。
1、了解被测系统
首先我们需要与开发人员沟通，了解清楚系统的部署架构釆用了哪些中间件、数据库、容器、缓存等，以及它们之间的架构关系，并画出对应的网络拓扑图和系统部署架构图。
了解业务模型。首先我们需要采用用户行为分析，分析用户使用产品的习惯，确定系统的典型业务及发生时间。很多大型系统的业务使用都有流量高峰
2、选取性能测试点
选取性能测试点是性能测试需求分析中非常重要的一个环节。面对一个功能繁杂的系统，要设计出有效的测试场景，最大程度上覆盖系统的性能问题和瓶颈，需要较多的经验积累。
目前我们可以按照以下原则来进行性能测试点的选取：
(1)核心业务模块，例如支付业务（100%不能错误）、核心算法（消耗cpu）；
(2)并发量较高的业务模块；（用户使用频率较高的关键）
(3)逻辑较复杂的业务模块；（逻辑复杂度大，涉及算法多，大数据推荐）
(4)有复杂数据库操作或事务的模块（大量的数据库访问）
3、选取性能测试的方法
对性能测试来说，选取性能测试的方法是致关重要的，只有方法选对，我们得到的性能指标也就会越准确。
比如我做接口的性能，是用jmeter做我们对应的接口的性能，
比如我要测这个软件的稳定性，那我可以选择，monkey命令来进行测试，
这就是我们选择性能测试的方法。
4、量化性能测试指标
梳理出来性能测试场景后，就需要进一步明确各个场景的测试指标，而大部分的产品经理给出的指标都是不完整的。
如果是有明确的指标的话:我们拿到被测的指标和产品提出的指标进行对比就可以
无明确的指标:和上一个版本进行对比，和竞品进行对比，查找行业指标规范。
三、性能测试计划及方案
测试背景
测试目的
测试范围
测试人员
环境说明
测试方法
测试时间表
组织架构
风险分析
测试报告
1、测试背景
首先要阐述本次性能测试的背景，即被测系统类型（web、app），面向哪些用户（内部、外部），具备什么特点（面向什么人群），为什么要进行性能测试，预期的一些指标等等。
比如：为了保证“双十一”大促期间，系统能稳定运行且保障业务的高可用，进行性能测试。
核心：评估系统性能、分析性能变化趋势、定位系统瓶颈风险、协助规划系统容量。
2、测试的目的
测试目的在于通过测试交易系统业务功能及流程实现的正确性、可靠性、易用性，确保系统符合业务需求规格说明书的要求，且系统性能指标和数据库服务器管理方案满足应用要求。通过测试找出系统的性能瓶颈及缺陷，为系统调优提供依据；确定系统能处理的最大业务量，能够支持的最多用户数、并发数
测试的目的要根据测试背景来分析设定，比如：
1、线上服务由于流量过高某部分应用挂了，那测试目的就是：定位瓶颈、分析调优验证；
2、系统架构由集群改为微服务，那测试目的就是：验证稳定性、可用性、单实例容量，为线上服务扩容提供容量规划数据；
3、测试范围
通过需求调研，分析用户使用场景，对业务数据量增长变化趋势及峰值活跃用户等数据做定量分析，确定被测系统的应用范围，比如登录+购物车
订单：创建订单，取消订单
购物车:添加购物车
4、测试人员
根据被测的范围，指定被测的人员进行负责测试对应的人员，责任到人
如:李四：测试订单的业务
张三：测试添加购物车的业务
5、环境说明
环境必须一样
一般来说，进行性能测试的环境尽量接近我们的真实环境，（不能在生产环境中进行性能测试，容易被搞垮）可以在我们的灰度环境（不同的服务器）进行测试,如在灰度环境，网络是wifi
如:软硬件环境
测试工具
网络
公司同一wifi等等
6、测试方法
比如我测试购物车压力测试:
模拟服务器与终端用户之间的网络连接，对Jmeter的虚拟用户使用512K的带宽限制设置，分别模拟50个用户同时（同一秒级）向同一功能点（单一业务）或多个功能点发出操作请求，测试系统的响应能力，包括响应时间以及CPU、内存、磁盘、网络等资源的使用状况，以验证系统对50个用户并发请求时的支持能力。
1）并发用户数量的设计
a．极限法：根据性能需求，假设目前系统要求最大的并发用户数为50个。选择不同的访问时间段，给系统50的查询处理并发量，并持续10分钟，在此过程中收集系统资源利用情况和响应时间（TPS,CPU%,Response Time）。
对于同一个场景，可以使用10，20，30，40不同的用户并发量（步进为10）。
b．用户趋势分析：按照今后N年的用户数量增长和业务增长（30％）分析，N年后要达到的用户数量与业务量的并发要求。假设N年后，最大并发用户数量是65，同时访问系统的最大用户数为1040。选择不同的访问时间段，以步进为10逐步增加并发交易数量，直至到达最大并发用户数量65，在此过程中收集系统资源利用情况和响应时间（TPS,CPU%,Response Time）。
7、测试时间表
对应的时间完成对应的工作量
8、组织架构
组织架构即本次性能测试涉及到的团队各角色成员，主要包含这些：PM角色（产品经理）、测试、开发、运维、DBA（数据库管理员）、网络、基础架构。示例：
9、风险分析
10、性能测试报告输出
四、性能测试用例设计
我们在做完测试需求分析和测试计划以后，那我们就要实际去对应的测试我们的性能，在我们测我们的性能测试之前呢，我们需要进行性能测试用例的设计，怎么样设计我们的测试用例呢？下面我们以
马士兵官网登录为例进行我们性能测试用例的设计：
例 马士兵官网 模拟用户进行登录操作，分别模拟并发用户数为1000，1500，2000等多种情况进行测试，数据库是mysql表是user表有100W 存量账户，加压方式 是全部初使化加压，全部退出的方式，压则时间是 600S 预期结果 并发>=1000，响应时间<=1s，tps>=600，事务成功率为99.5%（涉及资金的，要求100%），错误率小于 千分之三。
用例编号 ：M001
场景描述 ：模拟用户进行登录操作
并发量 ：分别模拟并发用户数为1000、1500、2000等多种情况进行测试
压测时间 ：每次600s
数据量 ：Mysql数据库user表有50万存量账户
脚本设置关键点 ：参数化用户名和密码，用csv进行保存
加压减压方式 ：全部初始化爬坡加压、全部退出
重点关注指标 ：响应时间、tps，事务成功率，错误率
预期指标 ：并发>=1000，响应时间<=1s，tps>=600，事务成功率为99.5%（涉及资金的，要求100%），错误率小于 千分之三。
五、性能测试的执行
当我们的性能测试用例执行完以后，我们就可以对我们的测试用例来进行执行，如同我们的功能测试用例一样，那如何去执行我们的性能测试用例呢？主要是按照如下4步去执行：
1：配好所需要的测试环境
根据我们的测试用例搭建性能测试环境，这里的环境包括我们的硬件环境，软件环境，以及对应的数据库和对应的网络环境
2：编写要测试的脚本
根据我们性能的用例，按照不同的工具写出对应的性能测试脚本(一般都是图形化界面的）
3：配置好要收集的性能指标
写完我们对应的脚本以后，根据我们测试用例要关注的性能指标，配置好对应的性能指标的重点关注。
4：用对应的工具去执行我们的编写的测试脚本
设置好对应的性能指标好，和插件后，进行执行我们的脚 本，并收集好对应的数据，供后面分析使用。
六、性能的分析和调优
当我们执行完我们的性能测试用例以后，就会拿到对应的性能指标（如，我们的响应时间，Tps,错误率等），拿到性能指标后，如果我们的性能达不到我们的期望值，那我们需要对性能进行调优，当然这个调优一般是开发人员对我们的性能进行调优，我们会对指标进行分析。
开发人员一般调优的步骤: 马士兵官网 登录 响应时间要求1s内，测试完成后响应时间为1.2s
第一步：测试
首先准备好测试背景，要给开发看出对应的性能指标，以及我们测试人员在测试当中的步骤是怎么样的，这样的话，开发人员才能根据我们的步骤找出对应的性能指标是否符合，对应的去解决对应的问题。
然后就是测试场景，比如一个是只有安装主功能，一个是不只有主功能，可能还有别的算法也在运行，在不同的场景下，性能上是否会有影响。这也可以成为对比性测试，比如对比一个方法在同步和非同步的情况下性能有什么不同。
最后就是确认测试目标，没有目标的行为都是没有意义的。
第二步：分析并制定调优策略（难）
查找问题（自下而上）：
操作系统层面，CPU、内存、I/O、网络I/O使用率是否存在异常
JVM 层面，查看 JVM 的垃圾回收频率以及内存分配情况是否存在异常
应用层面，查看是否存在性能瓶颈，例如 Java 编程的问题、读写数据瓶颈等等
再通过命令查找异常日志，最后通过分析日志，找到导致瓶颈的原因。
解决问题（自上而下）：
应用层面，优化代码，查看哪里的代码会做无意义的遍历。优化设计模式，比如单例模式在频繁调用创建对象的场景中，可以共享一个创建对象，可以减少频繁地创建和销毁对象所带来的性能消耗。优化算法，比如在不同的场景中，使用合适的查找算法可以降低时间复杂度。
JVM层面，合理地设置 JVM 的内存空间以及垃圾回收算法可以提升系统性能。比如通过设置，将这些大对象直接放进老年代，这样可以减少年轻代频繁发生小的垃圾回收。Java应用线程池的设置
操作系统层面， Linux 操作系统的内核参数设置不合理也有可能导致系统性能瓶颈。
时间换空间，比如String 对象的 intern 方法，可以将重复率比较高的数据集存储在常量池，可以大大节省内存存储空间，但是常量池使用的是 HashMap 数据结构类型，如果我们存储数据过多，查询的性能就会下降。
空间换时间，MYSQL的分库分表，通过将大表进行拆分，我们不需要遍历大表中的数据，而是对应小表的数据，从而缩小获取数据的时间。
第三步：执行
确认方案自然就是进行调优
第四步：测试
执行调优后继续测试从第一步开始，直到参考标准达到测试目标为止
最后：总结并反思
这一点很重要，每次遇到一个问题和挑战就是一个学习的过程，我们要明白这次没有达到标准的原因是什么，下次避免再次犯这样的错误。
七、性能测试报告
1、测试背景
首先要阐述本次性能测试的背景，即被测系统类型，面向哪些用户，具备什么特点，为什么要进行性能测试，预期的一些指标等等。
比如：为了保证“618”大促期间，系统能稳定运行且保障业务的高可用，进行性能测试。
核心：评估系统性能、分析性能变化趋势、定位系统瓶颈风险、协助规划系统容量。
2、测试目的
测试的目的要根据测试背景来分析设定，比如：
1、线上服务由于流量过高某部分应用挂了，那测试目的就是：定位瓶颈、分析调优验证；
2、运营做了拉新和新的渠道拓展，那测试目的就是：评估系统性能是否满足新的线上业务；
3、系统架构由集群技改为微服务，那测试目的就是：验证稳定性、可用性、单实例容量，为线上服务扩容提供容量规划数据；
3、测试范围
比如，梳理出测试的业务域、场景、对应的服务。马士兵登录，购物车
4、预期指标
这里的性能指标包含如下：
①、业务性能指标
即预期的TPS、RT、99%RT、请求成功率（一般默认请求成功率≥99.99%）。
②、硬件性能指标
即服务端资源耗用指标，常规的资源监控指标有：CPU使用率、Memory使用率、系统IO、网络IO等。
③、应用流量指标
比如：核心业务链路的QPS、Redis的命中率、DB的峰值QPS等数值。
5、实施说明
实施说明主要包含如下两项：
1、环境配置
2、测试策略
本次性能测试所采用的测试策略，比如：
探测系统性能拐点，需要阶梯式压测；
探测系统在可接受的性能指标下最大的处理能力，需要采用负载、容量测试策略；
验证系统的稳定性和高可用，需要采用稳定性、高可用测试策略；
验证系统在不同配置下的性能表现，一般采用配置测试策略；
6、测试结果
测试结果展示，依据具体的测试范围、目的来选择性展示。展示的方式可以是多种形式，最常见的是图表类型。
举个例子：单链路基准的场景，一般只需要以表格形式罗列出测试结果即可，做个记录。全链路压测，可以用相对具体的图表来体现测试的结果。
但最重要的，还是结论！以及最终在线上环境所展现的价值。
7、阶段进度
这里主要指的是从需求阶段到结束，各个阶段的工作进展以及资源安排，建议采用看板的方式，及时更新进度，方便推进工作的开展。
8、问题记录
压测过程中的问题进行记录汇报，也是很有必要的。
9、测试结论
本次性能测试在性能测试环境进行，所有涉及场景已测试完毕；测试过程中发现的缺陷已全部修复并验证通过。
为满足本次活动的营销增长需要，线上建议部署12台机器（10台正常提供服务，2台留作buffer）经过评估，当前性能表现满足预期性能指标，达到上线要求。本次性能测试通过。
