惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
B
Blog RSS Feed
GbyAI
GbyAI
Google DeepMind News
Google DeepMind News
B
Blog
博客园 - 司徒正美
Vercel News
Vercel News
A
About on SuperTechFans
Martin Fowler
Martin Fowler
WordPress大学
WordPress大学
Recent Announcements
Recent Announcements
S
SegmentFault 最新的问题
博客园_首页
Apple Machine Learning Research
Apple Machine Learning Research
Stack Overflow Blog
Stack Overflow Blog
L
LINUX DO - 热门话题
Y
Y Combinator Blog
F
Full Disclosure
月光博客
月光博客
C
Cyber Attacks, Cyber Crime and Cyber Security
MongoDB | Blog
MongoDB | Blog
The Cloudflare Blog
The Hacker News
The Hacker News
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
A
Arctic Wolf
Scott Helme
Scott Helme
V
Visual Studio Blog
C
Cybersecurity and Infrastructure Security Agency CISA
T
Tor Project blog
P
Privacy International News Feed
Spread Privacy
Spread Privacy
G
GRAHAM CLULEY
Microsoft Security Blog
Microsoft Security Blog
N
News and Events Feed by Topic
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
PCI Perspectives
PCI Perspectives
小众软件
小众软件
博客园 - 【当耐特】
Cloudbric
Cloudbric
S
Secure Thoughts
L
LINUX DO - 最新话题
Google Online Security Blog
Google Online Security Blog
T
Troy Hunt's Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
W
WeLiveSecurity
V
Vulnerabilities – Threatpost
人人都是产品经理
人人都是产品经理
酷 壳 – CoolShell
酷 壳 – CoolShell
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
量子位

博客园_首页

Plist 二进制格式 Milvus 和 PGVector,哪个更好? OpenClaw 已过时?在 VS Code 中运行 Hermes Agent! 第30篇文章:一个大三计科生的自白 Manim如何在数学公式中完美显示中文? Docker 部署 RocketMQ 5 并发编程核心概念辨析 C#事务处理最佳实践:别再让“主表存了、明细丢了”的破事发生 CLI 是什么?为什么大厂突然集体卷命令行? 【从0到1构建一个ClaudeAgent】协作-自主Agent UIImageView 设置图片不生效的原因排查 最小二乘问题详解20:无先验约束下的增量式SFM自由网平差 痞子衡嵌入式:大话双核i.MXRT1180之XIP应用里借助MU实现可靠Flash IAP的方法 AI Chat 封装, SemanticKerne.AiProvider.Unified 已发布 Windows下右键编辑js文件无法打开记事本——在注册表中使用环境变量 在后台服务中使用 Scoped 服务,为什么总是报错? H200 安装驱动并使用sglang启动模型 wireshark 抓包Trap上报告警内容 我用 AI 辅助开发了一系列小工具(2):图片压缩工具 [A Primer On MC and CC] 2.1 Memory Consistency 1 - 指令重排序和 SC 模型 Oracle数据库SCN推进技术详解与实践指南 玩转控件:封装个带图片的Label控件 Claude Code 4.7 真正该升级的不是模型,而是你的工作流 前端小白一句话,AI 帮我做了个颜值拉满的桌面媒体播放器。当代码不再是门槛,一句话编程就是现实。 5. WorkBuddy: 小龙虾的灵魂三件套,让你的小龙虾不只是工具 SQLite 分片方案实战:三种分片策略的深度对比 告别简陋 UI!一款基于 Fluent Design 和基于 WinUI 的开源免费、现代化的 Avalonia UI 控件库 关于二进制排列组合枚举的总结 AI开发-python-LangGraph框架(3-27-LangGraph从零实现大模型智能决策工作流) ElasticSearch主分片和副本分片概念详解 【002】HTTPS 粗解:证书、TLS 握手与对后端配置的影响 Hermes Agent 一周暴涨五万 Star,但我劝你别急着追 明明连接的是Redis的DB0,为什么能查到DB3的数据? 【从0到1构建一个ClaudeAgent】协作-Agent团队 熟悉电子元器件之后,电子小白下一步该怎么走? MAF快速入门(23)通过C#类定义Skills .NET 高级开发 | 手写一个对象映射框架 FastAPI数据库ORM怎么选?我肝了三个Demo后,终于不再纠结了 mysqldump 参数拾遗:在遗忘与铭记之间 C# .NET 周刊|2026年3月5期 Claude code入门 - 陈彦斌 一文学习入门 ThingsBoard 开源物联网平台 GitHub 热门项目 | 2026年04月16日 如何为GIT设置全局勾子,为每次提交追加信息 Number.isFinite和isFinite与isNaN()和Number.isNaN的区别 PortSwigger SQL注入LAB2 推荐一个测试人必备的Skills,从功能到性能全搞定(附详细实操和安装下载方式) 筑基期:掌握Odoo基础核心知识点02(Odoo XML 开发方式详解) GLM模型这么火,咱们用vllm也咧一个呗! 深入理解 AbortController:从底层原理到跨语言设计哲学 字符串学习笔记 多租户系统框架的基础模块设计和分析设计 Apache SeaTunnel Zeta 为什么能做到“又快又稳”? AI开发-python-LangGraph框架(3-26-LangGraph基本概念及第一个简单样例) Vue 3 组件通信,别只会用 Props 和 Emits 了,这几个狠活儿你得看看 ElasticSearch7.X版本配置密码 用Manim实现动态交点计算--从一个动点问题说起 团结引擎+Addressable+Instant Game打包抖音小游戏 function call 实战:让 LLM 自动判断 pod 异常、调用日志工具并完成故障分析 bubseek —— 让 Agent 的足迹,变成团队的洞察 通过 C# 读取并导出 PDF 书签 如何用 GitHub Actions 实现 Steam 自动化发布 【从0到1构建一个ClaudeAgent】并发-后台任务 .NET 高级开发 | 定制 ASP.NET Core 框架 电子小白:什么是运算放大器(运放) zero2Agent:面向大厂面试的 Agent 工程教程,从概念到生产的完整学习路线 堆上的ORW HC32F460 USB CDC通信异常:非对齐访问异常排查 20260413-Hyperbridge 攻击事件:发生在默克尔山上的验证绕过 那些喊着AI 要淘汰你的人,正在靠你的焦虑赚大钱! 深度学习进阶(八)Swin Transformer 最小二乘问题详解19:带先验约束的增量式SFM优化与实现 SnapTranslate 3.0 正式发布:全局划词翻译 + 完整英语学习闭环,一站式搞定查词、记词、复习 工作的意义、工作的困难认知再思考 .NET + AI 进阶实战:基于类的技能开发 - 打造可治理的 Agent 能力模块 【从0到1构建一个ClaudeAgent】规划与协调-技能 上周热点回顾(4.6-4.12) 电子小白的工具三件套:面包板、杜邦线、万能板 单表五亿数据的查询优化 | Mysql、StarRocks 2. WorkBuddy:从“我是谁”到“帮我干活” C# 如何减少代码运行时间:7 个实战技巧 基于HelixToolkit.SharpDX 渲染3D模型 - 笺上知微 从零开始的双臂具身VLA起源及现阶段发展综述 - SkyXZ 记对 xonsh shell 的使用, 脚本编写, 迁移及调优 - pluvium27 受够了Vibe Coding的失控?换个起点,让AI事半功倍 从开始配置漏洞环境到漏洞复现流程 - 難しい 关于10年工作经验的程序员对OpenClaw的实战经验分享以及看法 - 虚无境 Any metadata 的内存布局 C# .NET 周刊|2026年3月2期 - InCerry 我帮你测过了,测试圈排名第二的 Skill 依然很牛逼 Skill Discovery | 无监督技能发现的经典工作总结 - MoonOut 上下文工程是什么?过时了么?一文讲明白! - 一枫说码 开了 TUN 模式还是直连?90% 的人都踩过这个坑 AScript扩展多种脚本语言 - rockey627 AI 学习笔记:Agent 的记忆机制 你能被装进一个文件里吗?——7 万人把同事"蒸馏"成了 AI - 我没有三颗心脏 Claude Code 通关手册(七):给 AI 装上技能包——Skills 完全指南 - 暮色之狐 在浏览器中快速编辑代码:VSCode Web 集成实践 - Newbe36524 蒸馏自己 skill?基于 Deepseek 的蒸馏器,丐版蒸馏方式,简单便捷 - To_Carpe_Diem Spring AI Aliababa和AgentScope,哪个更好? - 苏三说技术
做一款企业真正敢用的AI测试应用,到底有多难?究竟难在哪?
狂师 · 2026-05-29 · via 博客园_首页

这两年,AI 测试 无疑是软件研发领域最炙手可热的赛道之一。

无论是中小研发团队,还是大型企业的技术部门,在AI大模型快速普及的浪潮下,几乎都有过这样的设想:

把需求文档丢给大模型,写一段精准的 Prompt,简单对接一下企业内部知识库,再搭一个简洁的交互页面,一套能自动生成测试用例的 AI 应用,似乎就大功告成了。

从 Demo 演示、技术炫技的角度来看,这件事确实不算难。上传一份需求文档,几十秒内就能输出几十条看似专业、逻辑通顺的测试用例,足以让很多不明真相者眼前一亮,甚至还会不禁感叹,哇哦,这么牛!

但当这套 “看起来能用,还貌似很牛X” 的系统,真正接入到企业的真实研发环境、对接核心业务需求时,各种隐藏的难题会瞬间如潮水般涌来。

我要讲的第一个观点: 企业真正需要的从来不是“偶尔生成一堆看起来能用的测试用例”,更不是“摆出来好看的Demo”,而是能深度融入研发流程、支撑核心业务运行、保障敏感数据安全,并且可长期维护、持续迭代升级实用、稳定、可落地的 AI 测试能力。

而打造这样的AI测试能力,远比单纯“让AI生成几条用例”要复杂得多、艰难得多

很多团队之所以折戟,核心误区就在于:误以为AI测试的核心是“生成”,却忽略了企业真正的诉求是“长期可用、安全可控、贴合业务”。

企业要开发和维护一套真正敢用、能用的 AI 测试应用,难的从来不是“生成测试用例”这个表层动作,而是“长期可用、适配业务、保障安全”这些深层要求。

企业要建设的,从来也不是一个“只是会写测试用例的AI工具”,而是一套能解决实际研发痛点、降低测试成本、提升测试效率的企业级 AI 测试能力。而这件事,在企业中真正落地下来,要踩的坑、走的路远比我们想象中的要难得多。

今天,我们就带着大家,详细拆解一下,从企业的角度,打造这样的企业级AI测试能力,到底难不难?真正的难点,到底又体现在哪些方面?以及针对各个难点,我的一些建议。

本篇文章首发于「狂师.AI 进化社」AI测试专栏版块,摘取其中一小部分,分享给全体读者。

文章中,涉及到的内容对于建设企业级AI测试能力,非常具有参考价值,篇符较长,拆分成了上下两篇,这是第一篇

大家可先点赞、转发、收藏一波,若喜欢的人多,后续还会考虑分享一些AI测试在企业如何具体落地的技术干货。

第一个难点:企业并不缺生成工具,缺的是测试分析专业判断能力

这两年市面上绝大多数 AI 测试产品,最先解决的、最容易实现的,基本都是围绕 “生成” 这件事。

一套大家都见过或已经非常熟悉的标准流程,通常是这样子玩的:

  • 上传产品需求 PRD
  • 让 AI 读取并理解需求
  • 自动梳理出测试点
  • 一键批量生成测试用例

flowchart TB A["📄 上传产品需求 PRD"] B["🤖 AI 读取并理解需求"] C["🔍 自动梳理测试点"] D["✅ 一键批量生成测试用例"] A --> B --> C --> D

从演示效果来说,这个标准流程看起来很完整、动作丝滑,几分钟就能产出一堆看起来很专业的用例,很容易让人觉得 “AI 测试已经成熟可用了”。

但企业一旦真的拿来用,很快就会遇到几个非常现实、又很扎心的问题:

  • 质量像过山车,不可预期:同样一份需求,这次生成的效果还不错,但下次却又不行了?
  • 高度依赖 "使用人的水平":为什么换不同的人、用不一样的话术输入,结果质量差异非常大?
  • "水土不服"是常态:明明是同一套工具,为什么某些业务线觉得有帮助,某些业务线却觉得根本不能用?

出现这些问题的原因其实很简单:

市面上,很多所谓的AI测试工具/系统,本质上做的都只是“文本生成”,而非“测试分析”。

测试用例,从来不是把需求简单改写一遍或者只是换种说法复述一遍,而是基于专业的测试思维,对需求做深度拆解、风险推演、逻辑校验

背后依赖 的是一整套完整、严谨的专业判断:

  • 这个需求应该按照什么逻辑去拆解?是按业务流程、功能模块,还是数据链路?
  • 整个需求里,最关键、风险最高的测试对象到底是什么?
  • 哪些是必须保障的核心主流程,哪些是容易出问题的异常分支?
  • 哪些边界场景、临界值,最容易线上出故障、埋隐患?
  • 哪些地方要结合项目过往的历史缺陷,做重点优先覆盖?
  • 哪些结论、哪些场景,必须人工复核、绝对不能完全交给 AI?

很多不明真相的团队都陷入了一个误区:觉得 AI 能输出用例,就是有价值、能落地。

但大家忽略了最核心的一点:测试分析才是灵魂,用例只是最终呈现的结果。

没有严谨、专业的测试分析过程,生成出来的东西,只是一堆通顺的文字堆砌,根本没有工程价值,也完全没法在企业里放心用。

我要讲的第二个观点: 企业并不缺生成能力,缺的是稳定、可靠、可落地的测试分析能力。

企业真正要搭建的,从来不是一个 “文档转用例” 的批量生成器,而是一套可重复、可解释、可校验、稳定靠谱的测试分析能力

测试分析 所依赖的可重复、可解释、可校验 的专业判断逻辑,这恰恰是纯生成式 AI 的短板:

  • 需求拆解无固定逻辑:同一个需求,该按业务流程、功能模块还是数据流转拆分,没有统一标准,全靠AI大模型随机输出,自然忽好忽坏,结果不可控。
  • 核心测试对象识别模糊:AI 无法精准判断 “哪些功能是核心链路、哪些是边缘模块”,容易遗漏高风险测试对象;
  • 边界与异常场景覆盖严重不足:人工测试中,专家会基于经验重点关注边界值、异常场景,但模型缺乏行业经验,往往只覆盖主流程,忽略易出故障的 “灰色地带”;
  • 无法对齐企业历史缺陷:企业过往踩过的坑、出现过的线上故障,是最宝贵的测试经验。而AI 如果不能结合历史缺陷调整测试重点,就会重复踩坑。
  • 结果不可校验、不可追溯:生成的用例有没有漏需求、符不符合业务规则、风险点有没有覆盖全,没有明确的校验标准,全靠人工事后逐行核对,反而大幅增加了测试工作量

我的建议

企业搭建自己的 AI 测试体系,第一步要先学会跳出 “唯生成论”的误区。

与其一味追求 “生成更快、生成更多用例”,不如先沉下心,沉淀团队测试分析的标准化方法。把需求拆解逻辑、核心对象识别、风险边界挖掘、异常场景设计这些专家经验,固化成可执行、可复用的规则。

先让 AI 学会“像资深测试专家一样思考、一样分析”,再去谈生成用例。

测试用例的价值,永远建立在严谨的分析过程之上,没有过程的标准化,就没有结果的稳定性。

测试用例只是结果,严谨、专业化的测试分析过程,才是企业最核心的测试资产。

第二个难点:企业测试场景复杂多样,远不是一个 Prompt 能兜住的

很多人对 AI 测试的第一印象还停留在:“不就是写个 prompt,把 PRD 丢给大模型,让它直接生成测试用例吗?”

这种思路用来做 Demo 演示确实可以,但真要放到企业里落地,就完全不够用了。

真实企业中的测试场景远比想象复杂,随便一数,就是一堆问题:

  • PRD 本身不完整: 很多企业的需求文档只写了核心流程,异常场景、边界逻辑、权限规则、状态流转这些关键信息往往缺失,光靠一个 prompt,模型根本没法自己补全这些上下文;
  • 需求与接口文档互相矛盾: PRD、接口文档、字段规则、配置说明可能来自不同团队,内容对不上、逻辑打架是常态,模型无法自动识别矛盾,更不知道该以谁为准;
  • 业务规则太分散: 真正的核心逻辑可能散落在多个系统、配置表、旧代码,甚至只存在老员工的经验里,prompt 根本没办法把这些碎片化信息整合起来;
  • 大量功能靠配置驱动,不同客户、不同租户的规则完全不一样,AI 很难自动适配;
  • 个性化场景太多: 同一个功能在不同行业、不同项目、不同地区的规则差异巨大,prompt 很难做到动态适配这些个性化需求;
  • 输出格式不兼容:企业内部都有自己的测试管理平台,用例格式、字段结构、分类规范都有固定要求,只靠 prompt 很难一次生成就能直接用,通常还需要人工修改调整。

所以,企业真实的测试工作从来不是 “问一次、答一次” 的单轮对话,而是一个不断补充信息、持续判断、反复校验的动态过程。

Prompt 只能解决 “这一次该怎么问模型” 的问题,却应对不了复杂场景的变化和连续性;

有人会说,可以通过RAG对接企业内部知识库,但知识库 顶多也只能解决 “模型应该知道什么”,但企业真正难的是 “面对复杂情况,下一步该怎么分析、怎么测、怎么保证质量”。

一旦脱离简单的 “PRD 转用例” 场景,prompt + 知识库这套组合很快就会碰到瓶颈。

这也是为什么,真正能在企业落地的 AI 测试,绝不能只停留在 prompt 工程层面。

我的建议

Prompt 不是不重要,但它只能算是基础能力,更像是一种局部的 “话术表达”,远远构不成一套稳定可靠的能力体系,更不能作为企业 AI 测试系统的核心。

真正的破局方向,是把测试专家多年沉淀的测试方法、分析思路、行业经验,固化成可复用、可编排、可迭代的能力模块。

比如电商领域的 “订单支付全流程测试模板”、金融领域的 “风控规则与边界测试方法”、后台系统的 “权限与数据隔离测试框架” 等等。

让 AI 在面对不同业务、不同项目时,能直接调用对应的专业模块,而不是每次都靠重新写 prompt 来 “碰运气”。

简单说:prompt 只是话术,方法模块才是能力。

企业要的是长期稳定、可复用、可管控的测试能力,而不是忽好忽坏、依赖人工调提示词的 “玄学生成”。

核心问题只有一个:如何把测试专家的方法沉淀成稳定能力,并在不同企业场景中反复复用。

第三个难点:企业最难沉淀的,并不是堆功能,而是方法

很多团队做AI测试应用,早期都把心思全放在了功能开发上,觉得只要把基础功能做全,系统就能用、能交差了,重点全盯在这些地方:

  • 能上传PRD、接口文档这些资料,不用手动复制粘贴;

  • 能调用大模型,不管是自家部署的还是第三方的,能生成测试用例就行;

  • 生成的用例能导出,比如导出Excel、JSON,方便导入企业自己的测试管理平台;

  • 生成的内容能二次编辑、修改,补全AI漏写的点,调整不通顺的地方;

  • 能对接企业自己的知识库,让AI参考内部的业务资料、历史数据,避免生成脱离业务的内容。

说实话,这些功能确实都很重要,是一个AI测试应用的基础,没这些功能根本没法用。但只要这套系统真正投入企业实际使用、需要长期维护,你就会发现,真正难的根本不是这些页面上的功能,因为功能改一改、调一调都能解决,最难的是背后的测试方法和逻辑。

现实工作中,企业中的业务从来不是一成不变的,只要系统一落地,很快就会遇到一堆棘手的维护问题,让人头大:

  • 新业务来了,该怎么适配?
  • 某些行业规则很特殊,比如金融、保险、证券,如何把行业规则准确融入体系,怎么纳入?
  • 不同团队关注重点差异巨大,有的侧重主流程,有的关注异常分支、边界场景、高风险链路,怎么调整策略?
  • 某类结果经常漏测、覆盖不足、质量漂移时,怎么持续修正?
  • 某些客户、不同团队拥有自定义模板、专属格式、内部标准,怎么兼容?

如果一套AI测试系统的核心能力,全都散落在零碎 prompt 里,没有统一的规范和逻辑,这套系统只会越来越难维护。

最后的结果往往是:没人说得清能力边界,没人维护得动,越改越乱。 改一个prompt可能影响其他功能,牵一发而动全身;新同事接手根本无从下手,只能靠老员工口口相传,效率极低,甚至老员工离职后,有些逻辑就彻底没人懂了。

做企业级应用,最怕的从来不是一开始做不出来,只要投入人力物力,基础功能总能做出来,哪怕做得粗糙一点也能迭代。最怕的是做出来之后,越来越不可控,维护成本越来越高,到最后要么勉强支撑,要么只能推翻重来,白白浪费前期的投入。

我的建议

要解决这类维护难题,核心就一句话:把测试能力模块化,把测试方法显式化,把分析过程变成可理解、可调整、可复用的系统单元。 简单说,就是别把所有逻辑都堆在prompt里,拆解开、理清楚,让所有人都能看懂、能调整。

这里,我们可以参考 Skills(技能) 提倡的设计理念,把复杂的测试能力拆解开,分成一个个独立的、有明确规则的技能,不用再把所有逻辑都混在一起。

比如,可以把业务测试能力拆解为:

  • 需求结构化解析能力
  • 业务流程建模能力
  • 测试对象识别能力
  • 边界条件挖掘能力
  • 异常场景构造能力
  • 数据链路与一致性校验能力
  • 用例覆盖率评估能力
  • 风险点智能识别能力
  • 行业规则适配能力
  • ...

每个 Skills技能 模块都有明确的输入、输出和调整规则,互不干扰但又能灵活组合。

这样一来,新业务适配就不用重新开发,只需组合已有技能模块;行业规则纳入只需修改对应技能模块;策略调整也只需微调某个技能模块参数,不用动整个系统。

这就把原来“隐藏在Prompt里的模糊逻辑”,变成了“所有人都能理解、能调整、能复用的技能单元”,维护起来也会轻松很多。

这也正是 Skills 的价值所在,把Skills定义为团队将成熟的工作流、测试方法,沉淀成可复用的指令模块,用来稳定输出结果,而不是每次遇到新场景,都要重新组织prompt、手工调教模型,做重复工作。

只有把这些测试能力真正沉淀下来,做成标准化、模块化的单元,这套AI测试系统才是可维护、可迭代的。否则,每来一个新场景、新需求,都会变成一次重新手工调教模型的过程,不仅效率低,还会让系统越来越乱,最终失去企业的信任。

本文内容,还有四大难点,以及企业真正值得建设的 AI 测试应用,应该是什么样?未完待续,敬请期待下一篇!

写在最后

如果你也在关注这些AI真实落地问题:

  • AI 如何真正走进测试设计环节,而不只是停留在 Demo;
  • 企业级 AI 测试系统到底该怎么建设、怎么长期维护;
  • Agent + Skills 模式在测试领域如何真正落地;
  • 如何在效率、质量与安全之间,找到企业真正敢用的平衡点。

欢迎加入 「狂师.AI 进化社」,我们一起交流、实战、共同把 AI 测试这件事做深做实。

想要一起加入同行,可以直接添加微信:762357658

我们很期待和更多真正关心 AI 测试落地的人,一起把这件事做深、做实。