【快速入职】拿下阿里26k全栈性能测试，监控以及调优（性能压测，分析，监控，调优）【一】

一：性能测试的价值在哪里

关注一个性能测试项目在分析调优了之后，响应时间有多大的提升，TPS 有多大的提高，资源有多少的节省。

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

我们努力的方向是性能的完整工程，这就是我在开头提到的，既要有前期的测试，还要有中间的分析，以及最后的调优，而不仅仅是做做脚本。

如果你想把性能测试做好，就不要局限自己的技术范围和认知范围。无论是系统、数据库、代码、中间件、存储、网络，你遇到什么问题，都要试着去分析下该如何判断，并考虑如何在后续的过程中进行调优。

性能领域要求的专业技能并不少，发展的宽度和深度完全取决于你自己的意愿。你可以选择只做一个写脚本的工程师，也可以选择成为一个性能调优的专家。从技术范围上说，测试工具、操作系统、开发语言、实现架构、数据库、网络、存储、部署架构等，都是你需要掌握的内容。

二：性能测试的价值在哪里？

 

 

性能测试分析优化之前，如果 TPS 是 100，你做完了之后 TPS 是 10000，这就是价值。

在性能测试分析优化之前，如果响应时间是 0.1ms，你做完了之后是 0.01ms，这就是有价值。

在性能测试分析优化之前，如果 CPU 使用率是 100%，你做完了之后是 50%，这就是有价值。

性能测试的概念

压力测试，容量测试，负载测试，太多混乱的概念。这里高楼老师给出一个概念：

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

性能测试需要有指标：，应该有的指标是：时间指标、容量指标和资源利用率指标。

性能测试需要有模型：模型是什么？它是真实场景的抽象，可以告诉性能测试人员，业务模型是什么样子。比如说，我们有 100 种业务，但不是每个业务都需要有并发量，可能只有 50 个业务有，那就要把这些有并发的业务统计出来，哪个业务并发多，哪个业务并发少，做压力时就要控制好这样的比例。这种做法需要的数据通常都是从生产环境中的数据中统计来

性能测试要有方案？方案规定的内容中有几个关键点，分别是测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险

性能测试中要有监控。这个部分的监控，要有分层、分段的能力，要有全局监控、定向监控的能力。监控是为了取证。

性能测试要有预定的条件：这里的条件包括软硬件环境、测试数据、测试执行策略、压力补偿等

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

 性能测试中要有分析调优 性能验证只需要一两周，加入调优后，项目变得复杂。

性能测试要有结果报告 测试报告是需要汇报或者归档的。大部分老板或者上司关心的是测试的结果，而不是用了多少人，花了多少时间这些没有意义的数字。我们更应该在报告中写上调优前后的 TPS、响应时间以及资源对比图。

压力测试、容量测试、负载测试等等，在实际的项目实施过程中，都不具备全局的指导价值。我个人认为，你应该在性能领域中抛弃这些看似非常有道理实则毫无价值的概念。 

想做好性能分析与调优：像语言、os、网络、数据库、存储、队列服务器、中间件服务器、缓存服务器、负载均衡等等的逻辑，都是需要知道的。

技术就应该被应用，否则就是耍流氓。

TPS和响应时间之间是什么关系？

 在这个图中，定义了三条曲线、三个区域、两个点以及三个状态描述。

三条曲线：吞吐量的曲线（紫色）、利用率（绿色）、响应时间曲线（深蓝色）。

三个区域：轻负载区（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）。

实际情况会与这个图有偏差。

实际：

负载区的资源饱和，和 TPS 达到最大值之间都不是在同样的并发用户数之下的。

响应时间的曲线都不会像图中画得这样陡峭，并且也不一定是在塌陷区突然上升，更可能的是在重负载区突然上升。

吞吐量曲线不一定会出现下降的情况，在有些控制较好的系统中会维持水平

最优并发数这个点，通常只是一种感觉，并没有绝对的数据用来证明。

最大并发数这个点，就完全没有道理了，性能都已经衰减了，最大并发数肯定是在更前的位置呀

这张图没有考虑到锁或线程等配置不合理的场景，而这类场景又比较常见。也就是我们说的，TPS 上不去，资源用不上。

简化出另一个图形，以说明更直接一点的关系。

蓝线表示 TPS，黄色表示响应时间。 

在 TPS 增加的过程中，响应时间一开始会处在较低的状态，也就是在 A 点之前。接着响应时间开始有些增加，直到业务可以承受的时间点 B，这时 TPS 仍然有增长的空间。再接着增加压力，达到 C 点时，达到最大 TPS。我们再接着增加压力，响应时间接着增加，但 TPS 会有下降（请注意，这里并不是必然的，有些系统在队列上处理得很好，会保持稳定的 TPS，然后多出来的请求都被友好拒绝）

性能场景和作用

 

三：性能测试的发展

首先是工具的的使用，loadRunner，jmeter精通一种，更重要的是把性能测试的流程做成一种模式，最后结合工具制定灵活的自定义方案，形成性能测试体系。
 性能测试的三个阶段：
  1、 制定性能测试的目标，对系统进行压测，出一个报告，让开发人员优化
  2、（1）方案的制定：包括制定目标，搭建环境，设计测试场景，录制脚本，执行，承担整个性能测试工作
    （2）发现问题，根据报告分析问题，找到问题瓶颈，定位问题，如是哪个模块的问题、是不是数据库的问题，IO是否慢。
  3、能解决问题，通过与人协作解决细节问题，分享每次解决的结果，不断积累每次经验
  必备知识：mysql，http协议，linux操作系统，编程经验，项目架构（分布式、缓存、操作系统）实战的重要性不言而喻，理论联系实际才能快速进步，但在实际工作中，不是所有的项目都能涉及或是能够接触到性能测试，正所谓工欲善其事必先利其器，性能测试的难点在于怎样通过日志或数据准确定位到问题的症结、以便进行系统的调优，如果不懂数据库、操作系统等知识，很难做好性能测试。因此先把知识体系架构起来，精通这些知识，转向一名性能测试工程师。在之后的性能测试工作中不断的积累经验，不断的向身边的高手请

教，不断的归纳、思考、总结。

 【软件测试到测试开发全测试生涯学习路线】

以及全套配套的学习资料，视频教程....

：【以下路线图太详细了只能展开部分，具体的可以在文章末尾扫描小卡片备注000领取哦】

1：自动化测试进阶系列：

2：全栈性能测试，监控以及调优

3：全栈测试开发平台实战

4：全栈安全测试渗透测试

5：devops持续集成部署

6：全栈接口测试工具进阶

7：跨平台自动化测试工具

8：大厂简历，真题，录音

9：全栈系列课企业项目实战

总结：下方是作者从功能测试到自动化测试拿到年薪34w，花费三年打造的软件测试到测试开发全职业生涯资料包，有需要的话可以点击文章末尾的小卡片备注000领取哈

​