介绍
如果你没有执行单元测试，你就会同时失去第一时间改善软件质量和削减开发时间和成本的机会。这种牺牲当然是令人失望的。在此之前，开发人员一直没有一种可行的方法来执行单元测试。现在，JAVA开发人员能够使用ParaSoft的Jtest自动化JAVA单元测试，而C/C++开发人员能够利用ParaSoft最新的C++Test工具自动化C/C++单元测试。
本文阐述了执行单元测试的方法、优点和难点，然后描述了C++Test任何能够给C/C++开发人员带来巨大的好处。
什么是单元测试?
我们对单元测试的定义是测试应用中最小的单元，如C/C++中的一个类。C/C++单元测试的目的是执行每个类中的每一个方法或函数，检测所有存在的功能性问题、错误和构造弱点。发现这些典型的问题通常涉及到三种测试方法：黑盒测试、白盒测试和回归测试。黑盒测试通过确定类的公共界面是否依照定义执行，检查类的功能性；执行这种类型的测试不需要有关实现细节的知识。白盒测试通过确定类在遇到非预期输入时执行是否正确，检查所有的类的方法和函数（包括保护和私有成员）的健壮性；执行这种类型的测试需要对类的实现细节的完整知识。回归测试检查是否类的修改会在原来正确的代码中引入新的错误。
什么是单元测试的优点?
单元测试被公认为软件开发过程中的一个关键步骤。单元测试能够简化错误检测，在减少开发时间和成本的同时提高软件质量。
单元测试促进错误检测的第一个方面是使你更接近错误。图1和图2说明了这一点。
图1：应用测试
图1显示了一个包含许多对象的应用的测试模型。大椭圆表示应用，小椭圆表示对象，箭头表示用户输入，红星表示潜在的错误。
为了发现错误，必须修改输入，对象间的相互作用将迫使某对象引发潜在的错误。这一点无疑是有一定难度的。想象一下你站在一张台球桌前，所有的球围成一个三角形放置在桌子中间，要求你一杆击球将中间的球打入指定的袋中。这是一件多么困难的事情啊！就像要设计一个输入从而发现应用中的一个错误一样。由于其难度，开发人员只能依赖应用软件的运行失败来发现错误，但却仍然没有测试到许多类。因此只做集成测试是一件非常困难的事情。
单元级测试提供了一种更有效的发现错误的方法。如图2所示。
图2：单元测试
单独测试一个类时（与其它对象分离），由于更接近错误，找到潜在的错误就会变得容易得多。用上述台球的例子来比喻，就像是台面上只有壹两个球时，一杆将一个球击入指定的袋中。
单元测试促进错误检测的第二个方面是，将你从在问题中艰难跋涉去修正一个简单错误的困境中解救出来。因为错误是相互关联和作用的，在较高的层次上找到和修正一个错误，常常会发现另外的问题。当你在较高层次上测试时，原始的错误就象是洋葱的最内层一样，另外的错误就象紧包着内层的其它层：只有把外层都剥掉才能看到最内层。当你测试每一个类时，错误还很少有机会建立在其它错误之上，并相互作用引起奇怪的行为。因此在单元级上检测错误会容易的多。
最重要的结果是，更容易的错误检测能够在改善应用质量的同时大量削减开发时间和成本。首先，由于能够更容易地找到错误，就会减少发现它们的时间和资源。其次，由于你一写完一个类，就能发现和改正其中的错误，你就不需要在以后花费时间重新了解和摸索。最后，最重要的理由是：由于类的相互作用和关联性，在单元级修改一个类只会影响到原始的类，而在较高的层次上修改一个类可能会改变多个程序部件的设计和功能性。越迟发现问题，通常就要修改越多的代码。当修改的代码量增加时，两个其它因素也会随之增加：
- 修改每一个错误所需的时间和费用。
- 在代码中引入新的错误的机会。
- IBM: 根据IBM的一份内部资料指出，确定软件错误的相对成本是：在设计阶段，1.5；编码前，1；编码中，1.5；测试前，10；测试中，60；交付后，100。[Watts Humphrey]
- TRW: 确定错误的相对时间：需求分析阶段，1；设计阶段，3-6；编码阶段，10；开发测试阶段，15-40；接受性测试阶段，30-70；应用运行中，40-1000。[Boehm]
- IBM: 确定错误的相对时间：设计评审，1；代码检查，20；测试，82。[Remus]
- JPL: Bush得出的每个错误的平均成本：编码，US$90-US$120；测试，US$10,000。[Bush]
- Freedman and Weinberg: 使用设计评审和代码检查手段的项目在测试时发现错误的数量会减少10倍，测试成本降低50%-8%，包括评审和检查的成本。[Freedman]
基于上述信息，单元测试看上去就象一剂万能药。如果是这样的话，为什么每一个C/C++开发人员不马上对每一个类进行单元测试？就目前可以使用的技术来说，对C/C++的单元测试是一件困难、烦琐和耗时的事情，没有很好的工具来自动化这一过程，使得许多C/C++开发人员望而生畏。
执行单元测试的第一步是是目标类变得可测。这需要两个工作：
设计一个运行目标类的测试驱动程序。
设计桩函数，它们为被测类所引用的任何外部资源返回值。
建立一个测试驱动，需要建立一个新的类，除了测试原始类以外它不能用于任何其它目的。测试驱动应该具有下列特性：
- 一个指定设置和清除的标准方式。
- 一个选择个别测试和所有有效测试的方法。
- 一个分析输出的预期（或非预期）结果的机制。
- 一个标准的错误报告形式。
如果你的类引用任何还没有准备好或不可访问的外部资源（如外部文件、数据库和CORBA对象等），你必须建立相应的桩函数，它们的返回值类似于这些实际的外部资源应该返回的值。当建立这些桩函数时，你需要选择桩函数的返回值，它们将影响程序的执行路径...
为了测试类的功能性必须执行任何的路径，
足够的路径能够提供彻底的测试覆盖性。
下一步是设计和建立合适的测试用例。为了彻底地测试类的结构和功能性，你应该设计两中类型的测试用例：黑盒和白盒。
黑盒测试用例基于说明和规格文档。特别地，至少应该为规格文档的每个入口建立一个测试用例；更好的是这些测试用例能够测试每个入口的各种边界条件。还需要为发现的每一个错误增加另外的测试用例，以及任何你认为必要的其它测试。
白盒测试用例通过各种不同的输入充分地执行类的所有方法以发现缺陷。对于手工测试来说这是非常困难的。为了建立有效的白盒测试用例，你必须研究类的内部结构，然后编写测试用例尽可能完全地覆盖类的所有方法，以及覆盖所有可能引起类崩溃的输入。要达到较高的测试覆盖性，需要有效的白盒测试用例它们能够执行相当多数的路径。例如，一个典型的1万行的程序，大约有1亿条可能的路径；手工建立能够执行所有这些路径的输入几乎是不可行的。
在建立这些测试用例以后，你将要执行整个测试用例并分析结果，确定在那里出现了错误、崩溃和薄弱环节。你还需测量这些测试的覆盖性，以确定类被测试的程度以及需要追加的测试用例。
任何时候一个类被修改后，你应该执行回归测试，保证没有引入新的错误和/或原来的错误已经被更正了。回归测试包括白盒和黑盒测试用例，并且分析结果以确定类的质量是否得到的改善。
C++Test: 一个自动化的单元测试解决方案
ParaSoft认识到了C/C++单元测试内在的的价值和难度，开发了C++Test，一个自动的C/C++单元测试工具，增强了ParaSoft的自动错误防止和错误检测产品线。C++Test自动执行所有可能的单元测试过程。特别地，它能够自动：
- 建立每个被测类的测试驱动程序。
- 建立任何必要的桩函数，并允许你定制这些桩函数的返回值或加入自己的桩函数。
- 单键执行白盒测试的所有步骤。
- 生成黑盒测试用例的基础集合。
- 运行黑盒测试用例。
- 生成黑盒测试的输出结果。
- 执行回归测试。
- 跟踪测试覆盖性。
C++Test还是高度可定制的；例如，你可以改变测试用例的生成参数，过滤一定的文件、类或方法，在任何层次上（从这个项目到单个方法或测试用例）进行测试。
另外，C++Test很容易与你目前的开发过程合作。C++Test直接安装在DevStudio环境中，因此你能够立即测试任何正在开发中的类。只要在Developer Studio的工具栏上按下Test File或Test Project按钮，那么C++Test就会自动在C++Test图形用户界面中打开你的文件，为每个类建立一个测试驱动程序并自动测试每个类。
图3：C++Test图形用户界面
通过自动化单元测试过程，C++Test使得单元测试切实可行，即使对时间非常紧张的项目和开发人员也是如此，并且比手工单元测试具有更好的精确行和正确行。这一切将转化成更高质量的应用，并且以更短的时间以及更低的开发、支持和维护成本。
文章来源于领测软件测试网 https://www.ltesting.net/