这篇文章的灵感来自于我多年来的一些对话，以及我对测试目标、测试意图和术语的一些思考。我注意到，在尝试为不同类型（或被认为是不同类型）的测试赋予不同名称时，常常会出现混淆，并且人们努力地为每种特定测试只设定一个名称或类别。我的观点，与许多关注术语的话题一样，共享的理解和意图才是最重要的事情。

话虽如此，我希望在“单元测试”、“集成测试”、“回归测试”以及这些对话中经常出现的其他术语的含义和意图方面，提供一点清晰的解释。

关于“单元测试”的含义有很多争论。可能最普遍的理解是，单元测试是对一个特定函数或方法的测试，仅此而已。因此，单元测试通常与实现方法紧密耦合，我曾听到这被提及为测试驱动开发（TDD）对某些人来说困难或不切实际的原因，因为他们还不知道他们会写哪些函数。

我有一个更灵活的观点，包括了另一种理解。在我看来，“单元”是小的，但有意义的。对我来说，比单个函数或方法更有意义的是业务功能或价值的单元。一些行为或过程，如果出了问题，会被认为是错误的。

你可能会争辩说，单个函数的失败测试也会导致错误，这是对的。但是，函数级别的单元测试集合可能无法检测到业务级别的测试会检测到的错误。为什么这很重要？我将在讨论使用哪种测试时谈到这一点。

基于函数的单元测试的优势在于，你能获得关于出错之处的更具体的信息。基于业务的单元测试的优势在于，你不必在每次实现细节更改时都更新它们，使它们在重构或实践TDD时特别有用。你只需要知道你的输入和预期输出是什么。

集成测试

你可能会认为我的“业务单元”解释是“集成测试”，在某些情况下，这可能是真的。我们可以将集成测试视为检查多个函数或方法之间交互的测试，这同样可能是最普遍的理解。但我们也可以将它们视为多个业务功能或行为之间的检查。

一个测试可以同时检查单个业务行为和多个代码方法。一个测试可以是“单元测试”和“集成测试”，取决于你对这些术语的理解。

如何决定使用哪种测试

假设你接受了我对“单元测试”和“集成测试”的解释，并能够与它们一起工作。你如何决定在给定场景中使用哪种（些）测试？在我们能回答那个问题之前，我们必须考虑我们为什么要有测试。

我认为这是我们经常忘记的事情，特别是当我们被给予代码覆盖率百分比目标时。但我们不应该因为“我们必须”而创建测试。我们应该创建测试作为帮助我们自己现在和将来的工具。

好的测试提供反馈。好的测试检测变化。好的测试是你需要关注的事情。

有了这些，我们再想一想我们试图测试什么。我们试图测试我们的代码是否有效，对吗？但那意味着什么？通常，这意味着它应该满足业务的验收标准。所以再次，业务单元似乎比代码单元更重要。当然，团队或项目应该始终考虑技术卓越和良好的系统架构，但在发布与否方面，我们通常更关心它是否满足业务需求，而不是涉及哪些方法或代码。

这并不是说我们不关心代码单元；我们关心。我们关心导致错误的代码的确切位置。因此，在我看来，拥有两种类型的单元测试（基于代码和基于业务的）是很重要的，它们最终是否是“真正的”单元测试（在检查单个函数的意义上）或集成测试是不太重要的。

所有这一切都在说，如果业务功能或行为很重要，就写一个特别涵盖它的测试，基于输入和输出。如果你将从有关代码中错误来源的更具体信息中受益，就写一个能给你那种具体信息的测试。

在决定你的测试是否足够时，问自己：这些测试会捕捉到被认为是错误的行为变化吗？如果这个功能中有一个错误，我会知道在哪里修复它吗？

回归测试和其他测试

到目前为止，我们一直在讨论我们想要测试什么，我们已经讨论了代表这些意图的术语。但还有另一套术语不知何故与此混淆。那是我们为什么想要测试。

当你想到“回归测试”时，你的脑海可能会跳到脚本化的测试用例，或者在更高层次上的自动化，比如通过UI。实际上，“回归”并不描述你想要测试什么，它描述了为什么——检查被测试系统（SUT）的质量自你的更改以来没有变差；它没有回归。

一个测试可以同时检查一些小的和有意义的事情，并检查它没有被代码更改改变。一个测试可以同时是“单元测试”和“回归测试”。

如果你已经在实施新功能时编写了单元和集成测试，你就已经在创建一组回归测试了。它们不必是单独的测试，也不必是唯一的测试。这就是说：仅仅因为你没有更高层次的测试，并不意味着你没有回归测试，仅仅因为你拥有单元和集成测试，并不意味着你不能或不应该拥有更高层次的测试。

理想的情况是，测试与实施一起编写，甚至在实施之前（TDD），而不是回溯并为早已存在的事物创建测试，尽管这通常也是为了填补空白和增强覆盖。当功能正在实施时，你可以称这些为功能测试。一旦功能完成，它们就变成了回归测试，只要你继续执行它们。

就像功能测试可以成为回归测试一样，回归测试的一个子集可以被用作冒烟测试（这些通常在更高层次上）——一组有限的检查，旨在在进行更详细测试之前检查SUT的最重要或基本功能。

一个测试可以同时检查变化，并就给定时间点进行更详细测试是否值得给出反馈。一个测试可以同时是“回归测试”和“冒烟测试”。

你应该为每个报告的错误编写回归测试吗？

简而言之，不会。更长版本的答案是，答案基于风险和投资回报（ROI）。这个错误再次发生的可能性有多大？如果这个错误再次发生，会有多灾难性？你希望多频繁地执行这个测试？编写、运行和维护测试（们）需要多长时间？

最终，这是一个基于判断的决定，依据是：如果错误再次出现，并且有人发现你之前没有为它创建测试，你会感到多么恐慌。

更多软件测试相关推荐：

软件测试更多干货文章

软件测试就业培训

  文章来源：51Testing软件测试网  版权归原作者所有