从软件测试到AI测试，一个测试人的认知重启
传统测试的尽头不是更高级的自动化，而是一次彻底的认知重建。
传统测试的尽头不是更高级的自动化，而是一次彻底的认知重建。
写在前面
我做了好几年软件测试。从手动点点点，到写自动化脚本，到搭CI/CD流水线里的测试环节——我一直以为测试这条路的终极目标就是"全自动"。
直到 AI 来了。
不是那种"AI帮你写测试用例"的浅层应用，而是整个"质量保障"这件事的底层逻辑正在被重写。我花了一段时间消化这个变化，今天把这些思考写下来，算是给自己的一次认知重启。
一、传统软件测试到底在测什么
往简单了说，传统软件测试做的是一件事：验证"实际结果"和"预期结果"是否一致。
需求说用户能注册，你测注册流程；需求说购物车能加商品，你测加购逻辑。本质是把人的意图翻译成检查清单，然后逐项核对。
这套逻辑在确定性系统里运行得很好——输入固定，输出可预测，测试用例能覆盖主要路径。
但问题来了：
- 维护成本爆炸。 需求一变，用例就废。一个中等项目几百个用例，改一个按钮位置可能要改十几个测试脚本。
- 覆盖率是假安全感。 你覆盖了80%的代码路径，但bug往往藏在那20%的边界里。
- 人在模拟机器的工作。 重复执行相同的检查，人类既慢又容易出错。
这些年测试行业的进化路线是：手工测试 → 自动化测试 → 持续测试。每一步都在试图减少人的重复劳动。但本质没变——还是人在定义"什么是正确的"，机器在执行"是否正确的"。
二、AI 到底改变了什么
AI 不是给测试加了一个"智能"前缀。它改变的是测试的基本假设。
从"验证正确性"到"发现不确定性"
传统测试问的是："这个功能按需求实现了吗？"
AI 测试问的是："这个功能在所有我没预想到的情况下，表现合理吗？"
举个例子。一个文本分类模型，准确率95%。传统测试会写用例验证那95%。但AI测试要追问的是：那5%是怎么错的？错得离谱还是情有可原？面对对抗样本、分布外数据、甚至输入里的微小扰动，模型会怎样？
传统测试验证确定性，AI测试探索不确定性。 这是根本性的区别。
从"脚本"到"判断"
写自动化测试脚本，核心技能是编程。但AI测试里，核心技能变成了判断力。
- 模型输出了一个结果，你能看出它是不是"看起来对但其实有问题"吗？
- 一个prompt在99%的情况下表现良好，但那1%的失败是随机的还是系统性的？
- 模型的"幻觉"你能识别出来吗？
这些不是写脚本能解决的。你需要领域知识、需要对模型行为的直觉、需要大量的实践经验。
从"通过/失败"到"概率/分布"
传统测试的结果是二元的：通过或失败。
AI测试的结果是概率性的：模型在不同输入下的表现分布如何？置信度校准是否合理？性能在不同数据切片上是否一致？
你要测的不是一个"点"，而是一个"面"。
三、AI 测试到底在测什么
如果要我给AI测试列一个清单，大概是这些：
1. 功能性测试（但方式完全不同）
- 准确率/召回率在不同数据切片上的表现
- 边界行为：空输入、超长输入、特殊字符、多语言混合
- 对抗鲁棒性：故意构造的恶意输入，模型扛得住吗
- 一致性测试：同样的输入，多次调用结果是否稳定
2. 安全性测试（这是AI独有的）
- 提示注入：用户能不能通过特殊输入绕过系统指令
- 数据泄露：模型会不会在输出中暴露训练数据
- 有害输出：在边缘场景下，模型会不会生成不当内容
- 越狱测试：各种花式绕过安全限制的手法
3. 性能测试（维度更多了）
- 延迟：首token时间、总响应时间
- 吞吐：并发请求下的表现
- 成本：每次调用消耗多少token，多少钱
- 退化：随着对话变长，质量是否下降
4. 评估测试（最难的部分）
- 人工评估：找真人判断输出质量，贵但必要
- LLM-as-Judge：用一个模型评另一个模型，快但有偏差
- 基准测试：标准化的数据集和评分方式
- A/B测试：线上实际用户反馈
四、测试工程师的转型路径
这是我最想聊的部分。因为我自己就在这条路上。
不是要你从零开始
很多人一听"AI测试"就觉得要学机器学习、要读论文、要会炼模型。不是的。
测试工程师的核心能力——系统性思维、边界意识、质量直觉——在AI测试里依然是金子。你只是需要换一套工具和视角。
真正要补的是什么
第一，理解模型的"不确定性"。 传统软件是确定性的——同一个输入永远同一个输出。AI模型不是。你需要习惯用概率思维看问题，接受"没有100%正确"这件事。
第二，学会设计评估方案。 不是写断言，而是设计"怎么判断这个输出算不算好"。这比传统测试难多了——因为"好"是模糊的。
第三，掌握prompt工程。 不是让你去开发AI产品，而是你需要用prompt来构造测试场景、生成测试数据、甚至让AI帮你分析测试结果。
第四，学会用AI测试AI。 这听起来像套娃，但确实是趋势。用一个模型生成测试用例，用另一个模型验证输出质量，用第三个模型做回归检测。人负责设计流程和判断最终结果。
我自己的实践
我现在的工作流里，测试相关的很多环节已经用AI辅助了：
- 测试用例生成：把需求文档丢给AI，让它生成初始用例，我再审核补充
- Bug分析：把报错日志丢给AI，让它帮我定位可能的原因
- 回归测试：用AI对比两个版本的输出差异，找出潜在的回归问题
- 测试报告：让AI根据测试数据生成报告初稿
但核心的判断——哪些bug要修、哪些可以放过、测试策略怎么定——还是我在做。
五、一些不成熟的想法
"质量"的定义在扩大
传统软件的质量标准相对明确：功能正确、性能达标、没有崩溃。
AI产品的质量标准模糊得多：输出"合理"吗？"合理"谁来定义？在什么场景下合理？对谁合理？
这意味着测试工程师的角色正在从"质量检查员"变成"质量定义者"。你不只是验证质量，你还要参与定义什么叫质量。
测试会越来越"左移"
在传统开发流程里，测试在开发之后。但在AI产品里，测试和开发的边界在模糊——你写prompt的时候就在测试，你调参数的时候就在评估。
测试不再是最后一步，而是贯穿始终。
人的判断力更值钱了
AI能帮你做越来越多的执行工作，但"判断AI做得好不好"这件事，短期内还是得靠人。
这和前面那篇"AI是专家的放大器"的观点一致——你在领域里越有经验，你做AI测试就越有优势。因为你知道什么是"对的"，你能看出AI哪里"不对"。
写在最后
从软件测试到AI测试，不是一次技能升级，而是一次认知重建。
你需要接受不确定性，习惯概率思维，学会在模糊中做判断。这很难，但也很有意思——因为你在做的事情，没有现成的答案，每一步都是探索。
如果你也是测试出身，正在犹豫要不要转型，我的建议是：别等了，现在就开始。 不需要一步到位，先从用AI辅助你的日常工作开始。用着用着，你会发现自己的思维方式在不知不觉中改变。
做过一次和从未做过，是完全不同的两种状态。
本文是"肖恩的博客"系列文章之一。作者是一名从软件测试转型AI领域的开发者，记录在转型过程中的真实思考。