看这菜单还能选下午茶，我们老早就没得选了

其实我觉得 AI 用的少，反而证明你这个工作不容易被 AI 取代，换个方向想想呗

项目复杂度兼顾不了的对于 AI 来说应该只是时间问题

你这理解确实是独一档

稀客，好久没见过这种问题了，我理解测试和开发是属于合作关系，你多给他们发现 bug，他们未来就少一点线上生产环境问题排查，人家谢谢你都来不及

我是越来越没有把自己固定在只做测试一个选项了，我是觉得有了 AI 以前很多不能做的现在能做的

这个可能是以后测试的生态 @ThinkMugz

你看吧，会有这一天的，自己见机行事吧，新的问题会带来新的解决方案，风险中总是有机遇的，我比较理想主义

对 AI 我还是有期待的，就像我们自己也能感受到 AI 生成代码的效率远远高于测试，测试的工作量正在慢慢成为项目开发的瓶颈，但是这个肯定只是过程。开发可能只需要简单描述一下问题让 AI 自己自闭环，其实测试也应该这样，百分之 95 的工作让 AI 来主导，人只是做微调，当然这个要实现不是测试这一个岗位能实现的，需要需求、规划、项目管理协同运营，但是这个应该是趋势，直到未来不需要人参与测试，测试作为一个能力原生到整个产品线里面。只是畅想....

大兄弟，没 AI 你觉得公司会让测试去吗

AI 测试目前感觉是探索阶段，重要的是思路

你先不管 AI，你可以先思考你自己是怎么根据设计稿写测试设计和用例的，肯定也不是只看设计稿的，先把自己如何解决问题的方法交给 AI，他才能走下一步，比如需求沟通、历史版本用例、历史需求、历史该模块的测试设计

我有点好奇这中间没有专门的测试设计吗，直接需求就到用例了？

完全可以合并啊，没有什么障碍，而且生成用例本身也可以参考这个历史用例知识库也可以参考历史版本的测试设计以及历史需求，再结合当前版本迭代的需求，这样写的用例会更加合理一点

完全可以啊，你给他输入库表名再输入条件就行了

等下一个龙虾

我只能说不要把自己限定在测试这个岗位上，openclaw 能带来的不只是这点东西，业务经验其实自己慢慢就有了，自己多去熟悉产品

总的还是向好的

有点像是一本书的简介

是不是不小心洒了点水啊，老哥

喜欢在发现缺陷后，看开发解释自己为啥会出现这个问题

好文章

是不是用例本身就没覆盖全，建议分析一下客户出问题的场景原因在哪里

笑死，不过既然你们头头都这么说了，这个版本就先测试全程投，把 bug 和用例执行情况披露出来，然后以周报形式定期抄送给全部门尤其是你们的研发主管，到时候项目要发了 bug 没解决急得就是他了

看楼主应该 17 年入行，现在还在干，可能他就是测试主管了