不要只关注测试嘛，花这么大精力搞的，更多类似于一个中台给其他业务引用吧

公司都出钱自己搭模型了，肯定不止做这一个事情咯，这个只能算是顺带做的吧

其实我不太懂模型本地部署是主要做啥，想请教一下

这个可以找前端开发问一下，他们前端的组件适配哪些浏览器和版本

不如实地调研一下客户的使用情况，一般这种应该会有技术支持做记录的，如果没有技术支持也可以根据现存的客户问题统计一下出问题的客户，分别都是哪些情况导致，再根据这些情况做测试的发散分析

他们确实算是版本前瞻不过参考参考一下就行了，国服和日服还是有本质区别的，比如日服的房产泡沫破裂的后果，之前也觉得是版本前瞻，但到了国服这点还是有明显区别的

我看我干的公司都是测试吊开发的 ，还没经历过被开发或者产品说提缺陷太多的情况，一般缺陷太多都是开发又被测试说，又被直系领导说，缺陷太多直系领导还得复盘改进

这才是真正的百亿补贴

要换个角度看，可能又多了几个坑位

本质没有什么区别，只是套了一层互联网的壳看着高大上一点

自动化在业务本身没变的情况下肯定都是百分之百吧

算是很成功了

给我们带来了很多乐子

产品没考虑到的是常态，开发和测试在设计过程中也是可以逐步完善的

有

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

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

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

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

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

校招吧可能

牛逼，我的哥

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

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

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