离五一只有两周了。

最近有朋友买了 cursor 的会员，我驻足观看了一番。

他先描述需求，然后让大模型生成原型，接着又让 LLM 根据原型来生成前后端项目的代码。

整体流程一气呵成，看着非常有科幻感。

不难想象，接下来根据可以工作的前后端代码就可以让大模型来生成 ui 和接口的自动化测试用例。

不久的将来，通过 AI 生成的各种测试代码可能会是开发标准输出的一部分了吧。

AI 与测试的思考

停止过度设计：为什么测试 ID 比人工智能驱动的定位器智能更适合 UI 自动化(英文)

https://testersdigest.blogspot.com/2025/04/stop-overengineering-why-test-ids-beat.html

并不是所有的测试人员都关注 AI。

并不是所有关注 AI 的测试工程师都盲目的拥抱 AI。

这篇文章就反对使用人工智能来解决 UI 自动化测试中的定位问题，而是提倡使用测试 ID（Test IDs）这一更简单有效的方法。

1. 测试 ID 稳定可靠：测试 ID（如data-testid="submit-button"）是可预测的，不会因为开发人员更改 CSS 类、更新布局或重命名元素而失效。

2. 避免不必要的 AI 复杂性：为什么要让 AI 去"猜测"正确的元素，当我们可以从一开始就通过测试 ID 明确告诉 DOM 要查找什么。AI 应该增强测试策略，而不是清理本可避免的混乱。

3. 效率优于优雅：在测试中，我们的目标是验证功能而非创造艺术。Test ID 是低耦合、高效率的工具，能直接指向我们关心的元素，且运行更快。

4. 过度工程化难以扩展：使用 AI 来修复不稳定的测试和适应 UI 变化增加了另一层复杂性，意味着更多不可控的点。如果 AI 模型抽风了，不仅测试会失败，还需要进行 AI 调试。

清明过后似乎会更加期待劳动节一些。

今年五一放五天假，时间是充裕的，但想到各大景点的人山人海，可能最终还是会选择躲在家里吧。

看看书，在附近活动活动，陪陪家人，安静的时光就足够了吧。

AI 工具

最近在读一本关于二战时期太平洋战争的书，里面一些细节很有意思。

比如美军在珍珠港被空袭之后大概一年的时间里，一直在边打仗边学习。

因为美军中大部分将军和士兵都没有经历过真正的战争。

因此战争初期配合失误和自身混乱的情况时有发生。

感觉跟最近的 AI 热潮很像，大部分人都没有既往的经验，只能边用边学。

在实战中创新。

这两周跟 AI 相关的测试动态里，最让人眼前一亮的就是 playwright 发布了官方的 MCP 支持。

github 地址在这里:https://github.com/microsoft/playwright-mcp。

目前 7k+的 star，热度还是很高的。

看一下官方介绍。

基于 Playwright 实现浏览器自动化的 MCP。该服务器使大语言模型(LLM)能够通过结构化的可访问性快照与网页交互，无需依赖截图或视觉模型。

核心优势

​- 快速轻量 ​​：采用 Playwright 的无障碍访问树技术，非像素级输入 ​- 适配 LLM​​：无需视觉模型，完全基于结构化数据操作

• 确定性操作 ​​：避免基于截图方法常见的歧义问题

应用场景

• 网页导航与表单填写(自动化操作)
• 结构化内容数据提取(爬虫)
• LLM 驱动的自动化测试(自动化测试)
• 智能体的通用浏览器交互接口(通用操作)

既然做 UI 自动化又难又花时间，那么不如让大语言模型帮助我们去实现吧。

目前已经看到有人使用 Playwright + Cursor + MCP Server 跑通了自动化测试的流程。

具体效果在这里：https://www.youtube.com/watch?v=cNh3_r6UjKk

AI 测试策略

https://testingtitbits.com/ai-usage-for-testers-quadrants-model/ 这篇文章里作者讨论了 AI 的测试策略。

作者把测试工作分成了 4 个象限。

看到一篇讨论质量指标的文章。

文中描述了 3 个过时的不推荐继续使用的指标。

前几天马斯克发布了 Grok3。

简单试用了一下，有几点感想。

前几天 Claude 模型更新一个杀手级应用。

这次最大的更新并不是新模型，而是让 AI 能够直接与计算机互动。

Anthropic 推出了「computer use」功能：通过 API，让 Claude 像人一样操作电脑，能够查看屏幕、移动光标、点击按钮和输入文字。换句话说，Claude 现在可以使用标准的计算机工具和软件。这对于开发者来说是个福音，他们可以借此减少枯燥的重复性工作，甚至让 Claude 执行一些开放式任务。

为了实现这一功能，Anthropic 通过 API 让 Claude 能够感知并操作电脑界面。开发者可以通过这个 API，将用户的指令（例如：「使用电脑上的数据并结合网上信息填写表格」）转化为计算机的操作步骤（如打开表格、浏览器，并自动填写数据）。

目前，部分公司已经开始应用该功能。例如，Replit 正在利用 Claude 3.5 Sonnet 的计算机操作能力，为其智能体项目开发关键功能，用于应用评估。

尽管如此，这种技术并非全新。在此之前，Asana、Canva、DoorDash 等公司已经在尝试用 AI 处理复杂、多步骤的任务。

现实中的挑战

尽管「computer use」功能颇具潜力，但目前仍处于测试阶段。官方也承认，操作速度较慢且容易出错。一些对人类来说非常简单的操作，如拖动、缩放和滚动，对 Claude 来说仍有难度。

在功能演示时也出现了一些问题，比如 Claude 不小心中断了一次长时间屏幕录制，导致录制内容丢失；另一段时间，它开始浏览黄石国家公园的照片。

由于 Claude 通过截图理解屏幕内容，它有时无法捕捉到屏幕上瞬时出现的动态元素或弹出窗口。

Anthropic 希望通过提前发布测试版来获取开发者的反馈，并表示随着时间推移，这一功能将不断优化。

Anthropic 的开发者关系负责人 Alex Albert 分享了一个趣事：在测试「computer use」功能时，团队决定让 Claude 通过 DoorDash 下单订餐。经过一番分析，Claude 最终成功订购了披萨。

「computer use」功能限制：

• 无法创建社交媒体账户
• 无法发送邮件或消息
• 无法在社交媒体发布内容
• 无法完成购物
• 无法访问私人信息
• 无法处理验证码
• 无法生成或编辑图片
• 无法拨打电话
• 无法访问受限内容
• 无法进行需要身份验证的操作

可以看出来当前 claude 的自动化能力比较有限，但表现出来的推理能力及思考能力还是非常让人印象深刻的。

看到一篇讨论如何处理难以复现的 bug 的文章，这应该是面试里会被问到的问题，随手翻译了一下，大家可以酌情参考。

转瞬即逝:什么是海森堡 bug?

你是否遇到过一种似乎违背逻辑、难以复现的缺陷？

如果你的答案是"是的",请放心,你并不孤单。

这类缺陷往往在看似随机的条件下发生,这意味着我们无法确定重现问题所需的具体步骤。通常,我们能得到的唯一信息可能是一些模糊的描述,比如"我在执行某个特定流程时遇到了这个问题,但之后就再也无法重现了。"

正因如此,这些问题通常被称为"不可重现的缺陷",或者就像我最近发现的,被称为"海森堡 bug"。海森堡 bug 的一个显著特征是,任何试图观察或调试问题的行为都可能改变应用程序代码的行为。仅仅是观察问题的行为就会无意中改变问题发生的条件。这一点我们将在下面详细讨论。

当密切关注反而适得其反:观察者效应

“海森堡 bug"这个术语是对著名物理学家维尔纳·海森堡的一个俏皮双关语,他首次提出了量子力学中的观察者效应。

“观察者效应(不要与测不准原理混淆)指的是观察某个情况或现象必然会改变它。观察者效应在物理学中尤为突出,因为观察和不确定性是现代量子力学的基本特征。观察者效应不仅存在于物理学,在社会学、心理学、语言学和计算机科学等领域也广为人知。” ——《观察者效应》,IEEE 出版物,K. Baclawski 等人。

一个简单的例子就是检查轮胎气压。仅仅是将气压表连接到气门上,就几乎必然会损失一些空气。所以,单纯尝试读取轮胎气压的行为就会改变轮胎的实际气压。

考虑到这一点,我们可以推断,仅仅是尝试重现缺陷的过程就可能足以改变代码的行为,使得缺陷不再出现。

海森堡 bug 的一个例子:同步失败的故事

同步缺陷是如何产生的

想象我们需要测试一个使用多线程的应用程序。多线程是一种执行方法,允许在一个进程中创建多个线程。每个线程都独立执行,但与其他线程共享进程资源。构建这样的应用程序需要细致的编程,以避免可能出现的问题,如竞态条件和死锁。

在应用程序代码中,开发人员创建了一个修改共享计数器变量的函数。理想情况下,开发人员会使用同步机制来确保每个线程在继续执行之前都达到与其他线程相关的已知操作点。然而,如果没有实现同步机制,两个线程就可能同时修改共享计数器。

简单来说就是:

我们有一个初始值为'0’的计数器变量。线程一将计数器变量更新为'1’,同时线程二将计数器变量更新为'2’。

那么正确的值是多少？

在这种情况下,根本无法确定,这很可能导致应用程序出现不可预测的行为。

观察者效应的实际表现

调试这样的问题可能异常困难。通过添加打印语句、日志记录或使用调试器,线程的时序可能会发生足够大的变化,使得竞态条件的出现概率大大降低。这就给人一种缺陷消失的错觉。

像这样的不可重现缺陷或"海森堡 bug"可能会让开发人员和测试人员头疼不已,因为它们经常出其不意地出现,又消失得无影无踪。这些缺陷的本质特征使得它们极难诊断、记录和修复,可能导致开发人员和测试人员之间的挫折感。

打破"在我的机器上能用…“的论调

处理那些我们无法可靠重现的隐蔽缺陷可能是软件开发中最具挑战性的方面之一。这些问题不仅需要技术专长,还需要团队成员之间的紧密合作和清晰的沟通。所有团队成员都必须以开放的心态来处理这些问题,认识到仅仅因为问题在一个环境中没有出现,并不意味着它在另一个环境中就不存在。

用随意的"在我的机器上能用"的心态来否定问题,这种做法会破坏寻找解决方案和提高项目整体质量所需的协作精神。相反,这些挑战应该被视为加深理解、加强合作和构建更具弹性系统的机会。

软件团队该怎么办？

不可重现的缺陷可能源于各种因素,包括罕见的时序条件、特定的硬件或软件配置,或软件内部的复杂交互。理解和修复这些缺陷需要敏锐的洞察力、系统的方法和大量的耐心。每次尝试调试问题都可能感觉像是徒劳无功,但耐心和沟通是关键。

如果缺陷仍然无法重现,我们该怎么办呢？

作为团队理解缺陷的上下文

"上下文:事情发生的情况,有助于你理解它。" - 牛津学习词典

所有提出的缺陷都需要对上下文有深入和广泛的理解。上下文包括各种因素,如软件运行的环境、发现缺陷时的具体条件,以及导致问题的操作序列。没有这些信息,就很难把握缺陷的全部影响,这可能会显著改变对其风险和影响的认知。

以下是一些可能有助于确定是否应该继续调试不可重现缺陷的考虑因素：

评估潜在影响

• 评估缺陷的潜在严重性。如果缺陷可能导致数据丢失、安全漏洞或重大用户中断,即使很难重现也可能值得进一步调查。
• 考虑缺陷可能发生的频率。一个罕见但灾难性的缺陷可能仍然值得深入调查,而一个罕见且轻微的问题可能不值得。

评估继续调查的投资回报

• 评估尝试重现缺陷所消耗的时间和资源。如果付出的努力与潜在影响不成比例,可能就不值得继续追究。
• 考虑如果团队专注于重现单个缺陷,可能会忽视或延迟哪些其他工作或改进。有时候,关注已知的、可重现的问题或新功能可能是更好的时间利用方式。

收集所有可用信息

• 确保缺陷详情得到记录并传达给团队。这应该包括预期与实际行为的对比、问题出现的位置、环境信息(如软件版本、操作系统、硬件和配置)、发生频率以及任何其他相关信息。
• 检查是否有足够的日志、错误报告或遥测数据。如果信息太少或没有信息,可能很难取得进展。如上所述,这些缺陷并不总是能获得统计数据和信息,因此团队不应该仅仅依赖日志提供的信息。
• 有时最终用户可以提供有助于重现问题的宝贵见解或模式。如果有持续的用户报告,可能值得进一步调查。
• 向组织内外的其他人寻求建议。你可能不是唯一遇到这个问题的人。在网上研究,与组织内的其他团队交流,检查在线缺陷报告(例如 GitHub issues)。你可能会在第三方包和开源软件的代码库中找到关于这个问题的好文档以及如何重现它。

监控系统并减轻缺陷的潜在影响

• 是否可以实施一个变通方案或保护措施来最小化缺陷的潜在影响？例如,如果你在代码中使用了第三方包,而缺陷存在于这个包中,你能否使用一个完全不同的包来解决问题？这样就消除了进一步调查的需要。
• 设置监控以捕获更详细的数据,以备缺陷再次出现时使用。这可能为未来的调查提供线索。
• 考虑创建自动化脚本来监视特定的词或对象,并计划它们在一天中定期运行。这样做可能有助于深入了解导致缺陷发生的原因。它还可能突显出问题是否在特定时间发生。这些信息随后可以与后台触发的其他服务和操作(例如备份或防病毒更新)相关联。

协调团队和利益相关者的优先级

• 考虑如果缺陷后续在生产环境中出现是否会对用户或利益相关者体验造成损害。如果缺陷对用户或业务利益相关者来说是高优先级的,可能值得继续努力。
• 确保团队充分了解情况,并与他们合作决定是否继续调查。有时一个全新的视角可能会带来不同。

总结:尝试找出海森堡 bug 的根本原因是否值得？

关于是否应该花更多时间调查海森堡 bug 的决策过程应该是一项协作努力,涉及所有相关利益相关者,包括开发人员、QA 工程师、产品经理,甚至在适当的情况下包括最终用户。这确保了各种观点都得到考虑,从而做出更明智和平衡的决定。此外,采用一种视每个缺陷(即使是那些难以重现的缺陷)为加强团队调试实践机会的心态,可以带来软件质量的长期改进。