什么是单元测试？
单元测试是一种软件测试类型，测试软件的各个单元或组件。目的是验证软件代码的每个单元是否按预期执行。单元测试由开发人员在应用程序的开发（编码阶段）中完成。单元测试隔离一段代码并验证其正确性。一个单元可以是单个功能，方法，过程，模块或对象。
在SDLC，STLC，V模型中，单元测试是集成测试之前完成的第一级测试。单元测试是白盒测试技术，通常由开发人员执行。不过，在现实世界中，由于时间紧迫或开发人员不愿进行测试，测试工程师也会进行单元测试。
为什么要进行单元测试？
有时，软件开发人员会尝试通过进行最少的单元测试来节省时间。这是一个谬误，因为跳过单元测试会导致在应用程序完成后的系统测试，集成测试乃至Beta测试期间更高的缺陷修复成本。在开发阶段进行正确的单元测试可以最终节省时间和金钱。这是执行单元测试的关键原因。
- 单元测试有助于在开发周期的早期修复错误并节省成本。
- 它有助于开发人员了解代码库，并使他们能够快速进行更改
- 好的单元测试可以作为项目文档
- 单元测试有助于代码重用。将您的代码和测试都迁移到新项目。调整代码，直到测试再次运行。
如何进行单元测试？
单元测试有两种类型
- 手动执行
- 自动化执行
单元测试通常是自动化的，但仍可以手动执行。软件工程并不偏爱哪一种，但自动化是首选。手动进行单元测试的方法可以使用分步指导文档。
在自动化的方法下
- 开发人员在应用程序中编写一段代码只是为了测试功能。他们稍后将注释掉，并最终在部署应用程序时删除测试代码。
- 开发人员还可以隔离功能以进行更严格的测试。这是一种更彻底的单元测试实践，涉及将代码复制和粘贴到其自身的测试环境中，而不是自然环境中。隔离代码有助于揭示被测代码与产品中其他单元或数据空间之间不必要的依赖关系。然后可以消除这些依赖性。
- 编码人员通常使用UnitTest Framework来开发自动化测试用例。开发人员使用自动化框架将标准编码到测试中，以验证代码的正确性。在执行测试用例期间，框架记录失败的测试用例。许多框架还将自动标记并报告这些失败的测试用例。根据故障的严重程度，框架可能会停止后续测试。
- 单元测试的工作流程是1）创建测试用例2）评审/返工3）基线4）执行测试用例。
单元测试技术
单元测试中使用的代码覆盖率技术如下：
- 语句覆盖
- 判定覆盖
- 分支覆盖
- 条件覆盖
- 有限状态机覆盖率
单元测试示例：模拟对象(Mock)
单元测试依赖于创建的模拟对象来测试尚不属于完整应用程序部分的代码。模拟对象填充程序缺少的部分。
例如，您可能具有一个需要尚未创建的变量或对象的函数。在单元测试中，这些将以模拟对象的形式解决，这些对象仅出于在该部分代码上进行单元测试的目的而创建。
单元测试工具
有几种自动化工具可用于协助单元测试。我们将在下面提供一些示例：
- Junit：Junit是可免费使用的Java编程语言测试工具。它提供断言以标识测试方法。该工具首先测试数据，然后将其插入代码段。
- NUnit：NUnit被广泛用于所有.net语言的单元测试框架。它是一个开放源代码工具，允许手动编写脚本。它支持可以并行运行的数据驱动测试。
- JMockit：JMockit是开源的单元测试工具。它是具有行和路径度量的代码覆盖工具。它允许带有记录和验证语法的模拟API。该工具提供行覆盖率，路径覆盖率和数据覆盖率。
- EMMA：EMMA是一个开源工具包，用于分析和报告用Java语言编写的代码。Emma支持覆盖类型，例如方法，行，基本块。它是基于Java的，因此它没有外部库依赖关系，并且可以访问源代码。
- PHPUnit：PHPUnit是用于PHP程序员的单元测试工具。它只占用一小部分称为单元的代码，然后分别测试每个单元。该工具还允许开发人员使用预定义断言方法来断言系统以某种方式运行。
这些只是一些常用的单元测试工具。还有很多，尤其是对于C语言和Java，但是无论使用哪种语言，您都一定会找到满足您的编程需求的单元测试工具。
测试驱动开发（TDD）和单元测试
TDD中的单元测试涉及测试框架的广泛使用。为了创建自动化的单元测试，使用了单元测试框架。单元测试框架不是TDD独有的，但对于它来说是必不可少的。下面我们看一下TDD带给单元测试领域的一些内容：
- 在编码之前编写测试用例
- 高度依赖测试框架
- 应用程序中的所有类均经过测试
- 快速简便的集成成为可能
单元测试的误区
误区：这需要时间，而且我总是安排得太久
我的代码坚如磐石！我不需要单元测试。
就其本质而言，误区是错误的假设。这些假设导致如下恶性循环：
事实是，单元测试可以提高开发速度。
程序员认为集成测试将发现所有错误，并且不执行单元测试。单元集成后，很容易就可以找到并修复的。然而，非常简单的错误需要花费很长时间来跟踪和修复。
单元测试优势
- 希望了解单元提供什么功能以及如何使用它的开发人员可以查看单元测试，以基本了解单元API。
- 单元测试允许程序员在以后重构代码，并确保模块仍然正常工作（即回归测试）。该过程是针对所有功能和方法编写测试用例，以便每当更改导致故障时，都可以快速识别并修复该故障。
- 由于单元测试的模块化性质，我们可以测试项目的各个部分，而无需等待其他部分完成。
单元测试的缺点
- 不能期望单元测试发现程序中的每个错误。即使在最简单的程序中，也无法评估所有执行路径
- 单元测试的本质就是将重点放在代码单元上。因此，它无法发现集成错误或广泛的系统级错误。
建议将单元测试与其他测试活动结合使用。
单元测试最佳实践
- 单元测试用例应独立。如果需求有任何增强或变化，则单元测试用例不应受到影响。
- 一次仅测试一个代码。
- 遵循清晰一致的单元测试命名约定
- 如果任何模块中的代码发生更改，请确保该模块有相应的单元测试用例，并且该模块在更改实现之前通过测试
- 在进行SDLC的下一阶段之前，必须修复在单元测试期间发现的错误。
- 采用“测试作为您的代码”方法。未经测试而编写的代码越多，检查错误的路径就越多。
总结
- 单元测试定义为一种软件测试类型，其测试软件的各个单元或组件。
- 如您所见，单元测试可能涉及很多内容。根据所测试的应用程序以及所使用的测试策略，工具和理念，它可能很复杂，也可能很简单。在某种程度上，始终必须进行单元测试。
end
视频编/译自Guru99，国外的一个免费IT课程平台，很喜欢这种短而精的视频教学形式，分享给大家。 本人英语水平有限，字幕是机器翻译后再校对的，存在不当之处敬请谅解。
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/te-unit/64636.html