职业探索-性能测试01-性能工程师成长路径-性能测试的核心概念-性能测试的全周期概览

职业探索-性能测试01-性能工程师成长路径-性能测试的核心概念-性能测试的全周期概览

参考来源
极客时间专栏：高楼的性能测试实战30讲
课程链接：https://time.geekbang.org/column/intro/100042501

性能测试分析的能力阶梯视图

性能工程师

真正的性能工程师，可以把结果整理清楚之后，又可以下结论，提出解决方案：线上根据这个测试结果，做对应的配置，系统肯定可以稳定运行。又或者是这样的：当前测试说明了线上不能支持，后面应该如何优化

性能测试的内容不仅仅包括测试，还包括分析和调优。

性能工程师的三大学习阶段

性能工具学习期：

理解工具的作用–做脚本和发压力

脚本的逻辑和压力场景的逻辑，和工具本身无关，和业务场景有关。

性能场景学习期：

如何做一个合理的性能测试

性能分析学习期

怎么判断性能瓶颈在哪里呢？
问题的解决，靠的是思维逻辑，靠的是判断，而不是靠工具。
我想看什么数据，而不是说“把数据给我看看”

性能测试分析的能力阶梯视图

1.工具操作：包括压力工具、监控工具、部析工具、调试工具。
2.数值理解：包括上面工具中所有输出的数据，
3.趋势分析、相关性分析、证据链分析：就是理解了工具产生的数值之后，还要把它们的
逻辑关系想明日。这才是性能测试分析中最重要的一环。
4.最后才是调优：有了第3步之后，调优的方案策略就有很多种了，具体选择取决于调优成本和产生的效果。

性能团队

性能团队职责定位

1.性能验证：针对给定的指标，只做性能验证。第三方测试机构基本上都是这样做的
2.性能测试：针对给定的系统，做全面的性能测试，可以得到系统最大容量，但不涉及到
调优。
3.性能测试+分析调优：针对给定的系统，做全面的性能测试，同时将系统调优到最优状态。

性能团队成长阶段

性能团队初建

这时的团队，可以执行场景，可以拿出数据，但工作出的结果并不理想。团队整体的价值就体现在每天跟着版本跑来跑去，一轮轮地测试下去，一个版本短则一两个星期，长则一个月。没有时间去 考虑测试结果对整个软生命期的价值，在各种琐碎的项自中疲于奔命，做脚本，拿出TPS和响应时间，做版本基线比对，出数据罗列式的性能测试报告。

性能团队初成熟

到了这个阶段，团队已经可以应付版本的更迭带来的性能工作压力，团队合作良好，稍有余力，开始考虑团队价值所在，在公司的组织结构中应该承担什么样的职责。在产品的流水线上终于可以占有一席之地了。这样很好，只是从实际的技未细节上来说，仍然没有摆脱第一阶段中琐碎的工作，没有把性能的价值体现出来，只是一个报告提供机器。

性能团队已成熟

有了标准、流程，团队的合作能力也成熟了之后，团队“是时候展示真正的实力了”。但问题来了，什么才是性能团队的真止实力呢？

团队实力的体现：
1.通过你的测试和分析优化之后，性能提升了多少？
这是一句非常简单直接的话。但是我相信有很多做性能测试工程师的人回答不出这样的问题。因为看着混乱的TPS曲线，自己都已经晕了，谁还知道性能提升了多少呢？
而一个成熟的团队应该回答的是：提升了10倍，我们调优了什么。这样的回答有理有据底气十足。
2.通过你的测试和分析优化之后，节省了多少成本？
这人问题就没有那么好回答了，因为你要知道整体的容量规划，线上的真实运营性能。如果之前的版本用了200台机器，而通过我们的测试分析优化之后，只用到了100台机器，那成本就很明显了。
但是，在我的职业生涯中，很少看到有人这样来体现性能存在的价值。有些场合是不需要这样体现，有些场合是不知道这样体现

性能测试的概念

性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下热行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评适系统的性能指标是否满足既定值。

性能指标、模型、场景、监控、实施、报告(记住核心的几个概念，更少更容易记住)

概念中的详细解释

有指标

时间指标、容量指标和资源利用率指标

有模型

模型是什么?它是真实场景的抽象，可以告诉性能测试人员，业务模型是什么样子。

性能测试也要选择适合自已系统业务逻辑的方式，用最低的成本、最快的时间来做事情。

有方案

方案规定的内容中有六个关键点，分别是测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险。基本上有这些内容就够了，这些内容具体的信息还需要精准。

有监控

这部分的监控，要有分层、分段的能力，要有全局监控、定向监控 的能力。

有预定的条件
这里的条件包括软硬件环境、测试数据、测试执行策略、压力补偿等内容。要是展开来说在场景执行之前，这些条件应该是确定的

有场景

场景应该如何定义，来源英文的scenario,

场景来源于英文的scenario，对性能场景中的“场景”比较正宗的描述是：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景热行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。

有分析调优

瓶颈判断、性能优化、涉及相关性分析、趋势分析、证据链查找等等手段。

是否需要调优对性能项目划分：

1.新系统性能测试类：这样的项目一般都会要求测试出系统的最大容量，不然上线心里没
底。
2.旧系统新版本性能测试类：这样的项自一般都是和旧版本对比，只要性能不下降就可以根据历史数据推算容量，对调优要求一般都不大。

3.新系统性能测试优化类：这类的系统不仅要测试出最大容量，还要求调优到最好

有结果报告

需要汇报或者归档

性能场景的分类

1.基准性能场景

这里要做的是单交易的容量，为混合容量做准备（不要跟我说上几个线
程跑三五遍脚本叫基准测试，在我看来，那只是场景执行之前的预执行，用来确定有没有基本的脚本和场景设计问题，不能称之为一个分类）。

2.容量性能场景

这一环节必然是最核心的性能执行部分。根据业务复杂度的不同，这部
分的场景会设计出很多入，在概念部分就不细展升了，我会在后面的文章中详细说明，

3.稳定性性能场景

稳定性测试必然是性能场景的一个分类。只是现在在实际的项目中
稳定性测试基本没和生产一致过。在稳定性测试中，显然最核心的元素是时间（业务模型已经在容量场景中确定了），而时间的设置应该来自于运维周期，而不是来自于老板、产品和架构等这些人的心理安全感。

4，异常性能场景

要做异常性能场景，前提就是要有压力。在压力流量之下，模拟异常

场景和测试用例，用例限定在了描述测试脚本和测试数据上，并没有描述需要实时的判断和动态的分析。

性能测试的全周期概览

在性能测试的概念中，性能指标、性能模型、性能场景、性能监控、性能实施、性能报告这些既是概念中的关键词，也可以说是性能测试的方法和流程

而这些概念我们在实际的工作中，都是非常重要的。因为它们要消除沟通的误解。让不同层级，不同角色的人，可以在同样的知识背景下沟通，也可以让做事情的人有清晰的逻辑思路，同时对同行间的交流，也有正向的促进作用，

性能指标：业务指标和技术指标

性能指标的表示法

对于指标的理解：

TPS

transactions Per Second ，性能领域中一个关键的性能指标概念，描述每秒事务数。

T可以直接定义为每个业务步骤和完整的业务流。

创建什么级别的事务，完全取决于测试的目的是什么。

TPS–每秒事务数

事务，统计了一段脚本的执行时间。

RT

响应时间
Response Time

调优在当前性能项目中的状态
时间的拆分定位是性能瓶颈定位分析中非常重要的一节。
做根本原因的分析或协调其他团队来分析。
性能只测不调，就是性能验证的工作。

性能指标中并发用户数的计算

性能工具学习期的工具选择思考

如何选择合适自己的工具

我们使用工具，一定要知道几点：
1.工具能做什么？
2.工具不能做什么？
3.我们用工具的目标是什么？
4.当工具达不到目标时，我们怎么办？

指标之间的关系

TPS和并发数是什么关系呢？

在并发中谁来承载”并发“这入概念呢
说到这入，我们先说一下所谓的“绝对并发”和“相对并发”这两入概念。
绝对并发指的是同一时刻的并发数；
相对并发指的是一个时间段内发生的事情。

什么是并发

在线用户数，并发用户数怎么计算

从并发用户数到压力机的并发线程数

TPS代表并发时，指的是Server端的处理能力，并不是压力工具上的并发线程数。
在意你服务端的处理能力就可以了

##END提示，>!<