AI 时代测试的信号与噪音：别只让 AI 帮你做得更快

最近看了 Katalon《质量人物》栏目对 Rahul Parwal 的一次访谈：

Rahul Parwal 谈测试领域 AI 时代的噪音过滤

Rahul Parwal 是 ifm engineering 的测试专家，长期从事工业自动化、物联网（IoT）和工业协议相关测试，也是 Ministry of Testing AI 分会的负责人。

访谈里聊了很多内容：AI、测试技能、智能体工程、上下文工程、AI 评测、测试指标、探索式测试、工具选择、测试社区和个人成长。

把这些内容压缩成一个问题，访谈在问：

AI 时代，测试人员到底应该关注什么？

现在最缺的可能已经不是信息。每天都有新工具、新框架、新智能体、新提示词和新的“最佳实践”。稀缺的是从这些信息里找出有用的信号。

Rahul 这次分享的主线是：测试人员需要过滤围绕工具产生的噪音，也需要把判断力放在产出数量之前。

AI 时代，测试行业先要处理的可能是噪音

关于 AI 和测试的信息已经多到很难全部跟上。每天都有人发布新的 AI 测试工具、新的智能体、新的框架、新的自动化方案，以及又一个“AI 将改变一切”的判断。

其中最响亮的一种声音可能是：

AI 会抢走你的工作。

Rahul 把它称为当前最吵、也最容易造成伤害的噪音之一。这个预测对不对，不是唯一的问题；更现实的是，恐惧会怎样改变测试人员的行为。

一个人进入“生存模式”后，很容易开始追最新工具、追最新框架、补新的 AI 技能，然后担心自己仍然落后，于是继续追下一个东西。最后学了很多，却越来越难回答：

我到底想解决什么问题？

噪音的危险就在这里：它让人一直忙，却不一定让人更接近要解决的问题。

真正的信号：AI 正在扩大测试人员能解决的问题

如果暂时放下“AI 会不会替代 QA”这个问题，看看实际发生的事情，另一个趋势会更明显：

AI 正在扩大测试人员可以尝试和解决的问题范围。

Rahul 自己就是一个例子。他现在会研究智能体 AI，把它融入产品开发，构建智能体系统，并参与 AI 评测和上下文工程。这些事情几年前未必会自然落到一个测试人员身上。

关键在于，没有人先给他一个正式职责，然后他才开始做。更接近真实情况的顺序是：他发现了问题，发现自己可以尝试，于是开始做；能力逐渐形成，职责也随之扩大。

这对应 Rahul 提到的高能动性。它要求你主动问：

现在有什么问题值得我解决？

过滤噪音的三个习惯

Rahul 提到了三个关键词：

习惯	在工作中的表现
高能动性	主动找到值得解决的问题，不一直等待许可或安排
清晰思考	先问工具解决什么问题，再问大家是不是都在用
高度质疑	敢于追问“为什么”，要求说明证据和适用上下文

高度质疑不是为了反对而反对，而是一种判断习惯：面对最佳实践、行业趋势、厂商宣传和热门观点时，仍然愿意问：

为什么？证据是什么？在我的上下文里也成立吗？

这三个能力都不依赖某一个具体工具，因此也不容易随着工具变化而迅速过时。它们看起来不像 AI 技能，却可能是 AI 时代最实用的工作习惯。

编码不再是唯一的门槛

Rahul 提出一个有争议的观点：编码不应该再被看成测试人员最重要的差异化能力。

测试人员仍然要懂代码。变化在于，AI 正在降低从想法到实现之间的成本。

过去，一个测试人员可能有很多好想法：

做一个解决实际问题的工具；
自动化一段重复流程；
分析一批数据；
构建一个测试平台。

但最后可能停在不会某种语言、不熟某个框架、没有前端经验、不知道怎么写插件，或者不知道如何把几个系统组装起来。这就是实现鸿沟。

AI 正在快速缩小这条鸿沟。实现变得更便宜之后，稀缺资源会重新回到：

想法 + 判断 + 执行

先找到值得做的想法，再判断它是否有价值，最后把它做出来。

Selenium 和 Playwright 的经验仍然有价值

学习 Selenium、Cypress、Playwright、接口自动化或编程语言的时间没有浪费。这些经历让你熟悉 API、选择器和页面对象，也让你逐渐理解系统会怎样失败：

异步问题；
状态问题；
数据问题；
环境和依赖问题；
时序和网络问题；
不稳定测试；
薄弱的断言；
不可测试的设计。

AI 能生成 Playwright 脚本，并不会抹掉这些经验。可能逐渐贬值的是把“我会写自动化脚本”本身当成长期差异化优势。会写代码仍然有用，但理解系统如何失败、知道怎样验证结果，会更接近测试能力的核心。

QA 技能栈需要再往上一层

Rahul 提到的一组能力包括：

智能体工程；
上下文工程；
AI 评测；
评分标准；
防护边界；
系统设计。

这些词带着明显的 AI 色彩，但它们背后的问题对 QA 并不陌生。

上下文工程关注的是：怎样让 AI 拿到正确、完整、可维护的上下文。这和测试人员一直在问的问题很接近——需求完整吗？测试数据正确吗？环境配置一致吗？依赖信息齐全吗？

AI 评测关注的是：怎样判断 AI 输出够不够好。对应到 QA，就是预期结果是什么、通过标准是什么、能不能重复验证、怎样做回归、如何识别退化。

防护边界关注的是：系统在哪些边界不能越过去。这自然会连接到负向测试、安全测试、边界测试和风险控制。

所以 AI 时代不一定要求 QA 彻底换一个职业。更准确地说，是把原有的质量思维映射到新的、具有非确定性输出的系统上。

把 AI 当成一个很快、但没有方向的初级测试员

Rahul 对 AI 的定位很有用：它像一个速度很快、非常积极，却没有自己方向的初级测试员。

AI 可以很快地生成一百个测试用例，写二十个自动化脚本，分析大量日志，整理几千行文档。但它并不知道什么才是这个项目真正重要的问题。

因此，Rahul 把常见的“人在回路”反过来想成“AI 在回路”。更有用的做法，是把 AI 放进由人负责方向的质量工作流里。

人先提供目标、上下文和约束，AI 协助实现、分析和执行，人再验证输出、证据和风险，团队根据验证结果做决定。这样，责任边界才不会被速度掩盖。

不要让纠正随着聊天结束

很多人现在使用 AI 的方式是：

AI 输出错误。
人指出哪里错了。
AI 修正答案。
这次看起来对了。
关闭聊天。

下一次，AI 重新犯同样的错误。

Rahul 的说法很直接：你的纠正会随着会话结束一起消失。这不是成熟的工程反馈循环。

更可靠的做法是把错误沉淀到系统里：先发现错误，再理解错误模式，把知识写进上下文，建立评测，让之后的输出可以自动检查。

目标也应该从“我能发现这个错误”变成：

系统以后能发现这一类错误。

这正是 QA 的思路。个人经验只有沉淀为可重复执行的质量机制，团队能力才会扩大。

从提示词工程继续走向上下文工程

提示词工程是很多人学习 AI 的起点，但要把 AI 放进工程流程，仅仅写一个更好的提示词远远不够。

还需要问：

模型知道什么？
模型不知道什么？
上下文从哪里来？
哪些是事实，哪些是历史经验？
哪些规则必须始终存在？
上下文什么时候更新？
谁负责维护？

提示词更像是“这一次我要怎么问”。上下文工程关注的是“怎样建立一个系统，让 AI 长期拥有完成任务所需的信息”。

对于 AI 原生测试，后一个问题会越来越重要。一次问得好，不等于系统长期都能在正确的上下文里工作。

AI 评测：把经验变成自动检查

假设 AI 经常生成这样的测试：

执行接口。
收到 HTTP 200。
标记为通过。

但它没有检查业务结果、数据变化、副作用和状态变化。这是一个看起来完整、实际很薄的虚假测试。

第一次发现时，测试人员可以人工指出问题。更好的方式是把这种错误模式沉淀下来：定义规则，建立评测，让后续生成结果自动接受检查。

从 QA 的角度看，把这种经验变成可重复执行的质量机制，可能比学习第十个 AI 测试工具更值得投入。

机械放大器，还是认知放大器？

Rahul 提供了一个判断标准：

你正在把 AI 当成机械放大器，还是认知放大器？

使用方式	它放大的东西	需要追问的问题
机械放大器	更多代码、测试用例、文档和自动化，更快完成原来的工作	我只是做得更快了吗？
认知放大器	发现以前看不到的风险，分析以前处理不了的数据，挑战假设，解决更难的问题	我是否想得更深、解决了以前解决不了的问题？

很多团队把第一种效果报告成第二种效果。产出速度变快，并不自动等于判断能力变强。

更快不自动等于更好

假设测试人员以前每天写十个测试用例，现在 AI 帮他写一百个。仪表盘上的效率变成了 10 倍，看起来很漂亮。

但更应该问的是：

找到更多重要风险了吗？
生产问题减少了吗？
测试覆盖变得更有价值了吗？
质量门禁更可靠吗？
可测试性改善了吗？

如果答案都是否定的，十倍的输出并不代表十倍的质量。它可能只是十倍的噪音。

“测试用例成瘾”会把质量变成数量

Rahul 把它比作数饼干：

数测试用例就像数饼干。数量越来越多，却没人尝过味道。

如果 KPI 是测试用例数量，团队很快会学会优化这个数字。一个有价值的测试可以被拆成五个很薄的测试用例，数字变漂亮了，质量却没有变化。

更糟的是，维护成本、评审成本和执行成本上升，真正用于探索的时间反而下降。这是典型的指标扭曲：团队优化了被测量的东西，却没有改善想要的结果。

固定测试用例只能找到已经想到的问题

Rahul 还有一句很值得记住的话：

固定用例只能找到你已经想到的问题。

固定测试用例的逻辑是先想到一个风险，再设计验证，最后执行。探索式测试则允许测试人员先观察系统，发现异常，形成新的假设，继续探索，最后找到之前根本没有想到的问题。

所以成熟的测试体系不应该默认“更多测试用例等于更高质量”。更重要的问题是：

我们有没有更有效地发现重要风险？

测试到底应该衡量什么？

比测试用例数量更有价值的，可能是下面几个问题。

第一，生产问题是否逐个版本减少？这是直接的质量信号。

第二，测试人员能不能说清楚自己探索了什么、最担心什么。相比“我执行了 128 个测试用例”，下面的描述包含更多质量信息：

我重点探索了支付失败、重复提交和状态恢复，目前最担心的是第三方回调失败后的数据一致性。

第三，客户到底在说什么。Jerry Weinberg 的一句经典定义仍然适用：

质量，就是对某个人有价值。

质量最终要对某个重要的人产生价值，而不是让仪表盘上的数字看起来漂亮。

如果 AI 进入测试流程，我更愿意观察这些变化：过去发现不了的风险现在能不能发现，过去只能在生产环境暴露的问题能不能提前发现，质量门禁是否更严格、更可信，可测试性是否变好，团队是否能处理以前处理不了的问题。

如果同一支团队使用同一个 AI，最终能够发现以前漏掉的风险，那才是真正的能力增长。

选择 AI 测试工具时，不要只看演示

现在 AI 测试工具越来越多，每个演示都很好看。这很正常，因为演示本来就是被设计出来展示优点的。

Rahul 把挑工具比作买车：展厅里的车很干净，灯光很好，销售人员也很专业，试坐体验可能相当舒服。但要问的是：

它能不能撑过你的日常通勤？

我会在演示里问三个问题：

问它在哪里会失败。 不要只问它能做什么，还要问它在哪些地方做不好。
把键盘交给我，用我的数据。 不要只看厂商准备好的示例项目，换成我的项目、我的数据、我的需求和我的代码。
规模化和退出的成本是多少。 不只问月费，还要问规模化成本、迁移成本、厂商锁定、数据退出方式，以及已有资产能否复用。

第三个问题经常比购买价格更重要。成熟的产品应该知道自己的边界，也应该能谈清楚用户离开它之后要承担什么成本。

一个好的工具不应该害怕说明自己的弱点

Rahul 同时是多个测试工具的工具大使，但他对这个角色的理解不是帮厂商宣传，而是成为工具和社区之间的桥梁。

健康的关系应该让信息双向流动：

方向	应该带回去的内容
厂商到社区	工具能力、适用场景和已知限制
社区到厂商	真实反馈、真实问题、真实使用场景和真实限制

一个好的工具大使应该可以说“这个版本很一般”，而关系不会因此结束。允许社区表达不满，也是过滤营销噪音的一种方式。

“失败简历”过滤的是另一种噪音

Rahul 公开过自己的“失败简历”，里面包括现场演示失败、EuroSTAR 提案被拒，以及其他没有成功的尝试。

我们看别人的职业经历时，通常只看到奖项、会议演讲、社区负责人和成功项目，于是很容易形成一个错误信号：

别人一直都很成功。

真实的过程通常是尝试、失败、调整、再次尝试，有时还会再次失败，然后继续，直到某一次成功。

如果只展示最后那个成功，过程本身就被隐藏了。公开失败提醒别人：作品和能力通常经过了多次迭代。

“等我准备好了”可能永远不会发生

学习 AI 时也很容易陷入同一个循环：

等我学完提示词工程；
等我学完 Python；
等我理解智能体；
等我学完 MCP；
等我真正理解 LLM。

问题是，AI 永远会有下一个概念。

高能动性更接近另一种做法：先找一个真实问题，缺什么就学什么，做出一个可以接受反馈的版本，然后继续迭代。

“完全准备好”可能是一个永远不会到来的状态。开始做，反而会告诉你真正缺什么。

社区给你的，是可以带走的身份

Rahul 有一句我很喜欢的话：

工作给你的是一家公司的职位名称，社区给你的是可以跟着你走的身份。

工作可能给你高级测试工程师、测试负责人或测试专家这样的职位名称，但这些名称有一部分属于组织。真正能跟着你走的，是你的文章、演讲、项目、开源贡献、案例、思考和作品。

这就是工作证明：可以被别人看到和检查的工作证据。

AI 时代，工作证据可能比职位名称更重要

AI 已经可以帮助很多人快速生成简历、求职信、作品集介绍和技术文章。单纯“写得漂亮”的成本越来越低。

真正有价值的问题变成了：

你真的做过什么？
代码在哪里？
项目在哪里？
文章和案例在哪里？
你的判断过程在哪里？
别人能不能验证？

也就是：

主张会逐渐让位给证据。

这仍然是 QA 的判断方式。测试人员不会因为一个结论写得漂亮，就把它当成证据；职业能力也会越来越需要可检查的工作记录。

把自己产品化，不等于做个人营销

Rahul 对未来五年的判断比较直接：真正危险的未必是不会某个特定工具，而是没有把自己的能力产品化。

我更愿意把它理解成：把自己的能力变成别人可以看到、理解和验证的东西。

它可以是 GitHub 项目、博客、技术笔记、开源贡献、演讲、案例、演示或研究。重点不是变成网红，而是让这条链路成立：

能力 → 作品 → 证据 → 可发现性

这和写一句“熟悉 AI 测试”完全不同。前者让别人有机会检查，后者只是一个没有上下文的声明。

QA 真正稀缺的能力可能正在变化

如果 AI 继续降低实现成本，写代码、写测试脚本、生成测试数据、整理文档和制作报告都会变得更便宜。

更稀缺的能力可能是：

找到正确的问题。
判断真正的风险。
提供正确的上下文。
设计好的评价标准。
识别错误输出。
建立可重复的质量机制。
把想法真正落地。

可以把它压缩成：

想法 + 判断 + 上下文 + 评测 + 执行

这可能比继续争论“QA 到底还要不要会编码”更接近问题本身。

最后

Rahul 的访谈表面上聊了很多内容：AI、编码、智能体、AI 评测、指标、测试用例、探索式测试、工具、社区和职业发展。

但这些内容背后只有一条主线：

学会区分信号和噪音。

“AI 会抢走你的工作”可能是噪音。真正的信号是 AI 正在扩大测试人员可以解决的问题范围。

“AI 今天生成了一百个测试用例”可能是噪音。真正的信号是我们有没有发现以前发现不了的风险。

“AI 让团队提效 10 倍”可能是噪音。真正的信号是测试有没有变得更锋利。

“这个 AI 测试工具的演示很惊艳”可能是噪音。真正的信号是它放到我的系统、我的数据和我的规模下还能不能工作。

“我还没有准备好”也可能是噪音。真正的信号是有没有一个真实问题，可以从今天开始解决。

所以我很喜欢用 Rahul 提出的两个概念来判断 AI：

机械放大器，还是认知放大器？

AI 当然可以让我们做得更快。但对测试人员来说，更值得追求的是让 AI 帮助我们想得更深，发现更多以前发现不了的风险，解决以前解决不了的问题。

如果最后得到的只是更多代码、更多测试用例、更多文档和更多仪表盘数字，我们可能只是用 AI 更快地制造噪音。

真正值得关注的信号是：

同样的团队，在 AI 的帮助下，是否能够做出过去做不到的质量判断？

如果答案是“是”，那么 AI 才真正开始改变测试。

参考：

《质量人物》：Rahul Parwal 谈测试领域 AI 时代的噪音过滤:https://katalon.com/resources-center/blog/quality-people-rahul-parwal-filtering-ai-noise