AI 时代，传统自动化测试脚本还有必要吗？
这不是一篇唱衰传统自动化的文章，也不是一篇无脑吹 AI 的文章。这是一个测试开发工程师，基于真实项目经验，聊聊自动化脚本在 AI 时代到底该怎么定位。
一、这个问题，越来越多人在问了
最近跟同行交流，发现一个很有意思的现象：
做测试的人分成了两个阵营。
一边在说"AI 都能生成用例、分析需求了，自动化脚本迟早淘汰"；另一边在说"我连自动化都还没搞明白，AI 又来了，到底该先学哪个"。
两种焦虑，其实指向同一个问题：AI 时代，传统自动化测试脚本还有没有必要？
我的判断很明确：不但有必要，而且比以前更重要。
但前提是——它不能继续停留在"能跑就行"的阶段了。
二、先说清楚：为什么 AI 现阶段不能替代自动化脚本
很多人觉得 AI 既然能理解需求、能写代码、能分析报告，那干嘛还要维护一套自动化脚本？
原因有三个，而且短期内不会变。
不可控
AI 的输出天然有不确定性。同一个需求，换个提示词、换个模型版本，可能得到不同的分析结果。
这种能力对探索性测试是好事——它帮你发现你没想到的边界。但对于每天要跑的冒烟验证来说，你需要的是确定性：输入固定、步骤固定、断言固定、结果非黑即白。
这恰恰是传统自动化脚本最擅长的。
太慢
AI 每次都要理解上下文、推理、生成判断。跑 100 条接口验证，脚本可能 3 分钟跑完，全交给 AI 决策可能要半小时。
复杂场景分析让 AI 来，批量重复执行让脚本来，各干各擅长的事。
有成本
自动化脚本写完之后，每天定时跑、部署后跑、手动触发跑，边际成本接近于零。但 AI 每次调用都有算力成本。
这不是"贵一点和便宜一点"的区别，是 0 和非 0 的区别。一个每天跑三次的冒烟流程，一年下来差距很大。
所以更合理的分工是：稳定、重复、低成本的事情交给脚本；需要分析、归纳、灵活应变的事情交给 AI。两者协作，不是替代。
三、自动化脚本在 AI 时代的新定位
以前提到自动化脚本，很多人的印象是"全量回归"——几百条脚本跑一遍，耗时几个小时，通过率看运气。
这种定位确实在衰退。但自动化脚本远不只是"全量回归"这一种用法。
第一层：稳定冒烟
覆盖系统中最核心、最不能出问题的流程。提测后第一轮验证、部署后冒烟、每日健康检查。
这类脚本的特点是：少而精，结果明确，跑不过说明有大问题。它不追求覆盖率，追求的是可信度——只要这一层过了，至少说明系统的地基没有塌。
第二层：模块专项
围绕某个模块、某次重构、某类场景建立。接口批量验证、数据状态校验、流程类场景回归。
这类脚本不一定长期执行，但在特定阶段能极大降低人工测试的重复劳动。尤其是那些人工测试成本高、容易遗漏、重复性强的场景，自动化往往比人更稳定。
第三层：AI 增强
这是新增的一层——自动化脚本的执行结果，作为 AI 分析的输入。
AI 来分析失败原因、归纳趋势、生成摘要、甚至草拟缺陷报告。脚本负责稳定产出数据，AI 负责从数据中提取洞察。
三层加在一起，才是 AI 时代自动化脚本的完整价值。
四、AI 应该接在哪些环节
不是让 AI "替你点页面"，而是让它参与到自动化测试的全流程中：
graph TB
A[需求输入] --> B["【AI】辅助分析需求\n拆分测试场景 · 识别边界条件"]
B --> C[测试人员确认测试范围]
C --> D["【AI】辅助生成\n用例框架 · 脚本模板 · 测试数据"]
D --> E[提测后调试补充]
E --> F["自动化脚本执行\nCI/CD 触发"]
F --> G[报告门户归档]
G --> H["【AI】分析失败原因\n分类问题 · 生成摘要"]
H --> I[测试人员确认]
I --> J[缺陷系统流转]
J --> K[修复后再次触发验证]
K -.-> F
style B fill:#1a1a2e,stroke:#667eea,color:#c9d1d9
style D fill:#1a1a2e,stroke:#667eea,color:#c9d1d9
style H fill:#1a1a2e,stroke:#667eea,color:#c9d1d9
style F fill:#1a1a2e,stroke:#3fb950,color:#c9d1d9
style G fill:#1a1a2e,stroke:#3fb950,color:#c9d1d9
几个关键节点展开说：
需求阶段：AI 帮你梳理业务流程、发现遗漏路径、给出自动化适配建议。但测试范围最终由你确认——AI 给的是辅助分析，不是最终决策。
提测前：需求还没正式提测，你就可以让 AI 根据需求文档先生成脚本框架、用例结构、断言思路。等真正提测后不用从零开始，基于框架调试补充就行。这一步能极大缩短从提测到脚本可用的时间差。
执行阶段：脚本负责跑，AI 不介入执行本身。自动化脚本的优势就是快、稳、便宜、可重复，这一步不需要 AI。
报告阶段：自动化报告的老问题是"有报告但没人看"——一堆日志和截图，不熟悉代码的同事根本看不懂。AI 可以把技术报错翻译成业务语言：这个失败意味着什么？影响范围多大？是环境问题、数据问题，还是真正的业务缺陷？
缺陷闭环：更进一步，AI 根据失败信息草拟缺陷报告——标题、复现步骤、实际结果、预期结果、优先级建议。测试人员审核确认后提交。这一步目前不建议全自动，但方向值得探索。
核心思路是：人来判断、脚本来执行、AI 来分析。三者各司其职，形成闭环。
五、一个真实案例：哪些让脚本干，哪些让 AI 干
理论讲完，来看一个我实际做过的项目——一套 1800+ 用例、覆盖 10 个业务模块的 Robot Framework 自动化测试工程。
这里不复述整个重构过程，而是聚焦一个问题：在这个项目里，脚本和 AI 到底是怎么分工的？
脚本负责的部分
| 环节 | 为什么交给脚本 |
|---|---|
| 冒烟验证（核心流程回归） | 每天跑、部署后跑，需要确定性结果，不能有随机性 |
| 批量接口验证（10 个模块） | 1800+ 用例逐条跑，AI 来做太慢、太贵 |
| CI/CD 自动触发执行 | 代码提交后自动跑测试，要的是秒级响应，不是等 AI 思考 |
| 并发执行策略 | 30 分钟压缩到 15 分钟，纯工程优化，跟 AI 没关系 |
| 结果推送企业微信 | 固定模板推送，不需要智能判断 |
这些环节的共同特点是：确定、重复、对速度和成本敏感。换成 AI 来做不是不行，而是没必要——脚本做得更好、更快、更便宜。
AI 负责的部分
| 环节 | 为什么交给 AI |
|---|---|
| 重构规划（梳理历史代码问题、设计改造方案） | 需要理解大量上下文、权衡取舍，脚本做不了 |
| 底层公共方法抽离 | 需要读懂多个模块的相似逻辑，找出可复用的模式 |
| 依赖冲突分析 | requirements 文件冲突错综复杂，AI 帮忙理清依赖链省了大量时间 |
| CI/CD Pipeline 配置 | 不熟悉的领域，AI 辅助生成配置、解释参数、排查报错 |
| 失败报告翻译 | 把技术报错转化成业务同事能理解的描述 |
这些环节的共同特点是：需要理解、分析、归纳，一次性或低频执行。人来做也行，但 AI 辅助能大幅缩短时间。
人负责的部分
这一层容易被忽略，但恰恰是最关键的：
- 判断哪些场景值得自动化——不是所有流程都该写脚本，AI 也不会替你做这个判断
- 确认 AI 的产出对不对——AI 帮我设计的重构方案，我逐项审核后才执行；它生成的公共方法，我跑过测试才合并
- 决定架构取舍——报告门户用纯 HTML 而不是上框架，是因为服务器资源有限。这种业务约束下的技术判断，AI 提供选项，人来拍板
分工的全景
把上面三张表合在一起看：
人：判断 + 决策 + 审核
↓ 确认方向
脚本：稳定执行 + 快速反馈 + 低成本回归
↓ 产出结果
AI：分析 + 归纳 + 生成 + 解释
↓ 辅助闭环
人：最终确认 → 进入缺陷流转
为什么要这么分？ 回到第二章的三个原因——AI 不可控、太慢、有成本。让 AI 去做它擅长的分析和生成，让脚本去做它擅长的稳定执行，让人来做判断和决策。三者各归其位，效率最高。
这不是理论推演，是在这个项目里实际跑出来的分工模式。结果是：环境搭建从折腾数天变成一键 install，执行效率提升 50%，报告从"没人看"变成"主动推送到企微 + 门户可追溯"。
六、给还在犹豫的测试同学
最后聊几句掏心窝子的话。
很多做功能测试的同学其实一直想做自动化，但总觉得门槛太高——不熟悉编程语言、不会设计框架、不会接 CI/CD、光搞环境就要折腾半天。再加上日常已经被需求评审、用例设计、功能验证、缺陷跟踪排满了，根本没有从零学起的时间。
AI 确实在降低这个入门门槛。
搭框架时，AI 可以帮你设计目录结构、生成基础脚本、解释报错信息。写用例时，AI 可以根据业务流程协助拆分测试步骤和断言点。接流水线时，AI 可以辅助配置 CI/CD、优化执行命令、整理报告输出。
你不需要先变成一个很强的开发，才能开始做自动化。更现实的路径是：从你最熟悉的业务场景出发，找到那些重复性高、稳定性强、人工执行成本大的流程，借助 AI 一点点把它们自动化、流程化。先跑通一个小闭环，再逐步扩展。
但这里要呼应前文说过的话：AI 降低的是入门门槛，而不是判断门槛。
"哪些场景值得自动化"——AI 不会替你判断。"这个脚本跑出来的结果对不对"——AI 的分析需要你审核。"应该上框架还是用纯 HTML"——业务约束下的技术取舍，最终是人来拍板。
前半篇我们讲了 AI 不可控、有边界。这些边界不会因为你在用 AI 搭框架就消失了。AI 帮你迈过了"从 0 到 1"的技术门槛，但"从 1 到 10"的工程判断力——什么该自动化、怎么接入流程、怎么让结果被团队真正用起来——这些始终是你的事。
这恰恰也是测试人员最核心、最不可替代的价值。
AI 时代不是远离自动化的时候，反而是重新进入的最好时机。工具在变强，门槛在降低，但对业务的理解和对质量的判断，永远需要人来做。
结尾
一句话收束：
AI 时代，自动化脚本不但没有过时，反而是质量工程闭环里不可缺少的基础设施。
它负责稳定执行、快速反馈、低成本回归；AI 负责辅助分析、生成、归纳和闭环。两者不是竞争关系，是协作关系。
测试人员的角色也在变——从脚本维护者，升级为质量流程设计者。你来决定哪些流程需要自动化、哪些环节让 AI 介入、怎样让质量反馈更快更清晰。
这是我理解的 AI 质量工程：不是让 AI 替代测试人员，而是让 AI、自动化脚本、CI/CD、报告平台和缺陷系统，共同组成一个更高效的质量闭环。
本文是「AI 质量工程」系列文章。上一篇聊了测试开发的 AI 工作流，这一篇聊自动化脚本在 AI 时代的定位和升级路径。后续还会分享更多实践，欢迎交流。
