货拉拉、蚂蚁都在卷“无人值守”：DeepSeek Harness火了以后，纯手工测试还能撑几年？

关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集

从登录页“偶现失败”到订单全链路无人值守：拆解 Agent + MCP + Playwright + DeepSeek Harness 如何重构自动化测试
最近某脉上有个关于测试行业的讨论，很扎眼：

货拉拉、蚂蚁都在做无人值守测试，纯手工执行层还能撑几年？

先不讨论这个说法是不是有点制造焦虑。

单看技术趋势，这个问题其实值得所有测试工程师认真想一次。

因为过去十年，测试行业一直在说：

自动化会替代手工测试。

结果喊了十年，手工测试依然存在。

但2026年这轮变化，和过去可能真有点不一样。

以前所谓“自动化”，本质上还是：

人把测试步骤写成代码，机器按照代码执行。

而现在越来越多团队尝试的是：

人给测试目标，AI自己理解页面、规划步骤、调用工具、执行测试、判断结果，失败后甚至自己尝试修复。

从腾讯云社区近期集中出现的Agent + Playwright、AI测试Skills，到华为云CodeArts的测试智能体，再到大量围绕MCP、Agent、自然语言自动化的开源实践，一个越来越清晰的方向正在形成：

自动化测试正在从 Script Driven，走向 Agent Driven。 ([腾讯云][1])

而最近火起来的DeepSeek Harness，恰好提供了一个观察这个变化非常好的窗口。

一、先别聊Agent，先说一个测试工程师天天遇到的小问题
假设你负责一个电商后台。

需求非常简单：

测试用户登录。

测试用例大家都会写：

1. 打开登录页面
2. 输入用户名
3. 输入密码
4. 点击登录
5. 验证进入首页
   如果做Playwright自动化：

from playwright.sync_api import sync_playwright

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

page = browser.new_page()
page.goto("https://test.example.com/login")

page.get_by_label("用户名").fill("test001")
page.get_by_label("密码").fill("123456")

page.get_by_role(
"button",
name="登录"
).click()

page.wait_for_url("**/home")

assert page.get_by_text(
"欢迎回来"
).is_visible()

browser.close()
非常基础。

但是做过UI自动化的人应该都遇到过一种情况：

昨天还能跑，今天突然挂了。

看日志：

TimeoutError:
Locator.click: Timeout 30000ms exceeded
然后你打开页面一看。

功能根本没坏。

只是前端把：

登录 改成了： 登录 业务没变。

测试脚本挂了。

二、很多人把这个问题叫“元素定位失败”，其实想浅了
面试里如果问：

UI自动化为什么不稳定？

初级测试工程师经常回答：

元素定位不稳定。

没错。

但这只是表面。

真正的问题是：

传统自动化把“测试意图”和“页面实现”绑定得太死。

测试真正想表达的是：

点击登录按钮
但是代码表达的却可能是：

page.locator(
"#app > div > div:nth-child(2) > button"
).click()
这两个东西完全不是一个层级。

前者是：

业务意图。

后者是：

实现细节。

于是UI一改，测试资产跟着报废。

所以很多公司自动化覆盖率看起来80%，真正敢在凌晨发布后完全无人看守地跑的，可能没那么多。

这也是“无人值守测试”真正难的第一关：

不是脚本能不能跑。

而是：

环境变化以后，它还能不能自己跑。
三、Agent时代解决这个问题的思路完全不同
假设我们不再告诉程序：

page.locator("#login").click()
而只告诉Agent：

完成用户登录，
并验证是否成功进入首页。
执行链路可能变成：

测试目标
↓
DeepSeek
↓
Harness
↓
Planner
↓
Browser Tool
↓
Playwright
↓
页面状态
↓
Evaluator
Agent先观察页面。

发现：

输入框：用户名
输入框：密码
按钮：登录
然后规划：

{
"steps": [
"填写用户名",
"填写密码",
"点击登录",
"验证首页"
]
}
接下来调用浏览器工具。

四、这里就是DeepSeek Harness真正值得测试工程师研究的地方
很多人最近看到Harness，只知道它又是一个Agent框架。

但对测试工程师来说，最重要的思想其实是：

把能力拆成可以被Agent调用的插件和工具。

比如我们可以把Playwright包装成一个非常简单的Tool：

class BrowserTool:

def init(self, page):
self.page = page

def open(self, url):
self.page.goto(url)

def input(self, label, value):
self.page.get_by_label(label).fill(value)

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

def get_text(self):
return self.page.locator(
"body"
).inner_text()
Agent不需要知道：

CSS Selector
XPath
DOM层级
它只需要知道：

BrowserTool.click("登录")
这一步看起来只是代码封装。

但实际上改变了一件非常重要的事情：

测试执行能力开始从“脚本”变成“Tool”。

五、Tool和Skill又有什么区别？
这是今年非常值得拿去做面试题的一道问题。

很多人会：

MCP。

会：

Agent。

会：

Skills。

但三个放在一起就讲不清楚了。

可以这么理解。

Tool解决：
我能干什么？

例如：

click()
input()
query_db()
get_log()
create_bug()
而Skill解决：

这件事情应该怎么干？

例如登录测试Skill：

登录测试必须覆盖：

1. 正常登录
2. 密码错误
3. 用户不存在
4. 密码为空
5. 连续失败
6. Token过期
7. 异地登录
8. 弱网重试
   于是：

Tool = 手

Skill = 经验

LLM = 大脑

Harness = 把它们组织起来的执行系统
这个理解，比背：

MCP是Model Context Protocol……

在面试里有用得多。

六、真正的无人值守，绝对不是“让AI点网页”
这也是现在很多AI测试Demo最大的问题。

演示的时候特别惊艳：

输入：

测试一下登录功能
然后浏览器自己打开。

输入。

点击。

成功。

大家鼓掌。

但是企业真正关心的是：

凌晨2点跑500条用例，其中37条失败，怎么办？

如果最后还是：

37条失败
↓
测试工程师起床
↓
逐条看截图
↓
看日志
↓
重新执行
那不叫真正的无人值守。

只是：

无人点击。
距离：

无人值守
还差很远。

人工智能技术学习交流群
伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇

七、真正难的案例来了：订单链路怎么做到无人值守？
我们看一个更接近真实公司的场景。

假设你负责一个类似物流/电商的订单系统。

核心链路：

用户下单
↓
优惠计算
↓
库存锁定
↓
订单创建
↓
支付
↓
履约
↓
状态更新
一个测试工程师验证订单创建成功，通常不会只看：

页面显示“下单成功”。

还需要验证：

订单表有没有记录。

库存有没有扣。

优惠金额对不对。

支付单有没有创建。

MQ消息有没有发。

日志有没有异常。

缓存状态对不对。

这就是大厂业务测试真正复杂的地方。

八、传统自动化怎么做？
以前通常会写一大坨：

def test_create_order():

create_order()

assert_order_page()

assert_order_db()

assert_inventory()

assert_payment()

assert_mq()

assert_log()
已经比手工强很多。

但问题又来了。

一旦失败：

assert_inventory FAILED
测试工程师还得继续调查：

到底是库存服务挂了？

消息延迟？

Redis缓存？

数据库事务没提交？

还是测试环境脏数据？

九、如果用Harness思路，可以拆成多个Agent能力
例如：

Planner Agent
↓
Execution Agent
↓
DB Agent
↓
Log Agent
↓
Diagnosis Agent
↓
Evaluator
测试目标只有一句：

验证优惠券用户购买SKU-10086后，
订单、库存、支付状态是否一致。
Planner拆任务：

plan = [
"创建测试用户",
"领取优惠券",
"查询初始库存",
"提交订单",
"完成支付",
"查询订单数据库",
"查询库存",
"检查支付单",
"检查关键日志"
]
然后不同Tool执行。

十、数据库验证不应该交给LLM“猜”
例如：

import pymysql

def query_order(order_id):

conn = pymysql.connect(
host="mysql.test",
user="readonly",
password="***",
database="order"
)

cursor = conn.cursor()

cursor.execute(
"""
SELECT status, amount
FROM orders
WHERE order_id=%s
""",
(order_id,)
)

return cursor.fetchone()
Agent调用：

query_order("202608210001")
得到：

{
"status": "PAID",
"amount": 899
}
这里有一个非常重要的工程原则：

LLM负责推理，程序负责事实。
不要让大模型自己判断数据库里“大概应该有什么”。

十一、库存也是一样
def check_inventory(
before,
after,
quantity
):

expected = before - quantity

return {
"expected": expected,
"actual": after,
"passed": expected == after
}
例如：

下单前：

stock = 100

购买：

quantity = 2

下单后：

stock = 99
Agent立即发现：

expected = 98
actual = 99
这时候不是简单返回：

FAILED
而是进入：

Diagnosis Agent。
十二、这才是“无人值守”真正值钱的地方
Diagnosis Agent开始自己收集证据。

第一步：

查询订单服务日志。

def search_log(order_id):

return log_client.search(
keyword=order_id,
minutes=10
)
发现：

OrderCreated
InventoryLockRequested
InventoryLockTimeout
InventoryRetrySuccess
再查MQ：

def query_mq_trace(order_id):

return mq_client.trace(
key=order_id
)
发现：

InventoryLockEvent
sent: 2
consumed: 1
再查询库存服务：

第一次消费：SUCCESS

第二次消费：TIMEOUT
于是Agent最终生成：

测试结果：FAILED

业务影响：
订单支付成功，但库存扣减数量异常。

预期库存：
98

实际库存：
99

初步定位：
InventoryLockEvent存在重复发送，
其中一次消费发生超时。

疑似模块：
order-service / inventory-service

建议排查：
MQ重试机制与库存幂等逻辑。
到这里才开始有：

无人值守测试

的味道。

十三、如果再往前走一步呢？
Agent可以自动创建Bug。

def create_bug(result):

issue = {
"title":
"支付成功后库存扣减异常",

"severity":
"P1",

"order_id":
result["order_id"],

"expected":
result["expected"],

"actual":
result["actual"],

"logs":
result["logs"]
}

jira.create(issue)
完整链路就变成：

代码发布
↓
CI/CD
↓
触发测试
↓
Agent规划
↓
自动执行
↓
发现异常
↓
自动收集证据
↓
日志分析
↓
根因推断
↓
失败复现
↓
创建Bug
↓
通知负责人
测试工程师第二天早上来公司。

看到的不应该只是：

37 FAILED
而应该是：

500 Cases

463 Passed

37 Failed

其中：

21 环境问题
9 已知问题
4 数据问题
3 疑似新增Bug

新增Bug已自动提交。
这才是我理解的：

无人值守测试。
十四、为什么说这不是一个遥远的PPT概念？
因为行业里的技术组件已经在逐渐拼起来。

腾讯相关AI测试实践已经在做生产流量识别、智能去重、AI测试数据构造、测试报告问题识别和根因推测；公开资料称，其流量智能去重可将测试数据集精简60%以上。([腾讯云][3])

华为云CodeArts的测试智能体已经可以从代码逻辑生成单元测试，并对生成测试里的编译错误进行识别和自动修复。([华为云支持中心][4])

腾讯云开发者社区近期关于AI测试的内容，也已经把Agent的能力描述为从需求分析、测试生成，到动态执行轨迹和历史缺陷分析，而不是简单生成几条Case。([腾讯云][5])

更值得测试工程师注意的是，一项今年关于Agent工程能力的研究发现：给Agent增加一次真实测试反馈，解决率能获得非常显著的提升。这再次说明——Agent再聪明，也离不开可执行、可验证的测试反馈。([arXiv][6])

这恰恰是测试开发工程师的机会。

十五、那么“纯手工执行层还能撑几年？”
我反而不想给一个：

3年。

或者：

5年。

这样的答案。

因为这是伪命题。

手工测试不会在某一天突然消失。

就像有了计算器之后，人类也没有停止学习数学。

真正变化的是：

企业愿意为哪种能力付多少钱。
如果一个人的主要工作价值长期停留在：

打开页面

点击按钮

输入数据

截图

提交Bug

重复回归
那么这部分工作确实正在面对越来越强的自动化压力。

但是如果你能解决：

怎么设计测试策略？

Agent应该调用什么Tool？

什么操作必须禁止？

怎么建立业务Skill？

如何设计测试Oracle？

AI执行结果怎么验证？

失败后如何自动归因？

如何处理脏数据？

如何做环境治理？

如何避免Agent误操作生产数据？

如何衡量无人值守的可信度？
你会发现：

测试工程师并没有消失。

只是工作的抽象层级变高了。

十六、还有一道大家经常遇到、但面试很容易答浅的问题
面试官：

自动化测试能不能完全替代手工测试？

很多人的标准答案：

不能，因为有些场景不适合自动化。

没错。

但2026年如果还只回答到这里，已经有点不够了。

更完整的答案应该是：

传统自动化解决的是：

重复执行成本。

Agent测试进一步试图解决：

理解、规划、适应和维护成本。

但即使到了Agent时代，人仍然需要负责：

测试目标、风险判断、业务Oracle、安全边界和最终质量决策。

所以真正发生的不是：

AI
↓
测试工程师消失
而更可能是：

手工执行
↓
脚本自动化
↓
平台自动化
↓
Agent自动化
↓
无人值守质量工程
测试工程师正在往上移动。

十七、所以DeepSeek Harness到底带来了什么？
Harness本身并不会神奇地帮企业完成无人值守测试。

但它背后代表的架构思想非常重要：

Model不再等于整个AI系统。

真正可以落地的Agent系统越来越接近：

Model
+
Harness
+
Tools
+
Skills
+
Memory
+
Sandbox
+
Evaluator
+
Observability
对测试行业来说，则可以进一步变成：

DeepSeek
+
Harness
+
Playwright/Appium
+
MCP
+
Testing Skills
+
DB/Log/MQ Tools
+
Evaluator
+
CI/CD
这才是AI测试开发真正值得研究的方向。

写在最后
“货拉拉、蚂蚁都在做无人值守测试，纯手工执行层还能撑几年？”

我觉得这句话最值得讨论的地方，不是：

手工测试哪年消失。

而是另外一个问题：

如果有一天，公司5000条回归用例真的可以在晚上自动执行、自动恢复、自动分析、自动归因、自动提交Bug，第二天早上还需要多少人负责纯执行？

答案可能不太舒服。

但换一个角度看：

企业仍然需要有人设计这套系统。

需要有人定义业务测试Skill。

需要有人把Playwright、Appium、API、DB、MQ、日志平台变成Agent可以安全调用的Tool。

需要有人设计Evaluator。

需要有人解决AI幻觉。

需要有人保证Agent不会越权。

需要有人判断AI给出的根因到底靠不靠谱。

以前测试工程师自己执行测试。

后来测试工程师写脚本执行测试。

下一阶段，可能是测试工程师设计一群Agent替自己执行测试。

所以真正值得担心的，从来不是：

“AI会不会抢走测试岗位？”

而是：

当测试执行开始无人值守之后，你还停留在执行层，还是已经开始设计那个“无人值守系统”？

这两个位置，未来的价值可能会越来越不一样。

推荐学习
DeepSeek Harnesst智能体公开课，8月20日20:00开讲：

🔥 DeepSeek Agent架构深度拆解——“一切皆插件”到底怎么实现
🔥 四大主流Agent横向对比：Opencode/Codex/Claude Code/Openclaw
🔥 Harness插件体系全解析：Web自动化+App自动化+视觉驱动自动化

一夜5万星的Agent框架，到底能做什么？一次讲透。

扫码进群，报名学习！

关于我们
霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。

我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。