涉及金额的，我们前端都只做试算，真正入账的金额都是在后端算。因为前端或者接口，都是很容易被伪造的。

PS：你的步骤里，没有收到鼠标移动的操作，所以他没有做 a-b=c 这个没太懂。鼠标移动操作这个没太看懂。

之前试用的时候，web 平台启动倒不复杂，但配套的 java agent 发现用不了，提示 class not found 。你有遇到不？

嗯嗯，我们大部分团队也是一个人一个测试集，一般一个迭代 1-2 个测试。但有些团队一个迭代有 6 个测试以上，所以需要共用测试集。

[Appium] Closing session, cause was 'New Command Timeout of 60 seconds expired. Try customizing the timeout using the 'newCommandTimeout' desired capability'

这条日志你看一下？里面写得很清晰了。

你用这个 url 看看，实际运行时 wda 的 fps 配置是多少？

http://<这里替换成你的 wda 地址>/session/<这里替换成你的 sessionId >/appium/settings

接口返回值大概是类似下面这样：

{
  "value" : {
    "screenshotOrientation" : "auto",
    "shouldUseCompactResponses" : true,
    "mjpegServerFramerate" : 30,
    "snapshotMaxDepth" : 50,
    "activeAppDetectionPoint" : "64.00,64.00",
    "acceptAlertButtonSelector" : "",
    "snapshotTimeout" : 15,
    "elementResponseAttributes" : "type,label",
    "keyboardPrediction" : 0,
    "screenshotQuality" : 1,
    "keyboardAutocorrection" : 0,
    "useFirstMatch" : false,
    "reduceMotion" : false,
    "defaultActiveApplication" : "auto",
    "mjpegScalingFactor" : 100,
    "mjpegServerScreenshotQuality" : 25,
    "dismissAlertButtonSelector" : "",
    "includeNonModalElements" : false
  },
  "sessionId" : "1053FDC1-77AC-4674-A0BF-04C7C1605098"
}

上面这个值里的 mjpegServerFramerate 就是实际使用的最高帧率。

我目前的改法，是直接改 atx 源码，建立 session 后，发一个请求去修改帧率的，默认好像是 15。实践中修改为 30，感受上会比较流畅，大部分时间帧率会在 25-30 之间。改为 60，实际受限于 wda 性能，也到不了 60 的，反而可能因为帧率不稳定感觉卡卡的。具体改动的 diff 截图发你参考下

对于运行速度这个，感觉 selenium 也不慢。有相同操作下两者运行速度差异的对比数据吗？

我觉得学一下倒无妨，留个印象，有时候广度就是这么来的，随性舒服，比如看到一个技术点感兴趣，就会花点时间去找下相关的材料，了解清楚背后大致的原理什么的。只是我一般会限制自己学习时间，比如设置个 20 分钟倒计时，到点就停响起闹钟停止探究，避免耽误正事。

真正要深入的技能，还是建议在工作中去试用，并尽可能争取到资源去落地应用，这样才能深入。毕竟工作时间有 8 小时以上，投入时间足够多，而且一旦立项也会有各种监督保障你不会半途而废，这样会比自己一直只是自学要来的高效靠谱。

会不会遇到后端改了自己代码，但没改文档里面的参数，导致文档落后于代码？这个实践中是通过什么方法来保障同步呢？

个人之前用的大多是类似 swagger 这类从代码生成文档的工具，这样一致性保障可以程序全自动完成，避免人为疏忽遗漏。也想交流了解下看这类通过文档生成代码的，在这个方面具体是怎么保障的。

好奇问一个点，这里面提到的最佳实践里，好像没提到 "你这接口参数怎么又变了？" 的解决方案？这个应该是前后端并行开发最容易遇到的问题了。

这个是幸存者偏差吧。

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

西安暂时没计划。

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

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 分钟左右达到了一个相对稳定的值，只能理解为系统有自动降级措施，直接放弃处理请求直接返回了，所以响应时间没有继续涨。

感谢支持