最近两个月高强度的使用AI进行了一些跟测试相关工作的探索，从之前大火的openclaw到hermes，从claude code到opencode再到codex，从各种国内模型到sunnet再到gpt5.5，感觉上是一日不见如隔三秋，两个月的时间变化相当迅速。

昨天同国内的某团队进行了一次关于ai在研发过程中使用的交流，发现大家所处的阶段以及遇到的问题都差不多，特别是在测试方面，大家的诉求痛点以及难点都是相似的，事后想了想，是时候做一些阶段性总结了。

实践

在ai与测试工作结合的方向上，我们做了一系列的探索，大体分为如下几个部分。

日常使用ai进行需求的分析，用例的增强以及知识盲区的学习

当前阶段，有些产品经理使用ai进行需求的补充和完善，某些需求一眼看上去就显得洋洋洒洒，面面俱到，但真正脱水和压缩之后，里面的信息量其实还是有限的。

这时候我们一些测试人员就使用ai进行总结，把里面的核心要素给提取出来，看上去像是提升了测试效率。

但是提取的重点有可能还是有遗漏的地方，所以需求我们还是要人工进行通读，写用例的时候也是要对照大而全的需求的，所以真实的情况是：通过ai对需求的要点进行了总结，能够比较快速的进行需求的了解，但是细节还是反复阅读和对比才能搞清楚，毕竟ai生成的需求里哪些是冗余的完全没有价值的，还是人工去判断才比较稳妥。

产品人员用ai去生成需求，其他角色用ai去阅读需求，也算是用魔法应对魔法了。

还有就是在日常进行用例编写的时候，我们也会把需求和用例都丢给ai，让ai进行一些场景的补充，很多时候ai给出的建议都是很有价值的。

最后在做一些技术优化类需求测试的时候，大部分的测试人员是不了解技术原理和优化细节的，这时候我们就会用ai进行快速学习，这点让我想起了二十年前我入行的时候，很多东西其实完全没接触过，当时硬是靠着百度和谷歌一点点的去搜索，去学习有异曲同工之妙。不过当时我们搜到的是各种材料，我们需要在材料里去总结去提炼，现在ai直接给答案了，效率跟之前相比真是不可同日而语了。

一键用例生成

我们用ai开发了一个简单的用例一键生成工作，思路是从tapd上导出项目的所有需求，并进行向量化。

测试人员在使用的时候直接把tapd的需求链接贴进去，工具会自动搜索与这个需求最接近的一些需求，然后对需求进行合并，最终分析合并过的完整需求，生成测试用例。

用例可以导出为xmind或markdown格式。

最后测试人员再精调一下导入的用例，去掉不合理的部分，加入一些用例中考虑不到的细节，形成最终用例。

这个工具目前来使用频率很高，属于不需要推广大家就会主动使用工具，在提升效率和测试质量上都有不错的帮助。

各种自动生成用例的框架

ai有其不确定性，比如问ai一个问题，ai有可能每次给出的回答都不太相同。

但对于非模型类的业务测试来说，我们需要的是确定性，确定的输入一定能得到确定的结果，这样我们才能把确定的实际结果跟预期结果进行比较，得到测试的结论。

因此用ai来直接进行测试活动还是有一定的风险的。

另外ai目前擅长的是直接输出代码，而不是直接执行用例。

基于上面这两点，我们目前对ai的使用其实是偏重于让ai直接编写测试用例（这是让ai写代码），规定好测试步骤和断言，这样每次执行的结果是稳定的，既发挥了ai写代码的优势，又一定程度上规避了ai运行结果不稳定的缺点。

我们做了如下的一些自动化的用例生成探索。

• 用claude code + playwright cli 全自动化生成web自动化用例。这个之前我有录过视频，感兴趣的同学可以去看一下。用这种方案只需要用自然语言把用例描述清楚，直接把用例扔给ai，就可以在无人值守的情况下让ai自己写自动化用例了。因为一般的项目都会有核心用例，只要这些用例不是xmind脑图形式的，其实都可以拿来直接用。这里有3个细节可能是比较有价值的。1，一定要让ai在写完用例之后自己跑几轮，确保所有的用例都能通过，这样用例的稳定性会大大提升；2，可以用定时任务的方式，让claude每天晚上自动去写，这样不占用上班时间；3，尽量给ai比较高的权限，比如claude code的--permission-mode auto模式，这样就不需要人工干预了；
• 用claude code + appium/maestro mcp实现客户端的自动化测试用例。跟上面的思路一样，只是测试对象换成了app。
• 用codex/claude code实现接口编排的测试用例。这里的思路是先让codex/claude实现单接口的用例，然后实现一些典型业务的接口编排用例，最后用自然语言给出高价值的业务场景，让ai自动去生成并运行用例。这里我之前是用纯pytest去实现的，后来发现接口编排的场景用代码描述出来不太直观，后面用pytest-bdd去实现了，效果要好不少。这里的思路是先实现单接口，类似于给出了接口的返回，然后实现典型场景，等于是给出例子教ai怎么去做接口编排，最后给出具体场景，让ai根据单接口和编排的例子自己去推断，准确性还是很高的，而且可以实现无人值守自己写用例。

实践中我还发现，对于一些简单的用例或者是在框架和存量用例都比较成熟的情况下，用国产模型的话都可以取得不错的效果。

各种稀奇古怪的测试工具

• 通过截图去测试多语言的自动化工具。我们的产品有9种语言，人工去比对翻译的正确线其实基本上是不现实的，所以这里我写了一个自动化工具，只要测试人员在对应的场景把英文和目标语言的截图保存下来，就可以自动去比对翻译的准确性了，这个工具对于提升测试效率有着不错的效果；
• 自动化造数工具。这里我写了几个版本，大概的思路就是导入所有的接口文档，把每个接口做成tool或者是function call，然后用agent框架，实现让ai自动去推断造数据需调用到哪些接口，自动把接口调用串起来，实现批量造数的功能。最后的效果是简单的造数行为还是可以跑通的，但是稍微复杂一点就不行了。效果一般的原因大体是接口文档可能不全，复杂的造数逻辑ai没办法一步一步进行推断，所以后面造数的工作还是要有一定的人工干预和补充，才能实现的更好；
• 疑难杂症的复现。有时候我们需要长期进行重复的行为去复现一些疑难杂症的问题，这属于机会主义，不仅费时，而且可能浪费了时间之后还无法达到效果。这时候其实可以用codex/claude，给其设定一个目标(goal)，让其自己写脚本去长时间运行，尝试复现；在codex辛苦复现的时候，我们可以做其他事情，不耽误日常的测试工作；
• tapd质量数据上报工具。我这边在tapd上有多个项目，想把所有项目的质量数据都拉下来做横向的比较和数据的挖掘其实还是有点费事的，所以我用ai写了个自动上报的工具，每天定时把每个项目的质量数据上报到远程机器上的indexdb上面，用grafana做呈现，目前看来挺方便的，推荐大家也可以尝试一下。另外远程机器上的indexdb和grafana都是codex自己搭建的，dashboard也是ai自己去创建的，非常省事；

一些感触

• 因为水平有限，现阶段大部分的探索其实都是针对存量的功能去做的，在新功能的测试上，特别是在app的测试上，目前人工点击还是比ai写脚本，ai调试脚本，通过脚本操作app的速度要快的多。因为我们的产品是给人类去用的，交互多，动效多，ai对新功能的直接测试行为帮助有限，所以目前情况下，根本不存在ai去取代测试人员的情况；
• 开发侧在使用ai进行代码的编写之后，单位时间内提测的需求数增加了不少，导致目前测试反而成了瓶颈，测试团队的规模其实是在增长的；
• 个别产品存在用ai提交的代码缺陷数量较多的情况，提测质量不高，反而导致测试的工作量增加；
• 大部分的测试人员其实没有开发思维，所以哪怕给了他们最新的工具和最好的模型，他们在进行测试工具和用例的开发上依然困难重重；
• 目前上层和中层对ai的态度是拥抱的，反而执行层面的人员学习ai的热情不是很高；
• 当项目中不同角色之间的沟通成本足够高的时候，ai进行代码编写的效率提升其实对项目的交付速度和交付质量并没有带来本质的变化；
• 从开发的角度上看，ai使得年轻人的体力优势变得不是那么明显了；但对于功能测试来说，当前阶段我们靠见啊来提升生产力；
• 不同模型之间差距还是比较大的，有条件的话还是得上好一点的模型；

最近一直在思考如何在测试过程中使用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地址。