这个是幸存者偏差吧。

一个培训班几十人，几期下来几百人，出来几个薪资比较高甚至进到大厂翻几番的，很正常。你公司测试团队有类似规模，离职的人里有一些学习比较积极，成长比较快的，出几个高薪的例子也是很正常的。

西安暂时没计划。

感谢志愿者们的在幕后的辛苦工作，大会圆满结束离不开各位志愿者的支持！

PS：志愿者的志字，文中有好几处错误，有空修正下吧。

第一个端口是否已被占用的，不大明白为啥要有 OSError 异常才算有占用？

第二个释放端口的，直接 kill 有点太粗暴了。。。相比强制释放端口，使用邻近的其他可用端口会更合适。如果必须固定端口号，直接抛异常给用户，让用户操作更好。

至于所有都基于 windows cmd 命令，个人不是很推荐。这样会导致无法跨平台使用，以后搬上 jenkins 也必须是 windows 机器上的 jenkins 。除非确定未来都没有跨平台需要，否则用 shell 会更好。

想交流下，在线用户数这个数据，以及由此衍生出的并发度概念，在实际性能测试里面，会怎么使用？

个人理解，在线用户数增加，实际增加的只是内存或者用户信息存储中间件（如 redis）的消耗。只要大致了解每个用户消耗的资源情况，以及系统配置的总资源大小，基本就可以倒推出最大可以支持的在线用户数了。至于并发度，个人觉得这个数据很难做到准确（不同时段、不同场景、甚至不同用户，并发度都会有很大差异），所以好像没什么适合使用的地方？

另外，里面提到的 每个业务操作为一个事务、每个用户操作为一个事务 ，感觉这个 TPS 在实际操作中并不好计算，而且也和开发日常接触运维监控数据里的 TPS/QPS 差异比较大。个人实际项目里用的 TPS 概念，一般直接用压测工具计算的 TPS ，即此接口在此次压测下，每秒完成处理的请求数。

最后，每个线程产生的 TPS 是 20 个、一个压力线程下的 TPS 是 200 ，这里每个线程产生的 TPS 是怎么计算的？平时很少接触到每个线程产生多少 TPS 这样的概念，个人实际应用，根据接口本身逻辑的复杂度，同样一个线程，在简单接口达到过千 TPS，在复杂接口降到只有几十 TPS，都会存在，没有相对固定的值。而且随着压测线程数增加，如果已经达到系统性能瓶颈，那系统总 TPS 会保持稳定，进而平均到每个压测线程的 TPS 也在减少，所以比较好奇这个值要怎么算？

感谢指正，问题已修复

思路挺清晰的，不错。

根据自己的经验，提两个小建议：
1、既然用了 shell=True，可以考虑用 shell 命令，而非 cmd 命令，进而兼容 mac 系统？
2、对于端口的使用，python 有一个库叫做 freeport ，可以获取特定范围内空闲的端口号，以及判定指定端口号是否已在使用。可以考虑通过这个来增加端口号检测或自动分配？

你在自己的工作中找机会吧。自学只能算入门，实际项目中用才能成为技能。

从报错上看，https 链接没有联通，ssl 协议有问题。你确认是 https ，而不是 http 么？

比如说用例 1 我需要某个特殊数据，用例 2 需要某个普通数据，那用一个函数可能实现起来比较复杂

放两个函数就行了。

我意思是这个造数据存在多接口依赖问题，解法可以参照流程自动化用例的解法，并不是说直接用流程自动化用例。你可以考虑用例做下分层，底层是每个接口的调用函数，中层是多个接口组合的流程调用函数（不带断言，所以不是用例），上层是调用中层并加上校验，成为自动化用例。这样中层就可以给造数据复用了。

1、 第一个数据如何创建？我最近有一个特殊的数据需要准备，准备测试 A 接口的数据，但是需要用到 B 接口的返回结果，需要一些前置信息，还有就是有的属性可能需要，有的属性在某次创建时不需要（不是说有默认值，而是直接不添加该数据）

测试 A 接口需要 B 接口前置信息，那去 B 接口拿就行。你可以当做接口流程自动化用例去设计和使用。
至于属性不需要时直接不添加，可以了解下 builder 模式，这种写法可以只设定需要设置值的 key，不需要的不用写。

如何创建出同类型的测试数据？如何判断数据的类型呢？

个人理解原文里的同类型数据，指的应该是用相同造数据脚本执行得出的数据，所以称为 同类型 。

并发数这个概念每个人理解都有不同，没有统一的定义。按照高楼老师在极客时间性能课程的定义，并发数就是 rps，指代系统实际最高性能。

压测工具里的用户数（并发线程数）不能代表真实用户的，毕竟真实用户不一定会这么高频访问接口。

建议你买本性能测试相关的书，或者看看极客时间里高楼老师性能测试的课程，先把性能测试相对完整的了解一下。

那就是并发线程数恒定了，压力相对恒定了。

这个报告中的 rps 可以直接给领导说是每秒并发嘛

从现在的响应时间增大情况看，其实早就达到系统瓶颈点了（响应时间涨，说明系统现有的处理线程不够用，有不少请求其实已经在排队而非立即处理了）。建议并发线程数从 10 开始，先试试，然后逐步增加，看到多少的时候 rps 就不再上去，而是响应时间增加。

应该从哪些地方进行排查呢

不知道你说的排查是排查啥，这里的信息看不出啥呀。比如你说 cpu 不再上升，按照你现在性能表现分析，有可能是请求在队列里等待，实际处理线程已经是配置范围内全负荷运行了，那 cpu 不再上升也不奇怪（在队列里等待不会消耗 cpu 的）。如果确认这个接口的处理逻辑属于计算密集型，要通过提升 CPU 利用率提高性能，可以考虑增大线程数配置，让它同时多干点活。

你用的是 groovy pipeline 方式么？

如果是，那直接脚本里判断就好，可以是 shell 运行的 returnCode 是否为 0 来判定（运行失败一般 return code != 0），也可以脚本里把结果存到某个文件，pipeline 去解析文件进行判定。

只要抛个异常，这个节点就等于失败了

没怎么用过 locust ，先好奇问下，最后一个 number of users ，y 轴指的是并发线程数，还是累计用户数？

如果是累计，从斜率说明发送请求的速度是恒定的，那这个 rps 是否已经极限不好说，要换下并发线程数看下是否还是保持一致。不过从响应时间 95% 已经增大到这么大的数据看，大概率已经达到极限了。

如果是并发线程数，rps 应该早就极限了，但响应时间却在 1 分钟左右达到了一个相对稳定的值，只能理解为系统有自动降级措施，直接放弃处理请求直接返回了，所以响应时间没有继续涨。

感谢支持

500 用户并发请求一分钟，实际的场景应该是我们的老师要上线上课了，大量用户登录并进入教室的场景，需求应该是不崩，且响应时间在几秒内吧，比如，5 秒？

这个还是有点模糊。可以再具体一点，比如预计大概会有多少用户进入教室，进入教室是 1 分钟内全部进入完毕吗？响应时间几秒内这个和你们交互也有关系，按照你们 app 交互设计，大概几秒以上会有不大好的体验？个人理解，性能场景设计的终点，就是要摸清系统要达到多少 TPS 才能满足实际业务的需要。增加虚拟用户增大压力，只是会增加响应时间，也就是体验上变慢，实际系统 TPS 达到上限就基本不会再增加了，变慢的本质是请求收到后都进去排队，而非立即处理了。

第二个问题，我问我们的开发应该是没有这种冷库机制，可能有分库分表的设计，但是我们的用户 id 都是递增生成的，我并不知道具体的分库分表逻辑

建议可以去了解下分库分表怎么分的。如果是按照 id 区间分，那有可能新的 id 所在表数据少，查询就会快一些，具体快多少要看你的表数据多大，如果命中索引，一般速度差别不会太大。

本质还是看重复 id 和非重复 id，背后执行的内容差异是否会引起性能差异，假设没有缓存都是落库查询，那就和你们数据库设计强相关，要看你们数据库设计上，不同 id 对应的查询，是否会有比较大的变化。

暂时还没确定，预计 7-8 月会开始卖，请留意社区置顶帖和公众号就好。

” 500 用户并发请求 1 分钟 “这种场景，是不是本身就是一个伪命题呢？

这个严格意义不算是性能场景，因为没有响应时间的要求，没法反推系统的 TPS 需要达到多少才能满足。

在不考虑缓存的情况下，我用同一个 userId，100 个线程同时请求登录接口，和 100 个不同的 userId 同时请求登录接口，制造的压力效果是一样的吗？

有没有缓存只是一个方面，关键是看系统在重复 id 情况下，是否每次请求做的事情，和不重复 id 做的一样。如果一样，压力应该就基本一致。举个极端点的例子，100 个不同的 userId，如果放在同一个表，且数据规模基本一致，那基本上就是一致的。但如果背后是分布在不同的数据库表，而且有的放在冷库冷表里（简单点说就是查询速度会慢不少）。那即使没有缓存，性能表现也可能会有比较大的差别。

个人观点，性能测试场景设计，需要尽量和真实场景一致是最好的，毕竟背后的系统深入了说涉及的东西挺多，比如查询结果的大小差异，也会影响性能表现。所以谁都说不准为了省事调整了场景后，是否会导致性能表现失真，尽量模拟真实场景反而是最简单有效的。

感觉你这个需求有点奇怪。

一般都是通过性能测试并调整系统，来达到 TPS 50 的，你这样刚好反过来，是怎么调整性能测试方式，让 TPS 达到 50 。性能脚本只需要模拟真实压力场景即可，这样出来的才是真实性能指标。

PS：我一般看系统 TPS 值，看的是虚拟用户数维持在一个水平的情况下，同一时间 TPS 的值。基本不怎么看聚合报告里的平均 TPS 值。

Selenium 4 中的 IDE 不仅仅是一个基本的播放和记录测试工具。与 Firefox 一起，它可用于 Chrome 浏览器（作为 Chrome 扩展程序）。

这句话读起来怪怪的，是机翻？

第二个点认同。

这个我觉得这个看实际需要把，各有各的道理。如果很关注入库正确性，最好是查下数据库。

这个情况，可以用 存草稿 功能来保存。

1、你说的同步计时器，是 Synchronizing Timer 吗？
2、如果同步计时器，指的是上面这个控件，那这个场景只有 1 个请求，好像没有设置同步计时器的必要（单线程情况下，本身就是一个请求收到返回结束后，下一个请求才开始发出）。能否把完整的同步计时器配置发下？有尝试过去掉同步计时器吗？

是不是没写完？

不明白为什么仅一次控制器控制登陆接口无效

不知道你说的无效，指的是不是设置了仅一次控制器，但登陆接口并不是只被调用一次？如果是，我解释下，仅一次指的是每个线程里仅执行一次此动作，相当于 for 循环里，只有第一次循环执行，后续不再执行。与之对应的是默认每个线程循环执行所有动作，直到到达时间要求或者其他限制条件。

如果你有多个线程，实际就会不止执行一次了。如果要线程数量无关地只执行一次，类似方案二这样的方法会更合适。

有兴趣可以看下官方文档的说明：https://jmeter.apache.org/usermanual/component_reference.html?#Once_Only_Controller

一般来说 TPS 跟并发数有关

你这里的并发数指的是 Jmeter 的并发线程数吗？如果是，这个和我理解刚好相反，tps 和 Jmeter 的并发线程数无关，只会和应用服务性能有关。只是现象上如果并发数过小，会导致应用服务的各个线程并非持续处于负荷状态，所以计算出来的 tps 会比极限值小。“并发为 1” 和 “1 秒只有一辆车过” 是两个不同的概念，并发为 1，但服务器性能高，响应时间为 100ms，那 1 秒可以处理 10 个请求，一样可以产生 10TPS。