前几天 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 工程师、产品经理,甚至在适当的情况下包括最终用户。这确保了各种观点都得到考虑,从而做出更明智和平衡的决定。此外,采用一种视每个缺陷(即使是那些难以重现的缺陷)为加强团队调试实践机会的心态,可以带来软件质量的长期改进。

今天看到一篇讨论测试职业发展的文章，原文比较中肯，我结合自己的经历，稍微发展一下，供大家参考。

常见的困惑

下面一些问题是测试人员的常见困惑。

• “我听说测试工作 10 年就到头了，我是不是应该转向开发或管理？”
• “我的经理建议说，成为管理者是测试职业发展的必经之路”
• “我感到困惑，不知道如何从 QA 自动化转型为 SDET”
• “测试是不是一个死胡同工作？这个领域真的有职业发展前景吗？”

职业阶梯

在国外，测试领域主要有 3 种角色。

• 测试工程师
• 测试开发工程师(SDET)
• 工程经理(EM)

其中测试和测试开发被定义为个人贡献者。

通常对个人贡献者有以下级别划分：

• 实习生、新手、入门级(0-2 年)
• 中级(2-6 年)
• 高级(6-9 年)
• Staff/主管级(8-12 年)(可能有直接下属)
• 架构师/首席(12 年以上)(可能有直接下属)
• …更高级别如高级首席/架构师、杰出工程师(比较罕见)

工程经理或者技术经理大概包含下面的级别。

• 工程经理(5-8 年)
• 高级工程经理(8-12 年)
• 总监(12-15 年)
• VP(副总裁)(15 年以上)
• SVP(高级副总裁)(15 年以上)
• GM(总经理)(15 年以上)

VP 及以上的职级通常只在大公司才有，但直到总监级别的职位却很常见。很多公司可能会根据职位需求和公司规模来设置职级上限。

在国内情况也差不多，无非就是个人贡献者的天花板可能是技术专家，技术经理的潜力可能更大一点。

晋升方式

大致来说，一般的晋升方式如下：

• 学习：在你的领域成为深度专家，确保你具备完成工作所需的技术能力，这可能涉及学习新技术、技术栈、编程语言或人际交往技能。
• 出色执行：你应该清楚理解自己在组织中的角色，与主管沟通确保双方对此有共识，然后去执行、执行、再执行。持续完成一个又一个项目，始终把客户放在心上，做到最好。确保你是团队中最优秀的 5%，努力在各个方面创造价值，成为团队的力量倍增器。
• 提前表现：关注你的下一级别职位的期望，并确保承担其中的一些职责。持续完成这些任务，展现出持续强劲的表现记录。绩效评估通常是滞后的，如果你已经在以更高级别的标准在工作，而且你的主管也不错，那么你很可能很快就会得到晋升。
• 寻求指导与传授：找到公司内部、本地区或全球最优秀的人，跟随他们。向他们学习，吸收他们的智慧。寻找导师，与他们讨论想法，然后回去实践并展示实际价值。你也应该把所学传授给身边的人，帮助他们提升。

在国内，可能还包含

• 运气。这里体现的是选择大于努力，加入一个业务好并且高速发展的团队，晋升的机会远远大于业务一般而且走下坡路的团队。
• 创新能力。国内其实非常卷创新的，测试需要晋升可能需要周期性的“搞事情”，落地一些高概念或者新技术就可能给管理者留下深刻的印象。
• 指标落地能力。能定指标，落地指标以及提升指标。其实就是换种方式去卷。

拓展领域

打怪升级不是职业生涯的全部。

你会发现，仅仅把薪酬、职称和职级作为成长的标准，最终可能会显得很肤浅。

请不要误解我的意思，这些确实很重要，你需要在这方面做得好。

✅ 你的生活和家庭都需要你这样做。我会鼓励你继续为此努力，确保你的付出得到应有的回报。

❌ 但这并不是唯一重要的事。

当人们说测试工作在 X 年后就到头了时，他们实际上是用职级阶梯作为唯一的成长指标，这种观点过于肤浅。

上周末参加了可能是国内顶级的 AI 技术峰会，主要观摩了测试专场的内容，全程基本都是大厂和高校进行分享，应该可以部分代码国内的头部水平，感触良多，跟大家分享一下。

可以看到大模型出现以来，很多测试同学都在探索 ai 在测试领域的应用，这一年多以来也有不少的落地项目和产出，总的来说还是让人颇受启发的。

简单回顾一下，大家的发力点大概在下面几个方面。

接口测试

ai 在接口测试中的应用大概有下面两种。

• 通过大模型和 RAG 结合，使用模型的推理能力，让模型根据 api 文档自动生成用例和断言
• 使用大语言模型生成接口测试的数据

讨论这个议题的同学很多，大家的实践也都比较深入了，特别是在跟现有系统的整合方面，有些公司可以做到在内部测试平台上直接一键生成各种接口的测试用例，并运行生产报告，在工程方面的探索还是值得称道的。

不过当前的进展也有很多不完善的地方

• 大家都没有很好的指标可以统计大模型生成用例的可用性以及准确性
• 没有人真正的展示 ai 生成的断言是什么样子的，在分享后的交流里，有的讲师表示目前他们只实现了非常简单的不带业务逻辑的断言，比如响应状态码的断言

UI 自动化测试

似乎只有 1 位大厂的讲师分享了他们在 UI 自动化领域的探索，他们的当前的进展可能是

• 通过 Agent 自动生成 ui 自动化用例，具体的实现细节也是先简化 dom，然后使用 agent 进行推断
• 通过 Agent 实现 ui 自动化用例自动更新的能力，比如更新页面上发生变化的元素

一些我觉得不是很清楚的地方是

• 项目似乎是进行时，并没有真正落地并大规模使用
• ui 自动化用例的更新范围似乎只是页面上发生变化的元素，如果系统流程发生了些许变化，大模型可能也是爱莫能助的

模型效果评估

使用指标对大模型的效果进行评估也是测试人员工作的一部分。

这里测试人员需要

• 准备测试数据集，也可以用 ai 生成测试数据集
• 进行自动化验证并提炼模型效果指标

这一块我不是很懂，不过目前看来大家用的可能是业内统一的评测框架和指标，这块的天花板很高，有很大的深入研究的空间。

需求分类

使用 Agent 和 RAG 对需求进行分类和打分，标识出需求风险的级别，高风险的需求需要进行人工测试，低风险的需求可以免测。

这是整场分享最吸引我的议题。

因为这个想法直接抓住了测试的核心问题，那就是需求问题。

目前看来这个方案的召回率很高，准确性还有提升的空间。

这个项目的局限性是

• 模型对多模态的文档没有很好的处理办法，毕竟很多需求里图文并茂，不能识别图片和视频实在是比较遗憾

总结

总的看来很多大厂都在大模型与测试相结合方面积极的进行实践和落地，大家在工程化方面的探索还是非常积极主动的。

不过目前看杀手级应用还是没有，最近正好 openai 和 claude ai 都在智能体上面重点发力。

看到一篇跟用例数据准备相关的文章，觉得挺有道理的。我之前在设计用例数据的时候就会犯类似的错误，这篇文章其实说的非常在理。

翻译了一下原文，供大家参考。

编写测试用例更像是讲故事而非纯技术工作，这种观点并不罕见。最近我在 The Bike Shed 播客中听到这个观点，而且在博客文章和会议演讲中也经常能看到类似的讨论。既然测试编写是一种讲故事的艺术，那么我们是否应该借鉴叙事原则来改进我们的测试呢？

谈到讲故事的原则，首先想到的就是契诃夫之枪原则。这个原则是什么？用安东·契诃夫自己的话说（引自大英百科全书）：

如果在舞台上放置了一支上膛的步枪，那么它就必须被开火。不要做出你不打算履行的承诺。

大英百科全书还给出了如下定义：

这是一条适用于戏剧、文学和其他叙事形式的原则，它强调故事中引入的每个元素都应该对情节发展必不可少。

那么这个原则如何应用到我们的测试编写中呢？想象一下你正在为电商系统编写测试用例。你有不同类别的产品，这些类别对买家有一些限制条件。最明显的例子就是不能向未满十八岁的人销售酒类产品。在我们的例子中，这类人群不能将这些产品添加到购物车。

让我们看一个测试代码示例（我使用的是 Elixir，但这个原则适用于大多数编程语言）：

test "don't allow adding products to cart when age constraint is not met" do
  buyer = %Person{
    name: "John Smith",
    age: 17,
    country: :uk,
    registered_on: ~U[2023-09-16T18:17:22Z]
  }

  category = %Category{
    name: "Alcohol",
    external_id: 3242,
    constraints: [
      %AgeConstraint{min: 18}
    ]
  }

  product = %Product{
    name: "Triple Hazy IPA",
    category: category,
    sku: "TRI-557",
    added_at: ~U[2022-01-01T12:16:54Z]
  }

  cart = Cart.init(buyer)

  assert Cart.add(cart, product, quantity: 2) == {:error, :constraint_violated}
end

这个测试本身并不算糟糕，但它在多处违反了契诃夫之枪原则。在我们测试的"准备"阶段引入的每个标量都是契诃夫意义上的"枪"。它们都被放在了舞台上，读者可能会期待它们都会"开火"。这里我们有 10 个标量，相当于舞台上放了 11 把枪。什么是"开火"？就是当我们把这个值改成其他值时，测试应该失败。让我们检查一下这些标量：

• name: "John Smith": 无论改成什么，测试都不会失败
• age: 17: 如果改成 18 或 22，测试会失败
• country: :uk: 不会失败（除非我们实现了基于国家的限制，但目前没有）
• registered_on: <date>: 无关紧要
• name: "Alcohol": 无关紧要
• external_id: 3242: 这是什么？无关紧要
• min: 18: 改成 15 会导致测试失败
• 产品中剩余的 name、sku 和添加日期都不会影响测试
• quantity: 2: 同样无关紧要

总结一下，我们的 11 个"枪"中只有两个会"开火"，约 18%。其余的都是纯粹的干扰，如果读者试图理解测试的动态性，这些都会让他们误入歧途。

写在前面

前几天富途大裁员的消息相信让很多同学都感到压力倍增。

如今互联网领域的裁员潮并没有收敛的趋势，大有人人自危的感觉。

今天正好看到了一篇跟裁员相关的文章，翻译了一下，希望可以给大家提供一些思路。

原文在这里: https://filiphric.com/laid-off-as-a-tester-what-now

正文

如果你在 QA（质量保证）领域工作已经几年了，你可能已经注意到这个行业正在迅速变化。不幸的是，这也意味着裁员浪潮正在席卷整个行业，无论是初级还是高级测试人员都不能幸免。

最近，我遇到了一个在 Reddit 上发帖的测试工程师，他在手动测试岗位上已经工作了 15 年，而他所在的公司正经历一些变革。对未来的担忧已经蔓延，我想和大家分享一些看法，因为说实话，这种情况其实并不罕见。

跳出公司的舒适圈

作为测试人员，我们往往会深入了解公司的专业领域。但当我们不再为这家公司工作时，很难将这些专业知识应用到其他地方。我们常常将自身价值与所在公司绑定，一旦环境改变，就会感到迷茫。然而，事实上我们还是很有价值的！

想想看 - 测试人员通常是全能型人才：

• 他们负责发布管理
• 他们能发现 bug
• 他们拥有技术知识
• 他们可能懂得编程
• 他们擅长编写文档

我认为记录下你的知识，并真正理解自己的优势、专长和经验是很重要的。

因为关键在于 - 在不同的公司中，你已有的技能可能会以不同的方式呈现！可能会有一家公司正在寻找你恰好具备的技能，只是他们没有将其称为"测试"岗位。这可能是产品负责人、Scrum 大师、发布经理、技术文档撰写员、开发体验工程师或其他角色。

自动化学习永远不会太晚

如果你一直在做手动测试，还没有接触过测试自动化，但觉得现在是时候开始了 - 我强烈推荐查看 Applitools 的测试自动化大学。那里有大量免费资源，你可以学习各种测试自动化。不要觉得自己错过了机会 - 学习永远不会太晚！

关于人工智能

我知道听到人工智能这个词，一些人可能会翻白眼（相信我，我懂！），因为网上关于这个话题的噪音太多了。要分辨哪些是有价值的信息确实很困难。

尽管所有关于 AI 的讨论可能令人感到无所适从，但现实是：AI 已经来了，而且不会离开。许多公司正在转型，如果你想保持竞争力，就需要至少掌握一些相关知识。

获取 AI 知识并不意味着你必须成为一名"提示工程师"。相反，想想如何运用你现有的专业知识并用 AI 来增强它。例如，在做测试自动化时，你可以：

• 用 AI 提高工作效率
• 尝试使测试自动化更加稳定
• 使用 AI 加速学习

我个人最近几个月一直在使用 Cursor，它大大提升了我的学习效率。当它生成我不理解的代码时，我可以直接选中那段代码并要求解释。

你可以将 AI 视为不会替代你技能，而是帮助你增强技能的工具。

展示你的工作

在当前的就业市场中，让你的工作可见是非常重要的。即使你刚开始接触写代码，我也建议创建一个 GitHub 账号，上传你的代码仓库，展示你正在做的项目。

虽然我已经很久没有面试了，所以请对我的建议保持警惕。但每当我看到一个展示自己工作的 GitHub 账号的候选人，他们都会立即获得加分（需要说明的是，我从未是唯一的决策者）。这不仅让我的工作更轻松，因为我可以清楚地了解候选人的技术水平，更重要的是，这表明他们愿意学习和尝试。

开始写博客

另一个绝佳的职业发展技巧是写博客并分享你的学习经历。正如 Angie Jones 最近提到的，这可能会为你打开很多机会之门。我就是一个活生生的例子。