如果没了，那就是业务不盈利，撤项目而已。
测试不会没的，如果 AI 真的都替代了研发，那测试就是最后一道人工防线。
自动化生产都多久了，质检这岗位不也还在，
所以我都在说现在鼓吹 AI 能替代测试的，大多数没在一线做过业务测试，只是挂着测试名头的开发

我也挺想吐槽 AI 做 UI 自动化 ， 可惜在其他社区已经写文章吐槽过了

去年到现在 在你们字节的相关 AI 社区参加活动写写文章，白嫖了好多 D 卡和奖励，很有活力

分享少了，交流也是老人出来压新人的状态，容不得其他意见。总有一种 G 企内部的感觉

这个解决不了，也解决不了需求一直变动的事实，测试这一环是最后的兜底，必需要有人工介入

我个人觉得现在最尴尬的就是测开，但凡你用一次 vibe coding 的工具，你都会感觉测开消失是迟早的事情，或者说只要是测试，都可以说自己是测开。一个业务测试经验丰富的测试，也不需要懂太多编程知识，只要他会用 AI 工具，他就是一个资深的测试开发

我兑换完积分就走人了，之前一直在 AI 社区混，搞了不少礼物，哈哈哈哈，这里不太行，都是传统派还有拉帮结派

所以说，我就很讨厌这种测试基础能力不扎实的
什么叫【传统测试用例确认太复杂了】，测试用例写得太随意太自我，后期的麻烦是无穷的

用好 AI 工具就行了，还有别被培训收割
别头脑一热去学习相关 AI 的测试，那个没鬼用的
可以去 AI 的相关社区论坛看看 AI 工具的使用经验就行

深圳的地铁很早以前就是全自动开的，按理来说是不需要司机
但是地铁一直配有司机的专职岗位，地铁招司机的要求通常有个视力好的要求，而不是复杂操作的能力。所以测试的护城河就是回归本质，业务测试能力和沟通能力，就是这么简单

就你目前的情况来看，airtest 最好

豆姐还在做测试吗？还是转行了

可以加入，ui 颜色和文案这的的确确是 bug，只不过要标记成等级相对比较低的 bug

你这情况太经典了。要我说，交接个差不多就得了，表面功夫可以做足点，但可别真上头。

首先，公司自己找个实习生来填坑，就没指望能 100% 无缝衔接，
你把能把文档整理了，就已经是仁至义尽了，难不成还想给你布置交接文档的 KPI？他咋不给你发两份工资呢？。

其次，你主动凑上去事无巨细地喂，人家还嫌你啰嗦，根本记不住。把核心资料甩过去，告诉他 “先看，看不懂再问”。他问的问题才是他真正需要的东西，这样交接效率最高。

最后， 你要知道有个职场” 潜规则 “，后续项目但凡出点屁事，第一个原因绝对就是 “你交接没交清楚”，不管你自认为自己整理的多详细，很多事情写在纸上是远远说不清的，你自己也不可能完善所有细节。

像上面那个兄弟比喻得就很好，类似你去食堂吃饭，收盘子放指定位置是你有礼貌，但帮人家洗碗那是慈善，你洗了碗也不会留下大善人的口碑，别把自己太当回事，也别自我感动。 理清这个界限

你可以参考思路，但是不是所有公司都有资源和人力去落地的，有些落地场景也需要依托他们公司过往的技术累积

这种第三方机构背调查不出啥的，连社保信息都要联系被调查人发。同事评价这种，填上几个熟悉的，打好招呼就行了，hr 也是。政审这种才是真正的背调，环节里还包括考察组要前往原单位核实档案信息，和相关人员开个座谈会

关键还反思起来了，哈哈哈哈

一句话： 关你嗨事咩

别把找到工作===技术能力水平
除了自身学历学校这种硬性条件，其他还是看你自身的推销能力
面试 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. 第三方服务依赖

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