本文深入探讨了性能测试的各种策略，包括基准测试、负载测试、并发测试、配置测试等，并阐述了如何进行性能指标分析。强调了在不同阶段进行的测试目的和内容，以及如何通过性能指标如响应时间、并发用户数、TPS等评估系统性能。此外，还介绍了如何获取性能测试需求、如何设计测试场景以及在没有明确需求时的数据收集方法。同时，讨论了用户、开发人员和系统管理员关注的性能要点，以及性能测试中遇到的问题和解决方案。
目录
1、常见的性能测试策略或方法有哪些，各在什么阶段进行、要测试什么内容或者说测试的目的或考察系统什么，以及如何执行
5.请问您是如何得到性能测试需求？怎样针对需求设计、分析是否达到需求？
7、描述不同的角色（用户、产品开发人员、系统管理员）各自关注的软件性能要点。
8、性能测试时，是不是必须进行参数化？为什么要创建参数？JMeter中如何创建参数？
10、假设在测试过程中某些事务的响应时间过长，但分析应用服务、数据库以及网络都属于正常现象，问题可能出现的原因有哪些？
19、性能测试的时候测试数据应该怎么造（需要成千上万大量的数据）
1、常见的性能测试策略或方法有哪些，各在什么阶段进行、要测试什么内容或者说测试的目的或考察系统什么，以及如何执行
参考答案:
基准测试，并发(业务边界值)测试，综合场景测试，负载测试(可置性测试)，疲劳测试，极限压力测试，大数据量测试、配置测试、可靠性测试（类似疲劳）、失效恢复测试
基准测试
基准测试 - 比较新的或未知测试对象与已知参照标准（如现有软件或评测标准）的性能。
性能基线指标测试：当软件系统中增加一个新的模块的时候，需要做基准测试，以判断新模块对整个软件系统的性能影响。按照基准测试的方法，需要打开/关闭新模块至少各做一次测试。关闭模块之前的系统各个性能指标记下来作为基准（Benchmark），然后与打开模块状态下的系统性能指标作比较，以判断模块对系统性能的影响。
目的：系统性能达到预定的指标
a、确定基线指标
b、设计基线指标测试方法
c、设计基线指标测试用例
负载测试
负载测试（Load Testing）：负载测试是一种主要为了测试软件系统是否达到需求文档设计的目标，譬如软件在一定时期内，最大支持多少并发用户数，软件请求出错率等，测试的主要是软件系统的性能。
负载测试- 核实在保持配置不变的情况下，测试对象在不同操作条件（如不同用户数、事务数等）下性能行为的可接受性。
考察软件系统在既定负载下的性能表现指标。指标体现为响应时间、交易容量、并发容量、资源使用率等。
1、根据系统详细设计文档，分析系统可能存在的负载点（并发用户数，业务量，数据量），可以按照特性及功能点进行负载分析
2、固定测试环境，在其它测试角度（负载方面）不变的情况下，变化一个测试角度并持续增加压力，查看系统的性能曲线和处理极限，以及是否有性能瓶颈存在（拐点）
目的：在预定的指标基础上，从多个不同的测试角度去探测分析系统的性能变化情况，获得性能指标，配合性能调优
a、确定测试组网模型
b、设计负载注入用例（系统处理能力）
c、针对不同的负载点，开发负载注入工具
d、开发性能指标采集工具
并发测试
并发测试测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题
1、模拟并发访问，测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题，如内存泄漏、线程锁、资源争用问题。
目的：并非为了获得性能指标，而是为了发现并发引起的问题
a、设计用户事务并发模型
b、设计测试用例
c、设计问题分析方法
配置测试
性能配置 - 核实在操作条件保持不变的情况下，测试对象在使用不同配置时其性能行为的可接受性。
1、通过对被测系统的软硬件环境的调整，了解各种不同环境对性能影响的程度，从而找到系统各项资源的最有分配原则。
目的：主要用于性能调优，在经过测试获得了基准测试数据后，进行环境调整（包括硬件配置、网络、操作系统、应用服务器、数据库等），再将测试结果与基准数据进行对比，判断调整是否达到最佳状态。
a、确定资源调整标准
b、设计配置测试用例
强度测试
强度测试- 核实测试对象性能行为在异常或极端条件（如资源减少或用户数过多）之下的可接受性。
1、特殊场景分析，构造异常或极端条件（如告警风暴、资源减少增多），查看系统状态
目的：核实测试对象性能行为在异常或极端条件之下的可接受性
压力测试
压力测试（Stress Testing）：强度测试也就是压力测试，压力测试主要是为了测试硬件系统是否达到需求文档设计的性能目标，譬如在一定时期内，系统的cpu利用率，内存使用率，磁盘I/O吞吐率，网络吞吐量等，压力测试和负载测试最大的差别在于测试目的不同。
1、测试系统在一定饱和状态下系统能够处理的会话能力，以及是否出现错误。
目的：通过测试调优保证系统即使在极端的压力情况下也不会出错甚至系统崩溃。
稳定性测试
测试系统在一定负载下运行长时间后是否会发生问题。
1、测试系统在饱和状态的70%压力下处理会话能力，以及是否出现错误。
目的：测试系统在长时间运行的情况下不会出错及性能下降问题
容量测试（Volume Testing）
容量测试（Volume Testing）：确定系统最大承受量，譬如系统最大用户数，最大存储量，最多处理的数据流量等。
争用测试
争用测试：- 核实测试对象对于多个主角对相同资源（数据记录、内存等）的请求的处理是否可以接受。
什么是全链路压测
基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程。
2、性能指标解释:
①资源指标：
资源利用率：对不同资源的使用程度，如 CPU，I/O,内存，网络带宽等。一般按照，CPU的使用率不超过80%；内存的使用率不超过80%；IO读写不能过大；用IO该计数器的值和目前网络的带宽比较。
②系统指标：并发用户数、响应时间、事物成功率、超时错误率；
响应时间、并发用户数，吞吐量，性能计数器，TPS，HPS，资源利用率
并发：所有用户在同一时刻对系统执行的操作，一般指做同一件事情或操作。如同时登陆等。另一种是从服务器端承受的压力来考虑，这里的"并发用户数"指的是同时向服务器端发出请求的客户数，该概念一般结合并发测试（Concurrency Testing）使用，体现的是服务端承受的最大并发访问数。
请求响应时间:从 client 端发出请求到得到响应的整个时间；包括：client 端响应时间+网络响应时间+Server 端响应时间。把它作为用户视角的软件性能的主要体现。
TPS（Transaction Per Second）：每秒钟系统能够处理的交易或事务的数量。它是衡量系统处理能力的重要指标。TPS 是 LoadRunner 中重要的性能参数指标。
吞吐量：是指"单位时间内系统处理的客户请求的数量"，直接体现软件系统的性能承载能力。
性能计数器（Counter）：是描述服务器或操作系统性能的一些数据指标。例如，对Windows 系统来说，使用内存数（Memory In Usage），进程时间（Total Process Time）等都是常见的计数器。
思考时间（Think Time）：也被称为"休眠时间"，从业务的角度来说，这个时间指的是用户在进行操作时，每个请求之间的间隔时间。从自动化测试实现的角度来说，要真实地模拟用户操作，就必须在测试脚本中让各个操作之间等待一段时间，体现在脚本中，具体而言，就是在操作之间放置一个Think 的函数，使得脚本在执行两个操作之间等待一段时间。
think_time的作用是什么？
A、降低当前运行时压力，环节对应用服务器所造成的压力；
B、模拟真实生产用户操作，考察对服务器所造成的影响。
点击率：HPS，每秒钟用户向WEB服务器提交的HTTP请求数。
事物成功率：
超时错误率：
并发用户数和响应时间来源于产品需求、事物成功一般需要满足99.99%
3、什么时候可以开始执行性能测试？
一般在产品相对比较稳定，功能测试结束后。灵活性比较强。
4、完成一个性能测试项目，请阐述你的实施流程:
参考答案：
测试设计阶段：
1）了解被测系统的性能需求，定义测试目标和范围；
2）了解系统的技术信息，如系统架构等；
3）确定测试方案、进度安排，并制定测试计划,场景设置方案,及需要收集的测试数据；
4）同相关人员协商讨论测试方案；
5）准备数据收集模板；不同项目的性能测试，需要收集的数据不同；针对性的制定一个模板，更符合需要；
测试环境准备：
1）技术准备；选择性能测试工具；测试方案中涉及到的技术问题；测试数据的收集方案实现；如：如何监控系统资源等；
2）搭建测试环境；
3）创建初始数据；如虚拟用户使用的账号等；
测试执行阶段：
1）录制脚本；
2）调试脚本；
3）执行场景；
4）收集测试数据，并简单整理；
测试分析阶段：
1）分析测试数据,报告整理
5.请问您是如何得到性能测试需求？怎样针对需求设计、分析是否达到需求？
获取性能需求：查看需求文档，从中提取性能测试需求，制定性能测试范围；从系统构架设计中发现系统构架设计可能存在瓶颈的点，与研发一同讨论确定测试点。
设计测试场景：结合业务信息设计操作历史访问记录场景总结出需测试的性能关键指标。
分析结果：执行场景用例后根据提取关键性能指标来分析是否满足性能需求。
6、如果没有明确需求怎么收集性能测试需求数据
答： 客户没有给出相关性能指标或性能指标不明确，①.若业务属于已运营业务，已有历史数据，利用历史数据分析，得出指标；②若业务属于新业务，没有历史数据，可以参考同行相关业务数据进行分析，得出指标；③.若此业务属于新兴行业业务，以往没有同类业务的数据，只有凭借经验以及系统类型进行分析，得出指标了
7、描述不同的角色（用户、产品开发人员、系统管理员）各自关注的软件性能要点。
用户：重点关注打开速度及响应时间
开发：重点关注响应时间和数据库交互
管理员：重点关注用户感受到的软件性能；如何利用管理功能进行性能调优；如何利用其他软硬件手段进行性能调优
8、性能测试时，是不是必须进行参数化？为什么要创建参数？JMeter中如何创建参数？
是。如果不用参数化方式，那么模拟出来的场景单一，不能很好的模拟用户真实的业务操作，那么测试结果也就不够准确或不具有参考价值。
创建参数列表，用参数替换固定的文本
9、性能测试中tps如果上不去原因有哪些？
- 网络带宽
在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。
- 连接池
可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。
- 应用问题，如垃圾回收机制
从常见的应用服务器来说，比如Tomcat，因为java的的堆栈内存是动态分配，具体的回收机制是基于算法，如果新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，那么对TPS
也是有一定影响的，因为垃圾回收其本身就会占用一定的资源。
- 数据库配置
高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等，
就会导致数据库事务处理过慢，影响到TPS。
- 通信连接机制
串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对TPS造成影响。
（关于协议的连接，可参考之前的博客：HTTP协议进阶：连接管理）
- 硬件资源
包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。
- 压力机
比如jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。
- 业务逻辑
业务解耦度较低，较为复杂，整个事务处理线被拉长导致的问题。
- 系统架构
比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。
10、假设在测试过程中某些事务的响应时间过长，但分析应用服务、数据库以及网络都属于正常现象，问题可能出现的原因有哪些？
A、LoadRunner客户机器是否已无法承载当前运行压力导致LoadRunner无法及时获取从服务端返回的信息；
B、Tink_time是否已忽略；
C、确定当前被测系统架构，是否存在缓冲机制，为在每次测试过程中清楚缓存所导致。
11、如何发现应用服务器的相关问题？
A、通过某些事务的运行，判断是否在应用代码层未进行调优导致事务响应事件过长；
B、通过实时监控工具(nmon等)监控分析：
a、系统在运行过程中其CPU是否稳定运行或CPU耗用是否过高；
b、在系统运行过程中其内存是否存在内存泄漏现象；
c、打开相应日志、分析在运行过程中是否存在交易报错并获取错误原因查看是否由于代码原因导致交易错误发生。
12、测试环境和生产环境服务器配比如何选择？
服务器配置版本保持一致，容量测试后等量代换、考虑边际递减效应、容灾方案
13、发现瓶颈，如何分析？
自上而下，从局部到整体，瓶颈分析粒度
14、如何准备测试数据？如何防止数据污染？
生产数据备份、数据隔离、测试数据落入影子库、挡板、mock
15、linux系统常用监控命令
答;（1）监控CPU:
java架构：
vmstat->top（查看使用cpu较高的进程）>pidstat(查看哪个线程消耗了，也可以使用pidstat -p 10846 -u -d -t -w -h 1 1000)、或者使用top -H -p 进程号>jstack(做thread dump,例如：jstack l 10846>10846.threadump)>查看nid(nid指native ID 对应系统的tid,但tid显示的10进制，nid显示的是16进制)>printf %x'\n' 10861>转换后的结果为2a6d->对应到threaddump文件中，查到nid在哪一行，从而确定代码的哪一行对cpu的使用比较高
（2）监控IO
vmstat 3 5 (3代表每3秒显示一次、5代表总共显示5次)->iostat -xm 3(-x显示和io相关的扩展数据、-m磁盘读写速度单位为MB )，可以查看系统磁盘的读写量及cpu占用率)->iotop（定位到什么进程下的程序在作祟）
(3)监控网络
iftop工具
（4）netstat
netstat命令用于显示与IP、TCP、UDP和ICMP协议相关的统计数据，检验本机各端口的网络连接情况。
（5）sar
sar系统活动情况报告（System Activity Reporter）是一个非常全面的系统监控命令，可以获取系统的CPU、内存、进程活动，系统调用等信息。
（6）nmon
nmon是一款计算机性能系统监控工具，因为它免费，体积小，安装简单，耗费资源低，广泛应用于AIX和Linux系统。需要单独安装，网上有很多安装的过程，这里就不多说了。
16、top命令中load average数据代表什么意思
答：显示的是最近1分钟、5分钟和15分钟的系统平均负载。数据是每隔5秒钟检查一次活跃的进程数，然后根据这个数值算出来的。如果这个数除以CPU 的数目，结果高于5的时候就表明系统在超负荷运转了。
17、了解jvm吗？jvm原理是怎么样的
答：JVM是Java Virtual Machine（Java虚拟机）的缩写，说到jvm，对我们性能测试人员最先想到的就是jvm内存管理和垃圾回收。
JVM栈：由堆、栈、本地方法栈、方法区等部分组成
堆：通过new创建的对象的内存都在堆中分配，堆的大小可以通过-Xmx和-Xms来控制；堆的组成：新生代和旧生代
新生代：新建的对象都是用新生代分配内存，Eden空间不足的时候，会把存活的对象转移到Survivor中，
新生代大小可以由-Xmn来控制，也可以用-XX:SurvivorRatio来控制Eden和Survivor的比例Eden区和Survivor区组成，
Survivor：From Space和To Space组成
旧生代：用于存放新生代中经过多次垃圾回收仍然存活的对象
持久带：实现方法区，主要存放所有已加载的类信息，方法信息，常量池等等，可通过-XX:PermSize和-XX:MaxPermSize来指定持久带初始
化值和最大值
JVM常见配置：
-Xmx:最大堆内存
-Xms:初始时堆内存
-XX:NewSize=n:设置年轻代大小
-XX:NewRatio=n:设置年老代和年轻代的比值
-XX:MaxPermSize=n:设置持久代大小
jvm内存调优：
对JVM内存的系统级的调优主要的目的是减少GC的频率和Full GC的次数，过多的GC和Full GC是会占用很多的系统资源（主要是CPU），影响系统的吞吐量。特别要关注Full GC，因为它会对整个堆进行整理，具体查看我的另一篇博客，链接地址：JVM原理讲解和调优_谷白的博客-CSDN博客
18、性能测试过程中有没有碰到一些难以解决的性能问题
答：在一次压测过程中，日志一直报timeout,然后抓请求，客户端说请求已发送，但服务器端却显示没有请求过来，后来定位了一周，运维才发现是由于防火墙策略导致的，最后关闭防火墙后，正常了
19、性能测试的时候测试数据应该怎么造（需要成千上万大量的数据）
20、常见术语
负载：对被测系统不断施加压力，直到性能指标超过预期或某项资源使用达到饱和，以验证系统的处理极限，为系统性能调优提供依据；
并发：①狭义上的并发：所有用户在同一时间点进行同样的操作，一般指同一类型的业务场景，比如1000个用户同时登陆系统；
②广义上的并发：多个用户与系统发生了交互，这些业务场景可以是相同的也可以是不同的，交叉请求和处理较多；
压力：系统在一定饱和状态下，例如CPU、内存等饱和情况下，系统能够处理的会话能力，以及系统是否会出现错误
特点：主要目的是检查系统处于压力情况下应用的性能表现，重点在于有无出错信息产生，系统对应用的响应时间等
事务：性能测试中，事务指的是从端到端，一个完整的操作过程，比如一次登录、一次筛选条件查询，一次支付等；
吞吐量：指在一次性能测试过程中网络上传输的数据量的总和，也可以这样说在单次业务中，客户端与服务器端进行的数据交互总量；
对交互式应用来说，吞吐量指标反映服务器承受的压力，容量规划的测试中，吞吐量是重点关注的指标，它能够说明系统级别的负载能力，另外，在性能调优过程中，吞吐量指标也有重要的价值；
吞吐量和负载之间的关系：
①上升阶段：吞吐量随着负载的增加而增加，吞吐量和负载成正比；
②平稳阶段：吞吐量随着负载的增加而保持稳定，无太大变化或波动；
③下降阶段：吞吐量随着负载的增加而下降，吞吐量和负载成反比；
总结：吞吐量干不过负载！！！
如下图所示：
a1面积越大，说明系统的性能能力越强，a2面积越大，说明系统稳定性越好，a3面积越大，说明系统的容错能力越好（啧啧，图有点丑。。。）
吞吐率:吞吐量/传输时间，即单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量，它是衡量网络性能的重要指标。
通常情况下，吞吐率用"字节数/秒"来衡量，当然，也可以用"请求数/秒"和"页面数/秒"来衡量；
TPS:Transaction Per Second：每秒事务数，指服务器在单位时间内（秒）可以处理的事务数量，一般以request/second为单位；
PS：看到很多博客或性能测试人员将QPS和TPS混为一谈，个人认为，他们是以测试结果的统计得到该结论的；
QPS是查询，而TPS是事务，事务是查询的入口，也包含其他类型的业务场景，因此QPS应该是TPS的子集！
QPS:Query Per Second：每秒查询率，指服务器在单位时间内（秒）处理的查询请求速率；
TPS和QPS都是衡量系统处理能力的重要指标，一般和并发结合起来判断系统的处理能力；
PV:Page View：页面浏览量，通常是衡量一个页面甚至网站流量的重要指标；
细分的话，有独立访问者数量、重复访问者数量、单独页面访问数量、用户停留时间等类型；
RT/ART:Response Time/average Response Time：响应时间/平均响应时间，指一个事务花费多长时间完成；
一般来说，性能测试中平均响应时间更有代表意义。细分的话，还有最小最大响应时间，50%、90%用户响应时间等；
Thinking Time:思考时间，在性能测试中，模拟用户的真实操作场景。用户操作的事务与事务之间是有一定间隔的，引入这个概念是为了并发测试（有交叉业务场景）时，业务场景比率更符合真实业务场景；
连接池:连接池是一个进程，多个连接在一个进程中存储、管理，它是共享、可复用的；
当客户端发起请求，先检查是否有闲置连接，如果有，则分配该连接给其使用；如果没有，则请求进入等待队列（等待空闲连接分配，这个取决于调度配置）或新建一个连接对象供其使用
（取决于连接池有多少连接以及允许的最大连接数）；
每次客户端发起请求，如果都新建连接，会消耗很多的资源，连接池的存在及其特性，减少了连接的建立所消耗的资源以及节省了很多连接创建时间，给系统提供了更好的伸缩性，也有助于
服务器性能的提升。
关于连接池中线程的状态，可参考此篇博客：线程的几种状态 - 测试匠艺的个人空间 - OSCHINA - 中文开源技术交流社区
标准方差:各数据偏离平均数的距离（离均差）的平均数，它能反应一个数据集的离散程度。离散程度越大，数据越不可靠；[ |http://baike.baidu.com/item/%E5%B9%B3%E5%9D%87%E6%95%B0]
性能测试中引入这个术语，是为了对高峰期、平缓期的系统响应时间分布，不同业务场景的响应时间分布，以及I/o数在时间段上的分布等情况进行分析，以判断系统的稳定性。
资源使用率:如下图所示，资源指标与硬件资源消耗直接相关，而系统指标则与用户场景及需求直接相关：
资源指标：
CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%；
内存利用率：内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%；
磁盘I/O: 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time
（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能；
网络带宽：一般使用计数器Bytes Total/sec来度量，其表示为发送和接收字节的速率，包括帧字符在内；判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较；
系统指标：
并发用户数：单位时间内与系统发生交互的用户数；
在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求；
平均响应时间：系统处理事务的响应时间的平均值；事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间；
事务成功率：性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如用户登录、保存订单、提交订单操作均可定义为事务，单位时间内系统可以成功完成多少个定义的事务，
在一定程度上反应了系统的处理能力，一般以事务成功率来度量；
超时错误率：主要指事务由于超时或系统内部其它错误导致失败占总事务的比率；
604
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
