霍格沃兹测试学院-小舟畅学-CSDN博客

原创 Selenium + AI：基于 DOM 分析的元素定位自愈，如何判断自动修复是否可靠？

做过 Web 自动化测试的人，应该都经历过这种情况。前端发布了一个新版本，业务功能没变，自动化回归却突然失败了几十条。打开日志一看，大部分都是元素定位失败。有的按钮修改了 ID，有的组件调整了 DOM 结构，还有一些页面经过前端框架重新渲染，原来保存的元素对象已经失效。测试人员只能重新检查页面、修改 XPath 或 CSS Selector，再运行一遍回归测试。如果维护的是几百条甚至上千条 Selenium 用例，这种工作会消耗大量时间。

2026-10-28 14:27:42 193

原创 Playwright CLI：语义快照与局部检索，AI 如何找到正确的页面元素？

最近，越来越多的测试开发开始尝试让 AI 直接操作浏览器。输入一句需求，让它打开网页、填写表单、点击按钮，看起来已经不是什么难事。但真正放到项目里，问题很快就出现了：页面元素太多，AI 需要反复读取页面；同名按钮容易找错；页面发生变化后，之前找到的元素引用又可能失效。Playwright CLI 提供了一种思路：先读取页面的语义结构，再通过局部检索找到目标，最后执行操作。对于正在研究 AI 浏览器自动化的测试工程师，这套机制值得掌握。

2026-10-22 22:32:25 65

原创 Playwright 1.60 不再只是测试工具，它正在变成“AI Agent 的操作系统”

Playwright 1.60 不是一个“功能更多”的测试版本。它是Playwright把自己从“测试工具”重新定位成“Agent操作浏览器的操作系统”的那个版本。感知层给了Agent结构化的“看见”，执行层给了Agent状态一致的“动手”，诊断层给了Agent可审计的“复盘”，角色层给了Agent预置的“工作流”。四层叠加，Agent不再需要“生成代码→执行代码”这条绕路，可以直接站在Playwright提供的运行时上操作浏览器。但操作系统从来不替应用做业务决策。

2026-10-22 22:03:25 211

原创 Playwright MCP + CI/CD：让每个PR都自动跑一遍AI驱动的冒烟测试

PR冒烟这件事，过去的核心矛盾不是“跑得慢”，是“跑得不可复查”。手动点一遍，截图存在某个人电脑里，结论写在PR评论里，三个月后什么都追溯不到。Playwright MCP在CI/CD里的真正价值，不是让Agent“替人点按钮”，是把冒烟从一次性的手动动作，变成一条有快照、有截图、有网络日志、可回放、可审查的工作流。Agent做机器的活：打开、操作、取证、落盘。人做人的活：判断哪些证据是有效的、哪些步骤值得沉淀、这个PR到底能不能合。这条线画清楚了，PR冒烟才真正从“走过场”变成“有据可查”。

2026-10-21 23:58:46 175

原创 Agent上线后才暴露的“软失败”，测试团队怎样提前拦住？

AWS在2026年10月16日公开了一套面向生产Agent的九阶段评测框架。它真正提醒测试团队的，不是再多接一个评测服务，而是Agent最危险的错误往往不会返回500：答案勉强可用、流程却已经偏航。本文把九阶段方法翻译成一套可执行的风险门禁。客服Agent调用了订单查询，也给出了退款状态，接口没有异常，用户甚至没有投诉。传统监控会把这次请求标成成功；但完整Trace显示，它先用了旧会话里的订单号，工具超时后又根据历史消息补写了“预计到账时间”。

2026-10-21 23:58:01 118

原创 Google Research 开源 Harness²：不改模型权重，AI Agent 如何持续进化？

ills、子智能体等组件，让 Agent 根据执行过程中的反馈，尝试改进自己的工作方式。项目采用 Apache 2.0 协议，支持 OpenCode 和 Codex，默认使用 OpenCode。需要说明的是，Harness² 是研究项目，并非谷歌官方支持的商业产品。项目地址：https://github.com/google-research/harness2。

2026-10-21 23:57:25 219

原创还在用 Selenium 跑 3 小时的回归？有人用 Playwright 砍到了 4 分钟

Selenium 的 3 小时，不是因为它“老”。是因为它的架构决定了每一次操作都要付一次 HTTP 往返的税，每一条用例都要付一次驱动启动的税，每一次并行都要付一次 Grid 维护的税。Playwright 的 4 分钟，也不是因为什么黑科技。它把协议开销压下去了，把等待逻辑内建了，把并行变成了原生能力，然后把省下来的时间还给了 QA。但最根本的变化不在工具，在谁做机器的活。3 小时里大量的“启动、等加载、写 sleep、修 flaky、维护 Grid”，本来就是机器该做的事。

2026-10-21 23:56:41 162

原创 Playwright CLI + Skills 实战：从页面探索到 Web 自动化用例生成

对于测试开发人员来说，这套工作流值得上手试试。页面探索、操作代码生成、失败信息收集和部分脚本修复，都可以交给 AI 协助完成。测试人员可以把更多精力放在业务场景梳理、风险判断和验证结果上。不过，生成速度快不代表覆盖率高，测试执行成功也不代表产品没有问题。先把测试场景定义清楚，再让 AI 操作页面、生成代码和排查失败。这才是 Playwright CLI + Skills 这套方案在 Web 自动化测试中的实际用法。

2026-10-21 23:56:02 177

原创 Playwright MCP调用链路全拆解：从自然语言到浏览器操作的完整闭环

Playwright MCP的调用链路，表面上看是“自然语言→工具调用→浏览器操作”。拆开看，真正让这条链路成立的是三件事：快照把页面变成了Agent能读懂的确定性文本，ref把“理解”和“操作”用同一个标识连了起来，反馈循环让Agent在每一步之后都有机会纠正自己。工具会变，模型会变，但这套“观察→决策→操作→再观察”的闭环逻辑不会变。快照是不是过期了？session是不是断了？断言是不是只看了Toast？

2026-10-20 18:50:44 56

原创 AI 生成 300 条测试用例，覆盖率涨了，Bug 却没少——问题出在哪？

AI 生成 300 条用例，覆盖率涨了，Bug 没少——问题不在“AI 不行”，在于你把“执行了多少代码”当成了“验证了多少逻辑”。覆盖率回答的是“代码有没有被走到”。变异分数回答的是“代码被改错了，有没有用例能发现”。缺陷检出率回答的是“线上会不会漏”。后两个数字，才是质量真正的温度计。AI 可以帮你把用例数量铺上去。但“哪些断言真的在拦错”“哪些业务规则 AI 根本不知道”“代码和测试是不是一起错了”——这些判断，只能人来做。

2026-10-20 18:15:42 91

原创京东JoyCode公开Testing Agent后，仓库级回归该怎样设计？

Coding Agent经常会经历“安装失败—改依赖—测试失败—改实现—再次通过”。如果报告只保留最后一轮，测试团队看不到它是否改了不该改的环境，是否删除失败测试，或是否通过放宽断言获得成功。Trace至少记录每轮命令、退出码、文件差异、测试集合变化、依赖变化和失败分类。失败归因建议分成五类：问题理解错；代码定位错；补丁逻辑错；测试Oracle弱；环境或偶发性问题。这样模型升级后做Agent Regression Testing时，比较的就不只是一条总通过率，而是各类失败有没有迁移。

2026-10-19 02:51:44 172

原创用Playwright MCP + GitHub Copilot实现自动化脚本自动生成

跑了这么多真实场景下来，我发现很多人用Playwright MCP生成脚本效果差，根本不是工具不好用，是指令写得太懒了。永远不要说“帮我写一个登录脚本”，要说清楚“覆盖哪几个异常场景、用什么方式处理动态验证码、用哪类定位器、失败后怎么清理数据”。你给的约束越具体，生成出来的脚本越不用改。‌长流程永远拆成短片段接力，不要试图一次性生成几十步的大脚本。基于真实页面状态一步步往下生成，稳定性比大段脑补出来的代码高10倍。‌生成完别直接丢进CI，花30秒扫一眼断言。

2026-10-19 02:47:47 525

原创美团CatPaw公开“录制生成Skill”后，测试团队要补哪条回归链？

从美团CatPaw公开的一键录制能力出发，拆解Skill版本、权限、Trace与业务副作用的回归闭环。美团技术团队公开介绍 CatPaw 时，给出了一项很容易让测试人产生画面的能力：内嵌浏览器可以一键录制操作过程，把日常高频流程自动生成专属 Skill，再由个人或团队重复使用。官方同时说明，CatPaw 能读取文件、操作浏览器、运行终端命令，并保留会话记录用于追溯。这不是一条“美团发生了自动化事故”的新闻。公开材料只证明了能力存在。

2026-10-19 02:42:37 307

原创字节 TRAE 不再只赌一个补丁：AI写代码的下一场竞争，可能是会不会选答案

TRAE Agent公开的方法里，一个容易被忽略的变化是：系统不再只让模型生成一份补丁，而是先制造多个候选，经回归过滤后再选择。真正值得测试团队研究的，不是榜单名次，而是“选择器会不会稳定地选中业务上正确的答案”。

2026-10-19 02:39:21 473

原创 Agent 也要被测试：如何评测一个 Agent 的 Skills？

去年年底，团队里一位同事改了一行 SKILL.md 的描述文字，把“优先查询订单状态”改成了“根据用户诉求选择合适工具”。代码没报错，pytest 全绿，PR 顺利合并。三天后线上开始出现跳过订单校验直接退款的事故。这件事让我意识到一个问题：我们给 Skill 写测试的方式，和给普通代码写测试的方式，几乎完全是两回事。普通代码改坏了，测试挂掉；Skill 改坏了，Agent 依然“能跑”，只是行为悄悄漂移了。

2026-10-19 02:37:11 469

原创 Playwright MCP：基于 AI Agent 的测试失败诊断与自动修复机制

Playwright MCP 已经能帮助 Agent 观察页面、查找元素、执行交互和检查浏览器状态。配合 Playwright Trace、代码操作工具与回归测试，一套基础的自动化测试失败诊断流程已经可以搭建起来。如果团队现在维护着几百条甚至上千条 Web 自动化用例，不妨先从那些每天反复出现的定位器失效问题入手。让 Agent 先分析失败日志，找到对应元素，生成修复补丁，再由测试开发人员审核。等这部分稳定后，再逐步引入页面异步问题诊断、网络请求分析和 CI 自动触发。

2026-10-16 00:06:28 152

原创用户模拟跑起来了，期望轨迹却断不了：Google 官方文档写下的一条互斥

给你们那条『用户第三句改口才暴露问题』的链路写一个模拟集用例：角色一句话、目标一句话，写完检查判据列表——把所有期望轨迹断言拿掉，只留任务完成、幻觉、越权三样。跑完如果命中了真实问题，把那条轨迹评审、固化、进固定集；如果连续两周什么都没命中，先怀疑模拟器，再怀疑链路。真实感与可断性这对矛盾没有两头占的解法，拆开，它们才能各自成立。多轮的真实感和精确的断言装不进同一个评估集：拆成两套，它们才能各自成立。

2026-10-15 23:56:43 105

原创 Playwright MCP：基于页面语义理解的元素定位与浏览器自动化操作

Playwright MCP 的页面语义定位建立在浏览器可访问性信息之上。模型根据元素角色、名称、层级关系和当前页面状态选择目标，再通过 MCP 工具执行浏览器操作。第一，重复元素如何消歧？通过父级业务对象和页面层级关系确定正确的操作目标。第二，动态 DOM 如何处理？页面状态变化后，使用最新快照重新确认元素，不应长期复用旧的ref。第三，如何保证测试可维护？将探索过程中形成的定位规则转换为稳定的 Playwright Locator，并通过独立断言验证业务结果。

2026-10-15 23:55:53 196

原创 Playwright MCP：基于 AI Agent 的测试失败诊断与自动修复机制

Playwright MCP 已经能帮助 Agent 观察页面、查找元素、执行交互和检查浏览器状态。配合 Playwright Trace、代码操作工具与回归测试，一套基础的自动化测试失败诊断流程已经可以搭建起来。如果团队现在维护着几百条甚至上千条 Web 自动化用例，不妨先从那些每天反复出现的定位器失效问题入手。让 Agent 先分析失败日志，找到对应元素，生成修复补丁，再由测试开发人员审核。等这部分稳定后，再逐步引入页面异步问题诊断、网络请求分析和 CI 自动触发。

2026-10-15 23:54:44 153

原创 AI Agent 运行时架构：Harness、Loop 与任务调度机制

AI Agent 的工程化发展，正在从单次模型调用延伸到完整任务生命周期管理。Prompt Engineering 解决任务描述问题，Context Engineering 解决上下文组织问题，Harness Engineering 解决 Agent 运行时控制问题，Loop Engineering 则关注复杂任务的持续调度与闭环管理。在生产环境中，这些能力通常需要共同发挥作用。模型决定系统具备哪些智能能力，Harness 决定执行行为如何得到约束，而 Loop 决定复杂任务如何被持续推进、恢复和验证。

2026-10-14 23:54:12 135 1

原创 Playwright MCP：AI Agent 驱动 Web 自动化测试的架构与执行机制

为了保证测试结果可以被验证，首先明确测试数据和预期行为。测试步骤预期结果打开 TodoMVC 页面页面成功加载，输入框可见新增“编写测试用例”列表显示该任务新增“执行自动化测试”列表显示两条任务新增“查看测试报告”列表共有三条任务勾选第一条任务第一条任务进入已完成状态检查剩余任务数量页面显示 2 items left切换 Active 筛选显示两条未完成任务切换 Completed 筛选显示一条已完成任务。

2026-10-14 23:53:11 235

原创 Jev火了之后，AI质检开始只输出概率：这种模型到底该怎么测？

从近期决策模型Jev切入，拆解“只输出概率”的AI质检器为什么仍会产生高置信误判，并给出数据集、阈值、校准、漂移和CI门禁的完整测试方法。客服回复了一句：“已经帮您申请退款，预计三个工作日到账。”AI质检器返回：合规概率0.94。流水线据此放行，第二天业务才发现，这个订单根本不满足退款条件，客服也没有真正发起退款。这类问题和聊天机器人答错不一样。决策模型不负责写一段漂亮答案，它只做判断：合规还是违规、投诉属于哪一类、图片有没有缺陷、这条请求要不要转人工。输出看起来更简单，却可能直接控制后续流程。

2026-10-13 23:59:03 49

原创公开课回顾｜提示词自我迭代进化：从静态 Prompt 到可进化系统

提示词自我迭代进化的重点，不是“写一条神级 Prompt”，而是建立一套可执行、可评估、可回归、可版本化的闭环。先掌握思路，再持续训练，最后更新出更好的提示词版本。按照这个思路去学习、去提高，就能逐步造出真正可用的 AI+测试能力。

2026-10-13 23:52:39 219

原创测试数据生成 Skill、Mock Skill、断言 Skill：Agent 测试三件套

Agent接口测试的核心，不是“让AI写脚本”，是“把测试逻辑拆成可复用的能力单元”。测试数据生成Skill解决“输入什么”，Mock Skill解决“依赖怎么响应”，断言Skill解决“怎么判断对错”。三个Skill各管一段，组合起来就是一条完整的测试链路。以前你把这三件事写在一个Python文件里，改一个牵动全身。现在你把它们拆成三个Skill，每个都能独立复用、独立迭代。你不需要再手写第N版测试用例了。你只需要把三件套拼起来，让Agent照着跑。下次你面对一个接口测试任务的时候，别打开编辑器了。

2026-10-13 23:47:01 848

原创 Agent、MCP、Skill、CLI、Model：企业老系统接入 AI 的架构与改造路径

随着 AI Agent 进入企业业务系统，越来越多的团队开始面临一个实际问题：如何让 AI 操作企业现有的业务系统，而不必重新开发一套系统？比如，员工通过对话查询年假余额、提交请假申请；研发人员用自然语言检索 PLM 系统中的 BOM 和图纸；测试人员让 Agent 查询缺陷、创建测试任务，或者执行已有的自动化测试脚本。这些需求都涉及 Agent、MCP、Skill、CLI 和 Model，但五者承担的职责完全不同。

2026-10-13 23:38:50 405 1

原创 2026年哔哩哔哩职级与薪资体系，附AI测试开发面试题

以视频平台场景为例，AI字幕主要检查识别准确率、专业术语、时间轴同步、多语言和噪声环境。视频摘要重点检查信息覆盖、事实忠实度和重要内容遗漏。此外还要覆盖无声视频、多人同时说话、异常格式、长视频和并发处理等场景。模型效果可以采用标注评测集与人工抽检结合的方式，不能只用“接口返回200”判断功能通过。从公开报薪记录看，B站2-1、2-2技术研发岗位分别有48万元和55.5万元的年薪样本。职级和年包值得参考，但实际选择岗位时，还要结合职责、薪酬构成及团队发展方向。

2026-10-10 22:37:22 111

原创第一次接手AI反诈项目：传统功能测试为什么很快就不够用了？

以Meta公开的WhatsApp端侧Scam Alert架构为事实起点，拆解端侧AI既要识别诈骗又不能扩张消息用途的测试难题，给出数据出境、模型完整性、实验分流、透明日志、对抗样本与持续评测方案。用户收到一条“快递丢失，点击链接领取赔偿”的消息。手机上的反诈骗模型判定风险较高，弹出提醒。功能看起来很简单，但测试团队马上会遇到两组互相拉扯的问题：如果模型看不到足够内容，诈骗识别可能变差；如果为了评测把消息、标签和反馈上传云端，隐私边界又可能被悄悄扩大。

2026-10-10 22:35:23 79

原创测试智能体评估与自我进化

课程将讲解如何定义关键指标：准确率、覆盖率、通过率、稳定性、成本、时延、人工接管率等，并建立可复用的基准测试与对抗评估思路。从单点工具到体系化能力，拆解测试智能体需要具备的核心技能：需求理解、任务规划、用例生成、自动化执行、结果评估、反思优化。智能体如何理解需求、拆解场景、覆盖边界、构造数据、输出可执行用例？为主线，从技能体系、用例生成、自动化执行，到评估方法、评测工具、反思机制，带你搭建一条完整的测试智能体能力闭环。测试智能体的分水岭，不在于“能不能生成”，而在于“能不能评估、反思、进化”。

2026-10-10 22:34:04 193

原创 UI 智能遍历测试：状态识别、路径规划与覆盖率评估

UI 智能遍历测试涉及状态建模、图搜索、路径恢复、执行规则、异常检测和覆盖率评估等多个技术环节。状态识别决定工具能否准确区分不同页面状态。路径规划与覆盖反馈决定遍历资源如何分配。执行规则用于限制探索范围，异常记录提供问题复核依据，Diff 测试则用于辅助识别不同版本之间的界面与交互变化。对于测试开发工程师，建设可靠的 UI 智能遍历系统，不只是让自动化工具执行更多操作。更重要的是减少无效遍历、提高有效状态与路径覆盖，并确保执行结果能够被记录、复现和验证。

2026-10-10 22:30:31 225

原创 AI 智能化测试：从测试用例生成到自动执行的工程实践

从传统手工测试到自动化测试，再到 AI 驱动的智能化测试，软件测试的技术体系正在不断扩展。自动化解决了大量重复操作的问题，大模型增强了业务语义理解能力，测试智能体让自然语言任务与自动化工具之间建立了连接，而知识图谱为复杂业务路径提供了结构化支撑。从国内外 AI 测试平台的技术实践来看，需求分析、智能用例生成、多端自动化执行和测试结果分析，正在逐渐形成相互协同的技术体系。对于测试工程师而言，理解这些技术的实现方式，比单纯掌握某一款工具更有长期价值。

2026-10-09 20:29:42 323

原创 AI Coding 质量治理：工程规范、代码评审与风险驱动测试

AI Coding 的普及，让代码生产方式发生了变化，也让工程质量治理的重要性更加突出。对于复杂业务系统，质量保障可以围绕以下几个方面展开。首先，建立统一的架构规范、业务模型和接口契约，并通过 AI Rule 与 Skill 将工程约束应用到实际开发流程中。其次，在代码提交之前引入 AI Code Review 和静态检查，将基础问题尽可能提前发现，同时保留人工对业务正确性的判断。再次，利用 AI 分析代码变更、辅助风险分级和测试设计，并结合自动化测试、覆盖矩阵和执行证据完成验证。

2026-10-09 20:15:04 150

原创 Playwright v1.63 把 reporter 做成插件：同一批红灯终于不用写三套报告

下一步动作很小：打开你现在那套 reporter，问三个问题——采集是不是只跑了一次？聚合口径是不是只有一处？三路呈现有没有在偷偷重算通过率。把这三层拆开，报告就从『框架吐给你的格式』变成『你能插拔、能评审、能回归的接口』。报告最贵的不是排版，是口径：一旦采集、聚合、呈现被拆成可插拔的三层，同一批红灯才第一次有了只有一个事实源的说法。[本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。#submit。

2026-10-09 19:51:27 271

空空如也

空空如也