程序中的每一项功能都是测试来验证它的正确性。它为以后的开发提供支缓。就算是开发后期，我们也可以轻松的增加功能或更改程序结构，而不用担心这个过程中会破坏重要的东西。而且它为代码的重构提供了保障。这样，我们就可以更自由的对程序进行改进。

编写单元测试将使我们从调用者观察、思考。特别是先写测试(test-first)，迫使我们把程序设计成易于调用和可测试的，即迫使我们解除软件中的耦合。

单元测试是一种无价的文档，它是展示函数或类如何使用的最佳文档。这份文档是可编译、可运行的，并且它保持最新，永远与代码同步。

自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地的快速运行测试。

如果要给单元测试定义一个明确的范畴，指出哪些功能是属于单元测试，这似乎很难。但下面讨论的四个问题，基本上可以说明单元测试的范畴，单元测试所要做的工作。1、 它的行为和我期望的一致吗?

这是单元测试最根本的目的，我们就是用单元测试的代码来证明它所做的就是我们所期望的。

编写单元测试，如果只测试代码的一条正确路径，让它正确走一遍，并不算是真正的完成。软件开发是一个项复杂的工程，在测试某段代码的行为是否和你的期望一致时，你需要确认:在任何情况下，这段代码是否都和你的期望一致;譬如参数很可疑、硬盘没有剩余空间、缓冲区溢出、网络掉线的时候。

不能依赖的代码是没有多大用处的。既然单元测试是用来保证代码的正确性，那么单元测试也一定要值得依赖。

单元测试能够帮我们充分了解代码的用法，从效果上而言，单元测试就像是能执行的文档，说明了在你用各种条件调用代码时，你所能期望这段代码完成的功能。

到这里，我们已经列举了使用单元测试的种种理由。也许，每个人都同意，是的，该做更多的测试。这种人人同意的事情还多着呢，是的，该多吃蔬菜，该戒烟，该多休息，该多锻炼……这并不意味着我们中的所有人都会这么去做，不是吗bsp; 我们知道，在开发时越早发现BUG，就能节省更多的时间，降低更多的风险。

下图表摘自<<实用软件度量>>(Capers Jones，McGraw-Hill 1991)，它列出了准备测试，执行测试，和修改缺陷所花费的时间(以一个功能点为基准)，这些数据显示单元测试的成本效率大约是集成测试的两倍，是系统测试的三倍(参见条形图)。

术语:域测试(Field test)意思是在软件投入使用以后，针对某个领域所作的所有测试活动。

如果你仍然认为在编写产品代码的时候，还是没有时间编写测试代码，那么请先考虑下面这些问题:

1)、对于所编写的代码，你在调试上面花了多少时间。

2)、对于以前你自认为正确的代码，而实际上这些代码却存在重大的bug，你花了多少时间在重新确认这些代码上面。

3)、对于一个别人报告的bug，你花了多少时间才找出导致这个bug 的源码位置。

回答完这些问题，你一定不再以"太花时间"作为拒绝单元测试的借口。

2、 运行测试的时间太长了。

合适的测试是不会让这种情况发生的。实际上，大多数测试的执行都是非常快的，因此你在几秒之内就可以运行成千上万个测试。但是有时某些测试会花费很长的时间。这时，需要把这些耗时的测试和其他测试分开。通常可以每天运行这种测试一次，或者几天一次。

3、 测试代码并不是我的工作。

你的工作就是保证代码能够正确的完成你的行为，恰恰相反，测试代码正是你不可缺少的工作。

4、 我并不清楚代码的行为，所以也就无从测试。

如果你实在不清楚代码的行为，那么并不是编码的时候。如果你并不知道代码的行为，那么你又如何知道你编写的代码是正确的呢?

5、 但是这些代码都能够编译通过。

我们前面已经说过，代码通过编译只是验证它的语法通过。但并不能保证它的行为就一定正确。

6、 公司请我来是为了写代码，而不是写测试。

公司付给你薪水是为了让你编写产品代码，而单元测试大体上是一个工具，是一个和编辑器、开发环境、编译器等处于同一位置的工具。

7、 如果我让测试员或者QA(Quality Assurance)人员没有工作，那么我会觉得很内疚。

你并不需要担心这些。请记住，我们在此只是谈论单元测试，而它只是一种针对源码的、低层次的，为程序员而设计的测试。在整个项目中，还有其他的很多测试需要这些人来完成，如:功能测试、验收测试、性能测试、环境测试、有效性测试、正确性测试、正规分析等等。

8、 我的公司并不会让我在真实系统中运行单元测试。

我们所讨论的只是针对开发者的单元测试。也就是说，如果你可以在其他的环境下(例如在正式的产品系统中)运行这些测试的话，那么它们就不再是单元测试，而是其他类型的测试了。实际上，你可以在你的本机运行单元测试，使用你自己的数据库，或者使用mock对象。

多数讲述单元测试的文章都是以Java为例，本文以C++为例，后半部分所介绍的单元测试工具也只介绍C++单元测试工具。下面的示例代码的开发环境是VC6.0。

产品类:

classCMyClass

{

public:

int Add(int i, int j);

CMyClass();

virtual ~CMyClass();

private:

int mAge; //年龄

CString mPhase; //年龄阶段，如"少年"，"青年"

};

建立对应的测试类CMyClassTester，为了节约编幅，只列出源文件的代码:

void CMyClassTester::CaseBegin()

{

//pObj是CMyClassTester类的成员变量，是被测试类的对象的指针，

//为求简单，所有的测试类都可以用pObj命名被测试对象的指针。

pObj = new CMyClass();

}

void CMyClassTester::CaseEnd()

{

delete pObj;

}

测试类的函数CaseBegin()和CaseEnd()建立和销毁被测试对象，每个测试用例的开头都要调用CaseBegin()，结尾都要调用CaseEnd()。

接下来，我们建立示例的产品函数:

int CMyClass::Add(int i, int j)

{

return i+j;

}

和对应的测试函数:

void CMyClassTester::Add_int_int()

{

}

把参数表作为函数名的一部分，这样当出现重载的被测试函数时，测试函数不会产生命名冲突。下面添加测试用例:

void CMyClassTester::Add_int_int()

{

//第一个测试用例

CaseBegin();{ //1

int i = 0; //2

int j = 0; //3

int ret = pObj->Add(i, j); //4

ASSERT(ret == 0); //5

}CaseEnd(); //6

}

第1和第6行建立和销毁被测试对象，所加的{}是为了让每个测试用例的代码有一个独立的域，以便多个测试用例使用相同的变量名。

第2和第3行是定义输入数据，第4行是调用被测试函数，这些容易理解，不作进一步解释。第5行是预期输出??错，ASSERT是VC的断言宏，也可以使用其他类似功能的宏，使用测试工具进行单元测试时，可以使用该工具定义的断言宏。

示例中的格式显得很不简洁，2、3、4、5行可以合写为一行:ASSERT(pObj->Add(0, 0) == 0);但这种不简洁的格式却是极力推荐的，因为它一目了然，易于建立多个测试用例，并且具有很好的适应性，同时，也是极佳的代码文档，总之，输入数据和预期输出要自成一块。

建立了第一个测试用例后，应编译并运行测试，以排除语法错误，然后，使用拷贝/修改的办法建立其他测试用例。由于各个测试用例之间的差别往往很小，通常只需修改一两个数据，拷贝/修改是建立多个测试用例的最快捷办法。

下面说说测试用例、输入数据及预期输出。输入数据是测试用例的核心，对输入数据的定义是:被测试函数所读取的外部数据及这些数据的初始值。外部数据是对于被测试函数来说的，实际上就是除了局部变量以外的其他数据，把这些数据分为几类:参数、成员变量、全局变量、IO媒体。IO媒体是指文件、数据库或其他储存或传输数据的媒体，例如，被测试函数要从文件或数据库读取数据，那么，文件或数据库中的原始数据也属于输入数据。一个函数无论多复杂，都无非是对这几类数据的读取、计算和写入。预期输出是指:返回值及被测试函数所写入的外部数据的结果值。返回值就不用说了，被测试函数进行了写操作的参数(输出参数)、成员变量、全局变量、IO媒体，它们的预期的结果值都是预期输出。一个测试用例，就是设定输入数据，运行被测试函数，然后判断实际输出是否符合预期。下面举一个与成员变量有关的例子:

void CMyClass::Grow(int years)

{

mAge += years; if(mAge < 10)

mPhase = "儿童";

else if(mAge <20)

mPhase = "少年";

else if(mAge <45)

mPhase = "青年";

else if(mAge <60)

mPhase = "中年";

else

mPhase = "老年";

}

测试函数中的一个测试用例:

CaseBegin();{

int years = 1;

pObj->mAge = 8;

pObj->Grow(years);

ASSERT( pObj->mAge == 9 );

ASSERT( pObj->mPhase == "儿童" );

}CaseEnd();

在输入数据中对被测试类的成员变量mAge进行赋值，在预期输出中断言成员变量的值。可以看到推荐的格式的好处了吧，这种格式可以适应很复杂的测试。在输入数据部分还可以调用其他成员函数，例如:执行被测试函数前可能需要读取文件中的数据保存到成员变量，或需要连接数据库，把这些操作称为初始化操作。例如，上例中 ASSERT( ...)之前可以加pObj->OpenFile();。为了访问私有成员，可以将测试类定义为产品类的友元类。例如，定义一个宏:

#define UNIT_TEST(cls) friend class cls##Tester;

然后在产品类声明中加一行代码:UNIT_TEST(ClassName)。

下面谈谈测试用例设计。前面已经说了，测试用例的核心是输入数据。预期输出是依据输入数据和程序功能来确定的，也就是说，对于某一程序，输入数据确定了，预期输出也就可以确定了，至于生成/销毁被测试对象和运行测试的语句，是所有测试用例都大同小异的，因此，我们讨论测试用例时，只讨论输入数据。

前面说过，输入数据包括四类:参数、成员变量、全局变量、IO媒体，这四类数据中，只要所测试的程序需要执行读操作的，就要设定其初始值，其中，前两类比较常用，后两类较少用。显然，把输入数据的所有可能取值都进行测试，是不可能也是无意义的，我们应该用一定的规则选择有代表性的数据作为输入数据，主要有三种:正常输入，边界输入，非法输入，每种输入还可以分类，也就是平常说的等价类法，每类取一个数据作为输入数据，如果测试通过，可以肯定同类的其他输入也是可以通过的。下面举例说明:

正常输入

例如字符串的Trim函数，功能是将字符串前后的空格去除，那么正常的输入可以有四类:前面有空格;后面有空格;前后均有空格;前后均无空格。

边界输入

上例中空字符串可以看作是边界输入。

再如一个表示年龄的参数，它的有效范围是0-100，那么边界输入有两个:0和100。

非法输入

非法输入是正常取值范围以外的数据，或使代码不能完成正常功能的输入，如上例中表示年龄的参数，小于0或大于100都是非法输入，再如一个进行文件操作的函数，非法输入有这么几类:文件不存在;目录不存在;文件正在被其他程序打开;权限错误。

如果函数使用了外部数据，则正常输入是肯定会有的，而边界输入和非法输入不是所有函数都有。一般情况下，即使没有设计文档，考虑以上三种输入也可以找出函数的基本功能点。实际上，单元测试与代码编写是"一体两面"的关系，编码时对上述三种输入都是必须考虑的，否则代码的健壮性就会成问题。

上面所说的测试数据都是针对程序的功能来设计的，就是所谓的黑盒测试。单元测试还需要从另一个角度来设计测试数据，即针对程序的逻辑结构来设计测试用例，就是所谓的白盒测试。如果黑盒测试是足够充分的，那么白盒测试就没有必要，可惜"足够充分"只是一种理想状态，例如:真的是所有功能点都测试了吗?程序的功能点是人为的定义，常常是不全面的;各个输入数据之间，有些组合可能会产生问题，怎样保证这些组合都经过了测试?难于衡量测试的完整性是黑盒测试的主要缺陷，而白盒测试恰恰具有易于衡量测试完整性的优点，两者之间具有极好的互补性，例如:完成功能测试后统计语句覆盖率，如果语句覆盖未完成，很可能是未覆盖的语句所对应的功能点未测试。

白盒测试针对程序的逻辑结构设计测试用例，用逻辑覆盖率来衡量测试的完整性。逻辑单位主要有:语句、分支、条件、条件值、条件值组合，路径。语句覆盖就是覆盖所有的语句，其他类推。另外还有一种判定条件覆盖，其实是分支覆盖与条件覆盖的组合，在此不作讨论。跟条件有关的覆盖就有三种，解释一下:条件覆盖是指覆盖所有的条件表达式，即所有的条件表达式都至少计算一次，不考虑计算结果;条件值覆盖是指覆盖条件的所有可能取值，即每个条件的取真值和取假值都要至少计算一次;条件值组合覆盖是指覆盖所有条件取值的所有可能组合。做过一些粗浅的研究，发现与条件直接有关的错误主要是逻辑操作符错误，例如:||写成&&，漏了写!什么的，采用分支覆盖与条件覆盖的组合，基本上可以发现这些错误，另一方面，条件值覆盖与条件值组合覆盖往往需要大量的测试用例，因此，条件值覆盖和条件值组合覆盖的效费比偏低。效费比较高且完整性也足够的测试要求是这样的:完成功能测试，完成语句覆盖、条件覆盖、分支覆盖、路径覆盖。做过单元测试的朋友恐怕会对测试要求给予一个字的评价:晕!因为这似乎是不可能的要求，要达到这种测试完整性?所以提出这种测试要求，是因为利用一些工具，可以在较低的成本下达到这种测试要求，后面将会作进一步介绍。

关于白盒测试用例的设计，程序测试领域的书籍一般都有讲述，普通方法是画出程序的逻辑结构图如程序流程图或控制流图，根据逻辑结构图设计测试用例，这些是纯粹的白盒测试，所推荐的方法是:先完成黑盒测试，然后统计白盒覆盖率，针对未覆盖的逻辑单位设计测试用例覆盖它，例如，先检查是否有语句未覆盖，有的话设计测试用例覆盖它，然后用同样方法完成条件覆盖、分支覆盖和路径覆盖，这样的话，既检验了黑盒测试的完整性，又避免了重复的工作，用较少的时间成本达到非常高的测试完整性。不过，这些工作可不是手工能完成的，必须借助于工具，后面会介绍可以完成这些工作的测试工具。

现在开始介绍单元测试工具，都是用于C++语言的。

首先是CppUnit，这是C++单元测试工具的鼻祖，免费的开源的单元测试框架。由于已有一众高人写了不少关于CppUnit的很好的文章，想了解CppUnit的朋友，建议读一下Cpluser 所作的《CppUnit测试框架入门》，该文也提供了CppUnit的下载地址。

然后介绍C++Test，这是Parasoft公司的产品。[C++Test是一个功能强大的自动化C/C++单元级测试工具，可以自动测试任何C/C++函数、类，自动生成测试用例、测试驱动函数或桩函数，在自动化的环境下极其容易快速的将单元级的测试覆盖率达到100%]。[]内的文字引自，这是华唐公司的网页。想要购买或索取报价、试用版，建议访问该公司的网站。

最后介绍Visual Unit，简称VU，这是国产的单元测试工具，据说申请了多项专利，拥有一批创新的技术。[自动生成测试代码 快速建立功能测试用例程序行为一目了然 极高的测试完整性 高效完成白盒覆盖 快速排错 高效调试 详尽的测试报告]。[]内的文字是VU开发商的网页上摘录的。前面所述测试要求:完成功能测试，完成语句覆盖、条件覆盖、分支覆盖、路径覆盖，用VU可以轻松实现，还有一点值得一提:使用VU还能提高编码的效率，总体来说，在完成单元测试的同时，编码调试的时间还能大幅度缩短。介绍工具索然无味，毕竟工具好不好用，合不合用，要试过才知道，还是自己去开发商的网站看吧，可以下载演示版，还有演示课件。