一　单元测试概述
　　工厂在组装一台电视机之前，会对每个元件都进行测试，这，就是单元测试。
　　其实我们每天都在做单元测试。你写了一个函数，除了极简单的外，总是要执行一下，看看功能是否正常，有时还要想办法输出些数据，如弹出信息窗口什么的，这，也是单元测试，老纳把这种单元测试称为临时单元测试。只进行了临时单元测试的软件，针对代码的测试很不完整，代码覆盖率要超过70%都很困难，未覆盖的代码可能遗留大量的细小的错误，这些错误还会互相影响，当BUG暴露出来的时候难于调试，大幅度提高后期测试和维护成本，也降低了开发商的竞争力。可以说，进行充分的单元测试，是提高软件质量，降低开发成本的必由之路。
　　对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。
　　要进行充分的单元测试，应专门编写测试代码，并与产品代码隔离。老纳认为，比较简单的办法是为产品工程建立对应的测试工程，为每个类建立对应的测试类，为每个函数（很简单的除外）建立测试函数。首先就几个概念谈谈老纳的看法。
　　一般认为，在结构化程序时代，单元测试所说的单元是指函数，在当今的面向对象时代，单元测试所说的单元是指类。以老纳的实践来看，以类作为测试单位，复杂度高，可操作性较差，因此仍然主张以函数作为单元测试的测试单位，但可以用一个测试类来组织某个类的所有测试函数。单元测试不应过分强调面向对象，因为局部代码依然是结构化的。单元测试的工作量较大，简单实用高效才是硬道理。
　　有一种看法是，只测试类的接口(公有函数)，不测试其他函数，从面向对象角度来看，确实有其道理，但是，测试的目的是找错并最终排错，因此，只要是包含错误的可能性较大的函数都要测试，跟函数是否私有没有关系。对于C++来说，可以用一种简单的方法区隔需测试的函数：简单的函数如数据读写函数的实现在头文件中编写(inline函数)，所有在源文件编写实现的函数都要进行测试(构造函数和析构函数除外)。
　　什么时候测试？单元测试越早越好，早到什么程度？XP开发理论讲究TDD，即测试驱动开发，先编写测试代码，再进行开发。在实际的工作中，可以不必过分强调先什么后什么，重要的是高效和感觉舒适。从老纳的经验来看，先编写产品函数的框架，然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产品函数的代码，每写一个功能点都运行测试，随时补充测试用例。所谓先编写产品函数的框架，是指先编写函数空的实现，有返回值的随便返回一个值，编译通过后再编写测试代码，这时，函数名、参数表、返回类型都应该确定下来了，所编写的测试代码以后需修改的可能性比较小。
　　由谁测试？单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。测试部门可以作一定程度的审核。
　　关于桩代码，老纳认为，单元测试应避免编写桩代码。桩代码就是用来代替某些代码的代码，例如，产品函数或测试函数调用了一个未编写的函数，可以编写桩函数来代替该被调用的函数，桩代码也用于实现测试隔离。采用由底向上的方式进行开发，底层的代码先开发并先测试，可以避免编写桩代码，这样做的好处有：减少了工作量；测试上层函数时，也是对下层函数的间接测试；当下层函数修改时，通过回归测试可以确认修改是否导致上层函数产生错误。

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

产品类：
class CMyClass
{
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、３、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测试框架入门》，网址是：http://blog.csdn.net/cpluser/archive/2004/09/21/111522.aspx。该文也提供了CppUnit的下载地址。
　　然后介绍C++Test，这是Parasoft公司的产品。［C++Test是一个功能强大的自动化C/C++单元级测试工具，可以自动测试任何C/C++函数、类，自动生成测试用例、测试驱动函数或桩函数，在自动化的环境下极其容易快速的将单元级的测试覆盖率达到100%］。［］内的文字引自http://www.superst.com.cn/softwares_testing_c_cpptest.htm，这是华唐公司的网页。老纳想写些介绍C++Test的文字，但发现无法超越华唐公司的网页上的介绍，所以也就省点事了，想了解C++Test的朋友，建议访问该公司的网站。华唐公司代理C++Test，想要购买或索取报价、试用版都可以找他们。老纳帮华唐公司做广告，不知道会不会得点什么好处？
　　最后介绍Visual Unit，简称VU，这是国产的单元测试工具，据说申请了多项专利，拥有一批创新的技术，不过老纳只关心是不是有用和好用。［自动生成测试代码 快速建立功能测试用例 程序行为一目了然 极高的测试完整性 高效完成白盒覆盖 快速排错 高效调试 详尽的测试报告］。［］内的文字是VU开发商的网页上摘录的，网址是：http://www.unitware.cn。前面所述测试要求：完成功能测试，完成语句覆盖、条件覆盖、分支覆盖、路径覆盖，用VU可以轻松实现，还有一点值得一提：使用VU还能提高编码的效率，总体来说，在完成单元测试的同时，编码调试的时间还能大幅度缩短。算了，不想再讲了，老纳显摆理论、介绍经验还是有兴趣的，因为可以满足老纳好为人师的虚荣心，但介绍工具就觉得索然无味了，毕竟工具好不好用，合不合用，要试过才知道，还是自己去开发商的网站看吧，可以下载演示版，还有演示课件。
这是一篇全面介绍单元测试的经典之作，对理解单元测试和Visual Unit很有帮助，作者老纳，收录时作了少量修改]

一　单元测试概述
　　工厂在组装一台电视机之前，会对每个元件都进行测试，这，就是单元测试。
　　其实我们每天都在做单元测试。你写了一个函数，除了极简单的外，总是要执行一下，看看功能是否正常，有时还要想办法输出些数据，如弹出信息窗口什么的，这，也是单元测试，老纳把这种单元测试称为临时单元测试。只进行了临时单元测试的软件，针对代码的测试很不完整，代码覆盖率要超过70%都很困难，未覆盖的代码可能遗留大量的细小的错误，这些错误还会互相影响，当BUG暴露出来的时候难于调试，大幅度提高后期测试和维护成本，也降低了开发商的竞争力。可以说，进行充分的单元测试，是提高软件质量，降低开发成本的必由之路。
　　对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。
　　要进行充分的单元测试，应专门编写测试代码，并与产品代码隔离。老纳认为，比较简单的办法是为产品工程建立对应的测试工程，为每个类建立对应的测试类，为每个函数（很简单的除外）建立测试函数。首先就几个概念谈谈老纳的看法。
　　一般认为，在结构化程序时代，单元测试所说的单元是指函数，在当今的面向对象时代，单元测试所说的单元是指类。以老纳的实践来看，以类作为测试单位，复杂度高，可操作性较差，因此仍然主张以函数作为单元测试的测试单位，但可以用一个测试类来组织某个类的所有测试函数。单元测试不应过分强调面向对象，因为局部代码依然是结构化的。单元测试的工作量较大，简单实用高效才是硬道理。
　　有一种看法是，只测试类的接口(公有函数)，不测试其他函数，从面向对象角度来看，确实有其道理，但是，测试的目的是找错并最终排错，因此，只要是包含错误的可能性较大的函数都要测试，跟函数是否私有没有关系。对于C++来说，可以用一种简单的方法区隔需测试的函数：简单的函数如数据读写函数的实现在头文件中编写(inline函数)，所有在源文件编写实现的函数都要进行测试(构造函数和析构函数除外)。
　　什么时候测试？单元测试越早越好，早到什么程度？XP开发理论讲究TDD，即测试驱动开发，先编写测试代码，再进行开发。在实际的工作中，可以不必过分强调先什么后什么，重要的是高效和感觉舒适。从老纳的经验来看，先编写产品函数的框架，然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产品函数的代码，每写一个功能点都运行测试，随时补充测试用例。所谓先编写产品函数的框架，是指先编写函数空的实现，有返回值的随便返回一个值，编译通过后再编写测试代码，这时，函数名、参数表、返回类型都应该确定下来了，所编写的测试代码以后需修改的可能性比较小。
　　由谁测试？单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。测试部门可以作一定程度的审核。
　　关于桩代码，老纳认为，单元测试应避免编写桩代码。桩代码就是用来代替某些代码的代码，例如，产品函数或测试函数调用了一个未编写的函数，可以编写桩函数来代替该被调用的函数，桩代码也用于实现测试隔离。采用由底向上的方式进行开发，底层的代码先开发并先测试，可以避免编写桩代码，这样做的好处有：减少了工作量；测试上层函数时，也是对下层函数的间接测试；当下层函数修改时，通过回归测试可以确认修改是否导致上层函数产生错误。

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

产品类：
class CMyClass
{
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、３、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测试框架入门》，网址是：http://blog.csdn.net/cpluser/archive/2004/09/21/111522.aspx。该文也提供了CppUnit的下载地址。
　　然后介绍C++Test，这是Parasoft公司的产品。［C++Test是一个功能强大的自动化C/C++单元级测试工具，可以自动测试任何C/C++函数、类，自动生成测试用例、测试驱动函数或桩函数，在自动化的环境下极其容易快速的将单元级的测试覆盖率达到100%］。［］内的文字引自http://www.superst.com.cn/softwares_testing_c_cpptest.htm，这是华唐公司的网页。老纳想写些介绍C++Test的文字，但发现无法超越华唐公司的网页上的介绍，所以也就省点事了，想了解C++Test的朋友，建议访问该公司的网站。华唐公司代理C++Test，想要购买或索取报价、试用版都可以找他们。老纳帮华唐公司做广告，不知道会不会得点什么好处？
　　最后介绍Visual Unit，简称VU，这是国产的单元测试工具，据说申请了多项专利，拥有一批创新的技术，不过老纳只关心是不是有用和好用。［自动生成测试代码 快速建立功能测试用例 程序行为一目了然 极高的测试完整性 高效完成白盒覆盖 快速排错 高效调试 详尽的测试报告］。［］内的文字是VU开发商的网页上摘录的，网址是：http://www.unitware.cn。前面所述测试要求：完成功能测试，完成语句覆盖、条件覆盖、分支覆盖、路径覆盖，用VU可以轻松实现，还有一点值得一提：使用VU还能提高编码的效率，总体来说，在完成单元测试的同时，编码调试的时间还能大幅度缩短。算了，不想再讲了，老纳显摆理论、介绍经验还是有兴趣的，因为可以满足老纳好为人师的虚荣心，但介绍工具就觉得索然无味了，毕竟工具好不好用，合不合用，要试过才知道，还是自己去开发商的网站看吧，可以下载演示版，还有演示课件。

by jack
You'll get it because of your sharing.

我修改的源码，解压缩后覆盖原有源码中的src目录，重新编译就可以用了；对编译有疑问的可参见我的帖子http://bbs.51testing.com/thread-121772-1-1.html

src.rar
(2008-07-31 22:33:51, Size: 1.59 MB, Downloads: 0)

监控的xml

status.rar
(2008-07-31 22:33:51, Size: 342 B , Downloads: 1)

编译好的包，象征性收取一点点数 ，希望大家还是自己尝试改一下编译一下，这样今后可以比较容易的扩展出自己想要的监控
下载编译好的包，把包里的两个jar包拷贝到jmeter的lib\ext目录下，覆盖原来的jar，重启启动jmeter，就可以使用我写的监控器了

ext.rar
(2008-07-31 22:33:51, Size: 755 kB, Downloads: 0)

目前还在写一个shell，用于生成linux下性能数据的符合上面格式的xml，写好后也会分享出来

[ 本帖最后由 qaarchitech 于 2008-7-31 22:38 编辑 ]

前言: 
    这篇文章介绍在LINUX下进行C语言编程所需要的基础知识.在这篇文章当中,我们将会学到以下内容: 
源程序编译 
Makefile的编写 
程序库的链接 
程序的调试 
头文件和系统求助 

--------------------------------------------------------------------------------
1.源程序的编译
    在Linux下面,如果要编译一个C语言源程序,我们要使用GNU的gcc编译器. 下面我们以一个实例来说明如何使用gcc编译器. 
假设我们有下面一个非常简单的源程序(hello.c): 
 int main(int argc,char **argv)
  {
printf("Hello Linux\n");
  }

要编译这个程序,我们只要在命令行下执行: 
gcc -o hello hello.c 
gcc 编译器就会为我们生成一个hello的可执行文件.执行./hello就可以看到程序的输出结果了.命令行中 gcc表示我们是用gcc来编译我们的源程序,-o 选项表示我们要求编译器给我们输出的可执行文件名为hello 而hello.c是我们的源程序文件. 
gcc编译器有许多选项,一般来说我们只要知道其中的几个就够了. -o选项我们已经知道了,表示我们要求输出的可执行文件名. -c选项表示我们只要求编译器输出目标代码,而不必要输出可执行文件. -g选项表示我们要求编译器在编译的时候提供我们以后对程序进行调试的信息. 
知道了这三个选项,我们就可以编译我们自己所写的简单的源程序了,如果你想要知道更多的选项,可以查看gcc的帮助文档,那里有着许多对其它选项的详细说明. 
2.Makefile的编写
    假设我们有下面这样的一个程序,源代码如下: 

/*  main.c */
 #include "mytool1.h"
 #include "mytool2.h"

 int main(int argc,char **argv)
 {
  mytool1_print("hello");
  mytool2_print("hello");
 }

/*  mytool1.h  */
#ifndef _MYTOOL_1_H
#define _MYTOOL_1_H

 void mytool1_print(char *print_str);

#endif

/*  mytool1.c  */
 #include "mytool1.h"
 void mytool1_print(char *print_str)
 {
   printf("This is mytool1 print %s\n",print_str);
 }

/* mytool2.h */
#ifndef _MYTOOL_2_H
#define _MYTOOL_2_H

 void mytool2_print(char *print_str);

#endif
  
/*  mytool2.c  */
 #include "mytool2.h"
 void mytool2_print(char *print_str)
 {
   printf("This is mytool2 print %s\n",print_str);
 }


当然由于这个程序是很短的我们可以这样来编译 
gcc -c main.c 
gcc -c mytool1.c 
gcc -c mytool2.c 
gcc -o main main.o mytool1.o mytool2.o 
这样的话我们也可以产生main程序,而且也不时很麻烦.但是如果我们考虑一下如果有一天我们修改了其中的一个文件(比如说mytool1.c)那么我们难道还要重新输入上面的命令?也许你会说,这个很容易解决啊,我写一个SHELL脚本,让她帮我去完成不就可以了.是的对于这个程序来说,是可以起到作用的.但是当我们把事情想的更复杂一点,如果我们的程序有几百个源程序的时候,难道也要编译器重新一个一个的去编译? 
为此,聪明的程序员们想出了一个很好的工具来做这件事情,这就是make.我们只要执行以下make,就可以把上面的问题解决掉.在我们执行make之前,我们要先编写一个非常重要的文件.--Makefile.对于上面的那个程序来说,可能的一个Makefile的文件是: 
#   这是上面那个程序的Makefile文件
main:main.o mytool1.o mytool2.o
gcc -o main main.o mytool1.o mytool2.o
main.o:main.c mytool1.h mytool2.h
gcc -c main.c
mytool1.o:mytool1.c mytool1.h
gcc -c mytool1.c
mytool2.o:mytool2.c mytool2.h
gcc -c mytool2.c

有了这个Makefile文件,不过我们什么时候修改了源程序当中的什么文件,我们只要执行make命令,我们的编译器都只会去编译和我们修改的文件有关的文件,其它的文件她连理都不想去理的. 
下面我们学习Makefile是如何编写的. 
在Makefile中也#开始的行都是注释行.Makefile中最重要的是描述文件的依赖关系的说明.一般的格式是: 
target: components
TAB rule

第一行表示的是依赖关系.第二行是规则. 
比如说我们上面的那个Makefile文件的第二行 
main:main.o mytool1.o mytool2.o 
表示我们的目标(target)main的依赖对象(components)是main.o mytool1.o mytool2.o 当倚赖的对象在目标修改后修改的话,就要去执行规则一行所指定的命令.就象我们的上面那个Makefile第三行所说的一样要执行 gcc -o main main.o mytool1.o mytool2.o 注意规则一行中的TAB表示那里是一个TAB键 
Makefile有三个非常有用的变量.分别是$@,$^,$<代表的意义分别是: 
$@--目标文件,$^--所有的依赖文件,$<--第一个依赖文件. 
如果我们使用上面三个变量,那么我们可以简化我们的Makefile文件为: 
# 这是简化后的Makefile
main:main.o mytool1.o mytool2.o
gcc -o $@ $^
main.o:main.c mytool1.h mytool2.h
gcc -c $<
mytool1.o:mytool1.c mytool1.h
gcc -c $<
mytool2.o:mytool2.c mytool2.h
gcc -c $<

经过简化后我们的Makefile是简单了一点,不过人们有时候还想简单一点.这里我们学习一个Makefile的缺省规则 
.c.o:
gcc -c $<

这个规则表示所有的 .o文件都是依赖与相应的.c文件的.例如mytool.o依赖于mytool.c这样Makefile还可以变为: 
# 这是再一次简化后的Makefile
main:main.o mytool1.o mytool2.o
gcc -o $@ $^
.c.o:
gcc -c $<

好了,我们的Makefile 也差不多了,如果想知道更多的关于Makefile规则可以查看相应的文档. 
3.程序库的链接 
    试着编译下面这个程序 

/* temp.c */
  #include 
  
  int main(int argc,char **argv)
   {
         double value;
 printf("Value:%f\n",value);
   }

这个程序相当简单,但是当我们用 gcc -o temp temp.c 编译时会出现下面所示的错误. 
/tmp/cc33Kydu.o: In function `main':
/tmp/cc33Kydu.o(.text+0xe): undefined reference to `log'
collect2: ld returned 1 exit status

出现这个错误是因为编译器找不到log的具体实现.虽然我们包括了正确的头文件,但是我们在编译的时候还是要连接确定的库.在Linux下,为了使用数学函数,我们必须和数学库连接,为此我们要加入 -lm 选项. gcc -o temp temp.c -lm这样才能够正确的编译.也许有人要问,前面我们用printf函数的时候怎么没有连接库呢?是这样的,对于一些常用的函数的实现,gcc编译器会自动去连接一些常用库,这样我们就没有必要自己去指定了. 有时候我们在编译程序的时候还要指定库的路径,这个时候我们要用到编译器的 -L选项指定路径.比如说我们有一个库在 /home/hoyt/mylib下,这样我们编译的时候还要加上 -L/home/hoyt/mylib.对于一些标准库来说,我们没有必要指出路径.只要它们在起缺省库的路径下就可以了.系统的缺省库的路径/lib /usr/lib /usr/local/lib 在这三个路径下面的库,我们可以不指定路径. 
还有一个问题,有时候我们使用了某个函数,但是我们不知道库的名字,这个时候怎么办呢?很抱歉,对于这个问题我也不知道答案,我只有一个傻办法.首先,我到标准库路径下面去找看看有没有和我用的函数相关的库,我就这样找到了线程(thread)函数的库文件(libpthread.a). 当然,如果找不到,只有一个笨方法.比如我要找sin这个函数所在的库. 就只好用 nm -o /lib/*.so|grep sin>~/sin 命令,然后看~/sin文件,到那里面去找了. 在sin文件当中,我会找到这样的一行libm-2.1.2.so:00009fa0 W sin 这样我就知道了sin在 libm-2.1.2.so库里面,我用 -lm选项就可以了(去掉前面的lib和后面的版本标志,就剩下m了所以是 -lm). 如果你知道怎么找,请赶快告诉我,我回非常感激的.谢谢! 
4.程序的调试 
    我们编写的程序不太可能一次性就会成功的,在我们的程序当中,会出现许许多多我们想不到的错误,这个时候我们就要对我们的程序进行调试了. 
最常用的调试软件是gdb.如果你想在图形界面下调试程序,那么你现在可以选择xxgdb.记得要在编译的时候加入 -g选项.关于gdb的使用可以看gdb的帮助文件.由于我没有用过这个软件,所以我也不能够说出如何使用. 不过我不喜欢用gdb.跟踪一个程序是很烦的事情,我一般用在程序当中输出中间变量的值来调试程序的.当然你可以选择自己的办法,没有必要去学别人的.现在有了许多IDE环境,里面已经自己带了调试器了.你可以选择几个试一试找出自己喜欢的一个用. 

5.头文件和系统求助 
    有时候我们只知道一个函数的大概形式,不记得确切的表达式,或者是不记得着函数在那个头文件进行了说明.这个时候我们可以求助系统. 
比如说我们想知道fread这个函数的确切形式,我们只要执行 man fread 系统就会输出着函数的详细解释的.和这个函数所在的头文件说明了. 如果我们要write这个函数的说明,当我们执行man write时,输出的结果却不是我们所需要的. 因为我们要的是write这个函数的说明,可是出来的却是write这个命令的说明.为了得到write的函数说明我们要用 man 2 write. 2表示我们用的write这个函数是系统调用函数,还有一个我们常用的是3表示函数是C的库函数. 
记住不管什么时候,man都是我们的最好助手. 


--------------------------------------------------------------------------------
好了,这一章就讲这么多了,有了这些知识我们就可以进入激动人心的Linux下的C程序探险活动. 

最近整理了一下常用的linux命令，呵呵，比较少，但常用，希望对大家有帮助

1、网络操作命令

(1)ftp常用命令
   登陆ftp            ftp 192.168.0.94
   显示目录信息       dir
   退出ftp            bye

2、用户管理操作命令
(1)Su - cstomcat 更改用户命令
  
3、文件管理操作命令
(1)ls列出目录的内容
(2)cd改变工作目录
(3)mkdir 创建新目录
mkdir -p ./mengx/dir 在当前目录下创建目录mengx/dir目录
(4)rm删除目录
(5)touch filename 创建文件
(6)vi filename 文件编辑命令
   i     插入命令
   esc   退出插入状态
   ：wq  保存文件退出命令
   ：q   退出编辑状态命令
   ：wq！不保存文件退出编辑状态命令

(7)pwd 显示当前所在目录
  
4、系统管理命令

(1)ps显示当前系统中由该用户运行的进程列表
   ps -ef 查看所有进程及其PID(进程号)、系统时间、命令详细目录、执行者等
(2)top动态显示系统中运行的程序(一般为每隔5s)
   top 显示当前进程
   q   退出显示进程页面
   top -i 只显示活跃的进程
(3)kill输出特定的信号给指定PID(进程号)的进程  
   kill 11 中止进程号为11的进程
(4)clear 清除屏幕

    linux中的服务管理与微软的windows中的不是很相同，大概我对微软服务器的服务启动也不是很了解，在这里说一下linux的服务吧。

    linux的服务分为两种，一种是系统服务，就是在系统启动的时候就可以自动启动的那种；还有一种就是由xinet服务来引导的守护进程型的服务。xinet也是一个服务，其能够同时监听多个指定的端口，在接收用户请求时，它能够根据用户请求的端口不同，启动不同的网络服务进程来处理这些用户请求。可以把xinetd看作一个启动服务的管理服务器。其中用户的端口配置都是可以通过更改配置文件来设置的，这里就不多说了。

    介绍一下相关的service服务管理命令

service --status-all    列出所有服务的当前状态
sevice network status   显示当前网络接口和设备列表。
sevice network start/stop/restart  其中这个命令也可以用于重启、启动或停止任何其它的服务。
启动、停止或重启网络服务，实质上是执行/etc/sysconfig/network-scrīpts/下的所有网络脚本

    其实也比较简单了，呵呵，不过启动服务之类的还有别的命令可以实现，这里俺也不是很了解，在以后的学习中会记录一下。

    主要原因是：开发部提供的测试版本太过随意，导致质量太差。要解决它，我认为有以下几个关键点：

×在项目开始时，最好能先开发一个原型出来，原型基本上要确定整体界面的风格、统一的操作习惯等，以后的开发要以原型为基础进行；

 

×开发部使用版本控制工具，比如CVS、VSS等，并且要保证每天定时Check-in和Check-out，避免积累大量代码，同时要强调在Check-out和Check-in的时候要注明缘由，是为了修改某个bug还是增加新功能等；

 

×每日构建（Daily Build）：每日构建要形成制度，构建过程最好能自动进行，如果因为是第一次这样做，没有经验，遇到技术问题，在这种情况下，建议由测试部指派一名测试员加入到开发部，协助开发部进行人工构建，每日能集成一个能运行起来的完整的软件系统；

 

×强化冒烟测试（Smoke testing）：加入开发部的测试员在构建后，集成了一个完整的软件系统，要及时对每一个build进行验证（Build Verification Test ），也可以称之为“冒烟测试”，对软件的基本功能点进行验证；

 

×强化测试的准入条件：软件测试启动是有条件的，并不是说开发部拿个软件过来，开发部就要测试，比如要启动测试活动，必须要有需求规格说明书、设计书、单元测试报告、冒烟测试报告等，这是前提。满足不了这个前提条件，测试活动不会启动。当然这个制度需要公司管理高层的认可，在项目启动时要和项目经理协调好的；

 

×强化BUG管理：测试组要使用BUG管理工具，例如bugzilla、JiRA等，要保证 bug、版本、以及人员的对应关系，同时分析在不同的版本、不同的时间段、不同的模块中BUG的走势，确定“危险模块”为重点测试对象，预测未来的BUG走势和工作量等。

 

×公司高层应该将软件版本发布的质量纳入部门绩效考核。

 

×测试人员的基本素质和测试态度起码不够坚强，研发人员没有站在测试人员的角度去考虑，要让他们时刻意识到“边测边改、边改边测”的办法是行不通的，测试人员更要杜绝“边测边改、边改边测”的不规范现象；

 

×当测试人员在测试中发现问题，在向研发人员确认此问题时没有提醒研发人员“不要修改版本”或“不要动服务器”之类的话，要时刻提醒他们，久而久之他们也会养成一个不在测试完毕不向更新程序的习惯。

 

×开发经理分配设计任务的时候，未进行设计优先级的划分，结果最基本和最重要的功能最后才设计出来。

 

×积极的态度：无论是开发部还是测试部，在这个困难的过程中都要有积极的态度，遇到问题要及时沟通，以最高效的方式解决问题。

 

   要从根本上根治这种矛盾，需要一套完整的、规范的开发过程。