职业探索-性能测试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提示,>!<