单元测试的意义

单元测试及工具

1.单元测试的意义

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。

经常与单元测试联系起来的另外一些开发活动包括代码走读(Code review)，静态分析(Static analysis)和动态分析(Dynamic analysis)。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。

单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行维护。

单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。测试部门可以作一定程度的审核。对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。

2.单元测试的时机

单元测试越早越好，早到什么程度？XP开发理论讲究TDD，即测试驱动开发，先编写测试代码，再进行开发。在实际的工作中，可以不必过分强调先什么后什么，重要的是高效和感觉舒适。先编写产品函数的框架，然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产品函数的代码，每写一个功能点都运行测试，随时补充测试用例。所谓先编写产品函数的框架，是指先编写函数空的实现，有返回值的随便返回一个值，编译通过后再编写测试代码，这时，函数名、参数表、返回类型都应该确定下来了，所编写的测试代码以后需修改的可能性比较小。

经验表明一个尽责的单元测试方法将会在软件开发的某个阶段发现很多的Bug，并且修改它们的成本也很低。在软件开发的后期阶段，Bug的发现并修改将会变得更加困难，并要消耗大量的时间和开发费用。无论什么时候作出修改都要进行完整的回归测试，在生命周期中尽早地对软件产品进行测试将使效率和质量得到最好的保证。在提供了经过测试的单元的情况下，系统集成过程将会大大地简化。开发人员可以将精力集中在单元之间的交互作用和全局的功能实现上，而不是陷入充满很多Bug的单元之中不能自拔。

3.单元测试的工具

我们公司所用的单元测试工具为Testbed，Testbed是英国LDRA公司的主要测试工具，支持C，C++，Ada83，Cobol等语言。

主要用于在软件编程、软件测试与软件维护阶段，以提高软件产品的质量。其中，在编程阶段可检测和修改软件的错误与缺点；在测试阶段，实时显示测试覆盖率，提供调整测试方案和优化软件测试的必要信息；在维护阶段，提供理解软件的逆向工程工具。

Testbed工具套件单元测试主要有以下优点：

∙自动生成测试驱动，无需编写脚本；

∙自动侦测源代码的更改，对需要修改的测试数据进行跟踪和报告；

∙测试数据和结果易于保存和管理，便于回归测试；

∙提供图形界面和命令行接口两种操作方式，极大的提高了测试效率；

∙交互式的操作方式便于用户直观，高效的进行测试结果确认；

∙提供文本和图形化两种方式进行代码覆盖率查看；辅助用户进行高效的测试结果分析和白盒测试用例设计。

Testbed单元测试工具实现了单元测试过程的自动化，传统的单元测试方法需要人工编写单元测试代码，然而使用Testbed只需输入输入输出参数以及返回值，便可自动生成测试驱动，极大地减轻了工作量，提高了工作效率。

在测试驱动编写完成后，可获取当前代码覆盖率分析，代码覆盖率分析能使我们直观、详细的了解被测试代码的测试覆盖情况即“哪些代码被执行过了？哪些代码没有被执行过”，并且通过进一步分析明确需要如何补充测试用例来验证没有被测试执行过的代码，或者分析代码未被执行的原因，从而帮助发现程序中的缺陷提高软件质量。

LDRA工具套件能够提供包括语句覆盖、分支分支覆盖、调用覆盖、MC/DC

覆盖、测试路径覆盖(LCSAJ)、目标码覆盖等在内各种测试覆盖率指标，便于修改代码已达到最优的状态。