今年初（可能去年下），公司 AI 部门就开始搞 AI 全流程软件研发框架了（基于某国际头部 Agent），完成初版后，就要求让其他部门也接入使用：不能使用 VideCoding，需要用此全流程框架：输入需求->需求分析拆解 + 澄清->系统设计/用例设计->(编码 React->[基于测试用例自动执行 UI 测试->自动修复->loop])
测试模块是后面接入的：主要是自动用例生成 +AI 进行自动化用例测试；相对开放的进度会滞后。当时（7 月份）说法，主要是 AI 进行自动化用例测试这块卡点（数据、环境、业务上下文）、准确率有些问题，只在一些特殊业务上运行过 demo，但其他复杂场景就歇菜了。——这个和我预期的也一致。
上个月从一些技术分享会得到信息来说，不管大厂还是技术先锋团队，AI 的完全自动化测试 + 修复也只是用于特定业务场景做的特调；但几天前部门领导参加了工作的技术沟通会，给我带来说法是：其他有个部门已经完全使用了（不知道是 1、2 个项目还是很多项目），而且 UI 测试完全交与 AI，人最终只要花 5-10% 的时间复查下。这样下去很危险（我想指的是测试团队）......
听完我的第一反应这里肯定有水分（毕竟是大会，那个部门是有 “基于 AI 研发” KPI 的......），这里的水分我是基于那个部门的部分业务场景是有些复杂的，AI 完全自动测试，卡点不少：业务上下文、测试用例完善、执行中卡点（自动化工具、页面复杂度...）、测试数据准备、测试环境稳定性、测试准确度、自身幻觉.....完全解决了（不是大厂）？但对于领导的说法，先听听表示点点头，表示事后了解下，因为这套流程本部门也需使用，还得直接跟那个部门直接沟通了解情况......
随着大模型的进步 +harness 工程，提供准确的知识库、有效测试技能，针对部分项目是验证过的，尤其是后端配置规则 + 前台展示类，AI 可以完成将近 90% 的工作，人的作用主要是澄清需求分析问题及用例，AI 可以自行了解原型和交互设计后，加上测试用例就可以跑测试了，剩下的部分人检查样式及一些特殊情况。但有些长流程场景（涉及多种角色、多种状态）在缺乏快速测试数据生成的情况下，都自己完成测试，感觉有些悬。
下面，我希望大家在评论区说说，你们公司或部门的 AI 测试已经能达到什么地步了，对齐下。
其实你自己都怀疑并且回答了答案了：业务上下文、用例完善、执行卡点、测试数据、环境稳定性、准确度、模型幻觉——是任何团队把 AI 测试从 demo 推到日常流程时都会撞上的东西，
就跟以前的自动化一样，有 KPI 的地方，汇报天然会向 “已完成” 倾斜，实际上能达到的程度大家都心知肚明。对测试团队来说，真正危险的不是 AI 本身，而是管理层用 demo 级指标做资源决策，最后大家做的事情只会更多更累，不仅要用古法测试去减少风险，还要维护革新的体面。
我部门现在是有 AI 工具使用，但是也只是辅助，而且需要严格控制敏感信息，毕竟做实事的部门，真的出现 bug 了，都是跟钱关联的，这锅谁都背不起
我也说下我从前同事交流里了解到的情况，样本有限，供大家参考。
大厂测开/效能岗：最痛苦，也最容易制造 “5-10%” 的假象。
这部分人很多是在用 AI 去构造理想环境，跑出类似 “人只花 5-10% 时间复查” 的数据。这个数字在特定演示场景里可能是真的，但很难推到常态回归。原因不复杂：这类岗位离线上业务结果比较远，做对做错影响都不直接；以前一部分压力稀释给外包，现在外包削减后，压力就集中到 PPT 和 “需要数据证明有用” 上。大厂业务部门反而谨慎，AI 不能背锅，领导很怕这一点。指标可以下，但真让高风险业务全交 AI 测试是另一回事，比如电商业务，一个优惠券或者营销场景的测试如果没人把控，真出事影响的不只是功能，还可能影响季度营收，最后是领导背责的。社区里如有某东 某多 某猫的员工，应该能明白我说的，业务测试这块是不能给 AI 瞎搞。游戏公司：很多场景确实用不上，或者 ROI 不划算。
游戏测试偏体力活，测试策略、上线时间、bug 分类都随项目情况变，甚至一款游戏能不能走到上线都不确定。测试不可能把有限时间大量投到收益不大的 AI 测试探索上。不是绝对不能用，是很多场景不值得优先用。中小厂：测试不可或缺
中小厂没有大厂那种外包支援，测试不多，整个公司可能最多 10 个、最少 2 个，很多业务都要经手测试。社区里觉得 “大厂让测试转研发，所以测试岗位要消失”，这个推论很荒谬。大厂有外包和平台分工，中小厂没有这层缓冲。反过来，大厂的外包业务测试，确实容易给测开一种 “效能很有用” 的错觉，因为真正兜底的业务测试压力被外包稀释了。实业公司：设备测试离不开人，AI 没有 “手”。
AI 再强，也不能伸只手出来点击设备、接线、确认现场状态。物理世界的最后一步仍然要人。当然日志分析、仿真、视觉检测这些可以辅助，但现场执行和最终确认离不开测试人员。
所以我的体感是：AI 测试现在能达到什么地步，不是按 “技术先不先进” 排的，而是按容错率、责任链、外包结构和物理边界排的。5-10% 这个数字，我听到的版本基本都对应特定演示环境或短链路场景，不是常态回归。大家可以对齐下各自的实际场景
虽然我是一个极端重度的 AI 使用者，并且把目前工作中的所有任务都 AI 化了， 但想要在 UI 自动化这个类型里完全依靠 AI 也是不现实的，总是需要有探索性测试的。
我是从去年 5,6 月份开始使用 AI 来辅助工作的，到现在经历了两个项目，当前项目是 Agent 沙箱，这个项目的特点就是没有 UI，属于很底层的产品，所有的测试都是调用接口来完成的， 所以基本上都是全 AI 的。 人在中间是负责检查 AI 的结果和计划，做必要的调整。 目前已经做好了数字分身， 基本上用例设计，自动化测试的编写，执行，失败分析，环境打通， 容灾，性能，日常调试等等都是有对应 skill 来完成。 workbuddy 很好用，我甚至连汇报材料都是 workbuddy 来完成的。
上一个项目是一个智能体产品，有很复杂的 UI， 如果看过我的 midsence 的文章和直播， 应该知道也是可以用 AI 来完成的，只不过这种有复杂 UI 的产品，人力上去做探索性测试还是很有必要的。 UI 自动化解决不了所有问题。 所以我们的策略都是 AI 负责跑确定流程 case，而人力上去做探索性测试。
AI 化是大势所趋，楼主的老板没说错。 楼主多关注关注行业动态就知道了。 目前大厂里已经没有不用 AI 的了，由于用 AI 提升了效率，各种裁员都已经跟上了。 各路中小厂也正在跟进。 我的星球群里有将近 500 人， 经常能看到大家在讨论 AI 对测试行业的冲击，已经有公司要求测试人员都转开发， 不转的就淘汰掉了。 也有公司全面推进测试 AI 化。 但这里要注意的是， 推进测试 AI 化，不是所有的事情都让 AI 来做， 这东西要循循善进，而且不是所有东西都适合让 AI 来做的，就像我刚才说的探索性测试这个东西， 这个就得人自己来做。
我做移动端的 QA，团队内部还有一部分古法测试。但 AI 能覆盖大约 40～70% 的基于需求和 API 文档可想到的验收场景，其他探索性测试、性能感知等也不是不能持续集成推进，但 ROI 不高通常不考虑。
还是用于辅助的比较多，比如造数据，验证某些数据落地，一些基本的可复用的功能都可以让 AI 进行测试了
但是核心的功能尤其涉及到钱相关的还是手动验证的，因为不放心，毕竟出问题了，AI 背不了锅，而且测试作为最后一关，流程后已经没有能兜底的了，所以未来因为 AI 冲击测试人员可能会减少，但是功能测试还是永远会有的
个人体感：
- 短链路或者单系统 AI 自动化测试效果还行，跨系统/终端就很费劲了，还是要人工操作确认
- 新功能 AI 自动化验证想想就行，能跑起来的不是特定场景，就是一些简单需求，主要是做自动化回归
- AI 执行幻觉很头疼，自动化回归需要确定性，我们是让 AI 自动规划执行 > 记录 UI 和接口操作链路 > 生成 UI/接口自动化代码 > AI 运行自动化代码并自行维护，目前来看效果还行，起码写自动化的效率提升很多
目前推进落地的模式：从需求到上线全链路中，需求澄清、研发方案与计划环节保留 AI 和人沟通对齐；测试、BUG 修复、上线等后续环节，都要由 AI 直接落地执行。测试集在探索由产品在输出需求时同步产出，核心思路是尽量减少人介入。
你们解决了执行慢的问题？每次交互都要截图给大模型做识别，下发指令
一个步骤，agent 与模型交互多次，不谈概率模型本身，真的已经应用于常规的新需求迭代中了吗
非常讨厌那些瞎吹牛比的，可能是因为我技术比较菜坐井观天吧。自己也试过给用例让 ai 测试，做做接口测试还可以，做功能测试还有很长的路得走
说下我的最新进展吧，完全用 AI 做测试比之前预计的要累，QA 这个岗位不会消失，QA 是个力气活。
我验证的，仅 pc 浏览器功能的产品，是可以达到 AI 100% 覆盖的，所以大会上说的，5% 靠手测是完全可能的，并且和普通的理解不同，是 100%AI 都能覆盖，但是有 5% 的核心功能人类不放心所以要复查下，5%-10% 应该是这么来的。
但是这个 100% 的 AI 覆盖比想象中要累，原因是 AI 的质量标准太高了，举例吧，如果外包能设计出 20 条用例，正式最资深人能想到 50 条，那么 AI 能想到 100～150 条，会不会更多我还不知道，因为我在尝试并且 AI 大模型也在快速发展。
20 条用例耗时 1 天比如，如果 AI 测这 20 条确实洒洒水，一小时搞定了，但是要测 100～150 条的极其深入的测试，AI 的耗时也少不了，所以整体的测试耗时并没有下降太多，跟研发的开发时间仍然是一个合理的比例。
并且还有一个弊端，极其发散的用例，创造的场景和复现 bug、验证 bug 的深度也是非常恐怖的，研发可能改几遍也改不好，所以研发的能力，造数的能力等，都耗时很高。
所以回到最初的说法，QA 是个力气活，极端的质量仍然是明珠，很难摘的。
当然肯定有公司对质量是得过且过，甚至我都见过有些 QA 对自己的工作也是得过且过，那不在我上述范围内。
其实 QA 是一个靠运气吃饭的工作，就啥都不测、糖化，但是线上就不出问题事故，照样很稳……都是玄学。
我这里是小公司，只有 2 个测试，每个项目的测试时间都很短，开发测试的时间占比大概是 1/10，但是老板在推 AI 测试，他们的想法很简单，写了测试用例，交给 AI 来执行就可以了，人来核对测试报告就可以了，但个人实现下来不现实。
实践下来发现，AI 是可以根据用例来执行测试的，UI 测试、接口测试都能进行。但是能发现的问题很局限，一些数据核对的用例执行效果比较好。但牵扯到一些业务逻辑或流程场景时就不行了，一个原因就是用例写的就是开放性的结果，不会写的很明确（比如会写有合适的错误提示信息，不会具体什么信息），还有一些就是页面报错或者接口 200 但结果错误的，这些也不能发现。有些甚至用例明确写了错误结果也出现了，AI 愣是识别不到，就很奇怪，不知道你们遇见过没。
而这些都需要人来介入进行调试才行。
个人对目前 AI 测试的理解是：AI 测试其实就是 AI 编写了一套自动化测试的脚本，手工调试测试结果或场景其实就是在使用 AI 来调试自动化测试脚本，底层还是使用自动化测试脚本来进行测试。
但对小公司、项目快速切换的情景下，基本就没什么项目积累，项目上线后很快就进入其他项目了，自动化这一套很难用。
我司现状跟你们差不多，不过焦虑是真的，接口测试比人工写的要完善很多，不论是广度还是健壮性，以前会觉得把接口测试脚本写好就已经算不错了，现在 AI 做得又快又准，毕竟分析了源码，跟人脑去理解的效率还是不一样。。UI 测试比较一般，但是能验证掉 30~50% 的操作，交互易用性、探索性测试还是得靠人。目前是招了 AI 专家顾问帮我们完善脚手架，安全测试、集成测试不分还在探索，特别是跨系统协作和硬件设备的，AI 目前效果还是不太好的，所以能苟几年苟几年吧
测试开发和业务测试的看法可能不太一样，作为业务测试，我觉得：单从 AI 生成测试用例的方向，需要强依赖产品文档和技术方案的完善和准确，抛开这些谈测试用例生成准确率就有点扯。大多数测试设计需要不断和产品、开发沟通细节，很少见到不需要沟通的需求。然而，现在产品和开发也在重度用 AI 写产品文档和技术方案，以前产品和开发写的文档，读起来比较容易理解，现在 AI 写的感觉就在 ‘堆砌’ 文本，我的评价是一坨勾石。补充一点，生成单元测试、接口测试的能力，在没有 AI 的古法编程时期就有很多解决方案，AI 只是降低了门槛，从始至终难搞的都是业务逻辑。
在 web 上 ai 根据用例做测试执行程度很高，我们还有小程序测试 AI 执行卡的几乎不可用
- UI 层面，AI 的执行效果比较差，还非常耗费 token
- 接口层面 特别是场景化的接口自动化，ai 还没有你们说的那么好（可能是我自己水平问题）
- 测试用例生成比较扩散，需要人工审核
- 对于写报告 ppt 觉得是效率提升最高的 嘿嘿
唐琪
回复
接口层面本来想测试左移，实际项目开发文档沉淀都没有，3 4 年的老系统，只给新接口的文档，也没法做场景化的测试，目前还是用 ai 写回归接口测试
沈雪松
回复
不要等文档，把前后端代码要过来，让 AI 读完所有代码把项目涉及接口都提取出来。直接写成测试脚本放到 CI 里。再进一步论坛有分享接口串联的 SKILL 合在一起看看是否更贴近业务实际情况。
白绍辉
回复
你做过实践没 中间会有很多的问题需要人工处理，比如 脚本的参数化，接口上下游的对接，前置//后置条件，场景化的接口关联； 看着没有那么简单额，，
唐琪
回复
可以要过来代码试一试，再把测试数据库给到 AI。然后把过程整理成一个业务 SKILL，很多事都能解决。
短期解决不了的需要人工的，人工后把过程往 SKILL 里补就行。补上几轮就不需要人工了。。。。。。
当大部分人都发现很难解决的时候，那就是事情本身的问题了。
我很多时候都想听大家诚实的说一句：真的不好用，或者并没有那么好用。但是实际上不是，大部分人都在说：我们一直用 ai 啊，很好用啊
