单元测试

单元测试（也称为单元测试或组件测试）是一种软件测试，用于检查计算机程序的各个可定义部分（例如，选定的代码部分、模块、子程序、单元或类）。 这些通常由软件开发者自己进行的软件测试的目的是证明它们的技术可操作性和技术（部分）结果的正确性。

元测试也被理解为测试的早期阶段，测试软件内部最详细的组件。根据软件验证和 验证计划单元测试仅对于关键性较低的模块（发生错误时对用户造成的不便很少）是不必要的。

由于单元级别的算法通常只有有限的复杂性，并通过明确定义的接口激活，因此可以用相对较少的测试用例对其进行全面测试。 这是后续测试级别集成测试的先决条件，以便能够将测试用例与更大的功能部分或整个应用程序的集成交互对齐； 因此，特定于模块的详细星座可以限制为随机样本，从而xxx减少所需的测试用例数量。

为了进行比较：只有在确保其各个部分的功能时，才对设备进行整体测试。

元测试是白盒测试。 这意味着在定义测试用例时，要测试的源代码是已知的。 软件的规格仅用于确定目标结果。 原则上，所有源代码部分必须至少执行一次。 语句覆盖、分支覆盖或路径覆盖可以帮助确定至少在理论上需要哪些测试用例（请参阅面向控制流的测试程序）。 在实践中，人们通常会尝试用尽可能少的测试用例来达到设定的覆盖率目标，因为所有单元测试也必须持续维护。

通常所有的元测试都是基于统一的基本结构。 首先 (1) 初始化初始状态，然后 (2) 执行要测试的操作，最后 (3) 将实际结果与从规范导出的目标值进行比较。 测试框架为这些比较提供断言方法。

单元测试测试孤立的模块，基本上不与其他模块交互。 因此，其他模块或外部组件，如数据库、文件、后端系统或子程序，必须或可以通过单元测试中的辅助对象来模拟，只要被测试的模块（测试项或测试对象）有此要求。

可用于此目的的辅助对象基本上可以根据

• 是否替换调用模块（测试是调用模块；替换对象称为“存根”），
• 它们是否替换了待测模块/子程序的调用（环境）（测试是子程序，模拟调用的程序称为“驱动程序”）。

辅助例程如何完全映射原始行为，例如在合理性检查或返回响应代码时，必须通过适当的测试用例设计来考虑。 特别是在面向对象的编程语言中，更进一步，可以在这方面区分更详细的帮助对象类别，请参阅模拟对象。

这样的辅助对象是 z，作为代理实现，通过控制反转的方式提供。 与所有模块都已集成相比，通常可以更容易地测试模块，因为在这种情况下，必须考虑各个模块的依赖性，并在测试处理中加以考虑。 如果测试实际需要的其他组件尚不可用，这种孤立的单元测试也是可能的。

所有组件在其原始版本中的完整测试是稍后进行的集成和系统测试的主题 - 在单元测试中未识别的错误（例如，由于测试对象和辅助例程的相同错误假设）应该被发现。

根据契约设计原则，元测试不测试方法的内部结构，而只测试其外部效果（返回值、输出、状态变化、到保险丝）。 如果检查方法的内部细节（这称为白盒测试），即使外部影响没有改变，测试也可能失败。 因此，通常推荐所谓的黑盒测试，即只检查外部影响。

随着敏捷软件开发方法的传播，尤其是测试驱动开发，尽可能自动地运行元测试已经变得很普遍。 为此，通常在 JUnit 等测试框架的帮助下编写测试程序。 测试框架用于调用各个测试类并运行它们的组件测试。 大多数测试框架都提供测试结果的图形摘要。

自动化元测试的优点是运行起来简单且成本低廉，并且可以快速发现新的程序错误。

• 平均而言，30% 的错误可以使用自动化单元测试检测出来。 使用测试驱动开发时，平均可以避免 45%，最多 85% 的错误。
• 在开发过程中通过元测试检测到错误。 根据十法则，单元测试避免的错误成本是后期测试级别的许多倍，这使得单元测试成为最有效的测试级别。
• 如果出现错误，可以更精确地缩小范围，从而更快地找到并纠正错误。
• 测试实现了动态文档的目的。 结合有意义的对象命名（干净的代码），可以省略额外的文档措施。
• 因为单个模块只有少数可能的代码执行路径，所以与其他类型的测试相比，要考虑的可能组合执行路径要少得多。 更高级别的测试可以随机关注最重要的执行路径，从而显着减少。
• 因为只测试单个模块，单元测试可以执行得更快，通常快几个数量级，因此比其他类型的测试更频繁（或连续）。
• 通过测试保护错误将防止该错误再次发生。
• 错误的减少导致大中型软件项目的开发速度优势。
• 由于必须避免依赖才能启用元测试，因此可以相对快速地更改代码。 这样可以更快地响应不断变化的需求。
• 由于自动化测试比手动测试快几个数量级，因此测试时间显着缩短。 这意味着可以更快地完成开发阶段并缩短发布周期。

• 实现新功能时，不仅要实现功能，还要准备/定义相关测试。 这通常会导致多项实施工作。
• 如果发生更改，不仅更改后的功能而且相关的测试都必须进行调整。 因此，测试通常是一个障碍，特别是在开发原型时，代码库变化很快。
• 因为测试使用了该功能，所以在 IDE 中更难查看某个功能是否不再在其他地方使用并因此可以删除。
• 如果测试相互依赖（例如，由于共享测试数据），对代码库的个别更改可能会影响大量测试，这会随着代码库的大小呈指数级增加更改工作量。

元测试（与任何测试一样）不能保证或证明被测试的模块没有错误，仅支持它。 元测试的局限性必然是只能发现所使用的测试能够检测到的那些错误。 因此，测试“绿色”的软件组件不一定没有错误。

测试“绿色”的代码的特性以及对这个结果的渴望可能导致实际（无意识地）只进行这么多测试，直到所有测试都是“绿色”。 将没有失败测试的模块视为无错误是测试驱动开发实践中的谬误。

为了获得足够的测试覆盖率，在创建测试用例之前应用重构措施可能是值得的。