AI测试 AI 对测试到底哪些领域有真正的收益

wuming · 2026年07月09日 · 最后由 dun 回复于 2026年07月13日 · 5686 次阅读

如果你说从上至下要求都要 AI 这 AI 那,那我觉得都有收益,都应该做,谁敢不做我弄谁。我还要帮忙推广到各个部门!但是如果只是灵机一动,自我提高,那我只想说,省点钱吧,我公司每个月送 token,你公司送吗?不会还天天抢各大 AI 公司推出的 coding plan 吧?

下面是个人看法,不代表行业共识 !

有收益

一、测试工具开发

这还是代码的开发工作。也算是对开发和测试都有收益的部分了。
测试比开发代码能力弱,在工具的开发能力上可以用 AI 去追平,实现自己的想法,不用到处翻资料了。
我个人用 AI 开发了 AI 质量中台,业务测试小工具,JAVA 版 MCP,基本都是前后端一肩挑。

二、接口自动化测试代码生成

我开发的 AI 质量中台里就有接口自动化生成,后面又做了 SKILL。对接了全司各种样式各种类型的自动化生成:testng,python,引用了开发二方包,有自己的接口自动化应用二方包等等。
到最后基本实现了生成代码后 0 代码改动,自己要关注的也是测试数据的添加和引用了。

待定

UI 自动化

说实在话,对 UI 自动化没有什么好感。虽然陆陆续续做了十多年,APP 端和 WEB 端都做过,各个自动化框架都研究过,进入了 AI 时代到目前为止依然进展不大。也许是一直在小厂混,不够正规。我接触过的都是投入远大于收益。最后自动化项目不是沦为摆设就是黄了

  • AI 增强型传统自动化框架,视觉为辅的 AI 工具

    • 代表工具:Playwright AI,Appium + AI 插件
    • 我个人最看好这种,以生成用例为主,视觉为辅的 AI 工具,感觉是目前的 UI 自动化的最优解
  • 开源视觉 AI 驱动(纯视觉、不依赖 DOM / 控件树)

    • 代表工具:Midscene.js,Browser-Use
    • 目前不看好,第一费 token,而且还是干同样的活费一次 token,第二没有 case 沉淀不能做回归测试,第三也就是最重要的一点视觉不一定准确! 可能以后 AI 随着发展越来越厉害,这个才是主流。

收益小

测试功能用例生成

我做过测试用例生成和测试用例评审,先是做的平台,后面做的 SKILL。

  • 第一个,产品需求文档和开发设计文档,质量参差不齐,风格各异。

    • 大家应该都有碰到过一句话需求甚至还有只有标题的需求吧。
    • 应该也有碰到过需求内容里都是图片吧。
    • 设计文档人家也是 AI 生成的,有大量的废话需要过滤
    • 你要进行需求清洗,文档过滤。甚至你要自己去补充产品没有写到的潜在需求,设计文档里没有提到的接口或者 SQL 语句。你想去推文档模板化?人家产品和开发鸟你吗
  • 第二个,生成用例质量问题。

    • 生成的模块和测试点很多都没覆盖或者不对,这个可能是需求或设计文档的原因。这个时候你会陷入三难的境地,选择一:改需求,设计文档,然后重新生成。选择二:直接在生成的测试用例上改,选择三:放弃 AI,自己新建个文档手动写
    • 生成的用例太多了,因为你的要求多,注入了等价划分法、边界值法、xxx 法各种法。同时不止关注功能测试,还有性能、兼容性、安全等等方面的考虑。这个需求你自己写测试用例也就 40 条,AI 给你生成了 100 条。100 条里每条包括了模块、测试点、预期、结果。你头晕眼花的对比完了,删除了 30 条,觉得 70 条还能用。一上午过去了。其实你自己写 40 条用例也就花 2 个小时。再加上这 70 条用例不是你自己写的,也许你还要再熟悉熟悉才能进行用例评审。又一个小时过去了。。。等到自己测试的时候,发现其实测试 40 条就够了,但还是忍着恶心把剩余 30 条也一起测了,整体测试非常全面!但是你比自己写用例全流程多用了一天。
  • 第三个,来自平台开发者和上级领导的要求,用得怎么样?

    • 覆盖率怎么样?有多少错的,有多少能用的?统统给我写到文档里。
    • 需求文档和设计文档,生成的用例,给我放到指定的地方,我要利用数据进行调优。
    • 忙不忙?我刚刚调优完,再帮我生成下,以你的经验看看还有没有问题了,谢谢哈,请你喝咖啡!

最后总结,人来写用例半天,AI 写用例两天。而且生成的真的是你想要的用例吗?

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 11 条回复 时间 点赞

想法几乎和我差不多了,还以为是我自己写的

最主要的问题是用例如果都由 AI 生成,那测试就没办法再书写用例的过程中梳理需求/理解需求,但是最终还要人来验证这就很扯淡,尤其是碰到新产品,跟没有用例有什么区别,让 AI 生成用例的不知道是咋想的

写测试用例其实是一个深入理解需求的思考过程,往往能在这个阶段发现一些需求上的问题。当然,用 AI 生成一些边界值、等价类等通用测试用例倒是能节省点时间。

牧遥 回复

AI 用例评审也做过,功能是再拿需求和涉及文档,对生成的用例进行评审,涉及到各个方向的评审,包括,测试点需求覆盖率,模块生成合理度,命令规则等等。但是效果聊胜于无,AI 自己生成再自己评审的路感觉也走不通

实际上开发者写代码的时候也是一个深入理解需求的思考过程,所以现在 AI 确实是提效的,不过也改变了现在的项目流程,更多的是前期的需求评审和理解,不然开发在 AI 设计环节无法审核,测试在测试点梳理以及用例评审环节就无法审核,甚至到用例执行都是困难的,由于最开始的需求文档文档质量不够高,导致后面的环节都需要人工去把关的。

用着免费的马维斯、workbuddy 天天签到、qorder 天天签到、trae work cn 天天排队,也被各种日周月限额; 目前收益最多的还是测试用例生成,不用自己写了,自己审和改就行,组内所有人都提效了 50% 左右,我们是 APP 应用展示层,逻辑不复杂; Midscene.js 这个我也在做测试阶段,感觉代替人来验证新功能,还是风险太高。。。如果是回归测试,那 appium minium dbdriver2 就够了,没必要视觉;

最近也在 AI 生成测试用例,用例步骤生成还行。用例前置条件和测试数据对业务逻辑依赖太强,AI 生成的要么太简略,要么引用了非这个测试点的数据。这种质量的用例,对于比较熟悉业务的同学还好说,对于新手如同噩梦。

最近这大半年的体感上来说 AI 对写代码基本上已经能完胜了,现在 UI 和接口都是一把梭哈。SKILL + 记忆框架能够直接让 AI 根据你的用例步骤写好自动化后测试通过,然后调用 CI 完成。人工只需要关注下断言和页面是不是真的点了,用多了说实话现在基本上不关注代码的生成了,只看结果。但是前期的框架层一定要约束好,说白了其实就是提示词工程

用 ai 搞 UI 自动化 涉及到两方面 一个是生成时用 ai,一个是跑用例时用 ai 我司不报销 token 还要跑用例时用 Midscene.js 识别😂 实际没啥提效 不过绩效上倒是添了一个说头

AI 生成用例,审核用例,需求功能合理性推导,生成接口自动化,WEB UI,APP UI。人只去核对场景是否缺失,以及探索性测试,专项测试。感觉现在真的做到几年前大家的设想测试工程师应该去做更有价值的地方。一开始有点迷茫现在感觉就是这样的趋势走了

喂给它需求文档生成测试点清单还是挺好用的,拿到清单后去思考还有哪些是可以进行覆盖的。
写代码是真好用,以前要做好久的平台或者工具,AI 几天就可以完成就拿 4 年前的一个财务金额校验工具,我自己敲代码做了 3 周,现在用 AI 干一天就出来了。
测试文档生成,AI 生成方案、结构化用例表格、测试报告,复盘资料等等,都不用自己去手敲。
写财务系统验证的 SQL,AI 不仅快生成的还好。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册