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

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 等）几个维度来展开。结合简历上的项目经验来决定哪些点可以深入沟通。基本上我的选人标准就是，逻辑和沟通能力>测试基础>项目经历匹配度>自动化技术能力。

仅楼主可见

测试时间已经不够了，你还要去搞自动化，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 水平参差不齐，手工测试的时间还压缩一部分给自动化了，导致测试进度缓慢且产出低。在实际工作中跨行业（指的是完全无关的行业）跳槽的应该还是少数吧，比如我之前是做金融行业的，可能跳槽的时候会找相关的领域的企业，大概率不会去找一个做交换机的公司，这其实也印证了精业务的重要性。

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

人在郑州，我的建议是保持现状。

从你的描述来看，需要的是一个 PQA 的角色。

同意三楼四楼的意见。自动化虽然听起来很高级，但是并不适合你们团队的现状且不能解决问题。单就功能测试方面也有很多可做的东西，就比如测试左移，我认为就可以对你的现状有改善，测试更多的参与到需求分析，设计，编码阶段，负责做保障，提前提出不合理的需求和设计，将问题提前解决，这也是一种突破。

首先，你说的这种交叉测试是有必要的，保证组内不止一个人熟悉对应的功能模块。我们的解决方案是：每个产品/模块有一个专门的负责人，这个人会主要测试该产品/模块，但不一定在每个版本都负责测试该产品/模块，他会参与到该产品/模块新需求评审，负责相应用例的维护，业务流的梳理与面向组内共享培训。相当于给每个模块安了一个唯一责任人，他需要搜集平时该模块的发测版本，每个版本测试中的问题，及时修正补充，根据需要给其他组员定期分享该模块的业务（内容不限，可以是新的功能，新版本增加的用例，问题定位总结等）。测试中遇的问题需要向这个负责人请教，这样也能保证及时了解到版本测试以及漏测情况。

前司有自研的测试管理平台，所有测试计划，任务，用例执行，bug 管理都在上面完成，但是用例必须 excel 导入。大部分人平时喜欢用 xmind 写用例，所以用了 xmind2testcase 工具二次开发，生成可以导入的 excel，用起来还挺不错的。