一句话： 关你嗨事咩

别把找到工作===技术能力水平
除了自身学历学校这种硬性条件，其他还是看你自身的推销能力
面试 30 分钟其实是看不出你有多少东西的，无非就是看你会不会营造自己有东西的感觉
别太纠结于简历上的技术栈自己会不会，全力复习面试问题就行，把简历发给 ai，然后让 ai 去提有深度的问题
你可以加上自己从 0 到搭建某一系统的自动化（有没有都没关系），问题你能回答出来就行，【面试是纯主观的，看的就是个人喜好】，不是高考这种选拔性考试。你自己意会一下。

找工作不要太老实，也不要有什么愧疚心理，要跟渣男一样，广撒网，有鱼上钩就行，只求进入公司但是不放在心里

我这里提一个很普遍且很简单的场景，一个非常经典、简单的小 BUG，应该符合楼主打标的标准

bug 背景：

• 标题：注册页 - 用户名输入框超过 20 字符时，前端未正确截断，导致提交后后端报错
• 步骤：
  • 1.进入游客页的注册页（url="https://testerhome.com/addUser"）
  • 2.在用户名输入框中输入超过 20 个字符
  • 3.观察到前端未有长度提示限制、无截断操作、能发起提交
• 预期：输入框应自动限制和提醒用户最多只能输入 20 个字符

如何解决接下来的这些麻烦：
1“进入注册页”

• 这个注册页如果需要先登录才能访问？AI 如何获取有效的测试账号和密码？是要在 bug 单里写上测试帐号和密码？还是在配置文件里加上通用的测试帐号和密码？

• 出于安全合规的要求，测试账号都需要区分环境（开发 / 测试 / 预发）、定期轮换密码、处理账号状态（被锁 / 过期 / 权限变更），每次账号变动都要人工同步更新 AI 配置吗？

• 若进入注册页有其他事件的弹窗干扰，怎么处理？

2” 找到用户名输入框 “

• a 方法: 将整个注册页的 DOM 发送给大模型，让它自己找（产生高昂的 Token 成本，且速度慢）
• b 方法：在创建 BUG 时，人工为 AI 提供定位器 page.getByLabel('Username')）（相当奇怪的做法）
• c 方法：用 "语义 + 视觉" 混合定位识别（类似 airtest 的图像识别，依然是成本不划算）

3” 断言 “
【“前端未有长度提示限制、无截断操作、能发起提交” 这一描述对人类清晰，但对 AI 是模糊的】
-【前端未有长度提示限制】提示是文本（如 "最多 20 字符"）还是图标？出现在输入框上方还是下方？是否有特定 role="alert"属性？这些细节若不在 BUG 描述中写明，AI 会陷入猜测；若要写清，本质是让测试人员提前完成 "断言设计"，AI 沦为执行工具，却额外支付了 AI 调用成本

• 【无截断操作】AI 在输入 21 个字符后，是否需要执行 await input.value() 来获取输入框的值，并断言其长度等于 21？，截断逻辑是 "输入时实时截断" 还是"失焦后截断” 这些都要在 bug 单上写明吗？

• 如果提示有了，但是截断逻辑没有修复，填写了 21 个字符后产生报错提示。AI 是否能验证提交？ 检查提交按钮的 disabled 属性是否为 false？还是让 AI 真正点击提交按钮，然后判断是否发出请求？

我让 AI 生成可以让 AI 回归更快捷的 bug 单，它给出以下回复

【AI 回归】注册页 - 用户名输入框超过 20 字符未截断导致后端报错

一、元数据（供 AI 快速识别场景）

• 适用 AI 回归：是
  
• 依赖环境：测试环境（固定 URL：https://test.testerhome.com/addUser）
  
• 前置状态：需游客身份（无需登录，若页面强制跳转登录页，使用预设账号：{TEST_ACCOUNT}，密码：{TEST_PWD}，从环境变量读取）
  
• 干扰项处理：若页面加载后 3 秒内出现 “隐私协议弹窗”，优先点击//button[text()='同意并继续']（定位器固定）
  

二、操作步骤（精确到 AI 可执行的原子动作）

三、断言规则（分解为可量化的验证点）

1. 前端长度提示验证

• 验证对象：错误提示元素（定位器：//div[@class='error-hint' and @for='username']）
  
• 断言条件：输入第 21 字符后 300ms 内，该元素可见且文本包含 “最多 20 个字符”（忽略标点/大小写差异）
  
• 失败判定：超过 1 秒未出现提示，或提示文本不含 “20”
  

2. 前端截断逻辑验证

• 验证对象：用户名输入框的value属性
  
• 断言条件：输入完成后（步骤 3 结束后 1 秒），获取输入框值，长度必须≤20 字符
  
• 特殊场景：若输入框采用 “失焦后截断” 逻辑（需在 BUG 单补充说明），则需在输入后执行blur()操作，再断言值长度
  

3. 提交拦截验证

• 验证方式：拦截提交请求（接口路径：/api/register）
  
• 断言条件：
  
  • 若提示和截断均生效：请求不应发出
    
  • 若提示生效但未截断：请求可发出，但请求体中username字段长度必须≤20（后端截断场景）
    
  • 若均未生效：请求发出且username长度=25 → 判定 BUG 未修复
    

四、异常处理规则（告诉 AI“遇到问题怎么办”）

1. 若步骤 2 定位输入框失败：自动截图并标记 “元素定位失败”，终止执行（不判定 BUG 状态）
   
2. 若提交后页面跳转至错误页（//div[@id='error-page']可见）：视为后端报错，判定 BUG 未修复
   
3. 若测试过程中出现未预设弹窗：截图并记录弹窗文本，标记 “未知干扰”，转人工处理
   

五、验收标准（明确 “通过/失败” 的刚性条件）

• 回归通过：满足以下全部
  
  • 提示验证通过（出现含 “20 字符” 的提示）
    
  • 截断验证通过（输入框值≤20 字符）
    
  • 提交拦截验证通过（无超长数据提交）
    
• 回归失败：任意一项验证未通过
  

就如果按 AI 这个写法，一个三四分钟就能回归的简单 bug，足足在 bug 单上就耗时至少 20 分钟

最后业务测试做多的人都会知道，bug 回归的核心是 “验证动态变化的功能”，就是 UI 可能改、逻辑可能调、异常场景可能新增
毕竟是面向人的验证工作，当然我不是找茬，只是感觉想用 AI 去做回归，真心有点难

这种对提单的要求都很高，而且要统一格式，我个人感觉光是规范流程和严格执行提 bug 的方式都不是一件容易的事

这感觉怎么有点像我打标些 bug 给实习生回归练手的场景。。。。期待你完成看下效果了

你这比训练一个大模型都难，，，，，，，

既然你离职了，那当她的话是放屁就好了，不用在意什么，她在享受管理的感觉，在你啵嘴之后，她不爽找茬而已。事实上这种旁枝末节的东西，你怎么写都可以挑刺，或许就是想把你恶心走，然后让她的姐妹入职而已，不要老是用技术思维去看问题

根据我自己的和面试时问的，大部分自动化报错原因会是如下

1. 网络波动
2. 用例不规范
3. 环境不一致
4. 测试数据问题
5. 第三方服务依赖

然后如果要保证回归质量，减少不必要的排错，就跟楼上说的一样，做好高可维护的测试用例是目标，需要做到这一点就不得不提一个必要条件：充分理解业务

你做这种 WEB3 的工资只 +1K 吗？？？亏大了，这种是灰色地带

挺多小年轻们意识不到，他现在比其他人好找工作，挺大一部分原因是因为年轻