学习笔记：性能测试
Posted 软件测试黑板报
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了学习笔记：性能测试相关的知识，希望对你有一定的参考价值。
学习课程极客时间高楼老师的《性能测试实战30讲》。
https://time.geekbang.org/column/intro/100042501
强烈推荐此课程，句句都是干货，里面提到的学习路径和理念让人受益匪浅！老师是真正大神（他的微信群里每月还有实战直播，拿真实案例现场指导分析！针不戳）
01丨性能综述
定义性能测试，需要包含以下内容：
指标：测试的目标，例如时间指标、容量指标和资源利用率指标。
模型：既对应真实场景的抽象，模拟真实业务模型。
方案：需要有测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险。
监控：要有分层、分段的能力，要有全局监控、定向监控的能力。
预定的条件：明确达到预定条件，就执行某些事（例如增加线程等）。
场景：基准性能场景、容量性能场景、稳定性性能场景、异常性能场景。
分析调优：
性能验证：针对给定的指标，只做性能验证。第三方测试机构基本上都是这样做的。
性能测试：针对给定的系统，做全面的性能测试，可以得到系统最大容量，但不涉及到调优。
性能测试+分析调优：针对给定的系统，做全面的性能测试，同时将系统调优到最优状态。
结果报告：调优前后的TPS、响应时间以及资源对比图。
02丨性能综述：关系
三条曲线：吞吐量的曲线（紫色）、使用率/用户数曲线（绿色）、响应时间曲线（深蓝色）。
三个区域：轻负载区（Light Load）、重负载区（Heavy Load）、塌陷区（Buckle Zone）。
两个点：最优并发用户数（The Optimum Number of Concurrent Users）、最大并发用户数（The Maximum Number of Concurrent Users）。
三个状态描述：资源饱和（Resource Saturated）、吞吐下降（Throughput Falling）、用户受影响（End Users Effected）。
03丨性能综述：指标
TPS计算：=压力机线程数*（1000/响应时间)。并发度拿5%来计算，就是10000用户x5%=500(TPS)，注意哦，这里是TPS，而不是并发线程数。如果这时响应时间是100ms，那显然并发线程数是500TPS/(1000ms/100ms)=50(并发线程)。
RT计算：时间的拆分定位是性能瓶颈定位分析中非常重要的一节。
04丨性能测试的阶段
性能测试工程师三大阶段
性能工具学习期：工具的使用。
性能场景学习期：如何配置，配置是否合理。
性能分析学习期：判断性能瓶颈，性能调优。
性能团队的阶段
刚组建：执行场景，罗列数据。
初期：定义性能标准，准入准出规则。
成熟：通过测试和分析优化后性能提升，节约了硬件成本。
05丨指标关系
在线用户和并发用户数的计算
吞吐量 / 并发度 = 在线用户数
(1000ms / 响应时间ms) * 线程数 = 吞吐量
并发度 = 每秒业务请求数 / 在线用户数
并发的概念
并发都是指服务端的并发，而不是指压力机上的并发线程数。
性能中常说的并发，是用TPS这样的概念来承载具体数值的。
06丨性能分析思路
鸿沟
操作到对监控计数器的理解。
相关性分析和证据链分析的过程。
瓶颈的精准判断
使用以下7种方式分析系统性能。
TPS曲线：
告知我们是否有瓶颈、瓶颈和压力有没有关系。
响应时间的曲线：
用来判断业务有多快的。
线程递增策略：
对一个系统来说，如果仅在改变压力策略（其他的条件比如环境、数据、软硬件配置等都不变）的情况下，系统的最大TPS上限是固定的。
常规场景中的线程递增一定是连续的，并且在递增的过程中也是有梯度的。
常规场景中的线程递增一定要和TPS的递增有比例关系，而不是突然达到最上限。
性能衰减的过程：
只要每线程每秒的TPS开始变少，就意味着性能瓶颈已经出现了（开始衰减）。在衰减的过程中，TPS才会达到上限。（瓶颈出现不代表到达上限)
响应时间的拆分：
对总响应时间进行拆分，查看后端处理的每个环节响应时间。
构建分析决策树：
它是对架构的梳理，是对系统的梳理，是对问题的梳理，是对查找证据链过程的梳理，是对分析思路的梳理。它起的是纵观全局，高屋建瓴的指导作用。
从压力工具中，只需要知道TPS、响应时间和错误率三条曲线，就可以明确判断瓶颈是否存在。再通过分段分层策略，结合监控平台、日志平台，或者其他的实时分析平台，知道架构中的哪个环节有问题，然后再根据更细化的架构图一一拆解下去。
场景的比对：
当你觉得系统中哪个环节不行的时候，又没能力分析它，你可以直接做该环节的增加。
以上是关于学习笔记：性能测试的主要内容，如果未能解决你的问题，请参考以下文章