我是强哥，一个在互联网苟且的程序猿，点个关注再看呗。

前言

缘起：促发写下性能测试入门这篇文章的原因，前几天的时候，强哥的同事在和强哥吐槽，他刚开始做性能测试，一脸懵，不知道从何做起，因此才有了强哥的这一篇文章。谈起性能测试，大家经常聊的是高并发、高可用、性能优化、全链路压测等Topic，听起来都挺高大上，但这些概念追本溯源，还是要落到性能测试基础的东西上。比如需求分析、场景建模、测试方案、性能分层、指标监控、结果评估和优化本身上面。具体的内容还要详细的在基础体系结构中进行学习与了解

一、什么是性能测试？

• 百度百科上的定义是这样的：“性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。”
• 从我过去的工作中我所理解的性能测试，就是对于当前的软件系统进行一个系统化的一个压力、全链路方式、单服务方式，尽可能的模拟用户使用的场景对系统施加压力，在一定压力（具体的压力施加需要根据实际情况进行分析）下，系统的响应情况是否良好、是否会出现无压力情况下未出现的问题，从而避免上线以后出现不可控的性能问题。（ps:最直观的性能体验既是用户对于产品的时间响应结果）

二、性能测试对应术语

1.响应时间：响应时间是指用户从客户端发送请求到所有的请求都从服务器返回客户所经历的时间。该定义强调所有数据都返回客户端所花费的时间，为什么说是所有数据呢?因为用户体验的响应时间带有主观性，用户可能会认为从提交请求到服务器开始返回数据到客户端的这段时间为响应时间。以一个Web 应用的页面响应 时间为例，如图所示。从图中可以看到，页面响应时间=网络传输时间+应用延迟时间。其中网络传输时间为(N1+N2+N3+N4)，应用延迟时间为(A1+A2+A3)，而应用延迟时间又可分解为数据库延迟时间(A2)和Web 服务器延迟时间(A1+A3)。

2.并发用户数：并发用户数指同一时刻与服务器进行数据交互的所有用户数量。 在工作中，对于并发用户这个概念的理解经常会出现以下两种误区：一是认为系统所有的用户都是并发用户;二是认为所有在线的用户都是并发用户。
3.吞吐量TPS：在性能测试过程中，吞吐量是指单位时间内服务器处理客户请求的数量，吞吐量通常使用请求数/秒来衡量，直接体现服务器的承载能力。吞吐量作为性能测试过程中主要的指标之一，它与虚拟用户数之间存在一定的联系，当系统没有遇到性能瓶颈时，可以采用下面这个公式来计算

其中，F 表示吞吐量;NVU 表示VU(Virtual User，虚拟用户)的个数;R 表示每个VU 发出的请求数量;T 表示性能测试所用的时间。但是如果系统遇到性能瓶颈，这 个公式就不再适用，吞吐量与VU 之间的关系图如图所示。从图中可以看出，吞吐量在VU 数量增长到一定值时，软件系统出现性能瓶颈，此时吞吐量的值并不再随着VU 数量的增加而增大，而是趋于平衡。

但在实际测试过程中，测试前吞吐量是不知道的，必须通过不断添加虚拟用户来不断地测试，才能找到吞吐量的拐点，即服务器实际吞吐量的值。
备注：

• 看到很多博客或性能测试人员将QPS和TPS混为一谈，个人认为，他们是以测试结果的统计得到该结论的；
• TPS和QPS都是衡量系统处理能力的重要指标，一般和并发结合起来判断系统的处理能力；
• QPS是查询，而TPS是事务，事务是查询的入口，也包含其他类型的业务场景，因此QPS应该是TPS的子集

TPS：Transaction Per Second：每秒事务数，指服务器在单位时间内（秒）可以处理的事务数量，一般以request/second为单位；
QPS：Query Per Second ：每秒查询率，指服务器在单位时间内（秒）处理的查询请求速率；

4. 性能拐点：在上面的概念中我们提到了“性能拐点”，那么什么是性能拐点呢，具体的从以下的图片进行说明；性能拐点：顾名思义，当系统软件达到一定程度的时候，发生了转变及发生了拐弯。

• 如下图所示，横轴坐标为虚拟用户量，竖轴坐标为响应时间（response time）、tps(Throughput)、资源使用率(Utilization)三条曲线,下图被横竖轴划分为三个区域，第一个区域 轻负载区、第二个区域重负载区域，第三个区域则为 塌陷区（用户无法忍受而放弃）
• 说明：随着并发用户数的增加，在轻负载区，资源使用率逐渐增加、tps相应时间逐渐变大同时相应时间逐渐增加，随着兵法用户数的逐渐增加，到达轻负载与重负载交界点时，tps开始逐渐缓慢增加、资源使用率开始逐渐趋于使用最大，此时为最佳并发用户点。当用户数到达重负载区和塌陷区的临界点时，响应时间陡增、tps陡降，此时交界点为性能拐点。此时为性能最大承受点
  

5. 事务: 性能测试中，事务指的是从端到端，一个完整的操作过程，比如一次登录、一次筛选条件查询，一次支付等
6. 思考时间: 思考时间(Think Time)也称为“休眠时间”，是指用户在进行操作时，每个请求之间的时间间隔。对于交互系统来说，用户不可能持续不断地发出请求，一般情况下，用户在向服务端发送一个请求后，会等待一段时间再发送下一个请求。性能测试过程中，为了模拟这个过程而引入思考时间的概念。
7. 资源使用率: 资源使用率是指服务器系统不同硬件资源被使用的程度，主要包括CPU 使用率、内存使用率、磁盘使用率、网络等。资源使用率=资源实际使用量/总的可用资源量。资源利用率表现当前服务器资源使用的情况，它是分析服务器出现瓶颈和对服务器进行调优的主要依据，在配置调优测试的过程中，通过比较配置调优前后系统资源的使用率来判断调优的效果
8. other

性能测试类型包括负载测试，强度测试，容量测试等。
负载测试（Load Testing）：负载测试是一种主要为了测试软件系统是否达到需求文档设计的目标，譬如软件在一定时期内，最大支持多少并发用户数，软件请求出错率等，测试的主要是软件系统的性能。
压力测试（Stress Testing）：强度测试也就是压力测试，压力测试主要是为了测试硬件系统是否达到需求文档设计的性能目标，譬如在一定时期内，系统的cpu利用率，内存使用率，磁盘I/O吞吐率，网络吞吐量等，压力测试和负载测试最大的差别在于测试目的不同。
容量测试（Volume Testing）：确定系统最大承受量，譬如系统最大用户数，最大存储量，最多处理的数据流量等。

性能测试中包含以下测试类型：
基准测试 - 比较新的或未知测试对象与已知参照标准（如现有软件或评测标准）的性能。
负载测试- 核实在保持配置不变的情况下，测试对象在不同操作条件（如不同用户数、事务数等）下性能行为的可接受性。
强度测试- 核实测试对象性能行为在异常或极端条件（如资源减少或用户数过多）之下的可接受性。
容量测试- 核实测试用户同时使用软件程序的最大数量。

负载测试、压力测试、性能测试之间的区别
总的来说：
负载测试是测试软件本身最大所能承受的性能测试；
压力测试就是一种破坏性的性能测试；
只要理解这两点区别，就非常好理解性能测试了
性能测试: 收集所有和测试有关的所有性能，通常被不同人在不同场合下进行使用。
负载测试: 是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。
压力测试 ：是在一定的负荷条件下，长时间连续运行系统给系统性能造成的

三、性能测试的基础体系结构

1.性能测试基础的体系图展示

2.性能测试基础的体系详解

• 以上内容虽然是整个整体的性能测试基础体系，但是，其中很多内容需要我们具体的进行学习和了解，比如分层中的中间件，中间包含的总类就有很多种，不同的项目使用的组件有所差异，知识点的涉及却是相同的
• 下面对体系中提到的具体内容展开进行知识点的分散总结
• 首先，了解整体体系前，需要了解整体的性能测试流程，方便加深整个过程中结果的理解，测试流程见下图
  待补充流程
• 对应的详解内容

1. 需求调研

• 项目背景：
  版本迭代&独立项目&新建服务&系统重构&性能优化&性能问题排查解决。
• 测试目的：
  超卖&高并发&扩容性&配置验证&资源耗用。
• 测试目标：
  目标是达到某服务多少并发，还是整体服务均达到某一目标值，资源使用控制在80%以内等。
• 业务场景：
  了解业务场景， 业务模型：只读、读写、批处理、定时Job； 业务配比；选取业务峰值的数据，单独统计； 如果各业务占比类似，则按照比例转化；如果比例差距大，则按照区间单独统计分析；
• 测试环境：
  需要确定性能测试执行所使用的测试环境配置，测试环境与生产环境的差异。PRE&PERF、app&Redis&MQ&DB&网络&网段&&带宽&防火墙，是否独享资源隔离等；
• 性能指标：
  业务指标：DAU、GMV、注册用户数、在线用户数、活跃用户数、增长趋势等；
  系统指标：协议类型、长短链接、同步策略、加解密、JVM内存分配、容器线程数&连接数&Timeout、MQ-Cousumer数量；
  压测指标：QPS、TPS、ART、99%RT、Success%；
• 时间周期：
  几个重要时间点：提测时间、验收时间、上线时间

2. 测试方案：

• 项目背景：说明项目开展的背景及目的；
• 测试方案：针对项目涉及的场景，测试实施的大体方案；
• 实施准则：任何项目，都要有准入准出和暂停终止的准则；
• 测试模型：针对具体的场景，设计的性能模型最好经过评估验证；
• 测试策略：针对测试模型所采用的不同的测试策略，同步的测试策略要达成什么样的目的；
• 性能指标：业务指标是多少？转化的技术指标是多少？冗余范围有多大？
• 准备工作：其中包含环境、数据、脚本、监控等准备事项；
• 组织结构：整个项目中涉及哪些事项？不同事项的负责人是谁？交付时间是什么时候？
• 系统架构：整个项目中从前到后梳理出来使用的架构体系，既架构图以及流程图

3. 结果评估：

• 性能实施方法论：
  基于指标构建；
  建模是分析的过程和结果；
  基于真实环境的系统模拟；
  压测实施过程是整体的核心；
  需要设定统一的目标、流程、分析方法、组织结构；
  正确描述性能结果和过程的术语
• 瓶颈描述：什么场景执行了什么策略/操作，因为什么原因导致了什么结果；
• 解决方案：优化了哪里？验证的方式及结果？是否满足预期&是否解决了发现的问题？

4. 性能分析层级

• 业务分级：业务-场景-数据-架构-参数；
• 技术分级：引擎-网络-应用-中间件-数据库；
• 工具：关注指标，从结果反推过程；
• 配置：线程、连接数、Timeout、长短链接、同步异步、路由转发；
• 应用：日志、硬件配置、资源使用率；
• 中间件：Job、缓存命中、消息堆积、Consumer配置；
• 数据库：资源耗用、库表结构、表锁行锁、活跃连接数、最大连接数；
• 性能拐点【详情见上文中的性能拐点分析】
  TPS增长放缓，RT快速上升；
• 性能交叉点
  模型上的TPS和RT交叉节点；
• 性能平衡点
  重点关注业务可接受的最大RT；
• 性能衰减点
  timeout参数&TPS急剧恶化抖降&RT快速飙升；

5. 脚本设计

• 脚本语言：一般根据项目语言进行选择，通常使用java
• 脚本工具：
• 并发事务：并发指的是同一时刻服务端接收到的请求数，而非压测引擎的并发线程/RPS；
• 思考时间：一般会在loadrunner中使用的较多，或者是在使用jmeter进行特殊场景压测的时候
• 逻辑关联：服务端结果动态返回，非幂等、response body的参数需要向下透传；

6. 典型特例

• 文件存储优化
  原理：文件/图片存储在源节点，利用CDN缓存各种变更和路径。CDN未命中，回源节点处理并返回，同时同步最新的变更和路径到CDN。

优点：节省存储成本，提高查询展示渲染性能，灵活满足业务。
注意事项：大文件分块存储，避免局部过热导致单机磁盘IO过载，分块有助于整体系统资源调度。

• 秒杀：适用场景：秒杀、限时抢购、限量抢购等。

单用户单端多次抢购；
单用户单端限量抢购；
单用户多端抢购→低并发；
单用户多端抢购→高并发；

7. 模型场景

• 数据模型：根据业务比例设定使用的数据比例
• 测试模型：关注核心场景，过滤无关及非核心业务
• 场景模型：从系统架构设计层面出发，关注不同层面，提升性能！
• 业务模型：业务场景、流量转化漏斗
• 性能分层：性能测试中，在优化以及分析阶段，亚也要考虑不同层级对于整体性能的影响
• 网络层：主要指带宽、网段、防火墙等设施，当然，CND之类的资源，也可以划分在这一领域；
• 网关层：网关是请求入口和业务接入层，一般登录验签调用、加解密鉴权、限流等操作，都是在网关进行；
• 应用层：无论是前端的渲染展示还是后端的逻辑处理，都可以理解为应用层；
• 中间件：中间件包含缓存、MQ、JOB、DTS/DRC/DAL、配置中心等一系列组件；
• 存储层：一般指数据存储和文件存储层级，典型的组件有MySQL、HDFS；
• 物理层：无论是云服务还是自建机房，物理硬件层面都可以归纳到这一层；

8. 性能指标

响应速度：TPS、RT ；
容量：吞吐量、PV、Hit；
资源：CPU、Memory、DiskIO、Network、文件句柄数、缓存资源

总结

本篇文章仅针对性能测试、性能测试的基础体系、性能测试应该注意的内容进行常阐述，想要了解更多的性能测试知识，可以关注后续系列内容。

知道的越多，就知道不知道的越多
我是强哥，一个在互联网抱着枸杞杯苟且的程序员。

最后

以上就是感动冬天为你收集整理的【性能测试卷一】性能测试全网最全-基础入门篇前言一、什么是性能测试？二、性能测试对应术语三、性能测试的基础体系结构总结的全部内容，希望文章能够帮你解决【性能测试卷一】性能测试全网最全-基础入门篇前言一、什么是性能测试？二、性能测试对应术语三、性能测试的基础体系结构总结所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。