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

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

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

一、测试环境统一

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

二、人员合理分工

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

三、测试用例复用

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

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

四、接口自动化

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

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

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

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

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

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

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

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

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 年白干，但是也没办法。减轻负债，轻装上路吧。

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

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

喜欢这种内容的帖子