夜雨聆风晚上九点半,办公室只剩下小林工位的灯还亮着。
需求是前天才冻结的"购物车满减+优惠券叠加"功能,测试领导要明天上午十点前出一版覆盖完整的用例。小林对着 PRD 一条条往 Excel 里敲:满 100 减 20、满 200 减 50、券和满减能不能叠加、叠加后金额为负怎么办、券过期了点结算……敲到第 187 条时,她自己都记不清"满减档位"和"会员等级"的组合到底覆盖全了没有。
这个场景,但凡做过几年测试的人都不陌生。我们不是不会写用例,而是被海量、重复、机械的组合枚举拖住了脚步——真正需要动脑子的边界判断和业务风险,反而没时间细想。
而今天,同样一份 PRD,我用一段提示词加一个脚本,三分钟拿到了 200 多条结构化用例的初稿,小林只需做她最擅长的事:审核、补漏、判断哪些是真正的高风险路径。
这就是这个专栏想跟你聊清楚的事:AI 到底在如何重塑软件测试,以及我们这些人,该往哪走。
一、先搞清楚:测试工具的三个时代,我们走到哪了
要理解 AI 带来的变化有多大,得先看看我们是怎么一步步走过来的。测试这行的工具演进大致经历了三个时代,每个时代都解决了上一代的痛点,也留下了自己的"债"。
第一个时代:手工与脚本录制(2000 年代)
最早的测试核心就是"人肉":对着需求文档一条条手写用例,再一步步手动点击执行。后来有了 QTP(后来的 UFT)、Selenium IDE 这类录制回放工具,你点一遍操作,工具录成脚本,下次自动重放。
它解决了什么:把"重复点击"自动化了,回归测试不用每次纯手点。
它留下的痛点:录制脚本极其脆弱。页面一个按钮 id 变了、布局调整了,整条脚本就崩,维护成本高到很多团队录完一轮就再没跑过。用例设计本身,依然 100%靠人脑。
第二个时代:框架自动化(2010 年代至今)
这是大多数团队现在所处的阶段。Selenium WebDriver、Appium、JUnit/TestNG/pytest、Postman/RestAssured、JMeter……一整套以"代码"为核心的自动化框架成熟起来。测试不再是录制,而是写代码:用 Page Object 封装页面、用断言库校验、用 CI 跑流水线。
它解决了什么:脚本可维护性大幅提升,自动化测试真正进了工程实践,能进 CI/CD、做持续回归。
它留下的痛点:门槛和成本都转移到了"写"和"维护"上。
用例设计还是人工——框架只负责"执行","测什么"依然得对着需求一条条想。 脚本本身要持续投入,元素定位、等待策略、数据准备哪样不上心,脚本就开始飘红。 机械工作没被消灭,只是从"手点"变成了"手写一大堆相似的断言和数据"。
一句话:我们把"执行"自动化了,但"思考"和"编写"这两件最耗人的事,基本没动。
第三个时代:大模型智能时代(2023 年至今)
转折点是大语言模型(LLM)的成熟。ChatGPT、DeepSeek、通义千问、Claude 这类模型,第一次让机器具备了"理解自然语言需求"和"生成结构化内容"的能力。这意味着前两个时代一直没被触碰的硬骨头——用例设计、数据构造、脚本编写、日志理解——第一次有了被部分自动化的可能。
还是小林那个"满减+优惠券"需求:
框架自动化时代:你得先把 187 条用例想出来,再把关键路径翻译成 pytest 代码。 大模型时代:把需求、满减规则表、券规则丢给模型,让它先穷举组合、生成用例草稿,你再审核裁剪;关键路径的 pytest 骨架也可以让模型先搭好。
二、AI 能做什么、不能做什么:一份能力边界清单
市面上对 AI 测试的讨论,要么贩卖"AI 要取代测试了"的焦虑,要么是"AI 写的用例没法用"的全盘否定。两种都不对。真相是:AI 在某些环节真能打,在另一些环节真不行。把这条线划清楚,你才知道劲儿该往哪使。
下面这张表,是我实践一年后总结出来的能力边界清单。
把这张表压缩成两句话,:
- AI 擅长"从有到多"和"从乱到齐"
已经有需求,让它扩成几百条用例;已经有一堆日志,让它归类聚合。这类规模化、结构化的活,它又快又稳。 - AI 不擅长"从无到有的判断"和"对错的最终拍板"
这功能该不该这么设计、这条路径是不是核心风险、这个根因是不是真的——这些需要业务理解和责任承担的判断,目前必须由人来做。
记住:AI 负责把活干快,人负责把关干对。
三、AI 测试工作流全景
这些能力串起来,实际工作里到底长什么样? 一个完整的质量闭环链路:
- 需求阶段
PRD 进来,AI 做需求理解、生成检查清单、识别歧义点。 - 设计阶段
基于需求生成用例、补齐边界值与等价类、智能造数。这是 AI 当前价值最大的环节。 - 自动化阶段
用例落地成可执行脚本——UI 自动化、接口与契约测试、单测自动生成。 - 执行与分析阶段
脚本在 CI 里跑,AI 做日志分析、缺陷聚类、根因定位、报告生成。 - 自主探索阶段
更进一步,让测试 Agent 在边界内自主探索、发现人没覆盖的问题。 - 平台化与闭环
把上述能力沉淀成团队级 AI 测试平台,数据回流、持续优化。
从"缺陷分析"指回"需求/设计"的反馈箭头——这是整个体系的灵魂。AI 测试不是一条直线流水线,而是一个越跑越准的闭环:每一轮发现的缺陷,都会反哺到下一轮的用例设计里。
记住一件事:我们要做的不是"用 AI 写几个用例",而是把 AI 嵌进整条质量链路。
四、灵魂拷问:测试工程师该担心被取代吗
绕不开那个最让人焦虑的问题:AI 这么能干,我们测试工程师,会不会被取代?
我的答案很明确:会被取代的不是"测试工程师"这个职业,而是"只会机械执行的测试方式"。
AI 干掉的,恰恰是最枯燥、最不需要思考的活:手敲几百条相似用例、手工造一堆 mock 数据、在日志里大海捞针。这些活本来也不体现测试价值,只是因为没人替我们干,才占用了大量时间。真正不会被取代的是这些:
- 对业务的深度理解
这个满减规则在大促时会不会被羊毛党钻空子?这个鉴权逻辑在并发下会不会越权?这种判断模型给不了,因为它不为你的业务结果负责。 - 质量风险的判断与取舍
时间只够测一半,先测哪一半?上线前这个已知缺陷能不能放?这是责任,不是计算。 - 测试体系的设计能力
怎么把 AI、自动化、人工探索组织成一套高效的质量保障体系——这恰恰是 AI 时代最稀缺、最值钱的能力。
与其担心被取代,不如想清楚转型路线。这条路大致这样走:
- 传统测试工程师
(手工/自动化执行)→ 把 AI 当工具用,先把重复劳动甩出去,把时间换回来。 - AI 测试工程师
(会用 AI 设计用例、造数、分析缺陷)→ 不仅会用工具,还懂得怎么写好提示词、校验 AI 输出、把 AI 接进现有流程。 - 质量平台工程师 / 测试架构师
(能搭建团队级 AI 测试平台)→ 把个人经验沉淀成平台能力,从"一个人快"变成"一群人快"。
焦虑没有用,卡位才有用。早一点把 AI 变成自己的"外挂",你就早一点站到取代别人的那一侧。
下篇预告
下一篇《大模型基础与提示词工程(为测试而学)》。
我们下篇见。
