1. 这个焦虑是怎么来的AI 对软件测试的真实冲击我经常在测试群里看到有人刷这句话“再不会 AI测试真的没饭吃了。”作为一个在测试行当里干了十年、这两年也在项目里实际用 AI 提效的人我想先说一句大实话AI 确实在改变这一行但它改变的方式和很多人想象的“明天就失业”不太一样。这两年能直接感受到的变化是AI 已经不是一个 PPT 里的概念了。GitHub Copilot 能帮我们补接口测试脚本ChatGPT 能帮我们分析崩溃日志Testim、Mabl 这类平台把 AI 用在元素定位和 UI 回归上还有一堆基于大语言模型的小工具散落在各个团队里专门用来生成测试数据、整理缺陷报告、辅助排查线上问题。工具越来越多自然会给人一种“AI 马上要全面接管测试”的错觉。但做测试的人应该有一个职业本能任何结论都要先看证据再看边界。AI 能做的事范围在快速扩大但它的可靠性、可解释性和业务理解能力依然有很明显的天花板。这篇文章我不想写成一个“AI 时代生存指南”式的鸡汤文而是想从一个从业者的角度把这个问题拆成三件事AI 现在到底能做多少哪些测试能力是 AI 替代不了的想跟上节奏你真正需要补什么1.1 先分清哪些“AI 取代测试”的说法靠谱网络上很多说法是把“取代”这个词用得太满了。AI 取代的不是“测试工程师”这个岗位而是一部分“模块化、重复性、不需要判断”的工作内容。说得更直接一点取代的对象不是人而是不产生增量价值的劳动。举个例子以前我们做回归测试有一批用例是“照着写好的步骤点开页面填数据点按钮比对结果”。这种工作标准化程度极高规则完全固定确实可以交给脚本去做AI 的出现只是让写脚本的成本更低。但如果测试工作里包含需求判断、风险权衡、业务理解、缺陷定性AI 目前还很难独立完成。它能帮你做很多事情但很难替你做“为什么测这个、不测那个”的决定。所以我的判断是AI 是测试工程师的放大器不是替代者。它能把一个人完成工作的效率拉高几倍但也意味着团队里可能不再需要那么多“纯手工执行”的角色。这不是岗位消失而是岗位边界在移动。1.2 现在 AI 在测试环节里到底能干什么按我自己的使用经验AI 在测试里的实际价值主要集中在以下四个方向。第一个是测试脚本生成。这大概是落地最快、最容易被感知的场景。把接口文档或者需求描述丢给大模型让它生成 pytest 或者 JUnit 的测试代码生成速度快初期覆盖率也不差。尤其是那种“字段多、组合多”的参数校验类用例人写容易漏AI 反而能列出一堆边界值。第二个是日志和缺陷分析。线上出了问题人工去搜日志经常要翻半天。大模型可以快速总结异常堆栈、聚合重复报错、给出排查方向。这个对测试工程师的价值是缩短定位时间而不是替你下最终结论。第三个是测试数据和用例设计。给 AI 一份接口定义或者业务规则它能生成正常场景、异常场景、边界场景的组合。虽然通常会有遗漏但作为第一版“头脑风暴”的产出效率比从零开始高很多。第四个是 AI Agent 类型的探索。现在已经有团队在尝试给 AI Agent 派任务让它自己读取测试环境信息、执行自动化脚本、记录异常结果。不过实测下来这类方案对环境稳定性要求很高Agent 跑着跑着可能就“迷路”了还需要人来兜底。这个方向未来会越来越成熟但眼下更适合把它当作“高级辅助工具”而不是完全不用管的全自动方案。1.3 真正会被 AI 挤压的是哪一类测试工作如果非要说哪些测试工作风险最大我的观察是机械执行型、不做思考的测试工作未来一定会被挤压。举个例子某外包团队专门负责“每天把主流程用例跑一遍”遇到失败就截图提单。这种工作本身不产生判断、不维护用例、不跟踪根因客观来说替换成本很低。AI 或者 RPA 都能做而且不会累、不会漏点按钮。相反下面这些工作 AI 暂时很难替代需求评审里判断“这个功能上线会不会引起账务不一致”看到一个偶现缺陷时能结合业务链路猜测根因方向版本发布前根据变更范围和风险点决定“今天到底重点回归哪里”线上监控出现告警时辨别“这是数据问题、环境问题还是代码问题”。这些都需要测试工程师对业务、系统架构和用户场景有真实理解而不只是会操作工具。所以我一直觉得测试的核心产出是“质量判断”不是“执行动作”。AI 让执行动作变得便宜反而让质量判断变得更加值钱。2. 不会被淘汰的测试工程师核心能力拆解既然 AI 已经把一部分执行工作接走了那剩下的测试工程师到底靠什么吃饭我梳理了几个我认为很难被替代的核心能力大家可以对号入座看看自己在哪方面比较强。2.1 测试思维和业务理解的不可替代性AI 可以处理文本、代码、日志但它不理解业务背后的“为什么”。我举一个自己踩过的例子。之前做一个库存系统AI 生成了一组扣减库存的接口测试用例覆盖了正常扣减、库存不足、参数缺失这些常规场景看起来挺专业。但真正上线前风险评估时发现一个更关键的问题大促期间同一个用户可能同时从购物车、直播、活动页三个入口下单如果库存临界系统能不能保证不会超卖这个场景不在 AI 生成的用例里因为 AI 只看到了接口定义没有看到“电商大促”这个业务上下文。这就是测试思维和业务理解的差别。AI 能帮你把规则内的边界测得很全但规则外的风险需要人来发现。一个测试工程师如果懂得用户怎么用产品、业务方在意什么指标、系统哪里最容易出问题他的价值就远远超过一个“AI 用例生成器”。2.2 质量工程全局视角从“执行者”变成“守门人”过去很多团队对测试的印象是“最后一道关”等开发写完了测试上来点点点发现问题就提单。但在 AI 时代这种工作方式越来越不成立。原因是如果 AI 能自动执行大量回归用例那么花在执行上的时间会越来越少真正需要人投入的地方变成了“什么时候测、测哪些、测到什么程度算合格”。这时候测试工程师的角色要从“执行者”变成“质量守门人”。你需要:参与需求评审提前发现逻辑漏洞看懂架构方案判断改动会影响哪些模块在有限时间内根据变更风险和用户影响决定测试优先级通过分析线上数据和监控指标持续反向修正测试策略。说白了质量保障不再只是“测功能”而是全流程的风险管理。AI 可以帮助你收集更多信息、生成更多用例但风险优先级最终还是要人来拍板。这个“拍板”的能力恰恰是经验的价值。2.3 AI 工具需要人来设计、监督和兜底很多人觉得 AI 工具是拿来即用的实际完全不是这样。我见过团队把接口文档丢给大模型生成测试用例然后不 review 直接执行结果用例里用了错误的鉴权方式跑出来一堆假的失败大家还以为是环境问题。花了大半天才发现是 AI 生成的代码本身写错了。AI 有几个天然问题做测试的人必须清楚一个是“幻觉”问题。大模型会一本正经地编造不存在的接口字段、错误码甚至生成的断言和业务规则不一致。这非常考验测试工程师的审查能力。你如果不理解业务就很难发现 AI 输出里的错误。另一个是目标迷失问题。AI Agent 虽然能自主执行任务但它没有“常识”。比如环境里突然弹出一个登录对话框它可能不知道怎么处理或者陷入循环重试。需要人在外面观察、纠正、设置超时和熔断机制。还有一个是质量评估问题。AI 生成的用例到底靠不靠谱不能只看“能跑通”。还需要看它有没有覆盖关键分支、有没有冗余、有没有把错误的预期结果当成正确。这就是为什么我说AI 不是替代测试工程师而是把测试工程师的工作重心往“审核、评估、兜底”方向推。3. 测试工程师应该掌握的 AI 工具与学习方法聊完“为什么”接下来聊“怎么办”。如果你现在还在纠结“要不要学 AI”我的建议是不用纠结直接开始用但要用对方法。以下是我总结了很长时间的一套学习路径和实操思路。3.1 从实际工作场景出发选择工具市面上的 AI 工具很多不用贪多先从自己手头最烦的工作场景切入。我给大家列一张选择参考表痛点场景推荐工具/方式注意事项写接口测试脚本效率低对话式大模型 项目里的接口文档生成代码后必须 review不要直接贴进流水线UI 元素定位不稳定Testim、Applitools 等视觉回归平台适合界面变化频繁的 Web 项目移动端要额外验证日志和报错信息看不懂大模型文本总结日志要脱敏不要把生产数据直接发出去测试数据构造繁琐大模型生成 SQL 或 JSON 数据注意数据合法性和隐私合规用例维护成本高用 AI 生成用例初稿再人工补业务规则不要追求“AI 全自动生成”要追求“人机结合”我特别想强调一点不要一上来就追求“全自动”。全自动意味着你要投入大量的工程化工作去处理边界、异常和稳定性这个成本比想象中高得多。更务实的做法是先拿 AI 当加速器在单个环节上把人解放出来等跑通了再考虑端到端的自动化。3.2 先搞懂基础概念再动手学 AI 不需要从数学推导开始但基础概念总要懂一点否则你会被各种技术名词绕晕。最少要理解几个词模型你可以把它理解成一个很大的“函数”输入文本输出文本。不同模型能力差异很大要按任务选。推理模型根据输入生成输出的过程。推理成本和时间会影响你把它用在测试脚本里的方式。提示词你给模型的指令。同样一个模型提示词写得清不清楚输出质量能差好几倍。Agent一个能自主规划和执行任务的智能体。它通常会把任务拆成多步每一步调用工具或模型最后汇总结果。理解完这些基础概念就可以上手实践了。我给大家建议一个四步学习法写提示词练习每天挑一个测试里的真实场景比如“帮我写一份登录功能的测试用例清单”强迫自己把需求描述清楚。在测试脚本里调用 AI API学会用 Python 调大模型接口把智能生成能力嵌到自己的测试工具里。做一个小项目选一个自己手上的接口用 AI 生成一版 pytest 用例然后人工 review、补全、执行记录前后效率变化。关注 AI Agent 测试找一些开源框架试着让 Agent 执行简单的测试任务观察它怎么理解需求怎么分配步骤怎么汇报结果。这套路径的核心不是为了让你成为一个 AI 专家而是让你成为一个“会用 AI 解决问题的测试工程师”。这是两个完全不同的目标。3.3 实操示例用 AI 辅助生成接口测试用例下面我用一个非常常见的场景给大家演示假设我们要测试一个“用户余额扣减”接口接口接收user_id和amount返回一个业务码。你可以把下面这段提示词发给大模型你是一名资深测试工程师请根据以下接口定义设计测试用例并给出 pytest 代码。 接口POST /api/v1/user/{user_id}/deduct 请求参数amountint必填表示扣减金额 业务规则 1. amount 必须大于 0 2. 用户余额不能小于扣减金额 3. 扣减成功后余额同步变更 4. 并发扣减时不能出现负余额。 请覆盖正常、边界、异常场景并为每个用例注明业务目的。AI 生成一版用例框架后我们还要人工 review 和补全。最终代码可能是这样的import pytest import requests BASE_URL http://example.com/api/v1 def deduct(user_id, amount): return requests.post(f{BASE_URL}/user/{user_id}/deduct, json{amount: amount}) def test_deduct_success(): resp deduct(1001, 50) assert resp.json()[code] success def test_deduct_zero_amount(): resp deduct(1001, 0) assert resp.json()[code] param_error def test_deduct_negative_amount(): resp deduct(1001, -1) assert resp.json()[code] param_error def test_deduct_insufficient_balance(): resp deduct(1001, 999999) assert resp.json()[code] insufficient_balance def test_deduct_concurrent_race(): # 并发测试需要多线程或使用测试平台这里演示用例意图 pass这个例子的关键点在于AI 帮我们把用例骨架搭出来了但并发场景、业务规则细节、断言值的正确性都需要人来把关。我见过有人把 AI 生成的一堆用例直接当成测试资产结果里面混入了很多重复、无效甚至错误的案例反而增加了维护成本。正确的姿势是AI 产出初稿 - 测试工程师 review - 业务补全 - 纳入资产。4. 实操中的坑和应对AI 辅助测试避坑指南这一部分是我觉得最有价值的因为这些坑都是我在真实项目里踩过的文档里很难找到。4.1 别把 AI 当绝对正确AI 生成的用例、代码、结论本质上都是“概率性的输出”不是“可验证的事实”。尤其在涉及业务规则时AI 很容易想当然。举一个很典型的例子给 AI 看一段商品优惠券的需求问它优惠券和满减叠加时怎么计算它可能会按照“默认两者互斥”来设计用例。但产品实际规则可能是“先满减再打折”或者“优惠券不参与满减门槛计算”。这种情况下AI 生成的用例不仅没用还会误导你把错误的逻辑当成预期结果。所以我给自己定了一个原则AI 输出只当建议不当标准。任何一条 AI 生成的测试用例在进入资产库之前都要回答三个问题这个用例的业务依据是什么预期结果是怎么推导出来的如果失败了我能不能解释失败原因如果这三个问题任何一个答不上来那这条用例要么继续研究要么直接丢弃。4.2 AI 生成的用例质量怎么评估我们不能因为“是 AI 生成的”就降低质量要求。我推荐把 AI 生成用例当作一种“测试设计辅助”然后用老办法评估效果代码覆盖率生成一版用例后先跑覆盖率看关键方法、分支有没有被覆盖到。覆盖率低说明需求理解还不够。需求覆盖率拿 AI 生成的用例列表和需求文档逐条对检查有没有漏掉显性需求和隐性边界。缺陷检出率这是最硬核的指标。如果 AI 生成的用例能发现几个漏网缺陷说明有价值如果只是把已有用例重复了一遍那就要考虑是不是场景选得不好。还有一种实用做法是“反向验证”把 AI 生成的用例交给项目里另一个同事评审让他挑毛病。因为写用例的人很容易陷入自己的既定思路旁观者更容易发现问题。4.3 数据隐私与权限风险不能忽视这是很多团队最容易忽略的问题。有些测试岗位的小伙伴为了图方便直接把生产环境的 SQL、用户手机号、日志片段复制到外部 AI 工具里然后让 AI 帮忙分析。这个动作风险极高。一个重要原则任何发到外部 AI 工具的数据都要先脱敏。凡是能定位到具体用户、具体订单、具体内部 IP 的信息都要做替换或者模糊化。公司有明确规定的更要严格遵守。如果公司不允许使用外部 AI那就用内部部署的模型或者用本地私有化方案而不是自己去绕。另外还要注意AI 生成的代码有可能包含许可证风险。比如它生成了一段和某个开源项目高度相似的代码如果你不清楚来源直接用到商业项目里可能会带来合规问题。所以对 AI 生成的代码至少要做一个代码来源审查再进代码库。常见坑后果应对方法AI 生成的用例直接入库错误案例污染资产必须人工 review 评审把生产数据发给外部 AI数据泄露风险脱敏后再使用不验证模型输出直接执行脚本跑错浪费时间先小范围验证再推广盲目追求全自动维护成本过高从单点辅助开始稳扎稳打5. 面试与简历如何呈现你的 AI 能力最后聊一个很现实的问题既然大家都在卷 AI那面试的时候怎么写简历、怎么回答问题才能不显得空洞我看了很多测试简历也面试过不少候选人发现大部分人还停留在“听说过 AI”这个层面。5.1 不要空谈 AI要讲场景如果简历上写“熟练使用 AI 进行测试”我基本会跳过。这个说法太虚了没法判断你真实的水平。真正的加分项是具体的项目描述比如“基于大语言模型生成接口测试用例人工补齐业务规则单接口用例编写时间从半天缩短到 20 分钟。”“利用 AI 辅助分析线上崩溃日志平均定位问题的时间缩短 30%。”“落地 AI 视觉回归工具替代原有的图片对比脚本UI 漏报率明显下降。”你看这些描述都有场景、有动作、有结果。哪怕你只是在小范围试用也能体现出你的思考能力和落地能力。5.2 用 STAR 方式描述 AI 测试项目如果你想讲一个完整的“AI 测试”项目建议用我下面这个模板Situation背景某个新功能迭代快每次回归都要花两天时间整理用例且用例遗漏严重。Task任务提高用例设计效率保证核心场景不遗漏。Action行动把接口文档和历史缺陷整理成结构化提示词交给大模型生成初版用例再组织一次人工评审补齐业务规则并沉淀成可复用的测试资产。Result结果用例准备时间缩减了一半上线后核心流程漏测率明显下降。面试官最想听的就是“你为什么会想到这样用 AI”以及“过程中遇到了什么问题”。你可以把 4.1 里说的“AI 幻觉”和 4.3 里说的“数据脱敏”抛出来这比背一堆 AI 名词更能证明你是真正实践过的人。5.3 高频面试问题与回答参考我把自己面试候选人经常问的几个问题整理一下顺便给一个参考思考方向面试官问题参考回答思路你怎么用 AI 做测试别背概念讲一个自己实际做过的场景包括输入、输出、人工介入点AI 会不会取代测试工程师不会整体取代但会取代机械工作测试工程师要往质量守门人方向转AI 生成的用例你能放心吗不放心需要人工 review、覆盖率检查和业务验证如果 AI Agent 在测试过程中跑飞了怎么办设超时熔断、沙箱隔离、人工干预、结果复核你了解 AI Agent 怎么扛并发吗可以从任务调度、限流、结果异步处理等角度谈不用追求深入这里多说一句面试时千万不要把 AI 吹得无所不能。面试官往往比你更清楚 AI 的边界你要是满嘴“全自动智能测试”反而显得没有实操经验。承认 AI 的局限性并说明你在边界上的处理方式才是成熟的回答。我个人在实际操作中最深的体会是AI 像一个非常聪明但缺少常识的实习生你给它清晰的指令它能给你惊喜你放养它它也能闯出一堆祸。真正能让你在 AI 时代站稳脚跟的不是会调几个接口而是你能把业务逻辑、质量风险和工程效率的平衡点想明白。从明天开始可以挑一个自己最烦的重复性测试任务让 AI 帮你做一版然后你只负责审。这个动作本身就比焦虑有用。