项目借人很正常，但是没有需求文档，对接人讲不清楚需求，那测试的最终输出是什么，总不能都是糊涂帐吧？还是要明确需求和目标，不然干活的人很心累。

接口异常，查具体接口的问题呗，我理解这个属于业务问题。

破案了。10M 的带宽理论传输速度是 1.25MB/s，再加上网络损耗，设备原因等影响，并发情况下 800 多 KB/s 也属于正常。可以判定为网络限制导致。

30 个并发 30 多秒。感觉是文件上传接口是单线程处理的，没有使用线程池。

我也差不多，基本上都是贴着简历问。主要还是看干活的能力，理解能力和沟通能力。不会我可以手把手教，但是你理解能力得跟上。

有两个时间的参数要设置的大一点，时间太短了可能没收到数据就报错了

看你是 WebSocket、gRPC、HTTP/2 哪种框架和协议了，需要依赖插件或自定义脚本

1、pytest-xdist
2、Jenkins 或 GitLab CI

年轻的时候在外打拼，年纪大了回老家。

打了一段经验之谈，读了一遍感觉太说教了，想想还是删掉了。个人感觉成长最快的一个方法：多揽活。

不太靠谱，性能测试更多需要的是实战经验积累（测试 + 分析 + 调优），大部分培训班只教你工具的使用，说到底性能测试还是得靠解决一个个问题积累，无法短期内有较大提升（业务 + 技术）。

压测的重点是被测接口，前期的请求只能算作数据准备阶段，数据准备的方式应该没有限制，能把数据完整模拟出来就行。

换个报告插件呗，目前在用 pytest-testreport，自己改了改源码，放到 Jenkins 里集成，还挺合适的。

依次递增请求参数，需要用到__V() 函数进行参数拼接， 参考：https://www.cnblogs.com/MyRecords/p/17982763

总结问题与经验，更新测试用例，测试方案，开座谈会交流，各种技能提升分享会。可以包括任何主题：比如自动化，性能，问题定位，业务知识，PPT 技巧。之前组内还有人分享摄影和美食，认真准备的情况下其实效果都不错。

在 Apache JMeter 中设置 7 个线程组和 1 个线程组的区别主要体现在以下几个方面：

1. 负载分布

7 个线程组：
每个线程组可以独立配置参数，如线程数、Ramp-Up 时间、循环次数等。
可以模拟不同类型的用户行为或不同的使用场景。例如，一个线程组可以模拟普通用户，另一个线程组可以模拟管理员用户。
更容易进行负载均衡和分布式测试，每个线程组可以独立地运行在不同的机器上。

1 个线程组：
所有虚拟用户共享相同的配置参数。
不适合模拟复杂的使用场景或多种类型的用户行为。
所有负载集中在一个线程组中，可能导致单点瓶颈。

2. 灵活性和可维护性

7 个线程组：
每个线程组可以独立配置和管理，便于维护和调整。
可以更灵活地添加或删除某些类型的测试，而不影响其他测试。
更容易调试和排查问题，因为每个线程组可以单独运行和分析。

1 个线程组：
配置较为简单，但灵活性较差。
修改一个测试场景可能会影响所有虚拟用户，增加了维护难度。
调试和排查问题时，需要处理整个测试计划中的所有请求，难以单独分析某一类请求。

3. 测试场景复杂度

7 个线程组：
可以创建复杂的测试场景，每个线程组模拟不同的业务流程或操作步骤。
更适合大规模、复杂系统的性能测试，可以细化到每种操作类型的性能评估。

1 个线程组：
适合简单、单一业务流程的性能测试。
不适合需要区分多种操作类型或用户行为的复杂系统。

在性能测试中，线程是模拟并发用户行为的关键概念，每个线程代表一个虚拟用户，可以同时执行一组操作，从而模拟多个用户同时访问系统的情景。
如果是前面没有性能测试积累，可以先做简单的单接口并发测试，像 “并发 5000 然后网关炸了” 这种情况就是单接口测试场景。
基于单接口测试的指标前提，可以设计出复杂的性能测试场景，比如 “系统可以支持 8w 在线用户”，不可能 8W 用户同时去请求同一个接口，可以按照一定的比例拆分去做不同的业务，比如有的用户去请求登录，有的用户去请求搜索，有的用户去请求提交订单，有的用户就什么都不做，这块可以参考系统功能模块使用情况分析。这样测试出来的性能指标才是真实有效的。

性能测试要注意的事项：
1.合理设置 Ramp-Up Period：确保系统有足够时间处理逐渐增加的负载，而不是瞬间启动所有线程。
2.使用定时器模拟真实用户行为：添加适当的延迟，以更贴近实际使用情况。
3.监控资源使用情况：在运行性能测试时，监控服务器和网络资源使用情况，以便识别瓶颈和优化点。
4.逐步增加负载进行压力测试：从小规模开始逐步增加负载，观察系统表现，避免突然施加过大压力导致系统崩溃。

如果你认为接口自动化就是请求一下 api 接口，断言一下返回值，那自然是没什么技术含量。基于现成工具来做接口自动化测试并没什么高不高级一说。接口自动化测试是一项复杂但非常重要的任务，其核心包括设计全面的测试用例、编写高效可靠的自动化脚本、管理不同环境下的数据和配置，以及集成到 CI/CD 管道中以确保持续交付质量。给你一个方向：尝试做一下持续集成，将接口自动化测试集成到 CI 管道中，确保每次代码变更后自动部署测试环境，自动运行测试脚本，并发送测试报告和错误日志，在这个过程中你会遇到各种各样的问题，尝试独立去解决这些问题，能力会成长非常快。

技术成长与业务沉淀并不冲突，基于业务场景解决问题打磨出来的技术更扎实。测试的最终出路并不只有走技术路线一条，转型产品经理成功的前辈数不胜数，对你而言可能是一个机遇。你都想到跳槽了，为什么不勇敢尝试一把，万一成功了呢？等到搞不下去了再跳槽也不迟。换一家公司不一定有这个机会给你尝试。

我说一下思路，你可以提取看看哪些是有用的。

一、测试环境统一

你提到三个项目功能都很复杂，且模块关联性很强，那想必维护环境，构造测试数据都是一个比较耗时的工作。不知道你们现在的测试环境是什么状态，是否有办法把三个项目的测试环境归一，这样有助于减少环境搭建，数据构造的时间。当然这里面会牵扯很多问题，比如产品的架构是否支持解耦，但是最简单的前后端分离应该是可做的吧。这个可以考虑下，但是如果太困难可以放弃。

二、人员合理分工

你们总共才三个项目，测试人员是 3 个人，那我的建议是每个人负责研究一个项目的系统业务，研究的过程中要有各种文档积累，包括但不限于业务流程图，数据流图，架构图，环境组网图，功能思维导图，然后三个人再开会互相讲，这样的好处是，每个人都可以同时熟悉三个系统，但是画流程图的那个人肯定是最熟悉的。发测的时候由熟悉的那个人来评估测试范围，排测试计划等。（熟悉系统的情况下，评估新需求范围和改动影响范围，估算工作量应该是不难的）

三、测试用例复用

【A 和 B 项目代码重合度非常高，项目基础部分 70% 共用。】

这样的话是不是可以提取通用功能，这一部分测试用例共用，那你写用例的时间又可以节省了。如果共用部分的代码是直接复用的话，那根据我上面的测试环境统一的前提下，共用功能只测试一次，不用重复测试了。

四、接口自动化

根据你的描述，A、B 两个项目的接口自动化可操作性和价值应该还是很大的。因为你们人少，可以先用一些现有的接口自动化工具来做，postman、apifox、MeterSphere、Jmeter 都可以，要是有代码能力，一两天时间搭个框架也是很简单的。接口自动化的重点是做回归测试，这样你们就有更多充足的时间测试新需求。

1.学历问题，这个问题很重要，目前好一点的岗位不缺人投，最低也要求统招本科。
2.做的项目很多，技术很全面。但是这是优点也是缺点，简历内容不够精炼，项目里面重复的东西太多了根本没时间仔细看，要根据投递公司的业务情况，针对性的把相关内容写详细，其他内容略写或不写。重点还是突出你在项目中承担的职责和重要产出。

首先压力机的网络出现瓶颈了，客户端线程阻塞，我理解你们视频的请求接口是不是长链接，服务端链接数增长会导致接口请求响应延长。当然具体原因要结合你们业务逻辑来分析。

并发数小的情况下，理论确实如此，但是你这个并发数好像已经很大了，已经达到压力机的性能边界。压力机成为瓶颈的话可以考虑分布式方式压测。

两台机器的下行带宽都满了，很奇怪你是什么业务需要这么大带宽？