当AI开始写测试用例，测试工程师会被淘汰吗？一位8年老测开的生存思考

原创已于 2025-02-18 16:50:58 修改

· 1.1k 阅读

11 ·

版权

文章标签：

#人工智能 #测试用例 #功能测试

于 2025-02-18 16:49:56 首次发布

职场感悟专栏收录该内容

5 篇文章

订阅专栏

一、一个凌晨的焦虑：当我的测试用例被AI“秒杀”

去年年底我在公司赶大促的压测方案。突然收到同事发来的消息： "用GPT-4生成的登录模块测试用例，覆盖率比我们写的还高3%..."

盯着屏幕上自己花了3天设计的200条用例，我第一次感受到背后发凉——那个曾经觉得AI替代测试还很遥远的预言，似乎正在变成现实。

但作为一名经历过从手工测试到自动化测试转型的老兵，我决定亲自验证：AI到底能否取代测试工程师？ 于是，我开启了一场为期两周的实验...

二、实验报告：AI写测试用例的真实水平

实验1：基础功能测试用例生成

任务： 电商购物车模块的边界值测试
Prompt输入：
"作为资深测试工程师，请为电商购物车的商品数量输入框设计边界值测试用例，要求覆盖整数、小数、特殊字符等场景"

结果对比：

指标	人工用例(8年经验)	GPT-4生成用例
用例数量	28条	36条
异常场景覆盖	15种	22种
需求误解率	0%	40%（如误判负数允许购买）

发现：

✅ 广度碾压人类：AI能瞬间枚举各种组合（如"1.5个商品"）
❌ 缺乏业务理解：把购物车当计算器测试，忽略商业逻辑（实际不可能卖0.5件商品）

实验2：自动化脚本生成

任务： 用Python+Selenium实现登录页面自动化测试
Prompt输入：
"生成带异常处理的登录测试脚本，包含：成功登录、错误密码、账户锁定场景"

结果分析：

# GPT生成代码（部分）
driver.find_element(By.ID, "username").send_keys("test_user")
# 缺失等待机制导致偶发ElementNotVisibleException
assert "欢迎页" in driver.title  # 未考虑页面加载延迟

结论：

✅ 框架级代码能力：完整实现POM模式+Unittest框架
❌ 环境感知缺失：忽略网络延迟、元素加载等现实问题

三、测试工程师的生存法则：成为AI的"教练"

在反复测试后，我逐渐看清一个事实：AI不是取代测试工程师，而是淘汰不会用AI的测试工程师。就像当年自动化测试淘汰纯手工测试一样，新的技术革命正在发生。

1. 角色升级：从"执行者"到"策略指挥官"

旧模式：70%时间写用例 + 20%执行 + 10%报告
AI时代：
- 30%训练AI（设计Prompt/校验结果）
- 40%风险评估（识别AI盲区）
- 30%效能优化（如用AI生成1000条用例后人工精选200条关键路径）

案例： 某跨境支付团队引入AI测试后，测试设计阶段缩短60%，但缺陷拦截率下降15%。后来通过**"AI生成+人工校验"双保险模式**，效率提升50%同时缺陷率降低22%。

2. 必须掌握的三大新技能

① Prompt Engineering（提示词工程）

初级：学会写约束条件

Bad："生成登录测试用例"
Good："生成包含手机号国际区号校验的登录用例，排除已过时浏览器兼容性场景"

进阶：建立测试知识库
将公司业务规则（如金融行业小数点处理规范）注入AI训练集

② AI测试监督员

开发AI验证工具链：

AI增强辅助：

③ 质量大数据分析

用ChatGPT分析缺陷库：
"分析近半年支付模块缺陷，给出TOP3根因及预防建议"
输出：

1. 异步回调超时（占比38%）→ 建议增加补偿机制
2. 加密算法版本冲突（25%）→ 建议建立版本管理规范

四、警惕！这些测试岗位正在消失

根据LinkedIn最新调研数据，以下岗位受AI冲击最严重：

风险等级	岗位类型	替代率	转型建议
🔴高危	纯手工功能测试	68%	转自动化/安全测试
🟡中危	基础API自动化测试	45%	提升框架设计能力
🟢安全	性能测试专家	12%	深化云原生压测技术