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

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

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

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

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

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

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

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

等下一个龙虾

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

总的还是向好的

有点像是一本书的简介

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

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

好文章

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

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

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

这种应该规范一下 bug 提交规范

我还没见过一天之类测试的内容能产出这么多 bug 的开发和发现这么多 bug 的测试，真是开了眼了

项目外包是这样的吧

到时候主管就是问有没有历史能复用或者能参考的，工作量中间先砍一刀

我期望我能干到 40 就知足了

我碰巧有负责过这类模块，我简单说一下我咋测的，先把表单内容进行分类，比如可能不同内容是不同团队负责，按团队维度或者按特性维度，比如订单类型的，执行操作类型的归为不同类，在写用例的时候针对不同类把特性拆细，最好是一个用例测一个数据点做到足够简单，最好是就输入输出这类，把测试设计作为接口自动化的指导，把测试前移，给到开发去实现接口自动化，转测前看接口自动化是否按照我们之前输出的测试设计实现了，用例确保都通过后转测。自己写那种基于用户使用场景的用例，比如客户什么时候什么情况会使用这种大表单，关注哪些内容，按场景去写，不用特意纠结某一个数据的准确性，因为边界值、等价类那些接口测试已经覆盖过了

我也不少了，我想攒着换个衣服