软件测试指南

2002年，我参加了XP/Agile Universe的一次研讨会，当时“实例化需求”这个词让我印象深刻，它可以用来描述测试在XP中的一个角色。

测试驱动开发（TDD）是一种通过编写测试来指导软件开发的软件构建技术。它是由Kent Beck在20世纪90年代后期作为极限编程的一部分开发的。本质上，我们重复执行三个简单的步骤

测试金字塔是一种思考如何使用不同类型的自动化测试来创建平衡组合的方式。它的要点是，您应该拥有比通过 GUI 运行的高级广义堆栈测试多得多的低级单元测试。

“测试金字塔”是一个比喻，它告诉我们将软件测试分组到不同粒度的桶中。它还给出了在每个组中应该进行多少次测试的想法。尽管测试金字塔的概念已经存在了一段时间，但团队仍然难以将其付诸实践。本文回顾了测试金字塔的原始概念，并展示了如何将其付诸实践。它展示了您应该在金字塔的不同级别中寻找哪些类型的测试，并给出了如何实现这些测试的实际示例。

在过去几年中，基于服务的架构已经转向更小、更集中的“微”服务。这种方法有很多好处，例如能够独立部署、扩展和维护每个组件，以及在多个团队之间并行开发。但是，一旦引入了这些额外的网络分区，就需要重新考虑适用于整体进程应用程序的测试策略。在这里，我们计划讨论一些方法来管理多个独立可部署组件的额外测试复杂性，以及如何在多个团队各自充当不同服务的守护者的同时保持测试和应用程序的正确性。

关于测试组合应该是金字塔形还是更像蜂窝状，存在争议。我对这场争论的第二个最大问题是，由于不清楚人们认为单元测试和集成测试之间的区别是什么，因此它变得模糊不清。

单元测试在软件开发中经常被提及，并且是我在编写程序的整个过程中都熟悉的一个术语。然而，像大多数软件开发术语一样，它的定义非常模糊，我发现当人们认为它的定义比实际更严格时，往往会出现混淆。

广义堆栈测试是一种测试，它可以测试大型应用程序的大部分部分。它通常被称为端到端测试或全栈测试。它与组件测试形成对比，后者只测试系统中定义明确的部分。

集成测试确定独立开发的软件单元在相互连接时是否能正常工作。这个术语甚至被软件行业中分散的标准所模糊，因此我一直避免在我的写作中使用它。特别是，许多人认为集成测试的范围必然很广，而实际上可以通过更窄的范围更有效地完成集成测试。

故事测试是面向业务的测试，用于描述和验证作为用户故事的一部分交付的软件。当一个故事被详细说明时，团队会创建几个故事测试，作为故事的验收标准。故事测试可以组合成软件的回归测试套件，并提供从需求（用户故事）到测试以及（通过执行）到系统行为的可追溯性。故事测试通常是广义堆栈测试。

使用测试替身的最常见情况之一是与外部服务通信时。通常，此类服务由不同的团队维护，它们可能会受到缓慢且不可靠的网络的影响，并且自身也可能不可靠。这就是测试替身很方便的原因，它可以防止您自己的测试变得缓慢且不可靠。但是，针对替身进行测试总是会引发这样的问题：替身是否确实是外部服务的准确表示，以及如果外部服务更改其契约会发生什么？

组件测试是一种测试，它将被测软件的范围限制在被测系统的一部分。它与广义堆栈测试形成对比，后者旨在尽可能多地测试系统。

面向业务的测试是一种测试，旨在用作与开发团队的非编程成员（如客户、用户、业务分析师等）进行沟通的辅助工具。自动化后，它们会以面向领域的术语描述系统，而忽略系统本身的组件架构。面向业务的测试通常用作验收标准，此类测试通过表明系统提供了客户期望的功能。

我使用皮下测试来表示在应用程序 UI 下运行的测试。这在对应用程序进行功能测试时特别有用：当您想要测试端到端行为，但很难通过 UI 本身进行测试时。

阈值测试是插入到部署管道中的一种测试，它通过将当前构建中的值与阈值进行比较来监控某些可测量的现象。如果当前构建的值超过阈值，则测试失败，构建失败。

Gerard Meszaros 正在写一本书来捕捉使用各种XUnit框架的模式。他遇到的一个尴尬的事情是，人们用来为测试屏蔽系统部分的存根、模拟、伪造、虚拟和其他东西的各种名称。为了解决这个问题，他想出了自己的词汇表，我认为值得进一步推广。

XUnit 是赋予一系列测试框架的家族名称，这些框架已在软件开发人员中广为人知。该名称源自JUnit，这是第一个广为人知的框架。

“模拟对象”一词已成为描述用于测试的模拟真实对象的特殊情况对象的流行词。现在，大多数语言环境都有框架，可以轻松创建模拟对象。然而，人们常常没有意识到的是，模拟对象只是一种特殊情况测试对象，它支持不同风格的测试。在本文中，我将解释模拟对象是如何工作的，它们是如何鼓励基于行为验证的测试的，以及围绕它们的社区是如何使用它们来开发不同风格的测试的。

本世纪，程序员测试显著兴起，程序员开始负责编写自己代码的测试。我们发现这有助于减少错误，更容易思考 API 设计，并使重构成为可能。实现这一目标的一个重要部分是 xUnit 系列简单测试框架，它起源于 Kent Beck 和 Erich Gamma 的工作。但是，尽管 xUnit 是一个简单的工具，但有效地使用它需要经验和技巧。Gerard Meszaros 是这些工具和使用模式帮助人们学习软件设计技术的理念的早期采用者。它提供了一个词汇表来帮助我们交流如何使用测试，并为经验丰富的从业者将他们的知识传递给新一代奠定了基础。

2014 年初发现了两个计算机安全漏洞：苹果的“goto fail”错误和 OpenSSL 的“Heartbleed”错误。两者都可能导致广泛而严重的的安全故障，其全部程度我们可能永远无法知晓。鉴于其严重性，软件开发行业必须反思如何才能检测到这些漏洞，以便我们能够提高在未来防止此类缺陷的能力。本文探讨了单元测试可以发挥的作用，展示了单元测试，更重要的是单元测试文化，如何识别这些特定的错误。它接着探讨了这种文化的成本和收益，并描述了这种文化是如何在谷歌扎根的。

自动化回归测试套件在软件项目中可以发挥至关重要的作用，它不仅对减少生产中的缺陷很有价值，而且对演进式设计也至关重要。在与开发团队的交谈中，我经常听到关于非确定性测试的问题——有时通过、有时失败的测试。如果不加控制，非确定性测试会完全破坏自动化回归测试套件的价值。在本文中，我将概述如何处理非确定性测试。最初，隔离有助于减少它们对其他测试的损害，但您仍然需要尽快修复它们。因此，我将讨论非确定性的常见原因的处理方法：缺乏隔离、异步行为、远程服务、时间和资源泄漏。

随着我的职业生涯转向全职写作，我经常担心自己会与日常软件开发的现实脱节。我见过其他知名人士与现实失去联系，我担心自己也会有同样的命运。我对这一点最大的抵制力量是 Thoughtworks，它就像一剂定期的现实剂量，让我脚踏实地。

Thoughtworks 也是一个来自该领域的创意来源，我喜欢写一些我的同事发现和开发的有用的东西。通常，这些都是有用的想法，我希望我的一些读者能够使用。我今天的话题不是一个那么令人愉快的话题。这是一个问题，而且是一个我们没有答案的问题。

我时不时会听到有人问他们应该以什么样的测试覆盖率（也称为代码覆盖率）为目标，或者自豪地陈述他们的覆盖率水平。这样的说法没有抓住重点。测试覆盖率是一个有用的工具，用于查找代码库中未经测试的部分。测试覆盖率作为一个数字化的指标来衡量测试的好坏，用处不大。

测试影响分析 (TIA) 是一种加速构建测试自动化阶段的现代方法。它的工作原理是分析源代码的调用图，以确定在更改生产代码后应该运行哪些测试。微软已经对这种方法进行了广泛的研究，但开发团队也有可能以相当低的成本实现一些有用的东西。

Ruby on Rails 的创始人 David Heinemeier Hansson 在 RailsConf 大会上发表主题演讲，宣称 TDD 已死。这在 Rails 和更广泛的软件开发社区中引起了意料之中的巨大争议。这也引发了 David、Kent 和我之间的一些有趣对话。我们认为这些对话很有趣，其他人可能也想看看，所以录制了一系列视频环聊，讨论 TDD 在软件开发中的作用。

当您针对网页编写测试时，您需要引用该网页中的元素才能点击链接并确定显示的内容。但是，如果您编写的测试直接操作 HTML 元素，则您的测试将很容易因 UI 的更改而变得脆弱。页面对象使用特定于应用程序的 API 包装 HTML 页面或片段，允许您操作页面元素而无需深入研究 HTML。

使用测试替身的典型案例之一是调用远程服务时。远程服务通常速度慢且经常不可靠，因此使用替身是使测试更快、更稳定的好方法。

有些程序元素天生就难以测试，甚至无法测试。因此，这些元素中的任何逻辑都容易出现错误并且难以改进。为了缓解这个问题，请将尽可能多的逻辑从难以测试的元素中移出，并移入代码库中其他更友好的部分。通过使不可测试的对象变得谦卑，我们减少了它们隐藏邪恶错误的可能性。

现代模拟工具对我们处理遗留代码的能力的积极影响，以及使用这些工具可能带来的负面影响。

如果您需要在代码中获取当前日期或时间，请不要直接访问获取该数据的系统例程。在其周围放置某种形式的包装器，允许您通过将“当前日期/时间”设置为特定值来覆盖它。这对于简化测试非常重要。

对象母体是测试中使用的一种类，用于帮助创建用于测试的示例对象。

我正在翻阅一些旧笔记，偶然发现了 Rich Garzaniti 给我的一个简单但有用的技巧。

传统上，QA 专注于在软件发布到生产环境之前对其进行测试，以查看它是否已准备好发布。但越来越多的现代 QA 组织也将注意力集中在生产环境中运行的软件上。通过分析日志和其他监控工具，他们发现了质量问题并向开发组织突出显示。这种方法在使用持续交付快速可靠地将新版本软件投入生产的组织中特别有效。

探索性测试是一种强调学习、测试设计和测试执行的快速循环的测试风格。探索性测试不是试图验证软件是否符合预先编写的测试脚本，而是探索软件的特性，发现将被归类为合理行为或故障的内容。

我们软件系统中的可观察性一直很有价值，在这个云和微服务的时代更是如此。然而，我们添加到系统中的可观察性往往在本质上是相当低级和技术性的，而且它似乎经常需要在我们代码库中充斥着对各种日志记录、检测和分析框架的粗糙、冗长的调用。本文描述了一种模式，可以清理这种混乱，并允许我们以一种干净、可测试的方式添加与业务相关的可观察性。

综合监控（也称为语义监控）定期针对实时生产系统运行应用程序自动化测试的子集。结果被推送到监控服务，该服务会在出现故障时触发警报。此技术将自动化测试与监控相结合，以便检测生产中的业务需求故障。