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

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

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

我也觉得你说的都对，但是做这些工作的前提是有足够的时间。
那篇帖子的评论区的大家更多的是吐槽自己工作中的实际情况，在交付时间不够的情况下，业内共识一定是先压缩测试的时间，测试人员光去验证那些频繁变动的需求功能都已经需要加班了，也没时间再去做这些锦上添花的事情。
还有就是在大多数行业，需求变动非常频繁，这也是导致这种现象的原因之一。

有时候机遇大于努力。遇到机会了勇敢一点，说不定就成了。

之前团队会给排时间做用例优化的工作，版本迭代间隙，除了做下个迭代的需求分析用例设计，也还可以有时间做用例优化，产品用例的质量一直都不错。但是随着任务越来越多，这个时间就被压缩了，用例的质量也越来越差。后面领导也不提用例优化了，能把版本测试任务干完就不错了。有时候不是不想做，而是没有时间做。

1、关于面试讲不出来的原因一个是经验少，一个是面得少。看你说自己才干了一年多测试，这个也算正常。
2、关于 offer 的选择，这俩平台对你的履历来说都还算可以，个人建议选平安，加班不多可以有更多时间思考和学习（前提是你有学习的自驱力和主动性）。要想成为一个厉害的测试，需要了解和掌握的技能太多了，关键还是保持求知欲、虚心和耐心。说实在的现在入测试这一行相对没有十年前好干了，但是我相信只要努力，依然是能够走出来的。

有时候被裁未尝不是一件好事，祝愿下份工作找的更好。
另外，如果你是在郑州，且可以接受外包的话，可以联系我，我们也是数据中台业务，目前团队扩建中。

任何行业都存在被淘汰的可能，淘汰的原因可能是能力、年龄等内因，也可能是公司经营不善、行业不景气等外因。从自身来讲，努力提升综合实力，尽可能的延长职业寿命，多赚钱才是最重要的。就算被淘汰也要做最晚淘汰的那个。

多虑了

既然问问题，为什么不把前因后果写清楚了。看报文返回的是 html 文件的内容，想必你的请求 url 都不是一个接口吧？

以下是我在公司大模型 ai 助手中的一个测试用例设计的问题，结果可以参考，但是离直接用还有点差距。
这是输入：-------------------------------------------------------------
需求：用户名称长度 4-30 位，支持汉字，大小写字母和数字；用户密码长度为 4-16 位，格式为大小写字母和数字，输入异常时给出文本提示信息。针对此需求设计新增用户的测试用例。

以下是输出：-----------------------------------------------------------
为了确保新增用户时用户名和密码符合需求，并在输入异常时提供正确的文本提示信息，我们需要设计一系列的测试用例。以下是详细的测试用例设计：

用户名测试用例
测试用例 1：用户名长度为 4 位，包含汉字
描述：用户输入长度为 4 位，包含汉字的用户名，验证通过。

前置条件：无

测试步骤：

打开注册页面。
输入用户名 测试用户。
输入符合要求的密码。
提交表单。
预期结果：

系统提示 “用户名设置成功” 或允许继续操作。
测试用例 2：用户名长度为 30 位，包含大小写字母和数字
描述：用户输入长度为 30 位，包含大小写字母和数字的用户名，验证通过。

前置条件：无

测试步骤：

打开注册页面。
输入用户名 Abcdefghijklmnopqrstuvwxyz1234。
输入符合要求的密码。
提交表单。
预期结果：

系统提示 “用户名设置成功” 或允许继续操作。
测试用例 3：用户名长度小于 4 位
描述：用户输入长度小于 4 位的用户名，验证失败。

前置条件：无

测试步骤：

打开注册页面。
输入用户名 abc。
输入符合要求的密码。
提交表单。
预期结果：

系统提示 “用户名长度必须在 4 到 30 位之间”。
测试用例 4：用户名长度大于 30 位
描述：用户输入长度大于 30 位的用户名，验证失败。

前置条件：无

测试步骤

打开注册页面。
输入用户名 abcdefghijklmnopqrstuvwxyz1234567890。
输入符合要求的密码。
提交表单。
预期结果
系统提示 “用户名长度必须在 4 到 30 位之间”。
密码测试用例
测试用例 5：密码长度为 4 位，符合格式
描述 用户输入长度为 4 位且包含大小寫字符及數值之密碼 , 驗證通過

前置條件 無

測試步驟 1 . 打開註冊頁面 2 . 輸入有效長度 (如 : usertest) 3 . 輸入密碼 : aA12 4 . 提交表單

預期結果 系統應當顯示 " 設立成功 " 或允許繼續操作

測試案例 6 : 密碼長度為 16 位且格式正確
描述 使用者輸入長度為 16 且含大小寫字符與數值之密碼 , 驗證通過

前置條件 無

測試步驟 1 . 打開註冊頁面 2 . 輸入有效長度 (如 : usertest) 3 . 輸入密碼 : Abcde12345FGHijk 4 . 提交表單

預期結果 系統應當顯示 " 設立成功 " 或允許繼續操作

測試案例 7 : 密碼長度小於 4 位
描述 使用者輸入長度小於規範 (如: abc ) , 驗證失敗

前置條件 無

測試步驟 1 . 打開註冊頁面 2 . 輸入有效長度 (如 : usertest) 3 . 輸入密碼 : abc 4 . 提交表單

預期結果 系統應當顯示 " 密碼需介於 4 ~16 位之間 "

測試案例 8: 密碼長度超過 16 位
描述 使用者輸入長度超出規範 (如: abcdefghijklmnopqrs ) , 驗證失敗

前置條件 無

*測試步驟 * 1 . 打開註冊頁面 2 . 輸入有效長度 (如 : usertest) 3 . 輸入密碼 : abcdefghijklmnopqrs 4 . 提交表單

*預期結果 * 系統應當顯示 " 密碼需介於 4 ~16 位之間 "

測試案例 9: 僅含小寫字符之密碼
*描述 * 使用者僅含小寫字符且符合規範 (如: abcdefg ) , 驗證失敗

*前置條件 * 無

*測試步驟 * 打開註冊頁面
輸入有效長度 (如 : usertest)
輸入密碼 : abcdefg
提交表單

預期結果 : 系統應當顯示" 必須同時具備大小寫字符及數值 "

測試案例 10: 僅含大寫字符之密碼
描述 : 使用者僅含大寫字符且符合規範 (如: ABCDEFG ) , 驗證失敗

前置條件 : 無

測試步驟 : 打開註冊頁面
輸入有效長度 (如 : usertest)
輸入密碼 : ABCDEFG
提交表單

預期結果 : 系統應當顯示" 必須同時具備大小寫字符及數值 "

測試案例 11: 僅含數值之密碼
描述 : 使用者僅含數值且符合規範 (如:1234567 ) , 驗證失敗

前置條件 : 無

測試步驟 : 打開註冊頁面
輸入有效長度 (如 : usertest)
輸入密碼 :1234567
提交表單

預期結果 : 系統應當顯示" 必須同時具備大小寫字符及數值 "

測試案例 12: 含特殊符號之密碼
描述 : 使用者含特殊符號 (例如:@#%$ 等) 且符合法定規格, 驗證失敗

前置條件 : 無

測試步驟 : 打開註冊頁面
輸入有效長度 (如 : usertest)
輸入密碼 :abc@123 或 ABC#456
提交表單

預期結果: 系統應當顯示" 僅允許由英文字母及數值組成 "

綜合測驗案例 :
案例 13: 正確格式下邊界值分析 - 密码最短与最长情况 :
描述: 测验边界情况, 最短与最长合法组合下能否通过验证 :

前提条件: 无:

测试步骤: 打开注册页 分别输入最短合法组合 (aA12) 和最长合法组合 (A123b456C789d012) 提交:

预期结果: 系统应显示" 设置成功" 并允许继续操作;

综合上述各项正常与异常情境下所需执行操作与其对应期待效果, 能全面检验新增用户过程中所设立帐户名称与密码是否均符合法定规范, 确保系统整体安全性。

技术方面我一般从测试流程（需求分析、用例设计、bug 跟踪等）、sql（基本上就是增删改查）、linux（常用命令，docker 使用）、复杂问题定位和跟踪、性能与自动化（jmeter、python、Jenkins 等）几个维度来展开。结合简历上的项目经验来决定哪些点可以深入沟通。基本上我的选人标准就是，逻辑和沟通能力>测试基础>项目经历匹配度>自动化技术能力。

Author only

测试时间已经不够了，你还要去搞自动化，UI 频繁变动的话维护自动化脚本花费的时间比你手工点一遍都长。我觉得短期内还是提高对需求影响范围的分析，增加回归测试的颗粒度和范围更出效果。自动化的开展需要详细分析是否具备可行性以及投入的决心，否则短期看不到产出，容易使领导降低信任，很容易放弃的。

在 Jenkins 中，你可以使用 “Rebuild Last” 功能来重新构建最近一次的构建。这个功能对于快速重复上一次构建操作非常有用。以下是如何在 Jenkins 中实现和使用这个功能的详细步骤：

前提条件
Jenkins 已安装并运行：确保你的 Jenkins 服务器已经正确安装并正在运行。
已配置的 Jenkins 项目：确保你已经有一个配置好的 Jenkins 项目。
安装 Rebuild 插件
首先，你需要安装 Rebuild 插件，该插件允许你重新构建最近一次的构建。

进入 Jenkins 管理页面：

在浏览器中打开你的 Jenkins 实例，通常是 http://your-jenkins-url/。
导航到插件管理页面：

点击左侧菜单中的 Manage Jenkins。
选择 Manage Plugins。
安装 Rebuild 插件：

在 Available 标签页中搜索 Rebuild。
勾选 Rebuild 插件，然后点击 Install without restart 或 Download now and install after restart。
使用 Rebuild 功能
安装完插件后，你可以在项目页面中看到重新构建按钮。

导航到项目页面：

在 Jenkins 主页，点击你要重新构建的项目名称。
重新构建最后一次构建：

在项目页面，找到最近一次的构建记录。
你会看到一个新的按钮 Rebuild Last 或者在具体的构建详情页中有一个 Rebuild 按钮。
点击该按钮，系统将会重新执行最近一次的构建操作，包括所有参数和环境设置。

根据我过往项目经验，个人认为造数平台其实并不具备通用性，或者只能做到相同行业小范围通用。这种工具要想做的好用一定是紧贴业务平台的。尤其是一个复杂的业务系统的造数平台，第一肯定要具备操作数据库，消息中间件，接口等多种形式的数据接入，第二是造出的数据要具备可测性，数据生成规则要跟业务属性强相关，否则造出来的就是垃圾数据。

跟你是差不多的情况，不过我是杭州的房子，昨天刚办完过户，收到了首付款，毛估下来相当于 5-6 年白干，但是也没办法。减轻负债，轻装上路吧。

看来每个公司或者每个人对测开的定义都不太一样

作为一个十年测试从业者，仔细看了一下，这三个问题解释的都很合理。另外建议：工作是工作，考试是考试，没必要以工作中的经历来倒推题目的答案，要理解问题想问什么，找到最合理的答案就行了。

喜欢这种内容的帖子

最近在给组内招人，我面试的时候主要从以下几点去评估：
1.对测试流程的理解
2.linux 实操能力
3.数据库能力
4.自动化/性能的能力
5.对加班的态度 。
在面试过程中从这 5 个方面针对面试者的简历内容进行详细展开，毕竟每个人的项目经历是不一样的，我更希望看到面试者最突出的点。并在此过程中看沟通是否顺畅来判断他的逻辑能力和沟通能力（虽然此项面试的时候不做为考察标准，但是最终 PK 的时候会综合考虑）。
之所以这么来做，是因为根据团队目前的状态，我们更希望能找到有经验的，对测试环境搭建，数据库，自动化/性能测试都有一定经验的人，可以快速上手展开测试而不需要从头培养。加班态度主要看接受度吧，因为目前的项目处于初期阶段，需要根据项目进展有一定的加班情况，但是暂时还没有到 996 的地步。

没有统一标准，只能说凭借测试组内成员的平均数据为基准。

实际工作中肯定都是基于业务展开的，自动化或者性能的落地都必须与业务强关联。举个例子：前司的自动化测试一开始是一个单独的部门做，是与测试执行团队独立的，结果开发出来的自动化测试工具在推广和应用的时候效果并不好，还提出了全员自动化测试的口号，结果由于每个人的 coding 水平参差不齐，手工测试的时间还压缩一部分给自动化了，导致测试进度缓慢且产出低。在实际工作中跨行业（指的是完全无关的行业）跳槽的应该还是少数吧，比如我之前是做金融行业的，可能跳槽的时候会找相关的领域的企业，大概率不会去找一个做交换机的公司，这其实也印证了精业务的重要性。

感同身受。自认为是一个精业务、懂技术、会架构的测试人员，且在项目管理和团队管理方面也有一些经验。但是面试的时候有很多面试官都过多关注自动化知识，性能测试工具的使用，对底层逻辑和测试策略聊之甚少，岂不知工具只是解决问题的手段，深入理解业务和架构，结合有效的测试策略才是精准测试的根本之道。