。

*valgrind网站上的，骑士战恶龙

PS：说起Run-time错误定位工具，我最初使用的是Boundchecker，那还是在Visual c++ 6.0的时代，那款工具确实很好用，功能、性能都不错，但后来不知道Compuware公司出了什么问题，对这款工具的改进很少，到了MS .net出来以后，我试用过Boundchecker针对.net的版本，性能很差。后来是否再有更新我就不清楚了，因为再也没有使用过Compuware的产品。Purify是现在的公司使用的Run-time错误定位工具，使用方法和Boundchecker非常类似（2002年的时候Compuware指控IBM错误分析器产品中使用自己拥有版权的代码，就是这款产品），也许是因为曾经使用过Boundchecker先入为主的原因，对这款工具始终感觉不是很好，在这次测试过程中，Purify自己竟然宕了。使用过valgrind后，我查了关于它的一些资料，对这款工具评价很好。遇到相同需求的朋友，可以试一下valgrind这款工具，相信不会让你失望！

1.1 概述
  函数接口（或称API）是一个产品类型。本部分的测试指南，描述了对这类产品进行测试时的参考过程。
  下面首先给出整体的测试过程，然后针对每个子过程需要进行的工作进行具体描述，最后是几点补充说明。

1.2 测试过程
函数接口的整体测试过程如下：
 * 制定测试计划
 * 设计测试用例
 * 执行测试
 * 编写可复用的测试代码
 * 增强测试
 * 结束测试

1.3 过程说明
下面是对各个子过程的具体说明：
1.3.1 制定测试计划
分析被测试对象的具体情况，制定测试计划，形成文档。测试计划至少要包括以下内容：
 测试范围。测试要覆盖哪些库以及库中的哪些函数，要覆盖哪些文档，包含哪些测试类型等等。
 测试工具。选择什么工具组织测试代码，是否还需要其它的辅助性测试工具。
 测试环境。都需要在什么环境下执行测试，环境指硬件类型、OS、DB等等。
 测试数据组织。对于测试代码所需要的测试数据，以什么方式来组织和保存。
 进度安排。各个阶段的工作内容、时间安排。
 测试尺度。测试的深度和广度是什么。根据现有的资源情况，在计划中设定一个标准，避免测试的盲目性和随意性。
1.3.2 设计测试用例
  按照函数接口说明文档，依据测试计划中的测试尺度来设计测试用例，形成文档。
  函数接口的测试用例设计，与传统GUI界面产品的用例设计思路是一样的，包括测试输入（正常、异常输入）和预期输出两部分，等价划分、边界值等设计方法也同样适用，只是这时的界面变成了函数接口的输入参数，而不再是GUI元素。
1.3.3 执行测试
  依据测试用例设计文档，编写调试代码，执行测试。这是函数接口测试中最为耗时的过程，Bug也主要是在这个过程中被发现的。开发人员修正Bug，测试人员进行回归测试，直至Bug被关闭。
1.3.4 编写可复用的测试代码
  当一个函数的bug修正基本完成后，整理调试代码，将其转化为可复用测试代码。
  函数接口最后的测试代码与其测试用例设计应该是一致的，测试代码是测试用例的具体实现。如果测试代码需要独立的测试数据，则要详细记录下这些数据的相关信息。测试用例设计文档、测试代码、测试代码所需测试数据，这三者构成完整的测试程序。
  在编写测试代码的时候需要注意：不同测试部分的测试数据应该互不干扰，各部分的测试代码，在测试结束时要负责恢复测试环境，以使下一个测试能正常运行，也便于测试代码的维护。
1.3.5 增强测试
  这是一个可选项目，不是必须的。是否进行这项工作，在制定测试计划的时候就要考虑清楚。
  对于函数接口的增强测试，可以考虑的测试内容包括（但不限于）：代码测试覆盖率的统计、函数接口的Run-time错误检测。这类测试工作需要工具的支持，可选的工具如：Compuware的Devpartner，IBM的PurifyPlus等。
1.3.6 结束测试
  结束测试阶段的工作包括：编写测试报告、测试资料整理。
  完成测试计划中罗列的所有工作，达到预期的测试目标后，进行测试报告的编写。
  对于测试过程中产生的测试资源——测试计划、测试用例设计、测试代码，这些是以后测试复用的基础。如果这些资源本身不能说明自己，则需要整理一份单独的说明文档，供以后参考使用。

1.4 补充说明
1.4.1 测试过程的补充说明
  对于上面描述的测试过程中的‘设计测试用例’、‘执行测试’、‘编写可复用的测试代码’这三个步骤，不是完成一项后，才开始进行下一项，而通常是一个交替进行、逐步迭代的过程。先制定好测试用例文档的整体结构，然后设计一个函数接口的测试用例，接着执行对其的测试，最后整理成可复用的测试代码。针对每个函数接口都重复这个过程，直至完成所有函数接口的测试。
1.4.2  测试过程中产生的测试资源
  测试过程中产生，测试结束后需要存档的测试资源包括：
    测试计划（文档）；
    测试用例设计（文档）；
    测试代码及相关数据（代码、数据）；
    测试报告（文档）；
    其它的相关说明文档（如果有的话）；
    测试框架的介质（如果选用了第三方测试框架的话）。
1.4.3 函数接口测试的自动化
  函数接口产品的一个特点就是对外表现比较稳定，因此一旦实现了对其测试过程的自动化，积累起可复用的测试资源，就会大大缩短以后该产品的测试周期。所以对于函数接口的测试，建议都能以测试自动化的过程进行组织。
  为了实现函数接口的测试自动化，就需要选择一个稳定、可靠的测试框架来组织测试代码，在这里建议使用XUnit工具。
（注：针对不同的开发语言，Xunit提供了不同的版本，如Junit（for Java），CppUnit（for C/C++），Nunit（for MS .Net）等等，每种主流的语言都有其对应的Xunit框架。Xunit是Open Source的工具，可以从http://sourceforge.net上下载。）
1.4.4 测试代码的维护
  测试代码并不是写完后一次后就一劳永逸了。随着被测产品的升级，测试代码也需要作出相应的调整，以适应被测产品的变化。

我在本文中介绍了NuMega Devpartner Studio 6.5测试工具套件(以下简称NuMega)在测试过程中应用的问题，以使该工具能更好的辅助我们的测试工作。

文中所介绍的NuMega，专指NuMega for Visual C++版，对于NuMega for Visual Basic版和NuMega for Delphi版的使用说明，不在本文的介绍范围之内，这一点请注意。

2应用方案

NuMega for Visual C++版共提供了三个工具BoundsChecker、TrueCoverages和TrueTime。我们也分三部分分别介绍BoundsChecker、TrueCoverages、TrueTime在测试过程中的应用。因为本文只讨论工具与测试过程的结合，所以对工具功能只做简单介绍。如果想要详细了解工具的功能和使用，请参见我Blog中的另一篇文章——《单元测试工具Numega》。

好了，现在就开始，先来说BoundsChecker。

2.1 BoundChecker

BoundsChecker主要定位程序在运行时期发生的各种错误。BoundsChecker能检测的错误包括：内存泄露；资源泄露；对指针变量的错误操作；内存读、写溢出；  使用未初始化的内存；API函数使用错误等等。

BoundsChecker是一个动态、白盒测试工具，最适合在单元测试阶段、集成测试阶段使用。在使用BoundsChecker对程序进行检测时，要求有程序的源代码。

在单元测试阶段、集成测试阶段使用BoundsChecker的基本步骤是：

1 为被测试程序制定测试用例。这一步很重要，因为BoundsChecker只能检查被执行过的代码中是否存在错误，如果某一部分的代码没有被执行到，即使这部分代码有问题，BoundsChecker也不能发现。所以，在开始使用BoundsChecker前，为被测程序制定覆盖全面的测试用例非常重要。

2 执行测试用例。打开BoundsChecker功能，运行被测试的程序，按照制定好的测试用例，逐个执行。在操作被测试程序时，就象操作平常的程序一样，输入数据，点击鼠标，观察预期的结果，BoundsChecker会在后台跟踪、监视程序的运行情况，一旦发现错误，会马上记录下错误的相关信息。

这个时候，BoundsChecker的价值就体现出来了。反映在功能上的错误，我们通过观察马上就可以发现，但对于象内存泄露这样的“癌症”，光从程序运行的外表是不能发现的，所以这种错误也就更可怕。通过BoundsChecker，能增强我们对程序内部正常运行的信心。

3第三步就是分析错误了。根据BoundsChecker列出的错误列表，分析错误产生的原因。对于每一个错误，BoundsChecker会给出该错误的类型、描述、发生位置等信息。

4除了用BoundsChecker检查程序中的Run-Time错误外，还可以使用BoundsChecker检测程序中使用的Win32 API函数在不同平台上的兼容性。能检测的平台包括：Windows2000、Windows NT 4.0、Windows NT 3.51、Windows 98、Windows 95、Windows CE 2.0，除此之外，还可以检测代码是否符合标准C和扩展标准C的要求。

5最后，根据发现的问题，提交检测报告。

2.2 TrueCoverage

覆盖率对于测试来说是一项重要数据。在我们执行了针对一个功能模块的所有测试用例后，非常想了解测试对于模块代码的覆盖情况，也就是测试覆盖率达到了多少，以此来判断测试工作是否可以结束，如果还未达到测试目标，如何进一步补充测试用例。对于这些问题，如果没有覆盖率统计工具的帮助是很难进行的。

TrueCoverage的功能就是统计测试覆盖率，它恰好能为我们就上面这个问题提供帮助。在使用TrueCoverage记录程序的覆盖情况时，要有程序的源代码。

TrueCoverage统计测试覆盖率时是针对代码级的，所以只适合应用于单元测试阶段和集成测试阶段，将TrueCoverage（包括类似的覆盖率统计工具）应用到系统测试上去是不适宜的。

在单元测试、集成测试阶段使用TrueCoverage的基本步骤是：

1制定出尽可能完善的测试用例。这一步和是否使用TrueCoverage没有太大的关系，不管你是否统计覆盖率，对于测试来说，制定出完善的测试用例都是必要的。

2打开TrueCoverage，启动被测试的程序，依次执行测试用例。你就象往常那样操作程序，按照测试用例进行输入，观察实际输出，并与预期输出进行比较，最后记录下每个测试用例的执行结果。TrueCoverage会在后台记录程序的执行覆盖情况。

3查看、分析测试覆盖情况。在执行完事先制定好的测试用例后，根据TrueCoverage提供的测试覆盖率信息，决定测试工作是否可以结束，如果还未达到测试目标，我们可以根据TrueCoverage提供的测试覆盖率信息，进一步补充测试用例。TrueCoverage用不同的颜色标识被执行的代码和未被执行的代码，这很有利于我们补充测试用例。

  4最后，达到事先要求的覆盖率。

TrueCoverage给出的覆盖率是“语句覆盖”，是一种低强度的覆盖率，所以我们测试的项目，用TrueCoverage统计覆盖率后，应使其尽量趋近100%。

TrueCoverage在我们的测试工作中是一个辅助、引导的角色，它本身并不能发现程序中的错误。它的作用是使我们能够了解当前测试达到的状况，并为进一步增强测试提供依据。

2.3 TrueCoverage和BoundsChecker的结合使用

TrueCoverage和BoundsChecker这两个工具可以结合起来使用。NuMega集成到VC++ IDE后，在TrueCoverage和BoundsChecker菜单下，都有一个菜单项[Rebuild with BoundsChecker and TrueCoverage]，通过这一菜单命令编译连接生成的可执行文件，在程序运行结束后，能同时得到TrueCoverage和BoundsChecker（FinalCheck）的检测结果。

2.4 TrueTime

如何提高代码的运行效率，是开发过程中的一个重要问题。程序运行速度慢，但不容易找到是在哪里出了问题，查找性能瓶颈的位置就成为解决问题的关键。TrueTime 就是一个对应用程序的运行性能进行分析，查找程序性能瓶颈的工具。

使用TrueTime的基本步骤是：

1制定测试用例。TrueTime只能给出被执行过的代码的性能数据，未被执行的代码不会显示性能数据。

这一步看起来好象与使用BoundsChecker、TrueCoverages的第一步一样，其实不然。在BoundsChecker、TrueCoverages中，要求测试用例制定的尽可能详细、全面，但在TrueTime 中没有这个要求，这是因为使用TrueTime的目的与前两者不一样。TrueTime用来测试程序的运行性能，但我们并不是对程序任何部分的性能都感兴趣，因此，我们只需要那些覆盖了想要了解其性能的功能部分的测试用例，比如：实际运行速度较慢的功能部分、需提供给用户性能指标的功能部分等。所以，在使用TrueTime测试程序的性能数据时，制定的测试用例是有针对性的，并不要求有多么多么的全面。

  2 打开TrueTime，启动被测试的程序，执行测试用例。TrueTime会在后台记录下程序的性能数据。

 3 查看、分析、报告性能数据。在执行完有针对性的测试用例后，根据TrueTime提供的性能数据，可以得出程序的性能测试报告。

3结束

BoundsChecker、TrueCoverages和TrueTime在测试中的应用就介绍到这了。这三个工具，最适合应用的测试阶段是单元测试、集成测试阶段，当进行这两个测试阶段的工作时，可考虑使用这些工具。

白盒测试
　　C++ Test对C/C++源代码进行分析，针对所有的类的成员函数（包括：公共的、保护的以及私有类型的）进行测试。测试的方法是判断当输入一个非法的参数时，有关函数能否正确处理。（Record命令）在此状态下软件针对指定的文件、类或者是函数自动生成测试用例。

黑盒测试
　　不对源代码进行分析，并且只针对类的公共接口函数进行测试。（Play命令）
在此状态下软件不自动生成测试用例，而是直接运行在"测试用例编辑器"中当前已有的测试用例（手工添加的）。

回归功测试
　　在修改源代码后用原有的测试用例进行重新测试。（Play命令）
　　建议在实际使用中首先用Record命令执行一遍白盒测试，让软件根据函数自动生成相应的测试用例，然后再根据需要手工添加一些测试用例，最后再通过Play命令执行一遍黑盒测试。

示例一
　　假设我们要测试如下一个类的成员函数：int mode2(int nParam)，则在进行白盒测试时软件会自动为我们生成如下6个测试用例：
　　nParam = 1, 0, -1, 2147483647, -2147483647, 230
　　可以看出，软件测试用例的生成主要还是测试一些边界值，例如最大值、最小值、0等。
示例二
　　假设我们要测试如下一个类的成员函数：void strcpy(char* dest, char const * src)，则软件会自动生成如下9个测试用例：
　　(1) dest = NULL, src = NULL
　　(2) dest = "yPqKIJ!u_", src = NULL
　　(3) dest = "", src = NULL
　　(4) dest = NULL, src = "h)zn9b"
　　(5) dest = "BsmC,/i=zI6CT}pX", src = "HcI{BeP(J"
　　(6) dest = "", src = "% i?~TnON"
　　(7) dest = NULL, src = ""
　　(8) dest = "($MN<n;^", src = ""
　　(9) dest = "", src = ""
　　可见，如果我们的代码在实现时没有对各种可能情况（尤其是边界条件）进行特殊处理的话，则通过C++Test可以方便地发现这些潜在的问题。此外，对于一些特殊的测试情况，我们还可以手工创建测试用例。此外，采用C++ Test也可以帮助我们检查程序的编码情况，判断是否严格按编码规范进行开发。

使用
　　C++ Test的使用比较简单，即可以针对一个VC工程进行全面的测试，也可以一次只对一个C/C++源文件进行测试。
在试用中发现，如果项目比较大时，最好不要直接对一个工程进行自动测试，而应按文件一个一个地测试，否则可会会导致程序死掉。由于其是采用JAVA技术开发的，所以在使用时最好使用运算速度较快的机器。