最近一直在思考如何在测试过程中使用openclaw等AI agent工具来提升测试效率。

直接用AI写用例一直是各个大厂关注的重点，各家也有了一定的突破，可以预见在不久的将来，一些通用用例的编写和执行是可以交给AI去完成的。

不过复杂业务场景下的用例编写和执行还是需要人工参与比较好。

这是因为

• AI对复杂业务场景的理解可能不如测试领域的业务专家；
• 测试策略的制定和把控最好需要有经验的测试人员进行介入，否则方向错了，做的越多，错的越多；
• 如果AI在复杂业务场景下的验证工作出了问题，那就找不到人背锅了；

所以我忽然意识到，与其苦苦追求提升测试效率，不如思考一下如何去提升测试人员整体的日常工作效率。

因为毕竟编写用例以及执行用例只是日常工作的一部分。

如果除了这两部分之外的其他杂事和重复工作的完成效率提升了，那么测试人员的整体输出也会有显著的变化。

测试人员的一天

大部分测试人员的典型一天可能是这样的。

早晨启动阶段（9:00–10:30左右）

• 开电脑 → 查看/回复邮件、钉钉/企业微信（经常一早上要回几十条）
• 参加站会/早会/Scrum Daily（10–15分钟）：汇报昨天做了什么、今天计划做什么、阻塞困难以及卡点是什么
• 查看Bug管理系统（Jira、禅道、Tapd）：自己昨天提的Bug有没有被开发修复/重开/驳回
• 拉取最新构建/提测包，部署或更新测试环境，如果环境被开发玩坏了，还要求助🙏开发进行修复
• 快速过一遍需求变更/新提测单/hotfix说明，评估影响范围

上午核心测试阶段（10:30–12:30 / 13:30–17:00）

最占时间的部分，通常占一天50–70%：

• 执行测试用例（手动为主，自动化为辅）
  • 跑冒烟测试/核心路径验证（新版本可能需要）
  • 按优先级逐条执行详细用例
  • 探索式测试（ Exploratory Testing）：随便点一点、试试各种组合、测试一下弱网、看看暗黑模式、有多设备就换设备跑一下
  • 接口测试（Postman/JMeter/自己写脚本）
• 发现Bug → 复现 → 提Bug单
  • 截图/录屏/日志/复现步骤/写清楚预期结果和实际结果
  • 做严重程度和优先级的判断（比如P0致命/P1高/P2中/P3低）
  • @开发、跟进讨论（经常要语音/会议演示）
• 跑自动化用例（如果有维护了自动化测试用例的话）
  • 触发CI/CD pipeline后看下结果
  • 分析失败用例的原因，是代码问题,环境问题,还是用例问题
  • 修复脚本，ui用例可能要更新locator或者加等待；接口用例就增加字段或者修改已存在的字段名称
• 专项测试（视项目阶段）
  • 性能或者压力测试（JMeter/Locust）
  • 安全测试（SQL注入/XSS/垂直或水平越权）
  • 兼容性/国际化/无障碍
  • 回归测试（尤其是大版本后）

下午/傍晚协作 & 收尾阶段（15:00–18:30）

• 参加各种会议（需求评审、缺陷评审、联调会、上线评审、复盘会）
• 与开发/产品/运营对齐（最耗时也最关键）
  • 需求不清晰，那么怼产品
  • Bug开发不认，那么拉产品一起怼开发
  • 上线有风险，各种升级，拉所有人一起评估
• 写/更新测试文档
  • 写各种测试报告（日报/周报/版本报告）
  • 做测试总结，覆盖率统计，典型bug分析，bug趋势分析，输出质量指标
  • 写操作手册或者输出验收的checklist
• 环境维护/数据准备
  • 造数、刷库、Mock接口
  • 清理脏数据、回收资源
• 学习/工具优化（优秀测试的常态）
  • 研究新需求的技术实现，或者参加开发的方案评审
  • 学习/优化自动化框架
  • 玩OpenClaw/Claude等AI Agent写用例/生成脚本/分析日志（这个比较科幻）

一天结束前（下班前30分钟）

• 汇总当天Bug/测试进度 → 发日报/更新看板
• 确认明天要测的内容、功能是否提测，环境是否ready
• 把未完成的用例/阻塞事项记下来

可以看出典型QA的一天比较零碎，可以工程化的部分其实有限。不过我们仍然可以提炼出一些可以进行自动化的非测试场景。

Scrapling应该是当下最强的爬虫工具了，关于它的特性和反爬能力这里就不赘述了，大家可以去项目主页了解一下。

Scrapling 提供了一套从单页请求到全站爬取、从普通站点到Cloudflare防护站点的较为完整的现代爬虫解决方案，尤其适合需要较高隐蔽性但对速度要求不是极致的场景。

实战1: 使用Stealthy Fecher来获取豆瓣电影的详情

第一个例子是使用Stealthy Fecher来获取豆瓣电影的详情。

豆瓣电影的详情页如果直接访问的话会有一次javascript的跳转，所以必须用打开浏览器的方式去爬，这也是Stealthy Fecher的使用场景。

Stealthy Fecher会用浏览器打开目标站点的地址，并且自动绕过一些通用的反爬限制。

具体代码如下，就是使用浏览器打开豆瓣电影的详情页，然后从页面上提取出具体的数据。

"""
示例目标：从豆瓣电影页面提取以下核心信息
- 电影中文名
- 上映年份
- 豆瓣评分
- IMDb id
- 前几条热门短评

使用的技术特点：
1. 使用 StealthyFetcher 而非普通 requests（带真实浏览器指纹）
2. 等待关键元素 #info 加载完成（豆瓣很多数据是 js 渲染的）
3. 使用 css 选择器 + 简单正则进行字段提取
4. 对可能为空的字段做了简单容错处理
"""
# 导入 StealthyFetcher 类，用于模拟真实浏览器行为来获取网页内容
# （相比普通 requests 更能绕过部分反爬机制）
from scrapling.fetchers import StealthyFetcher

# 目标网页：豆瓣电影的详情页面
url = 'https://movie.douban.com/subject/1296736'

# 使用 StealthyFetcher 进行网页获取（模拟真实浏览器访问）
page = StealthyFetcher.fetch(
    url,                    # 要抓取的目标URL
    google_search=False,    # 对于国内的站点，不使用 Google 搜索跳转（直接访问）
    real_chrome=True,       # 尽量使用真实的 Chrome 浏览器指纹（更像真人）
    wait_selector='#info'   # 等待页面中 id="info" 的元素加载出来再返回（重要！）
                            # 防止过早返回导致关键信息还没加载
)

# 从 div#info 块中提取 IMDb id（通常是 tt 开头的8位数字）
# 写法：先选 #info → 取整个文本内容 → 清理 → 用正则匹配 tt 开头的数字
imdb = page.css('#info').get().clean().re_first(r'(tt\d{5,8})')

# 提取电影标题（h1 标签下面的 span 文本）
title = page.css('h1 span::text').get()

# 提取年份（h1 里带 class="year" 的 span，通常是 (1993) 这种格式）
# 再用正则只保留数字部分
year = page.css('h1 span.year::text').get().clean().re_first(r'(\d+)')

# 提取评分（class 为 rating_num 的元素文本，通常是 9.3 这种）
# 直接转为 float 类型
rating = float(page.css('.rating_num::text').get())

# 提取所有短评（class 为 short 的 span 标签的文本内容）
# getall() 返回列表
shorts = page.css('span.short::text').getall()

# 将年份字符串安全转为整数，如果不存在则为 None
year_int = int(year) if year else None

# ──────────────── 输出结果 ────────────────
print("提取到数据：")
print(title, year_int, rating, imdb)

print("短评前3条：", shorts[:3])

上面代码的核心是 page = StealthyFetcher.fetch( url, google_search=False, real_chrome=True, wait_selector='#info')，因为页面打开之后会有个自动的javascript跳转，所以我们要等待跳转结束并且页面上的元素加载成功之后才进行操作，这也就是wait_selector='#info的作用。

感受

我最近用 opencode 搭建了一个完整的应用。

整个过程中，我大部分的精力其实都在做3件事情。

• 像产品经理一样设计功能和交互
• 像测试人员一样验证产品的功能及交互
• 不停的发现bug，提出缺陷，然后跟AI一起配合修复问题

这么反复循环了几次之后，我最终意识到：AI极大地降低了实现的门槛，却成倍放大了验证的难度和重要性。

用AI进行编码，实现代码确实是唾手可得了，但是验证的过程却是没有办法省略的。

AI在进行逻辑实现的时候，如果需求描述的不是很明确，那么一些实现细节是一定会遗漏的，这点跟现存的软件开发是类似的。

需求缺乏细节，那么只有用反复的测试来弥补。

比如我要实现一个需求，大致描述一番之后，AI会给出它的实现思路，然后让我们进行选择。

我们任意选择一个选项之后，很多的细节其实是AI自己去把控的，功能看似可以完成，但不一定跟我们的初衷相符，所以要反复测试和修改才可以真正达到可用以及正确的状态。

这其实让我意识到: 生产力工具越强大，对质量把控的要求可能就要越高。

毕竟现在需求可以实现的很快，但是要又快又好，很多细节和问题都需要人类来进行测试验证以及兜底。

AI时代的产品开发范式已经变了

传统的软件开发流程是这样的。

需求 → 设计 → 编码 → 测试 → 上线，根据Pressman教材数据，在经典软件工程里，测试环节通常占 20-30% 时间。

但是现在，编码环节被压缩到10-20%，但验证以及打磨环节占比飙升到50-70%。

JetBrains《2025开发者生态报告》显示：85%开发者定期用AI工具，62%依赖至少一个AI编码助手，但他们把更多时间花在“审查AI输出”和“调试AI生成代码”上（新增开销9-18%）。

我的看法是，如果多agent模式下的AI编码能力进一步提升，在一个项目团队里，产品和测试可能会比开发更为关键，毕竟编码的内容来自产品，编码的结果验证来源于测试。

在一个人一个团队的小型项目里，不会编码就能直接做应用的例子也逐渐习以为常，这一个人，大概率是更偏向于产品设计和测试。

市场的反馈其实也是这个趋势。

在中国市场，前程无忧《2026届校招AI人才需求报告》显示：AI测试工程师月薪中位数为13621元（虽低于核心算法岗的2.4-2.5万，但需求稳定增长，头部企业如阿里、腾讯、字节在AI质量方向扩招明显）。

这反映出：企业越来越愿意为“功能验证及质量控制”的能力买单。

为什么验证环节在AI时代变得更难、更重要？

第一个原因很容想到，那就是AI生成的代码充满概率性。

有数据称幻觉率（hallucination） 在复杂任务中可达 30-88%。

有时候AI觉得自己生成的东西没有问题，但真正上手测一下，就会发现一些隐藏的缺陷。

第二个原因是AI可以实现从“功能正确”， 但是“体验正确”却还需要反复的打磨。

AI很快做出“能跑”的东西，但“好用、防呆、边缘情况下不崩溃”的能力，还要靠人类来进行保证。

AI生成的代码往往停留在“表面能用”的层面：语法正确、逻辑基本通顺、基本路径走得通。但一到真实用户场景，就暴露出一堆“看起来小、实际致命”的体验问题。

这些坑AI自己很难感知，因为大模型缺乏真正的共情、上下文连续性和“好的人类体验”的直觉。

比如在我自己用 ai 实现的 kidcoins里，ai实现的兑奖下拉框原本是一个普通的select控件，用户体验不是很好。后面我自己上手之后给出了需要支持搜索的建议，反复修正之后，终于达到一个基本可用的用户体验。

openclaw的版本发布速度非常快，这几天基本上是一天一个版本。

最近的几个版本里值得一提的更新有：

• 首次官方添加飞书/国际版 Lark 插件，有完整文档。官方终于出手了，不用自己装插件了
• 新增 Agents 仪表盘：可视化管理多个 Agent 的文件、工具、技能、模型、channels、Cron 任务等。极大方便多 Agent 用户切换、调试、配置。这个我不太会玩，没感觉很方便
• 记忆后端优化：可选启用 QMD backend 用于 workspace memory的搜索，技术细节不展开讲了，简单来说就是这个可以省token
• 用户体验提升：中文文档爆炸式完善以及Web UI 强化，非开发者也能更容易上手，这个就见仁见智了
• 增加了用量页面，可以看到token的消耗了，终于知道钱花到哪里去了

升级

既然有新版本那就跟着升级吧。

用官方推荐的方式升级，命令行里运行一下这个命令。

curl -fsSL https://openclaw.ai/install.sh | bash

这次升级之后可能会报飞书插件的错误，可以忽略。

我手贱试着让openclaw自己去fix这个错误，结果导致配置文件出错，openclaw直接挂掉了，所以这个错误就先放一边吧。

如何快速恢复openclaw

openclaw的新版本增加了Agent的仪表盘功能，每个agent的状态现在一目了然。

我试着在聊天窗口里让openclaw自己去添加1个agent，openclaw自己跑着跑着，又把自己跑挂了。

是的，它自己把自己的配置文件给改挂了。

一天之内轻松完成了配置错误的帽子戏法，确实有点无语。

好在openclaw有个隐藏的快速恢复机制，我们可以用下面的命令快速让它满血复活。

cp ~/.openclaw/openclaw.json.bak.4 ~/.openclaw/openclaw.json

~/.openclaw/这个文件下面可能会有多个.bak文件，把最新的那个覆盖主配置文件~/.openclaw/openclaw.json就好了。

我的openclaw用的是智谱的模型。

据说默认情况下openclaw调用的是国际版的api，所以国内的同学最好是修改成中国版本的api地址。

这几天clawdbot的改名风波闹的沸沸扬扬。

从clawdbot到moltbot再到openclaw，一周装了我3个版本，搞得我都有点精神分裂了。

两个月前，clawdbot的作者peter花了一个周末搞了个叫“WhatsApp Relay”的小项目，结果现在GitHub星标破10万，一周内吸引了200万访问者。完全超出预期。

今天peter正式宣布：这个项目改名叫OpenClaw。

这个名字一路走来挺戏剧：最早叫Clawd，2025年11月诞生，就是那个大模型“Claude”加个爪子的梗，这是英文的谐音梗，我也不太懂，反正logo倒是挺可爱的。

结果火了之后，claude母公司的法务礼貌敲门了，这个名字太像了，蹭了我们的流量，能不能改？

peter表示：我们懂，向资本低头，马上整改。

然后凌晨5点在Discord脑暴，选了Moltbot的名字。molt大概是龙虾要长大就得蜕壳的意思，象征成长。很有诗意，但读起来总有点拗口。

peter不满意，几番折腾之后，现在终于定下来一个新名字：OpenClaw。

这次peter学乖了，商标没有被注册、域名也买好了、代码也迁移了。

现在的名字我觉得是很贴切的：Open代表开源、开放、社区驱动

Claw：就是爪子，保留龙虾爪子的血统，向起点致敬。

这次应该不会再改名字了，终于可以给大家分享一下如何安装openclaw了，对于没有技术基础的同学来说，本地安装还是很有难度的。

下面给大家演示一下如何在mac和linux上安装openclaw，这里我们的目标是让国内的同学不花一分钱把服务运行起来。

YouTube视频

B站视频

mac 系统

先看mac系统。

首先安装nodejs的最新稳定版本。我安装的是24.13.0，推荐用nvm安装，我把命令放这里了。

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash
nvm install --lts

Mac上还需要安装 Command Line Tools，命令放在下面了。

# 先彻底删除旧的（很重要，很多时候不删它就装错版本）
sudo rm -rf /Library/Developer/CommandLineTools

# 让系统重新拉取（会弹出安装窗口，按提示点继续）
sudo xcode-select --install

安装git，我们用brew安装。

brew install git

接下来把官网上的命令拷贝下来，在命令行里执行。