介绍
软件测试术语的起源可以追溯到 20 世纪 50 年代的 IBM。在此框架内，alpha 测试是旨在在公开发布之前评估软件的内部评估。其次是 beta 测试，在生产推出之前进行，而 gamma 测试是公开发布之前的最终检查。这些术语归功于 IBM 的 Martin Belsky，在 20 世纪 60 年代逐渐被淘汰，但在科技行业留下了持久的影响。
快进到 2010 年代，软件发布格局发生了显著变化。公司开始放弃冗长的测试阶段，转而采用快速发布周期。谷歌率先推出了 Chrome 浏览器的快速更新，并促使微软和 Mozilla 做出相应调整。微软在推出 Windows 10 时采用了软件即服务 (SaaS) 方法，对其操作系统进行了持续升级。
然而，软件部署速度的加快引发了人们对其可靠性的担忧。2024 年的 Windows 11 Moment 5 更新就是一个显著的例子，用户遇到了严重的安装问题，导致蓝屏和启动失败。不幸的是，在软件快速发布的时代，此类事件并非孤例。
这篇社论认为，微软等科技巨头应该重新考虑其软件开发的速度，优先考虑质量保证，确保更新是稳健的，并且可供用户使用。随着测试版和开发者渠道比以往任何时候都更容易获得，向普通用户提供稳定的软件不应该妥协。
“稳定”版本的衰落
从历史上看，从 Windows 95 到 Windows 7，微软一直保持着及时发布安全更新的记录，尤其是在每月第二个星期二的补丁星期二。这种做法使系统管理员能够保护其网络免受潜在漏洞的侵害。
虽然延长主要功能升级间隔可以提高兼容性和用户体验，但紧急安全更新必须毫不拖延地进行，以应对新出现的威胁。最近的挑战就是一个例子：用户尝试通过 USB 或 CD 安装 Windows 11 版本 24H2 时遇到更新失败，这暴露了 12 月补丁星期二解决方案之前的补丁测试中的缺陷。
此外，2024 年末的各种补丁星期二更新导致了严重问题，包括双启动失败和“开始”菜单故障。虽然微软的目标是迅速增强系统安全性，但矛盾的是，加快更新速度往往会导致更严重的用户中断。
为了解决这些反复出现的问题，重新考虑补丁星期二发布的频率可能会有所帮助。经过二十多年的实践，微软采取一种策略可能是明智的，这种策略允许回滚单个安全更新而不会影响不相关的修复。
这种快速更新趋势并不局限于 Windows。微软的 Xbox 生态系统自 Xbox 360 时代以来也同样采用了频繁更新。虽然今年的大多数更新都很稳定，但头几个月用户一直面临音频和网络连接问题，需要繁琐的重启才能解决。
对于 Xbox，功能更新通常优先于已知问题的故障排除。由于这些功能并非必不可少，因此公司明智的做法是先专注于解决现有错误，然后再为不知道自己实际上是 beta 测试人员的用户引入额外的复杂性。
转向 Mozilla，其 Firefox 浏览器引入快速发布周期反映了整个行业的趋势，这在很大程度上受到了 Google Chrome 模式的启发。尽管拥有稳定版、测试版和夜间版渠道，但主要 Firefox 渠道的用户仍然经常遇到需要后续修复的更新，正如 Firefox 版本 133.0.3 的快速修正版本所表明的那样。
问题的根源
2010 年代，快速发布现象势头强劲，因为企业寻求加快功能交付速度并获得竞争优势，而这往往以牺牲稳定性为代价。从 CD 等传统安装媒体过渡到高速互联网，可以实现快速更新，从而激发了消费者对不断创新的期望。
Google 的 Chrome 浏览器是这种敏捷方法的关键参与者，它每月都会进行更新，以最小程度地降低对用户体验的影响来引入增强功能。因此，Chrome 已成为世界上使用最广泛的网络浏览器，并利用其性能和易用性巩固了其市场地位。
现在许多浏览器都使用 Chromium 引擎，采用类似的快速发布策略，而 Mozilla 则选择调整其时间表以保持竞争力。然而，与 Google 不同，Mozilla 经常更新 Firefox 的界面，这种持续的重新设计可能会导致后续纠正更新的必要性。
SaaS 本地化进一步鼓励科技公司在功能上展开竞争，这通常会导致微软等公司寻求用户对新更新的反馈，就像 beta 测试一样。这种方法似乎更适合网络浏览器等免费应用程序，但当消费者为操作系统付费时，这种动态就会变得有争议。这可能会造成相当大的混乱，导致许多组织重新考虑对某些软件供应商的忠诚度。
有趣的是，由于苹果每年都会提供操作系统更新，而 Linux 发行版仅在主要版本发布时推出重要功能，微软频繁更新节奏的理由就减少了。与其急于推出功能，不如在发布周期中多花些时间，从而获得更完善的用户体验。
对消费者的影响
快速开发方法（正式名称为敏捷开发）提出了持续更新流程，旨在通过逐步解决问题来提高用户参与度。然而，这种方法引发了对产品稳定性的担忧，并且可能会带来不一致的用户体验。
虽然快速更新有利于提高市场竞争力，但补丁星期二期间小更新的失败表明，即使是很小的更改也会导致用户严重不便，最终破坏对软件可靠性的信任。用户不应该成为承诺稍后增强的功能的实验参与者。
遇到软件问题的个人会感到非常沮丧，这种情况在企业环境中更加严重，因为系统管理员必须解决多台计算机上的普遍故障，从而导致运营停机造成惊人的财务损失。根据 Atlassian 的研究，业务停机的平均成本约为每分钟 5,600 美元，这凸显了可靠软件的紧迫性。
因此，财务后果对公司继续使用某些软件的决定影响很大，尤其是当频繁更新导致严重中断时。通过在推出之前投入更多时间来确保质量，公司可以减轻因更新相关故障造成的声誉损害以及财务损失。
随着用户信心的下降，个人可能会出于对系统完整性的担忧而选择禁用自动更新，从而使他们越来越容易受到安全威胁。此外，审查不严的更新可能会无意中引入新的漏洞，这进一步加剧了微软等公司在保护用户系统方面所面临的挑战。
有效的敏捷开发可以促进软件质量的提高；然而，急于推出功能可能会导致在开发过程中走捷径，这通常会导致发布有缺陷的应用程序。
行业惯例和消费者选择
在其Windows 即服务 (WaaS) 概述中，微软强调了与组织的合作，以便在开发阶段的早期解决潜在问题。这包括对经常安装和评估版本的员工进行严格的内部测试，然后才能将其提供给更广泛的测试组。
持续的软件质量问题可能会扭曲公众对科技公司的看法，Android 和 iOS 之间的持续竞争就是明证。谷歌多样化的 Android 生态系统允许不同的用户体验，与苹果严格控制的平台形成鲜明对比，尽管苹果自身也存在一些挥之不去的问题，比如iOS 18发布时出现的问题，但无缝集成经常受到称赞。
鉴于日常生活对技术的依赖性越来越强，持续发布测试版软件可能会引发软件开发方法的范式转变，优先考虑稳健的测试和清晰的编码原则。监管机构对大公司垄断行为的关注度不断提高，可能会导致未来测试要求更加严格。
如前所述，在快速开发周期中征求最终用户的反馈可以带来有价值的见解，前提是反馈机制得到有效利用。然而，软件问题的持续存在引发了人们对发布前整体质量保证流程的担忧。用户在投资软件时会假设软件是稳定的，而依靠用户反馈来识别问题令人不安，尤其是当提供反馈的人往往很少或根本不得到公司的认可时。
对于对快速开发方式感到不满的公民，可以通过评论或讨论提出建设性的批评。虽然软件漏洞是行业中常见的问题，但对不稳定版本的不满情绪日益高涨，可能会促使人们呼吁制定法规，以确保用户获得符合基本质量标准的稳定产品——尽管测试和创新之间的平衡仍然很微妙。
结论
那些对不稳定软件版本感到不满的人应该考虑各种策略来减轻他们的挫败感。iOS 18 发布时出现错误的例子表明，用户可能应该明智地推迟更新，直到后续补丁被证实有效。同样，Firefox 的扩展支持版本 (ESR) 为那些喜欢经过更多测试的软件的人提供了一个稳定的替代方案。
最终，快速发布周期的趋势是否会减弱，转而采用有利于提高稳定性的模式仍不确定。这些频繁的更新冲淡了曾经伴随重大软件发布的兴奋感，让许多用户感到失望。
展望未来，找到一个平衡点，既能迅速发布新功能，又能对其进行彻底的测试，最终可能会提高用户满意度，并减轻快节奏技术环境中对软件质量的担忧。
发表回复