软件测试这个行当，最近两年被 AI 的风吹得有点站不稳了。各种大会上，PPT 里全是 AI 自动生成用例、AI 自主探索测试、AI 智能分析缺陷的画面，仿佛明天测试工程师就要集体失业，后天 AI 就能把质量保证这件事全盘接手。
于是市面上出现了一种论调：测试的职能被 AI 打下来了，测试的价值被 AI 消解了，测试这个岗位岌岌可危了。

但真正在一线干活的人心里都清楚——AI 只是让测试零门槛成为测开，但测试最核心的工作，AI 是一点都没接过去，甚至还添了不少乱

一、测试到底在做什么
先把那些花里胡哨的概念放一边，回到地面上来。

测试的本质工作是什么？是保证质量。这件事的核心路径从来都是：梳理业务的核心主流程和异常支线，把每一条路径变成可执行的测试用例，然后一步一步地执行，观察结果，判断对错，发现问题，推动修复。

这不是什么高深的理论，这就是测试每天在做的事。
例如一个面试问到烂的电商下单流程，正向路径有几步、哪些节点会分叉、支付失败怎么办、库存不足怎么处理、优惠券叠加的优先级是什么——这些东西，需要有人去想清楚、写下来、跑一遍。

而要完成这一整套动作，至少需要三个前提：

第一，清晰的需求文档。
没有需求参照，测试就是在黑暗中摸索。业务规则是什么、边界条件在哪里、异常情况如何处理，这些东西必须有人明确地写下来，或者至少在沟通中达成共识，据我跟多数测试同学的交流来看，这一步基本没几个团队能做好。

第二，对任务性质和优先级的筛选和排序。
不是所有功能都一样重要，不是所有路径都值得同等的精力投入。核心交易链路出问题是 P0 事故，某个角落里的文案展示问题可能连 P3 都排不上。什么先测、什么重点测、什么可以放一放，这个判断需要经验和对产品的理解。

第三，沟通和对业务的了解。
测试从来不是对着文档闷头干活。产品经理说的和实际想要的可能不是一回事，开发理解的又可能是另一回事。测试往往是在这三者之间反复对齐的那个人，靠的是对业务的熟悉程度和沟通的意愿与能力。

这三个前提，没有任何一个是 AI 能替你解决的。

二、AI 能做什么，不能做什么

AI 确实让一些事情变容易了。
写个接口测试脚本，AI 能生成；分析一段代码的潜在风险，AI 能给出建议；搭个小工具做数据构造或者结果比对，AI 也能帮上忙。以前这些事情可能需要一个有一定编程能力的测开来做，现在门槛确实被拉低了，一个业务测试同学借助 AI 也能搞定。

但问题在于，这些都只是测试的周边工作，不是测试本身。

测试本身是什么？是执行用例。是打开页面、点击按钮、输入数据、观察响应、判断对错的那一下。是发现实际结果和预期不符时，凭借对业务的理解决定这到底是个 bug 还是设计如此。是在复杂的业务场景中，捕捉到那种 “虽然看起来没问题，但总觉得哪里不对” 的微妙感觉。

这些东西，AI 做不了。

原因其实很简单，而且很根本：AI 本身有幻想。 用带有幻想的 AI 去执行测试用例，这本身就是一件极度悖论的事情。测试的目的是发现软件的缺陷，如果测试工具本身就会产生幻觉——它会凭空编造一个结果、它会忽略一个关键差异、它会自信满满地告诉你 “一切正常”——那你还测什么呢？，用不确定的工具去测试不确定的项目，然后不断去完善不确定的工具，这完全是扯蛋。

所以那些鼓吹 AI 能替代测试执行的人，要么根本不懂测试，要么是揣着明白装糊涂。

三、自动化的老账
就算不扯 AI 的幻觉问题，回头看看行业里那些所谓的 “自动化”，情况也从来没那么乐观。

接口自动化、UI 自动化、巡检用例、测试平台……这些东西，行业里做了少说十年了。
它们的定位从来都很清楚：锦上添花。

自动化能做的事情，是在测试人员已经完整执行过一轮、确保了基本质量之后，接管那些重复性的回归验证工作。
它是一道后期保障，不是主力部队。它能帮你守住已知的阵地，但它开疆拓不了土。

而且就连这个 “保障” 的性质，在行业里也一直颇有争议。自动化用例需要维护，业务一变它们就失效。UI 自动化的稳定性是个永恒的老大难，今天因为网络延迟挂了，明天因为页面加载慢了两秒挂了，排查脚本本身的问题比排查被测系统的问题还费劲。多少团队的自动化跑了好几年，发现的有效 bug 屈指可数，维护成本却持续走高。

自动化从来就没有大幅提升过测试的效率。 它只是改变了测试工作的时间分布——把一部分后续的重复劳动提前支付了编写和维护脚本的成本。这不是效率的提升，这是时间换时间，而且换得还不一定划算。

那些指望 AI 自动化来解放测试生产力的人，面对的现实是：过去的自动化没做到的事，带上 AI 的自动化大概率也做不到，因为问题的本质不在 “不够智能”，而在 “测试这件事本身就不是纯逻辑推导”。

四、AI 的真正 “贡献”

更讽刺的事情还在后面。

AI 确实没有给测试提升多大的效率，但它给开发提升的效率是巨大的。

代码补全、代码生成、bug 定位、重构建议——AI 让开发的效率实打实地提升了。以前写一个模块要三天，现在借助 AI 可能一天就搞定了。开发时间缩短了，那省下来的时间干嘛呢？当然是开发更多的内容。

产品经理看到开发效率提升了，需求也从前相对克制变得大胆起来。迭代周期没变，但每个迭代塞进去的需求量肉眼可见地变多了。代码量在膨胀，变更范围在扩大，系统复杂度在加速增长。

而这些多出来的代码、多出来的变更、多出来的复杂度，最终是谁来接？
是测试。

以前一个迭代三五个需求，测试还能从容地梳理用例、执行验证。现在一个迭代塞进十几个需求，每个都是 AI 辅助开发快速产出的，测试只能用同样甚至更短的时间去消化翻倍的工作量。

更麻烦的是，AI 写的代码本身就是一个巨大的不确定性来源。AI 生成的代码看起来规范、运行起来也基本正常，但那些藏在边角里的逻辑漏洞、那些似是而非的错误处理、那些在极端情况下才会触发的 race condition——这些东西比人写的 bug 更难发现，因为它们是 “看起来正确” 的错误。

测试不仅要测业务逻辑对不对，还要额外提防 AI 编码带来的隐藏巨坑。 这多出来的工作量，谁来买单？

所以现实就是：AI 的到来，对测试而言，工作没少，反而多了。对手变强了，你的装备却没什么实质性的升级。开发端效率飙升的浪潮，涌到测试端全变成了压力和风险。

五、最后说几句现实的话。

坦诚地讲，AI 工具带来的便捷性，我们应当是肯定的。它确实让一些重复性的脚本编写、数据分析、报告生成工作变得简单，让不懂代码的测试人员也能快速拼装出一些辅助小工具。这一点毋庸置疑，否定 AI 的便利性是另一种傲慢。

但必须清醒地认识到，这份便利主要停留在 “测试开发” 这个层面，它并没有给测试核心工作带来实质性的减负。 用例依然要靠人一个个去设计、去执行，业务风险依然要靠人一条条去梳理、去判断。AI 没能替你跑完哪怕一条核心业务链路，也没能替你挡下一次因需求模糊而引发的线上事故。

因此，在日常工作中必须格外小心。
眼前堆过来的不仅是翻倍的需求量，还有那些 AI 生成的、看似规范实则暗藏逻辑瑕疵的代码。
那种 “AI 生成的代码就比较安全的” 的想法，本身就是极其危险的妄想。
你的责任是守住最终交付给用户的质量，而不是去验证 AI 的工具箱是否完美——业务质量的防线一旦后撤到 “AI 产物监督员” 的位置，崩塌只是时间问题。

更重要的是，测试的精力分配需要一场清醒的转向。
不必再把时间大量投入在自研测试平台、搭建宏伟的自动化框架这些传统测开事务上了。
AI 擅长这些，而且会越来越擅长，你在这个赛道上和 AI 拼效率，拼持久度，既没有胜算，也没有必要。

正确的发力方向，是把省下来的那点脚本编写时间，和原本可能投在平台开发上的精力，全部倾注到两件事上：沟通交流和流程把控。

去和产品经理反复磨需求，把模糊的描述逼成清晰的验收标准；去和开发提前对齐技术方案，在编码之前就掐断那些注定会爆雷的逻辑分支；去建立更严密的提测规范，用流程来过滤掉一部分 AI 代码带来的不确定性；去把上线的灰度节奏、监控报警、回滚预案提前拉到可执行的状态。

这些工作，AI 插不上手，因为它们依赖的是信任关系、业务直觉和跨角色博弈的能力。而恰恰是这些工作，在 AI 大幅搅动研发节奏的今天，成了质量保障真正的承重墙。

【注：将观点输给 AI，然后 AI 生成的短文 】
最后，用节省下来的时间多多探索副业和自己感兴趣的事，不要为了什么提升测试技术去知识付费了，都是扯蛋，毛用都没