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

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

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

常见的困惑

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

• “我听说测试工作 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 都在智能体上面重点发力。