写在前面

当前，AI技术的迭代速度已然超出了我们的预期。每一天清晨醒来，都有可能看到全新测试工具发布、新框架开源或是新概念刷屏的消息。信息的爆炸式增长，不仅没有带来清晰的方向和满心的激动，反而催生了更多的焦虑：我们该选择学习哪款工具？该追逐哪个热点？该相信哪个观点？

在这股汹涌的技术浪潮中，随波逐流或许是最轻松的选择，却也最容易让人迷失方向。今天的热点，可能明天就被遗忘；今天依赖的工具，后天就可能被替代。如果我们仅仅执着于追逐表面的浪花，就永远无法看清潮水前进的真正方向。

为了不被海量信息淹没、不被认知过载压垮，我选择从追逐浪潮的队伍中停下脚步，静下心来，试图凭借自己十几年在软件质量领域的积累，结合当下对AI的有限认知，理清一个根本性问题——AI时代，软件测试的未来究竟在何方。

本文仅代表我在当前时间节点的思考与见解，随着AI时代的飞速发展，这些认知或许会随着技术的进步、自身实践与认知的提升，发生本质性的改变。

点击下方小卡片，回复“学习”

获取AI+软件测试系统课程

AI 时代软件测试从业者的三大命题

在我看来，AI 时代对软件测试从业者的影响大致分为三个命题：

命题一：源于 “测试对象” 的质变——如何测试 AI 软件系统

无论是大模型应用、Agent智能体，还是各类智能决策平台，当被测系统本身转变为AI系统，当系统的核心逻辑从确定性的“if-else”转变为“概率分布”，我们沿用已久的传统软件测试范式是否依然适用？测试范式是否需要重构？如果需要，又该如何重构？

命题二：源于 “生产力工具” 的质变——如何用 AI 赋能传统软件测试

当AI成为我们手中的核心工具，它能为我们带来哪些改变？撰写测试用例、生成代码、分析日志、预测风险——这些曾经需要投入大量人力的工作，能否通过AI实现自动化甚至智能化？这并非简单的“测试工具”升级，而是“测试生产力”的跨越式提升。

命题三：源于 “生产者” 的质变——用 AI 编写的软件系统如何测试

当代码越来越多地由AI生成（Claude Code、Cursor等工具的普及的背后，是AI编程的常态化），我们将面对怎样的系统？AI生成的代码与人类编写的代码相比，错误模式是否存在明显差异？AI对需求的理解方式，与人类是否有所不同？当开发速度因AI实现指数级提升，测试工作能否跟上这一节奏？

在本文中，我将重点围绕前两个命题展开讨论，即如何测试AI软件系统以及如何用AI赋能传统软件测试。（我所在的公司为一家创业企业，目前尚未大力推行AI编程。本着“没有调查和实践就没有发言权”的原则，命题三暂时不在本文中深入探讨，但为了保证概念的完整性，仍将其列于此处。）

命题一：测试 AI 软件系统的趋势

有人会说：这不是新命题。电商的千人千面、短视频的推荐系统，不都是 AI 软件系统吗？测试也一直在做。没错！但当 AI 时代来临，这个命题的内涵还是发生了一些变化。

AI 系统的变化

在前大模型时代，尽管已有不少企业运用自研垂类模型赋能业务，但这类实践对基础设施的要求极高：需要海量的数据积累、完善的A/B测试平台以及顶尖的算法研发团队。这也就意味着，真正能够将AI落地应用的，大多是头部软件企业。对于中腰部及以下的企业而言，自研AI的成本高到难以想象。

大模型的出现，彻底打破了这一壁垒。一时间，大量非软件企业以及腰部长尾软件开发商，都看到了在自身业务中落地AI的可能性。一家制造业工厂、一家医疗器械公司、一家律师事务所，都能够快速搭建属于自己的AI应用。

但随之而来的，是AI精度压力的指数级上升。

为什么会出现这种情况？核心原因在于应用场景的转变。过去的AI应用主要集中在ToC领域——推荐内容出错，用户划走即可；搜索结果不够精准，再尝试一次就好，用户对AI的“容错率”相对较高。但当AI进入制造业、医疗、金融、法律等严肃领域时，容错率会急剧下降。一个知识库Agent在回答“某材料的耐温极限是多少”时，若给出错误数据，对于严谨的制造业而言，可能引发灾难性的后果。

这意味着，当我们讨论“如何测试AI软件系统”时，必须面对“不同行业的AI应用该用什么标准测试”的场景化挑战。这是一个从“通用测试”向“领域适配”的跨越，也是当前AI质量保障面临的全新战场。

当然，也存在例外情况。由于目前各行业普遍存在“AI焦虑”，我们确实看到一些点状应用案例：AI被嵌入某些重业务逻辑的平台，或是客户为了避免被视为“落后”，象征性地上线AI功能。这类系统的质量保障，实际上仍以传统功能测试为主，精度并非当前优先追求的目标。但这种场景相对少见。

AI 评测给软件测试带来的挑战

AI系统的效果评测，涉及多个关键环节：评测数据如何构建、数据条数如何确定、评测指标如何选择、评测工具如何搭建。具体细节可参考https://testerhome.com/topics/43475。但如果只能挑选一个最重要的环节，我认为是**评测数据的拟真性**。

拟真性的核心要求是：我们需要高质量的业务数据作为评测数据。而要获取这样的数据，就必须在一定程度上理解业务——懂业务场景下用户如何使用AI系统，懂业务视角下什么是“正确”（即如何确定真值）。

在我近期的一些交流中，部分ToC领域的从业者甚至管理者不太理解：为什么评测数据会成为难点？对于ToC软件而言，流量充足，通过线上数据回流可以获取大量评测数据；而且绝大多数ToC业务的专家都在公司内部，数据构建相对顺畅。

但在绝大多数ToB场景中，我们面临一个残酷的现实：缺乏评测数据。

客户采购AI系统，往往是因为“自身无法解决相关问题，希望借助AI提供帮助”。但当我们需要评测数据来验证AI效果时，却发现客户无法提供“标准答案”。这是一个典型的“先有鸡还是先有蛋”的困境。

更棘手的是，即便客户愿意配合，其配合程度也往往难以支撑高质量的数据共建。数据标注需要投入人力、具备领域知识、花费时间成本——而在客户的优先级列表中，自身业务的推进才是核心重点。为本身仅起辅助作用的AI系统进行数据标注，通常排在非常靠后的位置。

面对这种情况，我们只能采取务实的策略：在项目初期，基于当前的理解预设可想到的场景，构建初步的评测数据集，得出基准值后再决定是否上线；上线后，通过持续验证，对比我们预设的场景与客户真实场景的差异，逐步优化评测数据和行业专业知识。

这就引出一个关键问题：软件测试角色如何获取更多行业专业知识？

由于测试通常处于研发流程的下游，直接接触客户的机会有限，因此需要通过方案、运营等渠道，将行业知识传递到测试环节。只有这样，软件测试才能继续发挥前置价值，在系统上线前就识别出可能的效果风险。

AI 评测是否一定要深入理解 AI 技术

先说结论：了解一些AI技术的基本概念是必要的，但深入钻研AI技术对于软件测试来说，是“锦上添花”，而非“必不可少”。

以我自身的经历为例。我曾参与一个自动驾驶业务的测试工作，当时为了读懂源码，重新复习了线性代数和概率论，在研究算法实现时，也曾纠结研发人员为什么采用矩阵左乘而非右乘、是否计算了置信区间。但越深入研究，我越意识到：这种深入对提升业务质量的帮助极其有限。

对于研发人员来说，你告诉他“高架桥下定位不准”，比质疑他“为什么用左乘而不是右乘”更有价值。只要你能清晰定义场景（高架桥下、隧道内、强光逆射等），研发人员就能有针对性地进行修复。与其花费时间深究源码，不如亲自开着车绕北京跑一圈，实地采集那些复杂场景——尽管后者看似没有技术含量，却是提升测试效果的关键性动作。

因此我的判断是：如果深入理解AI技术无法为AI评测带来实质性的提升，那么这项工作就不是强制要求。测试的核心价值，在于定义“什么是正确的场景”，而不是证明“算法为什么要这样写”。

AI 评测本身是否会被 AI 替代

命题二：用 AI 赋能传统软件测试的趋势

传统软件测试的工作范畴

软件测试的核心能力拆解及在 AI 时代的替代技术

由于各公司、团队和技术栈在成熟度上存在差异，上述工作范畴在实际执行中形态千差万别。然而，无论身处何种环境，这些表象之下始终贯穿着一些对软件测试人员的核心、普适性的能力要求。也正是这些能力，构成了软件测试群体的内部 “护城河”。

信息建模能力

能力介绍

问题规划/决策能力

能力介绍

然而，AI 在规划和决策方面的表现高度依赖于信息建模的完整性和经验沉淀的质量。如果输入信息不准确、领域模型不清晰，或缺乏真实的决策案例作为支撑，AI 的拆解与判断也可能偏离实际。因此，当前 AI 在这一维度的主要局限并不在于推理能力本身，而在于其所依赖的知识结构是否完备、经验是否可表达。

动作执行能力

能力介绍

AI 时代的替代技术

经验沉淀能力

能力介绍

人与 AI 交互的三种模式及预期场景

目前，人与 AI 的协作模式主要体现为以下三种场景：

“人在回路” 的模式带来的职业不安全感

在 “人在回路” 甚至 “人在旁路” 的人机协同模式下，另一种隐形的挑战正在浮现——AI 带来的职业不安全感。

这种不安全感主要源于两方面的心理博弈：

面对大模型，软件测试是等、走、还是冲？

Google大神新作，Agent开发终极秘籍，几乎解决了智能体所有问题（附中文版pdf）

AI+软件测试=时代红利

书中亮点 ：

✅全景化设计模式：涵盖决策、执行、环境交互及多智能体协作，帮助你从零搭建完整的 agent 架构。 

✅底层逻辑通透，筑牢开发根基：系统阐释智能体的核心定义、发展演进与核心架构，拆解智能体“自主规划—工具调用—反思优化—闭环执行”的五步循环逻辑，理清不同设计模式的底层原理与适用场景。

✅全场景实战落地：结合金融、电商、科研、办公自动化等跨行业案例，详解智能体设计模式在高精度任务处理、实时数据交互、复杂任务规划、多智能体协作等场景的落地方法。

✅理论与实践兼备：既是研究者的灵感库，也是开发者的工具箱，适合长期翻阅。 

✅ 21种核心模式：细拆解21种经谷歌内部项目验证的核心设计模式，涵盖ReAct、CodeAct、Self-Reflection、Multi-Agent Workflow、Agentic RAG等主流类型。

Antonio Gulli 的这本 424 页著作，不仅是一部 AI 设计模式手册，更是一本系统性讲述“如何打造有自主性与责任感的智能体系统”的权威指南。它融合了理论、代码与伦理三重维度，成为开发者和研究者理解 Agent 系统架构的必读之作。