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

关于问题 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 用的并发模型么？

国际化和本地化这方面的测试，我理解一般不怎么需要特意用 selenium 做自动化吧？毕竟大部分情况下，国际化和本地化大部分情况下并不会动到背后的处理逻辑，更多调整的会集中在展示方面的内容。

渲染是否正确这些，毕竟不是 selenium 自动化的强项。可以辅助用于快速遍历客户端界面，但判断是否正确可能人直接看，或者借助机器学习算法做一些自动判定的独立程序，可能效果更佳。

额，这个问题有点伸手了。。。我搜索引擎找了下，前几个结果应该都能满足你，你看下有没有合适的吧。

https://cn.bing.com/search?q=DB2%2F400+python&form=QBLH&sp=-1&pq=db2%2F400+py&sc=0-10&qs=n&sk=&cvid=287DC452D34541E9A19067917472D04A

如果你已经尝试了里面某些方法，遇到困难卡住的话，建议直接说明你的尝试和卡住的位置。

列一下你们已有的解决方案有哪些，以及这些解决方案后面会用于什么？

我理解只要能体现是属于开发方面的原因，他们需要优化，就行了。说实话，都属于比较低级的人为操作错误。

感觉你们聊的不是一个维度。。。

bug 指代的是结果。程序运行输出结果不符合预期称为 bug
而你前面列的 1-4 和开发说的 “外部原因” 都是在说原因，是指出现这个结果背后的原因。

bug 可以是外部原因造成的，两者不冲突。你想说的冲突，是不是测试认为这些属于开发人为操作失误导致，开发需要改进；而开发说是外部原因，即认为开发不需要改进？

底层貌似是基于 mobileperf ，目前貌似是只支持安卓。但楼主问的就是 android ，应该也够用。

我们内部有做了一个类似的取代 perfdog 的性能采集工具，支持 android + ios ，并打包成了独立的客户端应用可以开箱即用，但暂时没法开放。ios 的性能数据采集，可以考虑基于 tidevice 之类的逆向 instruments 协议获取性能数据的工具来做。

官方仓库里好像有打 docker 镜像相关的命令在了：

https://github.com/metersphere/metersphere/blob/dev/Jenkinsfile

具体是卡在哪里了，可以给点错误日志或者详细的操作步骤？

可以看下这个：http://testerhome.com/opensource_projects/solox-apm-tool

哈哈，客气拉。这些其实都是很常见的问题，基本都有经历过，相互交流。

其他的功能测试本身也没什么好的办法优化效率，排除没有发现的摸鱼情况之外，也就只有堆人和加班两条路了

这个不知道你是否有深入去分析过？说实话，要缩短测试周期，从你作为测试团队 leader 的位置来说，最有效的手段还是想办法缩短测试自己花费的耗时，因为只有这个范围内的事情你是有比较强掌控能力的。方式包括我前面提到的优先投入到高优先级需求、分析现在测试排期是否合理有没有优化空间、用到的一些测试方法是否是最高效的等。功能测试提高效率的方法很多，写造数脚本缩短造数时间、根据实际质量要求情况舍弃部分操作成本很高的异常场景用例等，你说的这种不涉及逻辑的调整直接免测也是一种。

其次是控制你的准入，比如前面提到的提测质量，这个关守好，也可以减少很多非常影响测试进度的阻塞类问题。不过这个涉及和开发的协作，相对不如上面说的把控性强。

另外，这些非测试内部引起的阻塞测试进度的问题，实际占据测试周期中多少时间，可以大概统计下。在 15% 内应该都算正常，超出的话看下最慢的是哪类问题，让下面的同学再出现的话多久没解决直接上升给你去推动。

其实是一个 “尽快开始测试” 和 “优先结束测试” 的抉择。但不管是优先结束，还是优先进入，都不会缩短项目整体的周期，只是让测试开始到测试结束看起来变短了。

额，这个倒不是优先进入还是优先结束的问题，而是办事方法的问题。测试资源大部分情况下是稀缺的（相比开发资源），有限的时间内只能做有限的事情，那最好是做优先级高的。领导关注的、对业务影响比较大的，也主要是优先级高的事情，优先级不高的，一般引不起关注（领导的时间精力也很有限），就算产品找过来，说明是由于资源优先给了高优先级需求，一般也说得过去。况且这里面也有一些其实就算出问题也风险不大的，评估改动范围后直接让开发自测 + 产品验收也并不是不可以，这样总工作量也有所减少。

同时产品内部也有竞争，同时进行的关键需求也不在少数

不知道你们现在开发测试比大概多少，但如果测试人员数量真的连关键需求都 cover 不住，那就想办法找领导加人吧。

楼主说的这种情况，其实还是很常见的。

不过楼主的思维有点陷入了 “为测试慢找阻塞进度的原因” 这样的方向了，这个其实很危险。因为这个方向找下去，会发现找到越来越多其他人的问题（因为别人才会 “卡” 住你，你自己怎么可能卡住你自己呢？），而这些问题其实都是很难解决的，它的处理超出楼主自己管理范围。同时，在领导参加的周会上直接说其他团队没做好影响到测试效率，不知道楼主有没有提前把这些复盘内容提前和兄弟团队的 leader 沟通？如果没有，那相当于背刺兄弟团队，这个很危险。。。

我说下如果是我，可能会怎么做，仅供参考：

1、先了解下从领导的角度，为何会觉得测试慢，领导觉得应该是多久，为什么，然后说明下实际情况和领导想的理想情况差异是什么，针对这个差距自己目前在进行的优化计划是什么，让领导对这个问题有清晰且全面的了解。这时候如果领导能理解认同，就没必要花时间精力搞报告了，因为首要目标是扭转领导的这个印象，避免领导觉得测试单方面拖后腿。

2、如果领导不认可，或者要求需要报告证明，那就出报告。但在给领导前，会私底下先和兄弟团队聊，让兄弟团队了解自己难处，也了解兄弟团队的难处，两边一起合计怎么一起优化这个事情（甚至借汇报机会找领导帮忙解决，比如需求太多人手不足的问题，核心是要让兄弟团队感受到是同一战线的），再写进报告里。这样周会上汇报，兄弟团队也可以立即接上这个问题已经在优化中。

另外，楼主上面说的都是其他团队的问题，不知道有没有总结测试自身的问题？建议先集中精力优化自己掌控范围内的问题，产生成效。比如 “目前只能一个人负责一个需求的测试工作” ，这里其实本身就有问题。需求是有轻重缓急之分的，不能一人一个。关键需求（直白点说就是领导都很关注的需求）就优先集中资源优先完成，非关键需求可以按正常排资源测试，或者风险不大的，让开发演示场景测试结果后直接上线（类似免测）。