性能测试的三个核心原理是什么？

1.基于协议。性能测试的对象是网络分布式架构的软件，而网络分布式架构的核心是网络协议
2.多线程。人的大脑是单线程的，电脑的cpu是多线程的。性能测试就是利用多线程的技术模拟多用户去负载
3.模拟真实场景。用户的访问时间，访问频率都不是固定的。

性能测试的核心关注点是什么？

1.用户关注。响应时间，稳定性、可恢复性
2.运维关注。服务器/数据库资源使用，服务器端处理速度,系统能否支撑7*24小时
3.测试关注。最大访问用户数量，最大业务处理数量，内存资源能否正常回收
4.开发关注。代码：算法、sql语句

简述性能测试流程

1.分析性能需求。挑选用户使用最频繁的场景来测试，比如：登陆，搜索，下单等等。确定性能指标，比如：事务通过率为100%，TOP99%是5秒，最大并发用户为1000人，CPU和内存的使用率在70%以下
2.制定性能测试计划，明确测试时间(通常在功能稳定后，如第一轮测试后进行)和测试环境和测试工具
3.编写测试用例
4.搭建测试环境，准备好测试数据
5.编写性能测试脚本
6.性能测试脚本调优。设置检查点、参数化、关联、集合点、事务，调整思考时间，删除冗余脚本
7.设计测试场景，运行测试脚本，监控数据
8.分析测试结果，收集相关的日志提单给开发
9.性能测试回归
10.编写测试报告

如何确定系统最大负载？

通过负载测试，不断增加并发，随着并发数的增加，各项性能指标也会相应产生变化，当出现了性能拐点，比如，当用户数达到某个数量级时，响应时间突然增长，那么这个拐点处对应的用户数就是系统能承载的最大用户数。Jmeter中可以用rps定时器或者阶梯加压线程组。

你们系统哪些地方(哪些功能)做了性能测试？

选用了用户使用最频繁的功能来做测试，比如：登陆，搜索，提交订单

你们的并发用户数是怎么确定的？

1）会先上线一段时间，根据收集到的用户访问数据进行预估
2）根据需求来确定，使用高峰时间段，注册用户数，单次响应时间等

你们性能测试在什么环境执行？

搭建一套独立的性能测试环境进行测试

你们性能测试什么时间执行？

基准测试：功能测试之后，系统比较稳定的时候再做。
负载测试：夜深人静，系统没人用的时候

怎么分析性能测试结果？

首先查看事物通过率，然后分析其他性能指标，比如，确认响应时间，事务通过率，CPU等指标是否满足需求；如果测试结果不可信，要分析异常的原因，修改后重新测试

think_time的作用是什么？

在业务基准测试中模拟用户的思考时间

在确定性能测试结果可信后，如果发现以下问题，按下面提供的思路来定位问题

问题一：响应时间不达标

查看事务所消耗的时间主要在网络传输还是服务器，如果是网络，就结合Throughput(网络吞吐量)图，计算带宽是否存在瓶颈，如果存在瓶颈，就要考虑增加带宽，或对数据的传输进行压缩处理；如果不存在瓶颈，那么，可能是网路不稳定导致。如果主要时间是消耗在服务器上，就要分别查看web服务器和数据库服务器的CPU，内存的使用率是否过高，因为过高的CPU，内存必定会造成响应时间过长，如果是web服务器的问题，就把web服务器对应上对应的用户操作日志取下来，发给开发定位；如果是数据库的问题，就把数据库服务器对应上对应的日志取下来，发给开发定位。

问题二：服务器CPU指标异常

1：关注cpu利用率和负载情况，如果利用率过低负载过高，那么可能是进程队列过多，造成了阻塞
2：关注上下文切换，如果主动切换过多，那么可能是内存/IO瓶颈；如果被动切换过多，那么可能时间片不够，可以考虑调整进程优先级来增加时间片

问题三：内存溢出，进程消失

1：观察堆内存的年轻代与老年代空间分配是否合理，调整内存参数
2：swap空间是否不足，触发了oomkiller

问题四：程序在多用户运行时严重超时，甚至提示连不上服务器。

程序可能是单线程处理机制，后续的线程全部在排队等待

 

问题五：如何识别系统瓶颈？

1：随着负载的增加，吞吐量是否能持续稳定的上升，找到吞吐量下滑的那个点
2：随着负载的增加，响应时间是否开始变长，找到响应时间突然变长的那个点
3：随着负载的增加，是否开始出现错误

常见的施压模型有哪几种？
1、并发模式（虚拟用户模式）
并发是指虚拟并发用户数，从业务角度，也可以理解为同时在线的用户数。从客户端的角度出发，摸底业务系统各节点能同时承载的在线用户数，可以使用该模式设置目标并发，也就是jmeter工具里面的线程数
2、RPS 模式（吞吐量模式）
RPS（Requests Per Second）是指每秒请求数。RPS 模式即“吞吐量模式”，通过设置每秒发出的请求数，从服务端的角度出发，直接衡量系统的吞吐能力。

性能测试的应用领域有哪些？

能力验证：通过实际的测试结果证明自己系统的预期能力
瓶颈分析：通过一系列的测试手段发现系统的性能瓶颈（并发，负载，压力，失效恢复）
性能调优：通过一系列的技术手段优化系统性能，包括响应时间，吞吐量，资源利用率
容量规划：为了符合未来的规划预期（用户数，市场占有率），对资源做相应的调整

jmeter如何设计性能测试场景？

并发测试：基础线程组（强调单位时间的并发，不存在绝对并发）
基准测试：反复对比结果，验证调优结果是否通过（tps是否提升，响应时间是否下降）
负载测试：持续不断地增加负载，发现性能瓶颈（阶梯加压线程组，Concurrency Thread Group）
并发用户模式的负载：不断增加并发用户数，发现瓶颈
吞吐量模式的负载：不断增加每秒请求数（rps）对服务端施压，发现tps瓶颈
压力测试：tps瓶颈点上持续负载
       稳定性压力测试：tps保持高压稳定。一般取最大tps的80%持续运行
       破坏性压力测试：目的是只需要服务端出现异常
失效恢复测试：出现异常之后，系统可以很快的恢复
容量规划测试：50万，高峰时间段2小时

tps无法上升原因有哪些？

1.网络带宽
在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，就会造成网络资源竞争，导致服务端接收到的请求数达不到服务端的处理能力上限。

2.连接池
可用连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。

3.GC
如果堆内存分配的不合理，就会导致频繁的gc，gc会导致线程暂停。尤其是fullgc，会造成线程长时间暂停

4.数据库配置
高并发情况下，如果请求数据需要写入数据库且需要写入多个表的时候，数据库的最大连接数不够，或者写入数据的SQL没有索引，或没有主从分离、读写分离，就会导致数据库事务处理过慢，影响到TPS。

6.硬件资源
包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）

7.压力机
单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，会影响TPS（这个时候就需要进行分布式压测来解决问题）

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取