有

这一点出来之后感受更深刻

+1，基本没有测试的活，百分之 95 是运维

我是这么理解，分析一件事情 AI 可不可以做，先分析这个事情由哪些组成的吧，打个不恰当的比方，比如买股票，你可以分析走势、资金出入等相关公开的信息，这些都是有机会拿到的数据，把这些数据根据一定的格式丢给特定培训的大模型，做股票分析，甚至给出推荐哪支股票

我有一点自己的拙见，这里面是存在俩个问题导致觉得使用困难
1.大部分使用低代码平台的同学是没有自己二开的权限和能力的，即便自己发现了问题可能也无法解决
2.低代码平台是直接拿的开源的或者是商业的，无法及时响应应用到自己公司项目的使用问题

我想针对交叉测试这里提一个问题，可以让其他人交叉执行其他人测试的模块，但是会存在由于模块复杂度的不同、熟悉程度等因素影响导致执行效率较为低下，这种有什么好一点的方法解决嘛

校招吧可能

牛逼，我的哥

现在主流大厂是这样的吗，我自己算个中厂测试吧好像也没说不需要写用例了，绝大部分还是围绕用例进行测试的

我看高职级的测试或者测开都基本没有写用例的吧，大部分都是写测试策略定测试方案，把控一些大方向，或者带一个测试小团队承接一个大的专项测试之类的

我现在是尽量让召回做到唯一，体量不大的时候还是可以的

这个应该会是趋势的

我的思路和你的差不多，不过你这里应该还可以继续细分知识类别，并加入知识库的标识特征，让他检索的时候可以减少检索的量，可以加快答案回复的速度

茅塞顿开

思路打开，写一个定时任务定期去触发接口拉取 token，比如 token 有效期是 30 分钟，你就 30 分钟触发一次呗，这个应该也不会频繁过期

只需要人工执行其实就说明可能业务只需要外包出去就行了，复杂的设计都被解决了的话

我理解需求提出 -- 需求细化为精准需求 -- 排期落地为开发设计稿 -- 再进行测试设计以及用例编写，前面三步都是不同的处理方式，你不可能说需求提出就直接变用例，我就算 AI 现在已经非常强这些都能做，至少这几步你得让 AI 分别进行吧。就像起楼一样，你不可能说你喜欢这栋楼的 3 楼，就只要 3 楼不要 1、2 楼吧。

其实我觉得测试项目有 bug 是很正常的情况，和你用什么方式测试没什么关系，重点还是看你们项目的测试策略，评估项目的侧重点，是不是为了项目进度就是可以牺牲掉一点已知的模块质量。但是如果是确实是验证了但是漏测，这个就比较难受了

主要困难点还是在洗数据上面，主要是他多，每个都需要人工过，答复的答案也需要人工一点点矫正，真的是多一点人工多一点 AI，想看有没有大佬能答复

这个属于痛点需求，好思路

如果模块就是你负责，其实你正常测试设计的时候是会去了解开发的实现逻辑的，基本看着设计文档也会知道是前端还是后端负责。如果你只是执行，直接提给你们小组的 TL，他会去转的。不过一般和开发关系好，爱咋提咋提，培养其实也很简单，自己负责开发的模块这么多 bug，开发对测试一般都是比较感激的，还是比较好培养的。

这样吗，而且有个问题上级注意这个 bug 好像也没什么啊，这样反而会去推开发改进转测质量吧

那就写执行了多少用例、回归了多少 bug，产出了什么文档或者其他什么，把自己的工作量化出来

期待连续剧

主要还是代码能力这个对于测试来说是加分项，但是对于开发那是基础，就像别人开发的代码都卷到什么程度了，我们测试的绝大部分其实也就是自动化、性能、稳定性、写写脚本写写平台，搞搞流水线，说句不好听其实还是很基础的