软件测试真的值得吗？

是的，也不是。嗯，就像所有事情一样，这取决于情况。在这篇文章中，我将尝试说明我作为开发人员以及作为初创公司创始人的测试经验。

关于我

你好！我是 Simone，一名全栈开发人员和首席技术官，在各个行业（包括网络代理、电子商务、成人和企业软件）拥有 15 年编码经验。在这篇博文中，我想分享有关软件测试以及如何针对不同业务需求和阶段确定适当方法的见解。

我是 Bugpilot 的首席技术官兼联合创始人，Bugpilot 是一种错误监控工具，可帮助 SaaS 团队捕获开发、测试和 QA 流程中漏掉的错误。

介绍

不同类型的测试

在软件开发领域，许多测试实践长期以来被认为对于确保软件产品的可靠性和质量至关重要。然而，重要的是要认识到，虽然这些方法有其优点，但它们也并非没有缺点。

这篇博文旨在引发一场对话，并阐明 TDD 和 QA 可能对软件团队造成的潜在危害。通过承认没有一种放之四海而皆准的方法，并且不同的业务和阶段需要适当的方法，我们可以开始更有效地应对软件开发的复杂性。

我承认围绕软件测试有许多不同的方法、常见实践和建议；在这篇文章中，我主要关注测试驱动开发和质量保证。

如果您不熟悉这些术语，这里有一个概述：

时分双工

测试驱动开发（TDD）是一种软件开发方法，涉及在编写代码之前编写自动化测试。这有助于在开发周期的早期发现问题，确保代码经过彻底测试并满足业务需求。开发人员首先通过测试定义新功能的预期行为，然后编写代码以通过测试，最后通过重构来优化代码。

质量保证

质量保证 (QA) 确保软件在发布前符合质量标准。通常，由 QA 工程师执行的手动流程通过手动和自动测试来识别和修复缺陷，例如验证功能要求和检查性能。这确保了可靠、稳定的软件能够满足业务和最终用户的需求。

有几个问题想请教您！

我写这篇文章的目的是引发一场对话。我无论如何强调，我坚信在许多情况下都需要进行测试。想想医疗设备、飞机软件、控制系统、银行业务以及其他数十亿人使用的软件，其中一个按钮的颜色就会带来显着的利润差异。

软件开发需要在结构和灵活性之间取得平衡，盲目遵循测试原则而不考虑上下文可能会导致次优结果 - 代码库可能受益于 99% 的覆盖率。但您的软件是否也需要 99% 的覆盖率？

我准备了几个问题。尝试回答“是”或“否”——这是为什么？

• 您真的需要测试您的 UI 组件吗？
• 您是否需要对“更新个人资料图片”功能进行端到端测试？
• 如果 Figma 设计和实际 UI 之间存在细微的不一致，您是否会通过 QA 并延迟发布？界限是什么？
• 我应该因为约翰拒绝编写测试而解雇他吗？

第 1 章我反对测试驱动开发的理由

挑战教条

测试驱动开发（TDD）几乎获得了虔诚的追随者。有些人声称它有助于心理健康，而且常常伴随着教条主义信念，认为这是成功的唯一途径。本章旨在探讨 TDD 的缺点，并阐明刚性陷阱、时间限制和错误的安全感。

作为 CTO，我遇到过一些同事，他们坚定地坚持使用 TDD，即使是最琐碎的功能。流行的教条似乎是： “你必须采用 TDD，否则你就是个白痴！”这种对 TDD 作为唯一可接受的方法的坚定信念常常让我质疑自己的判断和能力。我清楚地记得我因拒绝为一个简单的两行函数来过滤数组编写测试而被嘲笑的事件。

这一个人经历凸显了 TDD 的主要陷阱之一——刚性陷阱。教条地坚持首先编写测试有时会导致僵化的流程，进而影响公司的上市时间和竞争优势。

真的值得花时间吗？

TDD 带来的一个重大挑战是它对开发过程施加的时间限制。

为每段代码编写全面的测试可能非常耗时，尤其是对于对整个系统影响最小的琐碎功能。在快速迭代和及时交付至关重要的快节奏环境中，TDD 的额外开销可能会减慢开发周期并阻碍敏捷性。

我发现总是采用“我需要 99% 的覆盖率”的方法是不合理的。平衡彻底性和效率至关重要，在某些情况下，更简化的测试方法可能更合适，从而可以更快地迭代并更快地响应市场需求。

此外，编写涉及与外部依赖项或复杂系统交互的测试的复杂性和不完善性可能会进一步加剧 TDD 的时间限制。

作为一名开发人员，我什至可能会说我喜欢编写测试，但是……找到一位 CEO，他很高兴他们的团队花费 80% 的时间为最终将被删除的代码编写测试。

开发人员经常需要创建模拟对象或存根来模拟测试期间这些依赖项的行为。虽然模拟可以成为隔离代码和减少依赖性的宝贵工具，但它们也会带来额外的开销和复杂性。

对模拟的依赖可能会导致现实世界交互的不完美表示，因为准确复制外部系统或第三方组件的行为可能具有挑战性。这可能会给测试过程带来一定程度的不确定性，可能导致误报或漏报。

测试正在通过；我可以睡个好觉了，对吗？正确的？

测试正在通过；我可以安然入睡了！

仅仅依赖测试有一个固有但经常被忽视的危险——一种错误的安全感。虽然测试对于识别和预防缺陷无疑至关重要，但它并不是一个万无一失的解决方案。

“我们在每台设备上都进行了测试吗？”

测试所有可能的情况也很困难。特别是在 Web 开发领域，有很多因素会影响用户体验。其中之一是最终用户设备的多样性，包括不同的屏幕尺寸、分辨率、操作系统和浏览器。每种组合都会带来一系列独特的挑战，这些挑战可能会影响软件的功能以及对用户的显示方式。

考虑大量的设备和配置：智能手机、平板电脑、笔记本电脑和台式机，在 iOS、Android、Windows 或 macOS 上运行，使用各种版本的浏览器（例如 Chrome、Safari、Firefox、Edge 或 Internet Explorer）。每个设备、操作系统和浏览器组合可能以不同的方式呈现网页内容，并且用户交互也可能有所不同。实际上不可能预测和解释每种可能的设备和配置，这使得测试难以提供完整的覆盖范围。

“我是否像我的祖母一样测试了这个 UI？”

用户角色和个人资料又增加了一层复杂性。您的软件可能针对具有不同偏好、行为和可访问性需求的不同受众。测试可以帮助发现典型场景中出现的问题，但可能会错过边缘情况或偏离正常情况的特定用户交互。例如，依赖辅助技术的视力障碍用户可能会遇到仅通过自动化测试难以捕获的可用性挑战。

除了技术变化之外，用户环境和现实场景在塑造用户体验方面也发挥着至关重要的作用。网络条件、带宽限制或并发使用等因素可能会影响软件的性能和可靠性。

虽然测试可以提供受控环境，但它们可能无法准确模拟用户在日常生活中遇到的各种网络条件和使用模式。如果测试不能确保您的软件运行良好，那么最终值得吗？

第 2 章 QA 和对速度的需求

我亲眼目睹了“严格”质量保证实践所带来的挑战，特别是对于必须迅速采取行动以保持领先竞争对手的小公司而言。

我相信对于早期初创公司来说尤其如此。如果您的客户不使用整个功能，您可能很快就会放弃它。那么，整整一周的测试和改进单元测试值得吗？

让我分享我的个人经历，并阐明陷入完美主义的危险，特别是当次要的视觉或表现方面成为质量检查工作的焦点时。

在我之前在一家初创公司的职位中，我们面临着快速交付功能和确保无可挑剔的质量之间的持续斗争。在某些情况下，我们的发布周期会因为 CSS 边距未对齐、字体选择不正确或缺少换行符等微小问题而被不必要地延迟。虽然对细节的关注很重要，但我开始质疑对这些外观缺陷的痴迷对我们在市场上保持领先地位的能力的影响。

过度质量保证的风险之一是优先考虑完美而不是实用。在追求完美的过程中，我们经常发现自己投入了大量的时间和资源来修复微小的视觉问题。 这不是生产力的敌人吗？

虽然保持高标准至关重要，但我开始意识到，在这些微小细节上投入大量精力可能会适得其反，使我们的注意力从对客户真正重要的核心功能和用户体验改进上转移。

当我们观察到过于谨慎的 QA 方法的后果时，危险变得显而易见。我们的团队开始表现出规避风险的行为，选择缓慢而细致的发布过程。虽然我们的目的是提供近乎完美的产品，但我们无意中扼杀了创新，并阻碍了我们快速响应客户需求的能力。作为一家小型（30 名员工）公司，我们依靠敏捷性快速迭代并战胜更大的竞争对手。然而，过度的质量检查实践导致了对“错误”的普遍恐惧，这阻碍了我们。

难道我们不应该接受错误的存在吗？凡是工作的人都会犯错误；如果你不工作，你就永远不会犯错误。 （抱歉 - 足球名言）

第 4 章 客户可能是最好的测试者

延长发布周期的财务影响变得显而易见。错过市场窗口、延迟创收和潜在客户流失开始造成损失。作为一家资源有限的小公司，我们不能磨蹭。我们需要利用我们的敏捷性和速度来抓住机遇并保持竞争优势。

完善次要细节所花费的时间需要与快速迭代和市场响应能力的需求相平衡。推迟、推迟、再推迟每个版本，直到我们“更加确定”一切正常；周二发货成为首选。如果我们可以多花一天时间来测试所有内容，为什么要在周一发货呢？

虽然测试有助于识别和预防缺陷，但将用户反馈作为有价值的信息来源也同样重要。用户的体验、偏好和建议可以提供超出单独测试所能揭示的见解。我们可以通过与用户建立反馈循环、积极倾听他们的需求并将他们的意见纳入开发过程来创建满足他们期望的以用户为中心的产品。

让用户参与测试过程可能会非常有益，而不是仅仅依赖广泛的内部测试。早期的用户测试，例如 Beta 测试或可用性研究，可以观察真实世界的场景和用户交互。

这种以用户为中心的方法有助于识别痛点、可用性问题以及仅通过内部测试可能无法发现的意外问题。尽早纳入此反馈可以极大地增强用户体验和满意度。

不幸的是，我亲眼目睹了许多软件团队中存在强烈的“不平衡”。这里有一个问题要问您： QA 是否会因 UI 不一致而失败？ QA 应该多久失败一次？

第5章“用户遇到bug就会离开！”

研究一致强调功能损坏对用户保留的负面影响。我们获悉，许多研究表明，如果用户遇到频繁的错误、崩溃或破坏其体验的错误，他们就不太可能继续使用产品。

根据 Qualitest 的一项调查，88% 的用户会在应用程序出现一两次性能不佳后就放弃该应用程序。这些发现强调了功能稳定性在留住用户和建立长期参与度方面发挥的关键作用。

当用户遇到损坏的功能时，就会削弱他们对产品及其背后的开发团队的信任。即使问题最终得到解决，用户也可能会产生负面看法并不愿意再次使用。如果用户反复遇到功能错误或故障，可能会失去对网站或应用程序的信任。

但是……到了 2023 年，情况仍然如此吗？

错误无处不在，我们都知道无错误的软件可能永远不存在。

用户可能会不时遇到错误，区分小错误和关键功能问题很重要。如今，用户可能更能容忍不会显着影响其整体体验的小错误。我们认为，用户已经学会接受软件开发中不可避免的错误；错误是我们日常生活的一部分。

然而，当涉及到阻碍他们按预期使用软件的能力的损坏的核心功能时，用户可能不会那么宽容，并可能寻求替代方案。

B2B bug 更让人痛苦（或者不是？）

在 B2B 场景中，功能损坏可能会给用户及其业务带来严重后果。它可能会导致项目时间表延迟、错过最后期限，甚至造成4.4 亿美元的财务损失。

对于消费类软件，企业用户在遇到阻止他们完成工作的错误时可能会感到沮丧和愤怒。他们对软件产品的忠诚度与其可靠性以及帮助他们成功履行职业职责的能力密切相关。低可靠性应该等于更高的流失率。

然而，我了解到情况并非总是如此。一旦整个组织采用了一项技术，让整个公司转向竞争对手的解决方案那么容易吗？不太可能。

电子商务面临（更多）忠诚度挑战。

在电子商务中，用户可以轻松获得多种选择。作为用户，你要完成的工作是非常明确的。你需要买一个吸尘器。如果亚马逊应用程序崩溃，您需要多久才能尝试抽屉中的下一个应用程序？

功能损坏或错误可能会导致购物车迅速被放弃、客户满意度永久下降并失去商机。

第 6 章 TDD 和 QA 是唯一的解决方案吗？

显然，不。虽然测试在识别和防止某些缺陷方面发挥着至关重要的作用，但可以采取其他措施来最大程度地减少错误对用户的影响。以下是我研究过的一些方法：

监控和错误跟踪

实施强大的监控和错误跟踪系统可以主动识别和解决问题。实时监控可以帮助检测异常、性能问题和错误，以便在影响多个用户之前及时进行修复。错误跟踪可以捕获错误详细信息，并根据错误修复对用户的影响来确定错误修复的优先级。

Sentry 、 Rollbar 、Bugsnag 和Bugpilot等工具可帮助团队自动检测编码错误和有问题的 UX 会话，以便团队可以主动解决问题。

用户反馈和支持

积极鼓励和收集用户反馈可以提供有关可用性问题、错误和需要改进的领域的宝贵见解。及时解决用户报告的问题并提供支持表明我们致力于解决问题并保持积极的用户体验。

Canny 、 Hotjar和Bugpilot等工具可帮助团队轻松收集用户的反馈。

文档和用户教育

清晰、全面的文档和用户教育材料可以帮助用户有效地导航软件并最大限度地减少用户引起的错误的风险。提供解释常见问题和故障排除步骤的资源，使用户能够独立解决小问题。

在 Bugpilot，我们使用 Notion 页面来保存所有文档。简单又免费。

结论

测试通过在开发过程的早期发现问题来充当重要的预防措施。彻底的测试，包括单元测试、集成测试和端到端测试，在一定程度上有助于发现错误并确保软件的稳定性和功能。但从长远来看，过度测试和过于严格的流程很可能会损害公司。

然而，尽管我们尽了最大努力，错误偶尔还是可能会漏过测试网。因此，制定缓解策略同样重要。通过实施缓解解决方案，软件团队可以快速检测和解决错误，最大限度地减少其对用户的影响，并迅速解决出现的任何问题。

认识到没有任何软件可能完全没有错误，创建一个鼓励用户反馈并提供有效客户支持的环境至关重要。通过积极倾听用户报告并及时解决他们的担忧，软件团队可以与用户保持积极的关系并培养信任和忠诚度。

太长了；博士

不要过度测试。您可能不需要 99% 的单元测试覆盖率。发货快。