jmeter性能测试是对服务端的么
性能测试 ge meet 入门到精通第一集，呃，大家好，我是土匪啊，嗯，今天我来给大家带来 gee meet 性能测试的一个全套视频， 嗯，那么在讲解之前呢，我简单介绍一下我自己啊，我是叫土匪，我是湖南大学信管专业毕业，到目前来讲已经有十八年多的软件测试从业的一个经验，其中有十七年的这一个性能测试经验啊，主要的行业呢，是在医疗和金融行业， 曾经参加和主持过多个大型的去医疗系统，然后省级的啊，医疗平台，然后金融项目的性能测试啊， 那么我们一起来看一下这个视频给大家来怎么讲吧。嗯，首先我们准备从三个大的方向给大家来进行性能测试的一个讲解。第一个呢，给大家讲讲性能测试的一个最基础的一些理论啊，包括一些概念 名词啊，一些需要大家去掌握的一些知识点。第二个呢，我们会给大家来进行吉米特这个工具从入门到进阶的啊这一个讲解。第三呢，我们会结合这一个项目给大家来完整做一个项目啊，看看怎么用吉米特去完成这一个性的测试 好了。嗯，那么我们一起来看看第一个环节啊，性能测试的一个基础理论。那么对于性能测试基础理论呢，其实很多啊，我们这里在上课的时候呢，准备给大家来做以下的一些知识点的梳理。第一个呢，哎，过一下啊，什么是性能，什么是性能测试 啊？弄清楚啊，我们要做的事情到底是什么？我们为什么要去做啊？企业为什么需要他，对吧？弄清楚，然后第二个呢是性能测试的一些指标的梳理，在我了解到的情况啊，很多新手或者说已经在做性能测试的人对于性能测试指标呢啊，好像是机之其然不 啊，不知其所以然啊，这样的是不对的啊，我希望通过这个课程能够帮助大家啊，去了解相关的一些指标。然后第三呢是性能测试的一个分类， 性能测试的一个分类啊，这个呢也是很多人喜欢来问的问题，或者说在面试的时候被问到的啊，我们一起来看看到底会有哪些的分类，具体是怎么来分的。然后呢性能测试的流程啊，这是一个非常重要的点，对吧？我们性能测试到底应该如何去开展，需要去完成哪些事情呢啊？我们将会在性能测试流程这里给大家做详细的一个分解， 哈喽。呃，那么我们首先来看第一点啊，那就是什么是性能？什么是性能测试？ 讲到性能呢，呃，这个我们就离不开一个话题，叫软件质量模型啊，在软件质量模型里面呢，呃，早期的这一个六大模啊模块对吧？到后面呢发展成八大特性和呃四十二个 特性。那么在不管是这一个六大特性还是八大特性啊，这两个不同的软件治疗模型的研究的过程中，其中都提到了一点，就是叫做效率，叫做效率啊， 效率的特性里面呢就提到了以下几点，这个是从八大特性里面来讲啊，他提到了以下几点，第一个呢是时间特性啊，时间特性啊， 什么叫时间特性呢？那就是说，呃，在我们的软件系统在运行的过程中啊，啊，我们去做所有的操作啊，对于用户来讲，用户会有一个感受，对吧？我这个操作用了多长时间？对于系统本身来讲啊， 系统本身的运行系统，对啊，这一个啊，接口的一个调用啊，数据库的运行等等，这中间都会涉及到时间啊，可以这样讲啊，时间是我们在论及系统的性能中啊，是一个至关重要，或说头等头等重要的一个因 素啊，头等重要的一个因素，然后第二个呢，是资源的一个利用率，资源利用率啊，因为，呃，同样的一个软件，他如果说啊，在用户操作他的时候，他能够给出的这一个时间是一样的情况下啊，如果说啊， a 软件啊，他的对于资源的利用率是低于这一个 b 软件的，那我们可以认为 a 软件的性能啊是要更好的，就好比什么呢？呃，我们现在很多同学都应该啊，会用智能手机，会用智能手机去玩游戏，对吧？ 啊，那么对于游戏这一块呢啊，有一个非常重要的一个指标，就是啊，我们的游戏对于我们手机的一个资源的损耗 到底利用率怎么样啊？其中可能就会论及到，对吧？像手机的啊， cpu 的调度啊，啊，内存的使用啊，啊，网络的一个请求啊，当然这些呢啊，最终都会转化成大家一个之光， 可以感受到的就是手机越来越烫了啊，谁啊？运行的过程中啊，手机发热的问题比较严重，那我们可以用非常直观的就可以感受到啊，就是谁的性能会比较差，为什么呢？他对于资源的一个使用情况是更多的资源的使用情况啊， 然后第三个呢是容量，容量啊，其实讲到容量这里呢，呃，我们日常啊，可以把它转化成很多不同的名词啊，啊，一般我们可能更多的会论及到一个叫吞吐量的一个概念， 吞吐量的一个概念啊，最后呢是效率的一个依从性，这个依从性呢是这个软件质量模型里面经常会提到的一点，其实他就是就是指啊，在不同的行业，在不同的国家啊，他都会有相关的一些特性的一个要求。就好比说到性能啊，你如果说上升到传统行业里面去的话啊，那比如说这个能量的 转换，水电站对吧？他就会有一个能耗的一个转换啊，光能的发电啊啊，他的这个能量转换率啊啊，然后电灯泡啊，他的这个能量的转换率啊啊，汽车对吧，同样的燃油损耗下，他能够 啊，跑多远跑多快啊等等这些啊，其实在不同的行业里面都会有相关的一些指标或者说描述来论及啊，和这个性能有关的， 当然就是从软件质量模型的角度来讲啊。其实呢，呃从我们自己生的一个经验来说，对于性能啊，对于性能他的指标描述、感受各方面东西特别多特别多啊。但是呢，呃，我们可以从两个最本质的方向去把握，他从两个啊，第一个呢叫号码尺，号码尺啊， ok， 对吧？第一个是 how much？ 那么这个呢是用来衡量系统的一个处理能力的啊，一般来讲一个系统的处理能力越大啊，那对应的就是吞吐量啊，各方面东西他也会更高，他能够同时服务更多的用户啊，这是 how much？ 然后第二个呢是 how fast， 这个叫多快，对吧？ how fast 这个东西呢啊，说穿了它就是这个质量模型里面的时间特性，时间特性啊， 那么最终呢，我们系统中所有的这个性能相关的东西啊，其实都会依赖于 home 之后和 fast 这两点，一个啊是用来衡量系统的一个处理能力的，一个是用来衡量系统的处理效率的啊，当然啊，我们也都能够知道一点，就是在同等资源情况下啊，如果说啊， a 系统 处理效率高于这一个 b 系统，那么对应的啊，因为你处理效率高，比如说我一秒钟啊，我能够我处理一个请求啊，只需要十毫秒啊，那我一秒钟就能够处理一百个 一百个请求啊。另外一个系统如果说处理一个请求啊，需要这个一百毫秒，那么啊，对应的他一秒钟就只能处理十个请求， 所以这中间呢啊，给人的感觉好像啊， how much 和 how fast 是相关的，直接相关的啊，这个东西呢啊，其实不是这样讲的，为什么呢？因为这里面会涉及到系统的一个架构的问题啊，各方面的 啊，有的系统呢，他可能会做一些水平扩容，能够做水平扩容啊，有些系统呢，在加固设计的过程中，可能在某些节点上啊，他没有办法去进行扩容的一个处理啊，从而就会导致啊，他的平静始终停留在这一个地方啊，就你怎么去压怎么去加啊，详细时间 就只看着他在增加啊啊，这一个处理能力没有去上升啊，这也是我们日常可能会经常记啊，经历过啊，或者说接触到的一点，对吧？当然呢，这个没关系啊，大家弄清楚这个最基础的概念啊，凉快， 我们一般对于系统的性能都会从这两点去进行衡量啊，不能抛开几种啊，你只说快没有用，你只说多也没有用啊，一定是快和多要能够平衡，能够满足我们的一个需求啊，这才是啊，真正的性能要把握的一个点。 那么了，了解完这个之后呢，什么是性能测试啊，那就直接啊就出来答案了，什么是性能测试啊？ 就是我们通过各种啊测试方法，通过各种性能测试的方法去衡量，去测试我们系统的各项啊性能指标能否达到我们的需求，那么这个指标呢，我们最终都会反馈到好马齿和好发 上面啊， ok， 这就是最最基础的啊，一个性能和性能测试的一个概念，希望能够给大家啊解答相关的一些疑惑啊，谢谢大家，我们下节课再见啊。
粉丝1964获赞6011
相关视频
05:53查看AI文稿AI文稿你们压力测试是怎么做的？我们压力测试主要是去发多条数，去看 mq 和 radis 里面能不能进行正常的消费。嗯，你，你们一般是怎么去测试你们的服务上线的？ 测试服务上线就服务家服务性能的上线吗？你们也是怎么制定的标准啊？这个服务性能的上限啊，我给大家说一下，我给大家仔细的写一下啊， 这道题呢，就是他想问的就是服务性能，比如接口的瓶颈啊，以及调优的方案，他就想问这个东西其实怎么去测试，比如说我们用杰米特去做性能调优，先对接口压测啊，了解到一个接口日常 的 gps 啊，假设是假设是七十哈，七十 gps， 然后压测就梯度压测 的时候发现最高峰啊，拐点就是 七十，然后响应时间，时间是啊，比如说一秒啊，这种就是慢，就是慢查群的啊，如果大家会会那个做过性能测试调优的啊，马上就能知道这是慢查群啊，这是其中一种最大的一个可能性。然后 cpu 的 就是服务器的 cpu 使用率是比如说九十，百分之九十，这是一个一套话术啊，大家都可以这样去说哈，就只要学过新的知识的啊，学过卖查询的，大家都可以按照我这一套话术去说啊，绝对没有问题啊，服务器的 cpu 使用率是百分之九十啊，这个时候你就要思考了， 一般这种情况就是存在性能瓶颈的，就需要做调优，首先会会考虑到数据库的慢查询，我就去查看慢查询的日记，找到对应的 慢查询语句。慢查询语句啊，这个怎么找呢？比如说超过一秒的这种收口语句都是慢查询，找出来之后分析收口语句，我们发现没有做所以的创建，所以导致 的慢查询的产生，所以以后我们提交给开发，开发修改后，我们附件我们验收好的就直接到验收结果了，验收结果就是接口日常 能压到压到三百三百 tps， 然后响应时间为两百两百多毫秒啊， cpu 使用率啊，大大下降， 可能可能就可能就只有百分之七十，然后百分之六十，这不说 cpu 使用率也行啊，就就这样响应时间为两百多毫秒，这样的话就能够把整个就是发现性能平静 啊，然后进行调优，最后再验收啊，从从七十 tps， 七十 tps 调优到三百 tps， 然后把响应时间一秒钟给他调优到两百多毫秒，这就是一个真实的一个案例， 就这样去跟他讲一下，他就想听到这样的一个答案，这样答出来就是高新啊，就是高新他，但是他可能会问，你，继续问你，迈腾学有哪些情况啊？你有哪些调优方案啊？这一块的话要先把我的课看一下，好，我这个文件，这个 课间的话都给大家分享的哈。啊，这麦斯科的啊，你看这里面的麦查群啊，我都写的很清楚啊，这可以直接领取啊，在我这领取，这里面麦查群啊，麦查群， 你看有什么问题，所以问题咋？所以问题是不是刚刚讲的第一个问题就是我们的所以没有创建？第二个呢，数据库表结构的问题， 第三个呢，数据库参数配置问题，还有第四个查询语句的写法问题，慢查询就这四个问题，你，你把这四个问题做到了啊，把挨个去对比啊，看他怎么去调优，能够解决慢查询的问题。那么这就是调优的方案啊，这也是瓶颈的解决方案，这个课间可以找我，你选。 ok， 继续听。 好像没有太，我说的上限是说就是，呃，你们那个怎么看？你们的性能极限是是是，多少？是主要是想用这个，哎，性能极限就是我刚刚说的嘛，对吧？ tps 的 极限也是我们的响应时间的极限啊，响应时间的这个瓶颈 啊。 tps 就是 我们刚一个接口，它最高就压到九十，因为 cpu 都达到百分之九十了，就七十啊，最高压到七十， cpu 的 使用率就达到九十了，所以这块一定上不去的啊，因为他的资源都用完了。 那，那你跟他说你们主要看 m q， 这个是你们主要测试这个消息，消息的对，消息能不能正常的，就是消息能不能正常的推送进去，然后他能不能进行正常的消费，在数据库里面有没有进行正常操作 啊？其实这一块答的不好啊，他其实没有把我想表达的意思说出来，如果这块让我来答，我会怎么答呢？比如说我们就说一下 m q 啊的压缩这块，我会说我们我们会用 jimmy 对 m q 这个接口啊做压缩， 然后啊我们先发送上千的一个这个消息啊，发到我们的 m q 里面去， m q 的 容量呢？我们设置为五百啊， 这个时候有很多消息都进不去，那么这些多余出来的消息会找一个数据库给它存下来啊。最后当消息消息队的容量降低之后啊，消息队的里面的消费，那个数据被消费之后，我们还会把数据库里面的数据提出来，再放到我们的消息队里面继续消费啊，这想这就是我想表达的一个意思， 我们重点是要去测试消息对接，在极限的这个压力的情况下，它能否和 reddit， 能和，能否和数据库正常地去使用啊？我们测它的功能是否正常，而且我们要去测什么死性啊？啊？测什么这个数据流转啊？还是测什么那个 republic 啊，对吧？这都是我们要测的一些重点， 它是没有表达出正，没有表达出来啊，它只是说说了一下什么消息对接的基本的功能，它没有把我这一套意思表达表达完整啊，那这块我都在这个课典里面都写得很清楚啊。 没关系，但是问题不大啊，你大致的说一下也是不错的啊，那你们平时的一些就是功能操作啊，这肯定也会遇到一些接口调用吗？那这些，这这些上面是不会去做压力测试的是吗？不会，针对 m q， 呃，这方面的话，可能他是，他是想问那个接口的压测，就是刚刚我给大家说的一个性能调优啊，大家可以直接按照我这个模板去答就 ok 啊，没有问题，绝对没有问题。
03:38查看AI文稿AI文稿同学们，想让你的性能测试执行不只有把服务器打挂这一个结果，我们就必须用解密特做专业的性能测试分类，核心在于设计不同的压缩场景来回答不同的问题。下面这五种场景你都得会。第一，基本测试。 这是所有压测的起点，它的作用有两个，一是当你第一次对一个新系统做压测时，用单个或者很小的并发症，比如一到五个运行，得到系统在无压力状态下的性能表现，比如说响应时间、吞吐量， 这个数据要保存好，它是后续所有测试的对比精准。二是性能调优后进行回归测试前用同样的参数再测一次，和这个精准对比，就能快速发现调优是否有效。第二，压力测试。 这是最常用的，你想知道系统在持续高压下的表现，比如能不能扛住双十一的流量。在解密器里面，你只需要配置好现成组的千人数， 也就是虚拟用户数、循环次数和持续时间。目标呢，是让系统稳定运行在你能接受的较高的资源使用率下面，比如说 cpu 在 百分之八十的时候，看各项指标是否达标，会不会有内存泄露等问题。第三，覆盖测试。 这是模拟真实用户逐渐增加的一个关键场景，你不能一上来就给系统施加大压力，需要一个爬坡的过程。简秘书自带的普通性能组实现这个很麻烦，这时候建议你安装一个叫 stepin 3 的 group 的 插件， 用它来实现我们的加载加压。设置如下，开始的时候启动多少用户，然后每隔多长时间均匀增加多少用户，直到达到最大用户数并持续运行一段时间。 这个测试呢，能帮你清晰的找到随着用户数的增加，系统响应时间和吞吐量的变化曲线，从而找到新的拐点。第四，并发测试。 专门测试系统处理一瞬间大量用户同时操作的能力，比如说秒杀场景。这里要用到同步定时器， 你需要在关键请求前放置一个同步定时器，设置一个集合点。比如说你设置了一百个虚拟用户，当第一个用户到达这个定时器的时候，他会被拦住等待，直到凑满一百个用户，然后同时释放发送请求， 这样就能真正模拟出高病发的冲击，看系统是否能平稳的处理还是直接崩溃。 第五，稳定性测试。模拟系统在中等压力下长时间运行，比如说八个小时、二十四个小时，甚至更久的情况下，是否稳定？这里呢，建议大家用 utmeter 这个插件， 它能更灵活的编排不同压力阶段的组合，比如说模拟白天八小时高压力，晚上八小时低压力，循环的加压 目标呢，是在长时间的运行当中，监控系统的内存、 cpu 错误率等指标是否平稳，会不会因为累积的效应而宕积。总结来说，在真实项目里面，性能测试类型分为基本测试、压力测试、负荷测试、并发症稳定性测试。 具体做哪个类型，跟进项目要求选择即可。那么你们团队性能测试是如何执行的呢？欢迎一起来聊聊你的经验。
26墨尺老师说软测
01:09查看AI文稿AI文稿学习 geometry 不 用死记硬背，盲目自学，只需要吃透这四个核心阶段，轻松玩转性能测试工作，面试直接少走九成弯路。 第一阶段，基础认知，掌握 geometry 环境安装核心组件原理，弄懂现成组取样器配置原件监听器的用途，熟练搭建 http 接口请求，完成基础发包与简单接口调试。 第二阶段，进阶实操，重点掌握参数化接口、关联、断言、 cookie 绘画四大核心技能，搞定动态参数提取批量请求结果较验，适配真实业务多接口串联场景。 第三阶段，性能压测，熟练设计并发场景，阶梯加压、持续稳压，灵活配置现成数加压时间、循环次数，通过聚合报告 t p s 响应时间、错误率，精准分析服务性能瓶颈。第四阶段，高阶落地， 掌握分布式压测定时器、逻辑控制器脚本优化，学会打造企业级压测脚本，搭配 c i 集成定制化性能报告， 适配项目全流程自动化测试。针对这四个阶段的学习重点，这份文档包含了从入门到进阶的全部干货，把 g i m t 的 操作细节与实战技能都拆解的明明白白。
748测试不打烊（主页传送）
01:57查看AI文稿AI文稿搞懂这几个 jimmy 的 核心压缩主键，相信你做性能测试再也不用担心了。第一个的话就是现成主，现成主主键分为默认的以及插件的默认的情况，下面就是我们说的默认现成主， 那么除了这个之外的话，我建议大家去了解一个现成主的插件，它有梯度压缩以及终极现成主等多种模式，相关的一些插件配置我也会放在后边。 第二个主键呢就是监听器，我们在压缩过程中，所有的数据都将通过监听器以图表、表格以及个人翻的等等多种形式可以进行展现，这是我们去做性能数据的一个收集所必备的一个相关主键。 第三个主键就是 csv 的 文件加载。对于我们在压缩过程中，有很多数据是从数据面导出出来的，比如说我们要去实现一个批量查询，那么查询的参数，查询的数据信息，查询的一些内容可能是从数据库先行进行导出，然后再通过 gmail 的 方式进行一个 数据加载，之后通过参数化的形式进行请求。第四个呢就一定是我们的定时器主键了，定时器主键模拟我们用户思考时间以及控制现成执行任务的频率都是所必备的。根据你所需要的 实际业务场景去使用不同的定时器来达到你想要的一个压测需求。那最后一个分类也是最重要的点，就是我们说的前置和后置的处理器，在接口调用之前，我们是否要进行接口的加解密以及参数的一些动态生成， 在接口调用完毕之后，是否要进行参数提取、断言，以及说后续的一些数据较严的工作？同时呢， jmate 它因为有非常丰富的开源社区组建， 比如说像 word socket， 像 mqtt， 像 double 等等这些各项的接口，它都可以进行测试。所以我们不仅是要了解 jmate 本身自己具备的一些主键，可能还需要根据需要去下载一些插件来结合我们的一个压测场景进行使用。 关于 jmate 的 压测，其实之前我也做过很详细的一个分享的实操教程，有需要的话可以找我给你关注三丰老师，后续聊更多软件测试的干货知识。
99华测-张三丰
04:01
05:41查看AI文稿AI文稿g m t 做接口性能测试，怎么设计测试脚本？你说你会用 g m t 做接口性能测试，那你知道怎么设计一套稳定可用，企业能直接落地的测试脚本吗？刚面了一个三年经验的软件测试，我问他项目都是长链路接口， 带加密签名，多用户高并发场景。用 jmeter 做接口性能测试，怎么设计一套稳定不崩可附用易维护的专业测试脚本？ ai 能快速生成基础脚本，普通测试也会简单录接口改参数，看起来接口都能跑通，请求也能发出去， 那你该如何判断脚本是否规范可靠？能不能直接拿来压测上线做性能评估？完整设计思路和落地标准是什么？他想都没想直接回答。打开 jmeter 录制业务接口， 改下参数，加几个线程组，调好并发数，直接跑压测就行。我顺着他的话继续问，这个基础操作谁都会，但我再问你，接口 token 订单 id 这类动态参数怎么关联提取？ 加密接口签名时间戳怎么自动生成？适配多环境域名地址怎么一键切换管理？长链路业务怎么拆分模块做到附用维护高并发下？怎么避免脚本报错？请求重叠？数据缓存失真， 压缩出来的 tps 响应时间不准，怎么排查是脚本问题还是系统瓶颈？我补充到很多人写的 gm 二脚本，看似能跑通，实则杂乱无章，硬编码斜死参数，没有分层设计， 处理不了加密和关联，一到大病发多轮迭代就频繁报错，结果失真，完全没有参考价值。针对企业复杂业务场景，你有没有一套标准化的脚本？随便改改？没专门做过规范设计？电视到这里基本就可以结束了。 如果这道题你也没把握打好，我整理了一套能拿捏面试官的必考题库，包含测试理论功能测试、自动化测试、性能测试和 ai 测试的内容。只要是我粉丝留下，六六六直接带走 nice！ 很多测试从业者都有一个误区，觉得 jammer 只要能录制接口，发起请求跑出数据，就代表脚本合格能用。但大家忽略了一点，脚本能跑通和脚本稳定可用企业及落地完全是两个不同的技术维度，不能混为一谈。 一个能胜任企业接口性能测试的高级测试工程师，必须具备以下三层核心认知，缺一不可。第一层， j m t。 脚本模块化分层拆解与避坑核查。新手写脚本最容易出现各类问题， 所有接口堆在一个县城组，硬编码写死账号域名，接口杂乱无章，无法复用，看似能跑通业务流程，实则后期极难维护，迭代一次就要改变所有脚本。 j m t。 擅长简单单接口压测，但面对复杂场景，短板很明显。 登录 token、 动态关联上下由接口参数、依赖、接口加密、签名校验、多环境切换、长链路业务流程秒杀、瞬时高并发、弱网间隔模拟。这些场景随便录制的脚本根本适配不了，还容易出现请求重复数据，脏数据压测结果失真。所以绝对不能直接用原声录制脚本 要先做模块拆分归类，划分为公共基础模块、独立业务模块、压测场景模块三大类，逐一梳理接口依赖关系、动态参数、加密规则，确保脚本贴合真实业务流程，不做无效用于设计。第二层， jim meter， 脚本规范化、量化设计，拒绝凭感觉写脚本 设计稳定脚本，绝对不能随手添加组件、乱配参数，而是要建立标准化设计规范，重点把控这几个核心要点，脚本分层附用率、接口关联覆盖率、 参数化、数据多样化、加密接口适配率、压测场景匹配度、脚本报错故障率、多环境兼容适配能力。同时要对照需求文档 接口文档线上真实业务流量复刻用户常规操作、异常操作、峰值操作场景，参考过往线上性能故障，验证脚本能否覆盖高病发、超时限流、溶断等核心场景。除此之外，还要对脚本做分级管控，基础可用脚本需优化调整脚本逻辑错误，废弃稿本， 做到精准优化，而不是录完直接拿去压测，盲目出性能报告。第三层， gm e t 脚本落地优化方案，建立性能脚本质量准入标准。想要真正设计出稳定可用的性能测试脚本，首先要搭建标准化脚本规范，统一现成组命名原件层级 变量命名注视规范，用测试片段模块儿控制器实现公共脚本全局复用，减少重复开发。其次，核心场景重点适配，针对登录健全支付、下单商品、秒杀用户中心这些核心高并发模块儿，单独做加密处理， 集合点加压定时器模拟用户思考间隔，规避瞬间流量冲垮系统压测数据不准的问题。最后，把项目接口规则、加密算法、环境配置、常用压测参数整理成固定模板，沉淀企业专属 g m t 脚本规范，形成模板出使化模块拆分配置 关联参数化加密适配场景加压结果分析的完整流程。坚决杜绝随手录制、随意改身的粗放写法，建立明确的性能脚本质量准入标准，守住性能测试结果的真实性和可信底线。 说到这里，大家应该明白这道面试题的核心考察点了，它考察的是你能否从只会简单录脚本跑并发的基础层面，升级到能做脚本工程化设计、复杂场景适配、稳定性把控、性能瓶颈分析的高级层面。普通测试工程师只要脚本能发请求跑出数据就觉得万事大吉。 而高级性能测试工程师清楚 gm meter 工具操作只是基础，能否设计出易维护、可附用适配加密、长链路、高并发下稳定可靠的脚本，能否保证压测数据真实有效、精准定位系统瓶颈，关键在于你对脚本分层设计、 接口关联场景加压规范落地的深度理解，以及对性能测试全流程的标准化把控能力。最后想问大家，你们平时用 jimmy 写脚本有没有踩过脚本混乱、无法维护、加密接口跑不通、高迂发频繁报错、压测结果失真的坑？欢迎在评论区一起交流探讨！
120测试不打烊（主页传送）
01:48查看AI文稿AI文稿哈喽大家好，我是你们的测试老司机歪歪，今天这期视频，我要给大家搞一波超级狠货！一份大厂内部都在用的杰米特从零到精通实战手册，刷完它你也能拿四十 k！ 先问各位测试小伙伴一个问题，你现在出去面试，如果不会，杰米特还有公司要你吗？ 现实就是这么残酷，接口测试、性能测试、自动化测试，杰米特几乎是必问必考的工具。简历上写熟悉杰米特的人太多了，但面试官随便一问，杰米特怎么做？参数化怎么加？断言压缩时怎么监控？服务器资源分布式压测怎么搭？ 一堆人直接卡壳？为什么？因为平时只会点开始看，结果根本没系统学过。但我今天分享的这份杰米特从零到精通实战手册，可不是网上那种零散的教程，它是大厂内部培训用的实操手册，从基础到高阶全覆盖，内容全面到可怕， 基础概念现成组、 simper linux 断言讲的明明白白，参数化、 c s、 v 函数、触手用户参数，各种方式一次搞定，关联正则表达式提取器、接收器、手把手教学断言、响应断言、拘神断言、大小断言，再也不怕漏测。 性能测试、压力测试、鉴定器分析、聚合报告解读，全是干货。分布式压测， mas 的 style 架构搭建，大厂高并发必备技能， 监控集成，配合 prometheus 加 grafana 做实时监控生产级方案。最重要的是，它不是纯理论，而是项目！实操手册里提供了实战项目地址，你边看边练，学完就能直接用到工作中。 刷完这份手册，你能到什么程度？接口测试，独立搭建接口自动化框架跑通又流程性能测试设计压测，场景分析，性能瓶颈输出，专业报告，面试对答如流， jam 的 相关问题全部拿捏薪资直接谈，工作中独当一面，别人不会的你都会，团队核心就是你！ 从零基础到杰米特大神就靠这一本！不管你是刚入行还是想进阶，这本手册都能帮你！这份大赏内部杰米特实战手册我今天无偿分享给支持我的小伙伴，评论到手一定要跟着项目实操，别放收藏家吃亏！
44软件测试笑笑
01:57查看AI文稿AI文稿今天给大家分享一份性能测试的高频面试题的答案以及它的主旨考，其中呢一共有五十多道题，包含两个部分，第一个部分呢是我们性能测试部分的，性能测试部分就包含我们的性能调优，还有我们的 jmeter 的 一些操作，还有我们的 linux 的 一些操作。然后呢就是我们的中间键的一些调优，包括 radios 和我们的 mq 部分。 好，这里面呢问的最多的了，一般都是属于我们性能测试调优相关的一些东西，然后呢以及性能测试工作细节相关的东西，这里面呢会问到很多的一些细节，如果说你面试的过程当中，一问到你工作细节你就挂掉，那么肯定是没有仔细的去解决，没有去总结过复盘过， 比如这里面性能测试 cpu 满了，怎么去解决？这里呢，我们首先要清楚是什么服务器的 cpu 满了，是应用服务器还是数据库服务器，那么应用服务器 cpu 满了，这个时候要去查热点的代码，通过什么工具怎么去查？ 查到之后呢？接下来怎么去解决，包括我们的增加应用实力，调整现层次的配置，优化连接的一个配置等等的。那如果说是副数据库的一个服务器，它 cpu 比较高了，那么我们要看慢查询， 查办查询的一个日制，然后找到对应的一个 c 口，之后来执行计划分析，然后通过我们的分析来再进行一些解决。解决方案常见的有比如说优化数据库啊，增加数据库的势力啊，呃，调整数据库的配置啊，优化表的结构啊等等的一些内容， 包括我们用什么工具去做的性能测试，这里来同样的我们去猎取了很多丰富的一些工具，还有什么性能测，环境性能测试，然后有几台服务器好？一般问到这一类的问题了，我们也是列出了不同的项目啊，包括有 b 段的，有 c 段的，然后他热和是多少的好，那么推荐的一个服务器大概是怎么样的？ 那么还有就是包括我们 tps 上不去性能测试当中 tps 和 qps 比较低，哪些方面的问题好？这里呢也是从不同的方面，比如说压力机，网络瓶颈，中间件，还有我们的 java 现成等待本系统的资源，还有数据库连接尺耗尽 等等的一些原因，然后我们进行了一些分析，那么这些呢，就是面试当中非常体现工作能力的细节，如果说想要这份面试的同学呢，可以直接找我要。
58燃测老师
01:19查看AI文稿AI文稿今天面了个自称做过性能测试的，简历上写着熟练使用 gemiter loadrunner， 结果我一问，性能进阶题直接露馅儿了。 我问他压测时发现 pps 上不去，响应时间也超标，但服务器、 cpu、 内存使用率都不高，你怎么排查？他想了半天，只说增加并发症， 完全没思路。这就说明他只做过基础亚测，没处理过真正的性能瓶颈。其实这道题是大厂性能面试的高频进阶题，很多测试都会栽在这里。正确的排查思路分四步，一步都不能少。第一步，先检查网络贷宽，看是不是贷宽不够导致请求被堵塞，尤其是高病发场景下，贷宽容易成为瓶颈。 第二步，查数据库，看是不是有死锁，事务未提交或者慢查询太多，就算服务器资源卡顿，也会拖慢整个系统。第三步， 查接口本身，看是不是接口有串行堵塞，没有做异步接口，导致请求排队等待。第四步，检查压测脚本，看是不是模拟的用户行为不真实， 比如请求频率太快，没有设置思考时间，导致压测结果失真。性能测试不只是简单压测，更要会排查复杂品鉴，这才是高清测试的核心能力。 我把性能进阶的面试题瓶颈排查思路、优化方案整理成了专属题库和资料，想要的评论区扣。性能进阶我直接发你，帮你突破性能测试瓶颈。
89程序员一凡
02:21查看AI文稿AI文稿你说你精通 g meter， 那 我问你是怎么设计 g meter 脚本的？最近面试了一个测试工程师，我问，用 g meter 做接口性能测试，面对加密接口常规业务、高并发场景，怎样搭建稳定可靠的测试脚本？他说， 通过 jmeter 录制脚本，简单修改参数就直接运行。我追问，加密参数如何确保请求合法？关联逻辑该如何实现？测试脚本怎样高效附用并发加压策略需如何配置？测试结果应从哪些维度分析？他吱吱呜呜的答不上来，烦死了 啊！假如你对这道题目也不会回答，我整理了让面试官沉默的大场测试必考题库，包含测试理论功能、测试自动化、测试接口、测试性能、测试数据库项目等等。只要是我粉丝点个赞，评论区留下上岸直接打包带走。 nice！ 那 么这道题该如何回答才能让面试官哑口无言？接下来分享能在面试中脱颖而出的答题思路，帮你全面拆解 jmit 脚本设计逻辑。 一、核心原则， gmail 脚本需满足可附用、场景可还原、结果可分析、压力可调控四、大标准。二、脚本模块化搭建， 拆分登录、公共请求等通用模块封装成独立组建，减少代码领域，方便后期维护升级。三、关联与参数化优化，用正则表达式 jason 提取器完成接口关联，搭配 csv 数据文件，实现参数化。四、加密接口适配处理， 借助脚本编辑 jmeter 函数助手完成参数加密、接口签名校验，保证请求符合接口规范。五、并发场景精准配置，合理设置线程组、加压时长、循环次数，贴合真实用户访问逻辑， 避免瞬时压力过大导致系统异常。六、结果分析与性能调优通过聚合报告统计请求数据，重点分析响应时间、吞吐量、错误率，快速定位系统性能瓶颈。 核心要点， g meter 绝不是简单录制脚本就可以使用，核心是真实模拟业务场景，精准定位性能问题 支撑系统调优脚本混乱、参数无序，只执行不分析的压测，没有任何实际价值。这类问题考察的是工具实操能力与性能测试思维的结合， g meter 只是辅助工具，脚本设计逻辑与场景还原能力才是体现测试专业度的关键。大家在使用 g meter 做性能测试的过程中遇到过最棘手的问题是什么？
43程序员新一
09:44查看AI文稿AI文稿性能测试 gm 入门到精通第二集，呃，大家好，我是土匪啊，那么上节课给大家讲了这一个，什么是性能，什么是性能测试，那么这节课我们继续往下来看啊，那么我们了解完什么是性能，什么是性能测试之后啊，接下来我们来了解一下啊，常见的一些性能测试指标啊。 那么常见的性能指测试指标呢？呃，一般有以下几点啊？第一个是响应时间啊，这是一个最常规啊，用的最多的一个指标，是用来衡量系统的这一个处理效率的啊。 然后第二个呢，是像 t p s， r p s， q p s h p s 这些啊，大家可能经常会见到和接触到的，但是又分不太清楚的一些啊，和吞吐量有关的指标。然后第三个呢，是我们日常这一个用户数据相关的啊， p v 和 u v 啊，那么我们首先来看第一个响应时间， 那么对于响应时间这个指标来讲呢啊，定义非常简单啊，就是从你开始发送请求，从你发送请求开始啊，到你接收到啊，或者接收完服务器响应的一个时间啊，这里我用了两种描述，一种叫接收到服务器的响应，一种叫接收完的服务器的响应啊，那么 呃，很多人呢，做性能测试的时候，他不了解这个过程啊，什么叫接收到服务器响应呢？这里就会涉及到一点啊，以 http 啊，这一个协议为例啊， http 呢，他在这一个建立的，他的一个通信过程中啊，他其实是分为五个步骤的啊，连接的建立，然后连接的这个数据的传递，然后这一个 啊状态的响应回复吧，然后接下来是这一个数据的接收，最后是可乐子啊，反正是有五个这样的一个过程，五个这样的一个过程啊，那么对于我们来讲呢，其实这个过程中间 的过程我们并不是特别关心，我们只关心什么呢？哦，我开始发送请求， ok， 这个是需要去计时的，那这个计时谁去做呢啊？是由我们的性能测试工具去做的啊，然后啊拿到响应，拿到响应啊，那么在这个过程中呢，拿到响应，这里业界是有两种不同的一种 啊统计口径的啊，一种呢是把所有服务器响应的内容全部接受完毕的啊，啊，这个是一种。另外一种呢，就是我认为呢，这个从拿到服务器的响应的第一个字节，这一个时间啊，他更 能将更能够更加精确的去表述或说去描述服务器处理这个请求的时间，因为我拿到第一个响应字节，然后再把所有的数据接收完毕的这个时间啊，这个时间呢，一般我们管它叫 receive 的时间，它是和我们的这个客户端啊，和服务器的这个带框 是直接相关的啊，和这个内容的大小直接相关的，你内容越多，接受的时间越多，你的带框啊越差啊，那么接受的时间越多，那么这一部分的时间呢，往往和服务器本身和我们测试的对象这个系统啊，我们的软件是没有什么太大的关系的，或者说是完全没有关系的啊， 所以呢，在这里会有两种不同的一种啊统计方式啊，这个大家弄清楚一下。那么对于响应时间来讲呢，其实在概念上弄清啊，了解之后，我们在脑海里面啊，是需要有一个这样的过程去想一下的啊，去想一个东西，这是我们平时 啊请求发送了，对吧？从发送开始，从发送开始啊，到这个结束，这个时间的计量啊，首先是有工具做的，对不对啊？他我们管他叫请求的结束时间，减去请求的一个开始时间， 是啊，一个相对啊共就相对比较准确的一个值，但是呢这段时间包含哪些内容呢？第一个啊，连接的建立时间，这个连接建立呢啊，他会包括客户端 啊，受到客户闹的一个性能的影响，然后呢啊他会受到网络状态的一个影响，然后连接建立之后啊，连接建立的过程中他可能还需要做 dns 的解析，对吧？比如说呢要做啊，如果像 ssl 协议的话，他还会涉及到啊 ssl 隧道的一个建立，就是这个通信建立啊验证权限的一个过程， 如果涉及到像 f t p 这样的，它会有一个 f t p 的权限认证，诸如此类的啊，这个都是会放在这个连接建立的一个过程里面的连接建立的过程啊，然后呢接下来就是数据的发送这一部分的时间呢，收到客户端和服务器之间的网络的影响，但是呢基本上时间是很小的，因为我们日常 作为测试来讲，除了像上传文件这种特别的啊这种业务啊，其他业务我们客户端向服务器发送的数据都是比较小比较小的啊，耗费的时间是比较少的。 然后第三个呢啊，到了服务器端，这个时候大家可能就得弄清楚啊，因为在服务器端可能会有很多不同的架构，比如说啊，有这个 word 服务器，或者叫前端服务器，对吧？像有些公司用 ngx， 有些公司呢直接用 tomcat， 有的用 httpd 啊，诸如此类的都会有。 然后接下来到了这个 word 服务器这里呢，他向后他可能会有网关服务器，对吧？ g w 啊，网关这里呢？再往后一般就到了应用节点应用服务器了，应用服务器这里呢？ 呃，其实在网关和应用服务器中间可能还会有像消息对列啊啊，像缓存缓存啊， redis 数据库啊这种啊，然后最后呢就到数据库 这个具体啊，具体的东西呢，每个公司啊，每个业务，每个系统都是不一样的，这里呢？啊，作为一个性能测试工程师来讲啊，我们是需要去了解这一块过程啊，你不能说啊，相应时间我看到是五秒就是五秒 啊，如果只是做到这个层次啊，你没有办法去做后续的这种分析定位，你得在脑海里面，你得弄清楚啊，响应世界会有哪些部分构成，将来万一出了问题，对吧？万一性能不达标，我们知道啊，应该从哪些方向去进行左手去分析，去找到问题所在啊， 就是响应时间的一个基本的概念，然后接下来呢叫 t t b f f b 啊，这个词大家在很多工具或者在很多报告里面都会看到啊，他叫 time to first buff 啊，这就是我刚才说的啊，响应时间呢，有一种统计方式，就是从我们请求发送开始到接收到服务器的响应的第一个字节，所以叫 time to first buff 啊，第一个字节的一个时间，第一个时间啊，然后过程，这里刚才已经给大家做了一个简单的解析啊，这里大家可以看一下，然后最后呢，在响应时间这里呢，我们还会在日常统计过程中啊，会有两个非常重要的词，一个叫啊 啊 r t， 或者叫 a v g， a v g 啊，我们日常可能会叫平均值，或者叫平均响应时间啊，这个简称呢？ response 啊， response time， 简称 r t。 然后第二个呢叫 pct 啊，叫 pct， 叫 pensant pensant 啊， pensant， 百分比的一个时间，百分比时间啊，那么这两个东西呢，它有不同的应用场景啊，日常中啊， 平均响应时间这个东西呢啊，从统计学的角度是没有任何问题的，但是对于性能来讲啊，我们单纯的看平均响应时间，很多时候可能是不够的，尤其 是啊，那我怎么老师我怎么去判断这个平均详细时间？他是可用还是不可用啊？可信还是不可信呢？我们可能就会要用到数学上的一个知识，叫做标准方差， 标准方差啊，那么标准方差越小，平均值的可信度就越高，因为标准方差它是用来反映数据的一个离散程度的，这个离散就是相对于平均值来的啊，相对于平均值， 所以如果方差越大，那就表示那这一个数据的离散程度就越大啊，越大的话呢，这个平均值就没有意义，就好比我们在座的同学啊，随便拿几个人和我组个队，我们九个人，再加上马云十个人，对吧，我们这十个人，我们的平均资产可能是啊，上百亿 啊，上百亿啊，但事实上这个我和你有没有上百亿的资产呢？并没有，对不对？那此时此刻呢，你去看这一个标准方差，那就是啊，我们的零减去这个平均值括号平方之后再求和啊，就是 那个公式，大家可以自己去百度一下，我这就不给他去罗列了啊，那么最后算出来，只估计啊上百万，上上亿都有可能，我算一下应该是上百万、几百万的啊，将近是三四百万的一个 方差值，而我们这一个平均值，对吧？平均值才一百万，那这个一除一笔啊，就大于一了，大于一的话，这个标准啊，这个平均值的可信度就 很低了啊。那么在这种情况下，在这种情况下，为了更好的去衡量我们被测系统它的性能啊，从详细时间来讲，这个详细时间这个指标是否能够达标，我们就会引入另一种叫派森特 啊耐，或者叫 p c t 的一种时间。它的做法很简单啊，就是把所有的相应时间从小到大去进行排序，排序啊，排序完之后呢啊，取百分之九十，百分之八十啊，你指定的一个百分比 的一个区间，然后呢他就会获取到一个响应时间的值，那就表示，比如说百分之九十，那他就拍成的百分之九十啊，拍成的九十，他就表示什么呢？表示我们所有的数据里面，百分之九十的数据是小于等于 p c t 九十，然后剩下的百分之十的数据是大于等于 pct 九十的，就类似于一个这样的概念啊，那么像我们刚才说的马云和我们，对吧，百分之九十的人啊，他的资产可能也就是个零或者是个几万块钱，是吧？百分之十呢？可能是啊，几千个亿。 好，那从这里我们就知道这个平均值已经没有任何可信度了，那么性能也是一样的啊，我们很多时候并不能够通过平均响应时间去碰到啊，我们的系统的性能是好或者是坏啊，那老师，那这样这样的话平均值就没有意义啊，这个必须得说啊，平均值他的获取统 是一个比较简单啊，对于大家来讲呢，也是比较能够认可或者比较啊，了解的比较清楚的啊，怎么得出来的一个值？所以我们是一般是初步先用平均值，然后啊，当你发现平均值不可用的时候，我们才考虑去用 p、 c、 t 来作为这一个相应时间的一个 这一个指标啊，碰到依据吧，或者说一个维度，好吧，好了，那么这就是我们日常啊，对于响应时间在性能领域的一些基本的概念啊，就给大家解释到这里啊，谢谢大家。
79软件测试资源分享
01:09查看AI文稿AI文稿软件测试入门最快的办法就是功能测试加接口测试，加上接口自动化测试，搞定了之后呢，直接开始进入项目实战，这个路线呢适用于比较着急找工作，不想学那么多技术的同学，但是呢又想把核心技术学到手的一些同学，那么接下来我详细的讲解这三大板块当中到底要学会哪些细节。 首先第一部分呢，就是我们的一个功能测试，来这里我们要学会一些测试理论的基础，还用力，怎么去设计权限，怎么去查日期， mac 怎么去做数据的一个教训。 接下来呢就开始学我们的接口测试。接口测试呢，我们学接口测试的一些基础流程，还有用力设计以及工具，比如说像解密点 pos 慢，然后怎么去做好三方接口， g a 口加密，然后怎么去操作，那完成之后呢，接下来学习我们的 python 编程语言以及 python 的 框架。 python 编程语言呢，主要学习首先是它的一些基础的语法，包括循环语句啊，容器啊，还有函数面向对象，文件操作，异常处理等等。然后接下来就是 python 加载，最终呢结合 python 加 python 加锐制来搭建我们的一个关键字驱动的接口自动化框架。 哎，搭建完这个关键字驱动的一个接口自动化框架之后呢，接下来就可以开始直接进入到项目之中进行一个实战了啊，如果想要领取这份学习路线的一个方法，可以直接找我。
105燃测老师
