从元素定位、显式等待到Page Object：当AI Agent开始自己操作浏览器，传统自动化测试到底还有没有用？

如果现在让你回答一道测试开发面试题：

Selenium和Playwright有什么区别？

很多做过自动化测试的人应该都能说几句。

再问：

显式等待和隐式等待有什么区别？

背过面试题的人基本也能答。

但是今年如果面试官继续往下问一句：

如果不是你写Playwright脚本，而是让DeepSeek Harness里的Agent自己操作浏览器，你准备怎么保证它每次都操作正确？

很多人可能突然卡住。

因为这个问题已经从：

“你会不会写自动化脚本？”

变成了：

“你知不知道AI Agent到底是怎么执行自动化测试的？”

这两周爆火的DeepSeek Harness，真正值得测试工程师关注的地方，其实就在这里。

8月13日，DeepSeek正式开放DeepSeek Harness开发者预览，并同步开源。

它有一句非常重要的设计理念：

Everything is a plugin。

模型、Tools、Skills、Session、Sandbox、Storage、Loop、Scheduling甚至UI，都可以通过插件进行组合和替换。([DeepSeek][1])

这意味着什么？

以前我们理解一个AI产品：

大模型 ≈ AI。

现在越来越接近：

AI Agent = Model + Harness + Tools + Skills + Runtime。

这也是为什么最近技术圈突然开始疯狂讨论：

Harness、MCP、Agent Skills、Browser Agent。

对于测试工程师来说，这件事情尤其有意思。

因为其中一个最天然的应用，就是：

让AI自己做自动化测试。

一、先来一道最经典的面试题：为什么UI自动化最容易“偶现失败”？

假设你测试一个电商网站。

登录之后点击：

“加入购物车”

最简单的Playwright代码可能是：

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch()

    page = browser.new_page()

    page.goto("https://example.com")

    page.fill("#username", "test_user")
    page.fill("#password", "123456")

    page.click("#login")

    page.click("#add-cart")

    browser.close()

代码没什么复杂的。

但真正做过UI自动化的人都知道：

线上项目绝对不会这么顺。

你可能遇到：

页面还没加载完成。

按钮被弹窗挡住。

接口还没返回。

元素重新渲染。

DOM发生变化。

定位表达式失效。

网络突然变慢。

于是你会看到测试平台里那个所有测试工程师都很熟悉的结果：

PASSED
PASSED
PASSED
FAILED
PASSED
PASSED
FAILED

开发问：

为什么失败？

测试回答：

偶现。

这两个字，大概是自动化测试领域最危险的两个字。

二、为什么Playwright越来越火？

原因之一就是：

它试图替你处理大量“等待”的问题。

例如：

page.locator("#submit").click()

看起来只是点一下。

但Playwright并不是看到DOM里存在这个元素就立即点击。

它会进行一系列Actionability检查。

例如元素是不是：

Visible

Stable

Enabled

以及是否真的可以接收事件。

所以很多以前Selenium时代需要自己处理的：

sleep(3)

正在被更智能的等待机制替代。

这里顺便说一道特别高频的面试题：

为什么不推荐大量使用time.sleep？

初级工程师最常见回答：

因为浪费时间。

只答这一句，其实是不够的。

真正的问题是：

time.sleep(5)

代表：

无论页面1秒加载完成，还是4秒加载完成，我都等5秒。

更麻烦的是：

如果页面第6秒才加载完成呢？

还是失败。

所以它同时带来了：

效率问题 + 稳定性问题。

这才是面试官真正想听的。

三、但是AI Agent来了以后，问题又变了

以前自动化脚本是：

工程师
 ↓
编写代码
 ↓
Playwright
 ↓
浏览器

工程师已经明确告诉程序：

点击哪个按钮。

输入什么。

下一步做什么。

而Agent模式变成：

工程师
 ↓
自然语言任务
 ↓
LLM
 ↓
Harness
 ↓
Tool
 ↓
Playwright
 ↓
Browser

例如你只告诉Agent：

登录商城，搜索iPhone，把价格最低的一款加入购物车。

以前你可能需要写几十行甚至上百行代码。

现在Agent需要自己决定：

先找登录入口。

再输入账号。

再寻找搜索框。

输入iPhone。

分析搜索结果。

比较价格。

选择商品。

加入购物车。

于是一个非常重要的问题出现了：

Agent怎么知道网页上哪个按钮是“加入购物车”？

这就进入了Browser Agent真正有意思的部分。

四、面试题升级：XPath还要不要学？

这是我特别建议今年测试开发面试准备的一道题。

很多人觉得：

AI来了以后XPath没用了。

实际上没这么简单。

传统UI自动化可能写：

page.locator(
    "//button[contains(text(),'加入购物车')]"
).click()

但是页面稍微改一下：

<button>
    <span>加入购物车</span>
</button>

你的定位方式可能就需要调整。

Playwright更推荐利用用户可感知的信息：

page.get_by_role(
    "button",
    name="加入购物车"
).click()

这件事情到了Agent时代更加重要。

因为AI并不像传统脚本那样永远依赖一个写死的XPath。

它更希望理解：

“页面上有一个用户认为是加入购物车的按钮。”

所以未来UI自动化可能越来越从：

DOM定位

走向：

语义定位。

但注意。

这并不意味着CSS、XPath、DOM不用学了。

恰恰相反。

如果Agent定位失败，你作为测试开发工程师需要知道：

到底为什么失败。

AI可以帮你写Locator。

但是出了问题之后：

你得能Debug。

五、这就是DeepSeek Harness真正值得测试工程师关注的地方

DeepSeek Harness的插件化设计意味着：

你完全可以把测试能力变成Agent能够调用的Tool。

例如：

def open_page(url):
    page.goto(url)


def click_button(name):
    page.get_by_role(
        "button",
        name=name
    ).click()


def input_text(selector, value):
    page.locator(selector).fill(value)

然后向Agent暴露：

open_page

click_button

input_text

于是Agent不需要知道Playwright所有API。

它只需要理解：

什么时候应该调用哪个工具。

这其实就是现在Agent工程里一个特别核心的问题：

Tool Calling。

六、MCP为什么突然火了？

理解完上一段，MCP就很好理解了。

很多初级工程师背MCP定义：

MCP是Model Context Protocol……

然后就没了。

面试官如果继续问：

它解决什么问题？

又卡住。

可以用一个特别简单的方式理解。

假设你有：

DeepSeek
Claude
GPT
Gemini

同时企业内部有：

Jira
GitLab
数据库
Playwright
测试平台
日志平台

如果每一个模型都分别写一套接入：

4个模型 × 6个系统

连接关系会越来越复杂。

MCP想解决的问题之一，就是：

让AI调用外部工具和数据时拥有更加标准化的接口方式。

所以你可以把Playwright封装成Tool。

把数据库查询封装成Tool。

把Jira创建Bug封装成Tool。

最终：

             ┌─ Playwright
             │
LLM → MCP ───┼─ MySQL
             │
             ├─ Jira
             │
             └─ GitLab

这时候一个AI测试Agent就可以做非常有意思的事情。

七、举个测试工程师每天都会遇到的场景

比如：

测试登录功能。

你告诉Agent：

测试商城登录功能，发现问题后创建Bug。

Agent可能执行：

1. 打开测试环境

2. 输入正常账号

3. 验证登录成功

4. 输入错误密码

5. 验证错误提示

6. 输入不存在账号

7. 检查异常处理

8. 查看Network请求

9. 查询日志

10. 发现异常

11. 创建Jira Bug

背后可能调用：

Playwright Tool
        ↓
API Tool
        ↓
Log Tool
        ↓
Jira Tool

以前需要测试工程师在四个平台之间来回切换。

现在Agent理论上可以自己串起来。

这才是：

AI测试智能体。

而不是让ChatGPT帮你生成几条测试用例。

八、但是这里藏着一道更狠的面试题

面试官：

Agent说测试通过了，你相信吗？

很多人第一反应：

当然不信。

那么继续：

怎么证明？

这就进入AI测试真正的核心问题。

传统自动化：

assert actual == expected

例如：

expect(
    page.get_by_text("登录成功")
).to_be_visible()

结果相对确定。

但是Agent可能告诉你：

任务执行成功。

你不能直接把：

Agent自己说成功

当成：

测试真的成功。

所以必须建立独立验证机制。

例如购物车任务：

expected_count = 1

actual_count = page.locator(
    ".cart-item"
).count()

assert actual_count == expected_count

这件事情特别重要。

未来测试Agent不能只有：

Executor

还需要：

Evaluator

也就是：

执行Agent负责干活。

评估系统负责判断它到底干没干对。

九、这又撞上了昨天AI圈另一个热点：Agent Skills怎么测？

NVIDIA昨天刚刚公开介绍了一个很有意思的方向：

SkillEvaluator。

它研究的核心问题就是：

给Agent加了一个Skill之后，它到底有没有变强？([NVIDIA Developer][3])

这其实特别符合测试思维。

假设：

Agent A

没有测试Skill。

完成100个任务：

成功：63
失败：37

增加：

Web Testing Skill

之后：

成功：84
失败：16

你至少可以计算：

success_rate = success / total

print(success_rate)

但还不够。

因为成功率提高的同时可能：

Token翻倍。

执行时间翻倍。

成本翻倍。

于是AI测试真正要看的可能是：

result = {
    "success_rate": 0.84,
    "avg_latency": 12.6,
    "avg_tokens": 4380,
    "cost": 0.032
}

这才开始接近：

Agent Evaluation。

十、为什么这对初级测试工程师特别重要？

因为最近很多人特别焦虑：

AI是不是要把自动化测试干掉？

我觉得这个问题问反了。

真正发生的是：

自动化测试正在成为AI Agent的一种基础能力。

以前你学习：

Selenium。

Playwright。

Appium。

Pytest。

接口自动化。

未来它们可能不会消失。

而是变成：

AI Agent可以调用的测试基础设施。

所以现在最值得初级测试工程师升级的，并不是把原来的技能全部扔掉。

而是在原来的：

Python
+
接口测试
+
Playwright
+
Pytest

上面增加：

LLM
+
Prompt
+
Tool Calling
+
MCP
+
Agent
+
Harness

最后形成：

AI测试开发

十一、最后留5道面试题，看看你能回答几道

如果你今年准备测试开发、自动化测试或者AI测试开发岗位，可以试着不查资料回答下面5个问题：

1、为什么UI自动化不推荐大量使用sleep？Playwright的自动等待解决了什么问题？

2、XPath、CSS Selector和语义定位各有什么优缺点？Agent时代XPath还有必要学吗？

3、MCP和普通API调用到底有什么区别？为什么Agent需要MCP？

4、如果让DeepSeek Harness调用Playwright完成Web自动化测试，你会怎么设计Tool？

5、Agent告诉你“测试执行成功”，为什么不能直接相信？你会怎么设计Evaluator？

如果前两道能回答，说明传统自动化基础还可以。

如果3、4、5也能讲明白：

你其实已经开始进入：

AI测试开发的能力范围了。

写在最后

DeepSeek Harness最近为什么值得测试工程师关注？

并不是因为测试行业又多了一个需要背的AI名词。

真正值得关注的是：

AI Agent终于开始从“聊天”走向“干活”。

DeepSeek Harness把Model、Tool、Skill、Sandbox、Session、Agent Loop这些能力拆成可组合的插件；而多模态、Agent Skills、MCP和Browser Agent又正在快速往这个体系里汇合。([DeepSeek][1])

于是测试工程师正在看到一个非常有意思的变化：

过去我们写：

test_login()

未来可能是：

“帮我完整测试一下登录模块，
发现问题自动分析日志并提交Bug。”

表面上看：

代码少了。

但背后对测试工程师的要求反而变高了。

因为你必须知道：

Agent为什么选择这个Tool？

为什么定位到了这个元素？

为什么认为测试成功？

失败以后怎么恢复？

如何避免误操作？

如何衡量100次任务到底成功了多少次？

怎么控制Token和执行成本？

会写自动化脚本，正在逐渐成为基础。

能把自动化能力变成AI可以调用、可以评估、可以治理的测试能力，才可能是下一阶段真正值钱的东西。

这可能也是DeepSeek Harness真正值得测试工程师研究的原因。