可以要过来代码试一试，再把测试数据库给到 AI。然后把过程整理成一个业务 SKILL，很多事都能解决。
短期解决不了的需要人工的，人工后把过程往 SKILL 里补就行。补上几轮就不需要人工了。。。。。。

你做过实践没 中间会有很多的问题需要人工处理，比如 脚本的参数化，接口上下游的对接，前置//后置条件，场景化的接口关联； 看着没有那么简单额，，

不要等文档，把前后端代码要过来，让 AI 读完所有代码把项目涉及接口都提取出来。直接写成测试脚本放到 CI 里。再进一步论坛有分享接口串联的 SKILL 合在一起看看是否更贴近业务实际情况。

请问移动端你们让 AI 做 UI 测试还是 api 测试，我们用 AI 做 UI 测试非常的卡

接口层面本来想测试左移，实际项目开发文档沉淀都没有，3 4 年的老系统，只给新接口的文档，也没法做场景化的测试，目前还是用 ai 写回归接口测试

1. UI 层面，AI 的执行效果比较差，还非常耗费 token
2. 接口层面 特别是场景化的接口自动化，ai 还没有你们说的那么好（可能是我自己水平问题）
3. 测试用例生成比较扩散，需要人工审核
4. 对于写报告 ppt 觉得是效率提升最高的 嘿嘿

在 web 上 ai 根据用例做测试执行程度很高，我们还有小程序测试 AI 执行卡的几乎不可用

测试开发和业务测试的看法可能不太一样，作为业务测试，我觉得：单从 AI 生成测试用例的方向，需要强依赖产品文档和技术方案的完善和准确，抛开这些谈测试用例生成准确率就有点扯。大多数测试设计需要不断和产品、开发沟通细节，很少见到不需要沟通的需求。然而，现在产品和开发也在重度用 AI 写产品文档和技术方案，以前产品和开发写的文档，读起来比较容易理解，现在 AI 写的感觉就在 ‘堆砌’ 文本，我的评价是一坨勾石。补充一点，生成单元测试、接口测试的能力，在没有 AI 的古法编程时期就有很多解决方案，AI 只是降低了门槛，从始至终难搞的都是业务逻辑。

我司现状跟你们差不多，不过焦虑是真的，接口测试比人工写的要完善很多，不论是广度还是健壮性，以前会觉得把接口测试脚本写好就已经算不错了，现在 AI 做得又快又准，毕竟分析了源码，跟人脑去理解的效率还是不一样。。UI 测试比较一般，但是能验证掉 30~50% 的操作，交互易用性、探索性测试还是得靠人。目前是招了 AI 专家顾问帮我们完善脚手架，安全测试、集成测试不分还在探索，特别是跨系统协作和硬件设备的，AI 目前效果还是不太好的，所以能苟几年苟几年吧

他整你，你也整他，怕啥，职场上不要让人觉得你好欺负，不然就会一直被欺负

你直接问啊，“被间接点名说开发反馈测试同学下班找不到人？” 指的是找不到谁？
如果说是你，你就开怼啊，真有事打电话啊，企微象征性 call 一下是真心想找人吗？
他无非就是想隐晦地点明你没在加班而已，但是这个话谁都不敢明面上说，你这么怼他没有领导会站他，怕啥？

替代外包的方式，你去看下孙高飞的文章吧，里面说的很清楚详细了。高飞测沙箱都不是手来操作了，也没有外包来测试，你可以从这个角度来思考下。

你也留个 bug 半夜 call 他

说说为什么字节现在还有 QA/外包吧：

1. 决策层应该是 100% 知道这个事实，但是希望无痛过渡，一刀切不可取。
2. 字节内部的大模型还不够，用国外模型确实能搞定，但是国外大模型成本较高（比招个外包差不了多少），也有数据安全风险。国内大模型比如 deepseek 预计还有不到半年的窗口期，半年以内 deepseek（豆包可能得一年）会成熟到可行。
3. 字节内部的代码权限屏障太硬，代码数量极其庞大，历史业务很多没落盘或者找不全了，boe 环境还有提升空间，历史包袱太重，都换成 AI 需要时间，需要人整理。
4. 纯 AI 后预计还有 10% 的核心用例（操作简单，UI 用例为主）还需要人来点，纯执行留极少部分人无伤大雅。

他给加班费吗？24 小时 on call？

you want,you can, you do,then nothing......

建议别裸奔，除非提前找到下架了

何必跟傻子计较呢，不鸟他就行了

跟开发搞好关系，想想办法干他一炮

AI 怎么替代外包的？展开讲讲

我这里是小公司，只有 2 个测试，每个项目的测试时间都很短，开发测试的时间占比大概是 1/10，但是老板在推 AI 测试，他们的想法很简单，写了测试用例，交给 AI 来执行就可以了，人来核对测试报告就可以了，但个人实现下来不现实。

实践下来发现，AI 是可以根据用例来执行测试的，UI 测试、接口测试都能进行。但是能发现的问题很局限，一些数据核对的用例执行效果比较好。但牵扯到一些业务逻辑或流程场景时就不行了，一个原因就是用例写的就是开放性的结果，不会写的很明确（比如会写有合适的错误提示信息，不会具体什么信息），还有一些就是页面报错或者接口 200 但结果错误的，这些也不能发现。有些甚至用例明确写了错误结果也出现了，AI 愣是识别不到，就很奇怪，不知道你们遇见过没。
而这些都需要人来介入进行调试才行。

个人对目前 AI 测试的理解是：AI 测试其实就是 AI 编写了一套自动化测试的脚本，手工调试测试结果或场景其实就是在使用 AI 来调试自动化测试脚本，底层还是使用自动化测试脚本来进行测试。

但对小公司、项目快速切换的情景下，基本就没什么项目积累，项目上线后很快就进入其他项目了，自动化这一套很难用。

AI 能 100% 替代外包（所以我匿名了），这是真的，不是我不想为外包发声，是真的是事实，外包同学对不起。

展开说说 测试全部替代了吗

1. 字节的外部不是人干的活，曾经的阳光男孩慢慢沉默寡言，亲眼所见。
2. AI 能 100% 替代外包（所以我匿名了），这是真的，不是我不想为外包发声，是真的是事实，外包同学对不起。
3. 外包没有未来，字节的外包还有很重的考核，所以不是人干的，有别的选别干这个。

非常讨厌那些瞎吹牛比的，可能是因为我技术比较菜坐井观天吧。自己也试过给用例让 ai 测试，做做接口测试还可以，做功能测试还有很长的路得走

一个步骤，agent 与模型交互多次，不谈概率模型本身，真的已经应用于常规的新需求迭代中了吗