用AI做自动化测试，哪些是真不行，哪些是你不会用？

在测试圈子里待久了，你会反复听到同样几种对 AI 测试的抱怨。

有些抱怨，是真的。AI 现阶段确实干不好，硬上也没用。

还有一些，说白了是自己基本功没到家，自身技能不足不自知，硬要锅甩给了"AI "。老实讲，这种我一点都不同情。

但更常见的，其实是第三种情况——大多数人都停在“会一点，但远远不够”的阶段。说完全不会，也不准确，毕竟还能让 AI 勉强跑出些结果；可要说真会，脚本又总是隔三差五出问题。Prompt 随手写两句就收工，业务规则讲不透，可测性这类基础设施也懒得补齐，结果就是 AI 一会儿灵，一会儿不灵，今天刚跑通，明天可能就失效。说到底，这种情况真怪不到 AI 头上，问题还是出在能力没有学扎实。

今天咱们来掰开聊一聊。

AI 也能做，但做的不够好的几件事

这一类是我重点想聊的。AI 确实能上手——能产出代码、能跑通流程、能交付一个看起来像那么回事的 Demo。但你真拿它去测生产业务，就会发现它只做到了 60 分，剩下那 40 分还得靠人补。下面这几件，就是典型的"能做，但做不好"。

1. 业务断言

"业务断言"听着就是一句 assert，但真正卡人的从来不是语法，是"断什么"。

要断的不是接口返回 200，是业务结果对不对——订单金额算对没、风控规则触发对没、积分发放对没。这一层，很多时候，连人工都不一定能讲得很不清楚，更何况是想让AI来做好 。

举个促销的例子：满 300 减 50，会员再打 8 折，还能叠加一张 20 元优惠券。

让 AI 点完一个下单流程没问题。但你让它判断"这个订单的最终金额对不对"——它开始瞎猜了。

AI 能写出这种：

# AI 默认输出：通用的接口断言def test_create_order():resp = client.post("/api/order", json=payload)assert resp.status_code == 200assert resp.json()["order_id"] is not None

但真正要验的，是这个：

# 真正的业务断言——AI 写不出来data = resp.json()# 满减 → 折扣 → 券，顺序不能错expected = (300 - 50) * 0.8 - 20assert data["final_price"] == round(expected, 2)assert data["discount_sequence"] == "fullcut_discount_coupon"# VIP 叠加优惠会触发风控规则assert data["risk"]["triggered_rules"] == ["RULE_VIP_OVERLAP"]# 积分 = 实付金额 × 会员积分系数assert data["points_earned"] == int(expected * member_point_ratio)

第二段代码里的每一行，都需要知道促销规则、风控规则、积分规则。这些不是文档里读一遍就能抓住的——是在需求池里泡、跟产品吵、上线翻车翻出来的。

这一块，AI 替代不了，别浪费时间硬塞。

2. 复杂异步链路验证

"异步链路验证"听着抽象，场景却很常见——用户点个按钮，背后牵动的是一整条链路。下单扣库存、库存扣了发消息、消息触发推物流、物流到了回写状态。中间任何一环异步挂掉，前端照样显示"成功"。

AI 的问题在哪？它只看得见同步返回那一秒，背后那一串异步发生了什么，它压根不知道。

举个真实场景：下单 → 扣库存 → 生成订单 → 触发消息 → 推送物流 → 更新状态。一条链路穿六个系统、三张表、两个消息队列。

AI 默认只会写这种：

# AI 写的：只验了同步返回def test_order_flow():resp = client.post("/api/order", json=payload)assert resp.status_code == 200print("✅ 订单创建成功")

看起来过了，实际上真正会出问题的全是异步环节：

# 真正要验的——AI 不会主动写assert resp.status_code == 200order_id = resp.json()["order_id"]# 1. 订单创建消息真的发出了msg = consume_mq("order.created", timeout=5)assert msg["order_id"] == order_id# 2. 库存真的扣了assert db.query("SELECT stock FROM sku WHERE id=%s", sku_id) == origin_stock - 1# 3. 物流队列收到了推送assert mq_count("logistics.push") == 1# 4. 订单状态在 5s 内流转到 PUSHEDwait_until(lambda: order_status(order_id) == "PUSHED", timeout=5)# 5. 幂等：重复调用不会重复扣库存client.post("/api/order", json=payload)assert db.query("SELECT stock FROM sku WHERE id=%s", sku_id) == origin_stock - 1

中间任何一环异步失败，AI 都看不见。你以为它过了，库存早超卖了。

这种链路，目前没有绝对银弹。靠人先梳理清楚规则、靠监控、靠对账，AI 进来最多是个跑腿的。

3. 性能根因分析

性能问题，难的不是"发现慢"——加个埋点、配个阈值告警，谁都会。难的是"为什么慢"。

慢在 SQL？慢在连接池？慢在下游？慢在 GC？还是 Redis 里藏了个大 key？这背后靠的是经验、是排查路径、是对整套系统的理解。AI 能报信儿说"接口慢了"，但真要往根因深挖，它顶多算个新手。

AI 能告诉你"接口慢了 800ms"，也能告诉你"SQL 没走索引"。

# AI 能做的：阈值告警def test_api_perf():resp = client.get("/api/products")assert resp.elapsed.total_seconds() < 0.5

但真正的根因定位，它干不了：

# 下面这套，AI 能辅助但不能独立完成1. 看火焰图 → 70% 时间卡在 redis_cmd2. 查慢日志 → 发现一个 KEYS * 扫描3. 查监控曲线 → GC 时间同步上涨4. 结合经验 → 判断是连接池配置   大 key 共同导致5. 给出方案 → 业务侧拆 key，运维侧调连接池参数

报信儿归它，破案而得要依靠人来做。

AI 其实可以，但你不会用的几件事

再往下看第二类，情况恰好和前面相反。下面这些事，AI 其实不但能做，而且通常做得并不差。要是还觉得“AI 在这块不行”，问题十有八九不在 AI 本身，而在使用方式上——要么应用缺少足够的可测性，要么 Prompt 交代得不够清楚，要么底层基建压根没搭稳。说白了，这一类出了问题，责任大多还是得自己来扛。

1. 元素定位

先说个事实——现在主流的 AI（Claude、Cursor、Copilot）写 Playwright 代码，默认就用 get_by_role、get_by_label；写 Appium 默认就用 accessibility id。绝对 XPath 早就不是 AI 的默认选择了。

那为什么你的 UI 脚本还是崩？问题不在 AI 选什么定位策略，在你应用根本没给 AI 留可用的"锚点"。

AI 默认写出来的代码，现在长这样：

# ✅ Playwright：AI 默认就用智能定位，根本不写 XPathpage.get_by_role("button", name="提交订单").click()page.get_by_label("手机号").fill("13800138000")

# ✅ Appium：AI 也默认走 accessibility iddriver.find_element(AppiumBy.ACCESSIBILITY_ID, "login_button").click()driver.find_element(AppiumBy.ACCESSIBILITY_ID, "phone_input").send_keys("13800138000")

代码看着没问题，一跑就崩。为什么？因为你应用长这样：

提交

# App：所有元素的 ContentDescription 都叫 "button"# AI 想抓 accessibility id，抓出来全是同一个名字

AI 想 get_by_role("button", name="提交订单")，结果你页面里同时有 5 个"提交"按钮；想 ACCESSIBILITY_ID("login_button")，结果你 App 压根没设这个标签。

这不是 AI 写得烂，是你应用的可测性烂。

新一代 Agent 工具（agent-device、mobilerun）也是同一个逻辑——它们基于无障碍树给元素分配语义引用：

$ agent-device snapshot# @e1 [button] "提交订单"# @e2 [text-field] "手机号"$ agent-device fill @e2 "13800138000"$ agent-device click @e1

但前提还是那句话——你 App 得有无障碍树可读。把可测性基建做好，AI 找元素的稳定性立刻上一个台阶。不做这件事，换什么模型来都白搭。

2. 测试数据

"测试数据"是抱怨重灾区——"AI 生成的数据全是 test123、张三李四，一点不真实"。

但你先别急着骂。AI 给你 test123，是因为它脑子里只有 test123 该有的信息量。你跟它说"生成 10 个用户"，它不知道你的业务、不知道沙箱号段、不知道风控规则——除了 test1 到 test10，它还能给你啥？

❌ 你的 Prompt：

"生成 10 个测试用户"

AI 老老实实输出：

test1, test2, test3 ... test123, password123

你把规则说清楚，立刻不一样：

✅ 你应该写的 Prompt：

"""生成 10 个测试用户，要求：- 用户分三类：普通用户 5 个、VIP 3 个、商家账户 2 个- 手机号以 138/139/188 开头（沙箱号段）- VIP 账户 level 取值 3-5，余额 1000-50000- 商家账户必须有 shop_id 且 status='active'- 避开风控：同一手机号 24h 内不超过 3 次注册- 每个用户带一个 profile：注册时间分散在最近 30 天"""

按这个 Prompt 生成的数据，能进沙箱、能跑通业务流程、能触发各种边界场景。

AI 是个实习生。你不给需求文档，它只能给你 test123。

3. 脚本生成

让 AI 写测试代码，它默认产出的是线性脚本——从头到尾一路堆，能跑就行。

# ❌ AI 默认输出：线性脚本，能跑但难维护def test_order():client.post("/login", json=cred)resp = client.post("/cart", json={ "sku": "A1"})assert resp.status_code == 200resp2 = client.post("/order")assert resp2.status_code == 200resp3 = client.get("/order/"   order_id)# ... 一路堆下去，没有分层，没有复用

能跑，但问题一堆：步骤之间强耦合、登录流程每个用例都重写一遍、改一个接口满地回归、跑完留一堆脏数据。

这不是 AI 写得烂，是你没告诉它该按什么框架写。

你给它规则，立刻不一样：

✅ 你应该给 AI 的规则："""按 Page Object 模式生成，要求：- 页面/服务封装成类（LoginPage、OrderService）- 业务动作封装成方法（login()、create_order()）- 测试数据用 fixture 注入，不写死在脚本里- 每个 test 函数遵循 Arrange-Act-Assert 三段式- 用 pytest 框架，支持参数化- 公共步骤抽成 fixture，便于复用"""

按这个规则生成的代码，长这样：

# ✅ AI 按规则输出：分层、可复用、好维护class OrderService:def __init__(self, client):self.client = clientdef create(self, payload):return self.client.post("/order", json=payload)@pytest.mark.parametrize("user,expected", [(UserData.vip(), "VIP_DISCOUNT"),(UserData.normal(), "NORMAL"),])def test_order_discount(auth_client, order_service):# Arrangeorder_data = OrderBuilder().with_user(user).build()# Actresp = order_service.create(order_data)# Assertassert resp.json()["discount_type"] == expected

AI 默认产出的是"能跑的代码"，不是"能维护的代码"。前者靠一句 Prompt，后者得靠你给规则、给框架、给范式。

4. 等待策略

自动化测试里有一种特别折磨人的问题——flaky test。同一个脚本，这次跑过了，下次又莫名崩了，重跑一次又过，查都没法查。

但你打开那些 flaky 的脚本看一眼，十有八九都是同一个问题——等待没做好。

AI 写测试脚本，默认产出的都是这种代码：

# ❌ AI 默认输出——这是 flaky 的万恶之源time.sleep(1)driver.find_element(By.ID, "submit").click()

time.sleep(1)——多么朴实无华，多么糟糕。

为什么糟糕？因为它在等时间，不在等"该等的东西"。

环境快的时候，0.3 秒就加载完了，你 sleep 1 秒，浪费 0.7 秒；环境慢的时候，2 秒才加载完，你 sleep 1 秒，元素还没出来就点了——崩。

崩了你肯定想："那我把 sleep 加到 3 秒不就行了？"

# ❌ 更糟的"修复"time.sleep(3)driver.find_element(By.ID, "submit").click()

恭喜你，现在每个用例多浪费 2 秒，跑 100 个用例多花 3 分钟，跑 1000 个用例多花半小时。更狠的是——该崩的时候还是会崩，因为总有人网速比你想象的更差。

正确的思路反过来：别等时间，等信号。

页面给我们的信号其实很多——loading 消失了、骨架屏消失了、某个 DOM 出现了、URL 跳转了、window 变量就绪了。等这些"业务信号"，比拍脑袋等 1 秒 3 秒靠谱多了。

# ✅ Playwright：等业务信号，不等时间# 等加载动画消失page.wait_for_selector("[data-loading]", state="hidden")page.get_by_role("button", name="提交").click()# 等 URL 跳转page.wait_for_url("**/dashboard")# 等前端信号量就绪page.wait_for_function("() => window.appReady === true")

# ✅ Appium：WebDriverWait 显式等待# 等元素出现WebDriverWait(driver, 10).until(EC.presence_of_element_located((AppiumBy.ID, "content_loaded")))# 也能等自定义条件——比如购物车数量变成非 0WebDriverWait(driver, 10).until(lambda d: d.find_element(AppiumBy.ID, "cart_count").text != "0")

你看，等的是"loading 消了""URL 跳了""count 变了"——这些是业务上"真的准备好了"的信号，而不是拍脑袋的 1 秒 3 秒。

但问题是——AI 不会主动这么写。

它不知道你那个列表是异步加载的，不知道点击之后会有 loading，不知道弹窗有 300 毫秒动画，不知道提交成功会跳到 /dashboard。这些"业务时序"信息，得你在 Prompt 里告诉它：

✅ 你应该在 Prompt 里加这几句："""时序约定：- 列表是异步加载，等到骨架屏消失再操作- 点击"提交"后会出现 loading，等到 loading 消失再断言- 弹窗有 300ms 进入动画，别在动画期间点按钮- 提交成功会跳转到 /dashboard，等到 URL 变化再继续"""

AI 按这个 Prompt 写出来的代码，立刻就稳了。

等待策略这事，本质是测试的基本功。AI 不会主动判断"什么时候该等、等什么"，你得在 Prompt 里把"业务时序"讲清楚。这件事不讲明白，换什么模型来都救不了你的 flaky test。

最后啰嗦两句

写到这，回到开头那个问题——AI 做自动化测试，到底行不行？

我的回答是：行，但看你怎么用。

业务断言、异步链路、性能根因——这几件事，AI 现阶段真的做不好。让它在这些地方当主力，是难为它，也是难为自己。让它跑跑腿、提提效、辅助一下人就够了。

元素定位、测试数据、脚本生成、等待策略——这几件事，AI 真的能做。但凡你觉得"不行"，先别急着骂，回头问自己三个问题：

你的应用有没有给 AI 留可用的"锚点"（无障碍标签、testid、aria-label）？你的 Prompt 有没有把业务规则、时序、边界讲清楚？你的测试基建有没有搭扎实（数据工厂、环境隔离、代码框架）？

这三件事都没做好，换什么模型来都白搭。

至于那些喊着"AI 全自动替代测试工程师"的——醒醒，那是推销话术。

说到底，AI 做自动化测试这件事，考验的从来不是 AI 有多强，是用 AI 的人，测试基本功扎不扎实。

一个连可测性、断言、等待策略都讲不清楚的测试，配什么模型都救不了；

会用 AI 的测试，迟早会让不会用的失业。 这句话我说的。

下次你想骂"AI 不行"之前，先回头看看自己的 Prompt 和代码基建。那才是问题的根源。