好文采！

从堆栈上看，全是 pycharm 内部的报错。

卸载掉现在的 pycharm ，重新装一下试试？

看这哥们在 4 楼回复的意思，不是录制后运行录制出来的脚本报错，而是录制过程中 web 页面操作时，由于多了个 jmeter 代理上传功能不正常。

你说的问题，是从最后一张图框里的报错么？

报错信息直译过来是：

ValueError: buildins.type 大小改变了，可能表示二进制文件不兼容。从 C header 读取到的预期值 888 ，但 PyObject 提供的实际值是 880

从报错信息看，应该和你执行代码没啥关系，网上搜了下 may indicate binary incompatibility， 大多是说和 numpy 库版本有关，重装依赖可以解决。
你截图里堆栈信息不全，所以也看不出到底和啥有关。你把堆栈信息文字直接贴上来吧，不要只是截图。

你查看下我发你的链接吧，里面有具体操作文档。

我自己也没操作过，所以没法说，得你自己尝试了。

不过如果你实际被压服务所在的系统如果并不是 windows ，这个问题其实没啥解决的必要，你直接到你实际压测环境部署确认更好。

1、如果测试人员拿不准请求的是哪个服务器，那就想办法去确认。不管谁维护的，问环境维护人员，这类信息都可以得到。
2、就算有多个服务器，也一样可以监控的，专业点的运维会在 grafana 里设组，把同服务的多个节点监控数据聚合到一个视图里，方便直观查看每个节点的情况。

总而言之，做性能测试，是必须了解清楚你压的是什么服务、服务部署在什么机器上、怎么获取这台机器上的系统资源等相关监控数据的。如果这些不清楚，就去问负责这部分内容的同学，问清楚。监控平台如果目前确实没有现成可用的（很多时候测试环境确实不会弄监控平台，线上才会弄），那就自己搭/自己找同学协助搭。重要的不是谁去做，而是要去做。

PS：“全链路监控” 这个词你在这里用得不大对，全链路监控核心关注的是全链路，是请求到了服务端后，内部会经过 a 服务->b 服务->c 服务 多个服务才能完成处理的这种链路，关注的是一个请求在这个链路里面每个服务处理部分的耗时情况，进而方便针对性优化对应的服务。单个服务多节点部署，并监控多个节点的资源消耗情况，这个和 “链路” 没啥关系。

我是先学接口测试，搞清楚接口测试要测什么才对，然后初期先用 Postman 测，熟练后再找趁手的平台框架将它写成自动化用例的。

至于自动化平台开发，暂时我们调研后觉得没必要重复造轮子，所以最后用的是 ms ，在它基础上做一些二次开发以便支持内部特有的协议。

如果是想学习怎么写一个平台，建议你看那些怎么一步一步设计和开发测试平台的文章，而不是找接口自动化的，因为这部分知识相比接口自动化，更偏向平台开发。这类文章我目前比较多是在一些测开公众号里见到，大多是系列文章，你可以在微信里找找。

我之前没怎么看书哦，主要靠自学以及和其他有经验的同学交流。所以书这方面暂时没有特别好的推荐。

可以再细化下，你对学习资料的期望具体是什么？一个 “接口自动化” 有点笼统，你要学习的是用例设计，还是自动化框架/平台使用，还是自动化框架/平台设计，还是具体实践案例？

这个只是一个表象。需要进一步排查下：

1、作为处理逻辑起点的浏览器，开发者选项-network 里显示是否有发出上传请求？有的话请求结果是什么？
2、作为处理逻辑中间点的 http 代理，Jmeter 录制代理里这个上传附件的请求数据有录制到么？从录制信息看是否有什么异常？
3、作为处理逻辑终点的服务端，有收到上传的附件吗？（可以看下有没有日志打印，有的话通过日志查看是比较方便的）

需要有这些信息，才能进一步排查定位问题，进而找到解决方案。

非常详尽的问题描述，点赞！

关于问题 2，google 了下，找到一个相对靠谱的结果：https://stackoverflow.com/questions/59528198/jmeter-perfmon-exception-access-violation

大致意思可能由于 windows 里面的性能计数器没有打开，导致 perfmon 插件获取不到数据。看你日志末尾系统信息里写的是 windows 11 ，版本比较新，也可能是兼容性问题。

PS：监控系统资源可以先问下运维对服务器本身有没有什么监控，有的话直接用运维提供的会更方便。

这里其实也可以作为一个技术方案的评审点，对于实时性要求高的，直接用实时通讯方案（如 http ）比消息队列要合适。

个人理解，消息队列本身作用之一，就是可以作为压力的缓冲，让上层短时间高流量以消息积压的方式存在消息队列里，避免下游系统也受到这么高压力一下子被击垮。所以消息堆积只要控制在一定范围内，是可以接受的。然后队列里的积压消息数需要作为一个预警项，当积压数达到一定程度时，人工去确认原因，然后采用适当的手段（如对消费者进行扩容增加消费速度、生产者相关功能暂时关闭或降级）进行处理。

社区 wiki 上有一个接口测试白皮书：https://testerhome.com/wiki/apitest
然后极客时间也有一些相关课程，京东上搜 接口测试 也有不少相关书籍。

至于交流群，进群不多，不大知道有啥群是专门交流接口测试且相对不水的。实在找不到，上来社区发帖交流也是可以的。

如果不能解决实际的问题，你的代码能力就没什么值的炫耀的

为这句点赞。

我个人并不反对造轮子，造轮子本身是一个很有效的学习方式，毕竟你自己去实现一个轮子，考虑的东西会比光看别人的代码更全面，也能更深入了解这个领域的整体知识。而且只要造出来的轮子确实比开源的好用、更符合公司团队需要，那就造起来。

不一定要很深入，其实微服务刚出来的时候，很多这类微服务技术特点科普文的，看个两三篇，微服务相关的核心技术知识就了解得差不多了。

当然，也要看实际业务情况。如果线上经常高压力的话，那熔断限流之类的还是得去模拟环境做预案演练，确认符合预期。只是从面试层面和大部分实际场景，一般了解知识点和大致原理，就差不多了。

那确实可能不同公司情况不一样。

客户端和服务端有些概念是有点差异的，可能你了解了 monkey 测试本质是啥后，应该不会有这么多问题。

常规的 monkey 测试本质上就是随机测试，通过发送随机事件流给应用，这些随机事件流基本可以认为是乱来的（像猴子一样乱点，所以叫 monkey 测试），会有一定的概率会命中某些藏得比较深的崩溃隐患。服务端相对比较接近的概念我理解应该是模糊测试（Fuzz），通过给出各种随机的输入数据，查看系统是否可正常响应，会不会出安全问题。

现在有些更智能点的，不是随机事件，而是识别界面元素后，能点的按钮尽量点，并记录下每个页面，尽可能把每个 app 能点的按钮点一遍，能进的页面进一遍。这种一般也称为智能 monkey 或者叫自动遍历，用处是低成本发现一些 app 可能存在的某些页面进不去/按钮点了会出问题的情况。

但这两类本质上和服务端高并发不一样，其实都不会给 app 带来 “压力”，而且 app 天然就是单人操作的，所以使用场景本身也没有太多类似服务端用户量增加带来的系统资源不足的压力。之所以会有人称为压力，是因为常规 monkey 的随机事件流发送速度可以比人工点击快很多，而这个高速度可以让某些可能引起内存泄漏的操作效果放大，快速发现内存泄漏类问题（内存占用量一旦达到系统最大限制，会直接被系统 Kill 掉，这也是崩溃的一种，所以通过监控崩溃也可以捕获到这类问题）。这点和服务端压力测试会比较接近。

当然，app 也有自己的专项性能测试，这类测试是要监控性能数据的（常见指标包括内存、cpu、网络流量、FPS 流畅度、耗电量等），但这类一般很少用 monkey 或者遍历来做，因为这两类测试都偏随机，无法满足常规性能测试里 “固定模拟场景” 这个需要。

不至于吧，有经验的开发这些除了性能测试可能平时弄得少一些外，其他应该都会，而且熟练程度比测试要高（毕竟天天写）。

服务端 2 年什么水平，我也不大清楚，只能说我觉得一个好的服务端测试，大概需要下面这些技能吧：

1、清晰了解接口背后的逻辑流转，有需要随时可以写出核心流程的时序图，并基于这个逻辑流转评估技术方案优劣及风险、设计对应的高效测试方案。
2、可以做一些服务端相关的专项测试，比如性能测试。注意不只是能执行和反馈性能数据，还得能通过各种监控日志等定位到性能问题原因以及给出靠谱的建议解决方案。
3、对服务端用到的技术有一定了解，比如 spring 、各种中间件（redis、数据库、消息队列）、jvm 一些基本配置、服务端一些相关的术语或者说架构知识（熔断、限流、降级、CAS）等，如果自己直接就具备相关的写代码实现功能能力最佳。
4、熟练使用 linux 命令，毕竟有需要的话经常得上服务器查看日志等操作。

技术范畴的防范，楼上已经很精辟了。

稍微补充一个点，除了系统发布相关配置外，还有不少故障来自于运营/产品在后台不合理配置造成，这类问题有些时候通过技术手段很难防范（很可能发现问题时已经造成一定损失了）。鉴于运营产品人员流动性比较大，且后台系统有一定复杂度，让大家都熟悉系统成本很高，所以我们这边的做法是：配置调整流程里，加多一个 QA 把关环节。

重大活动调整配置，运营/产品在预发环境配置完毕后，提交给 QA 进行二次检查确认，确认后再到线上配置。

我觉得楼主有点走偏了，数据准确性测试不应该只关注结果，还要关注计算过程吧？

对于展示结果的测试方式，楼上已经说得很清晰了。不过从完整性角度，还得看计算过程。比如金融类业务，计算过程用浮点数直接计算会造成不准确（浮点数本身的特性导致，必须更换为专门的高精度计算库进行计算）、数据库存储金额单位有差异没有做合理转换（比如有的字段单位是分，有的字段单位是元，有的字段保留 2 位小数，有的字段保留 5 位小数等）。这些都是测试数据准确性需要关注的。

二次开发不见得必须全栈，取决于你要二次开发啥。而且二次开发一般难度相比从零创造低很多，不见得必须一上来就全栈。

也不用一上来就整二次开发，你先部署用起来，项目里用了后，有需要再二次开发就好啦。一上来就直接做纯平台/工具开发项目，容易导致你陷入各种技术细节而忽略了测开最关键技能——发现并解决效率问题。

可以尝试下这几个方面：
1、现在测试的项目，有做了 Jenkins 打包 + 部署，让测试/开发都能一键操作了吗？如果没有，那这就是你的机会，去学习下 jenkins 怎么用，应用是怎么打包和部署的，把这个搞起来。
2、现有测试项目，会不会存在很多场景的数据很难找/模拟的情况？如果有，那也是你的机会，搞点 sql/python 脚本啥的帮助自己找/造数据，提高效率。
3、项目里会不会有大量的重复回归测试工作？如果有，去看下做什么自动化性价比高，这类型自动化有什么平台/工具自己试用后觉得适合，然后拿过来内部部署用起来。

一般面试时看测开的经验，更多看的是你在自家项目上有没有做起来一些测开相关的工作并获得一些成果，其次才是这些工作里面技术含量和技术水平情况。如果你最熟悉的公司项目你都折腾不出什么成果，怎么相信你来到新公司的新项目会发挥测开的作用？

项目这个，在你现在公司的项目里，针对一些工作效率低的地方，先从脚本写起，再根据需要逐步扩展和让更多人用上，产生价值，这就是起步了。只要这个价值能获得老大的认可，允许你投入更多时间做这些提升效率而非单纯测试项目的事情上，测试技术难关交给你去攻关，那你做的已经是测开的活了。

别人问有没有什么自己做的工具平台什么的，但我想很多平台都是开源的，自己部署下就好了，需要测开做什么呢？

关于这点，测开要做的还真不是单纯部署（当然部署肯定是第一步）。开源工具平台设计都是通用型的，但实际情况往往千差万别，很多时候都需要二次开发去优化里面的一些功能满足自己公司情况的需要，这些二次开发能力也是测开需要具备的。

没用过，帮顶下

没有理睬是指没有人邀约你面试？

如果是，可能和你简历内容有关。可以把你简历里你觉得比较亮点的东西摘出来看看不？

actor 异步 IO 模型，是类似 Gatling 用的并发模型么？