六 面向对象的单元测试(OO Unit Test)

    传统的单元测试是针对程序的函数、过程或完成某一定功能的程序块。沿用单元测试的概念，实际测试类成员函数。一些传统的测试方法在面向对象的单元测试中都可以使用。如等价类划分法，因果图法，边值分析法，逻辑覆盖法，路径分析法，程序插装法等等，方法的具体实现参见[6]。单元测试一般建议由程序员完成。

    用于单元级测试进行的测试分析（提出相应的测试要求）和测试用例（选择适当的输入，达到测试要求），规模和难度等均远小于后面将介绍的对整个系统的测试分析和测试用例，而且强调对语句应该有100%的执行代码覆盖率。在设计测试用例选择输入数据时，可以基于以下两个假设：

    1. 如果函数（程序）对某一类输入中的一个数据正确执行，对同类中的其他输入也能正确执行。

    2. 如果函数（程序）对某一复杂度的输入正确执行，对更高复杂度的输入也能正确执行。例如需要选择字符串作为输入时，基于本假设，就无须计较于字符串的长度。除非字符串的长度是要求固定的，如IP地址字符串。在面向对象程序中，类成员函数通常都很小，功能单一，函数的间调用频繁，容易出现一些不宜发现的错误。例如：

    f (-1==write (fid, buffer, amount)) error_out();
    该语句没有全面检查write()的返回值，无意中断然假设了只有数据被完全写入和没有写入两种情况。当测试也忽略了数据部分写入的情况，就给程序遗留了隐患。
    按程序的设计，使用函数strrchr()查找最后的匹配字符，但误程序中写成了函数strchr()，使程序功能实现时查找的是第一个匹配字符。
程序中将if (strncmp(str1,str2,strlen(str1)))误写成了if (strncmp(str1,str2,strlen(str2)))。如果测试用例中使用的数据str1和str2长度一样，就无法检测出。
    因此，在做测试分析和设计测试用例时，应该注意面向对象程序的这个特点，仔细的进行测试分析和设计测试用例，尤其是针对以函数返回值作为条件判断选择，字符串操作等情况。

    面向对象编程的特性使得对成员函数的测试，又不完全等同于传统的函数或过程测试。尤其是继承特性和多态特性，使子类继承或过载的父类成员函数出现了传统测试中未遇见的问题。在[7]中，Brian Marick 给出了二方面的考虑：

    1. 继承的成员函数是否都不需要测试？

    根据[7]中的论述，对父类中已经测试过的成员函数，两种情况需要在子类中重新测试：a）继承的成员函数在子类中做了改动；b）成员函数调用了改动过的成员函数的部分。例如：

    假设父类Bass有两个成员函数：Inherited()和Redefined()，子类Derived只对Redefined()做了改动。　　　Derived::Redefined()显然需要重新测试。对于Derived::Inherited()，如果它有调用Redefined()的语句(如：x=x/Redefined()),就需要重新测试，反之，无此必要。

    2. 对父类的测试是否能照搬到子类？

    援用上面的假设，Base::Redefined()和Derived::Redefined()已经是不同的成员函数，它们有不同的服务说明和执行。对此，照理应该对 Derived::Redefined()重新测试分析，设计测试用例。但由于面向对象的继承使得两个函数有相似，故只需在 Base::Redefined()的测试要求和测试用例上添加对Derived::Redfined()新的测试要求和增补相应的测试用例。例如：
　　Base::Redefined()含有如下语句
　　If (value<0) message ("less");
　　else if (value==0) message ("equal");
　　else message ("more");
　　Derived::Redfined()中定义为
　　If (value<0) message ("less");
　　else if (value==0) message ("It is equal");
　　else
　　{message ("more");
　　if (value==88)message("luck");}
　　
    在原有的测试上，对Derived::Redfined()的测试只需做如下改动：将value==0的测试结果期望改动；增加value==88的测试。

    多态有几种不同的形式，如参数多态，包含多态，过载多态。包含多态和过载多态在面向对象语言中通常体现在子类与父类的继承关系，对这两种多态的测试参见上述对父类成员函数继承和过载的论述。包含多态虽然使成员函数的参数可有多种类型，但通常只是增加了测试的繁杂。对具有包含多态的成员函数测试时，只需要在原有的测试分析和基础上扩大测试用例中输入数据的类型的考虑。对类为粒度进行面向对象的单元测试，可参考[10]中关于如何从MtSS生成测试用例的说明。

    七 面向对象的集成测试(OO Integrate Test)

    传统的集成测试，是由底向上通过集成完成的功能模块进行测试，一般可以在部分程序编译完成的情况下进行。而对于面向对象程序，相互调用的功能是散布在程序的不同类中，类通过消息相互作用申请和提供服务。类的行为与它的状态密切相关，状态不仅仅是体现在类数据成员的值，也许还包括其他类中的状态信息。由此可见，类相互依赖极其紧密，根本无法在编译不完全的程序上对类进行测试。所以，面向对象的集成测试通常需要在整个程序编译完成后进行。此外，面向对象程序具有动态特性，程序的控制流往往无法确定，因此也只能对整个编译后的程序做基于黑盒子的集成测试。

    面向对象的集成测试能够检测出相对独立的单元测试无法检测出的那些类相互作用时才会产生的错误。基于单元测试对成员函数行为正确性的保证，集成测试只关注于系统的结构和内部的相互作用。面向对象的集成测试可以分成两步进行：先进行静态测试，再进行动态测试。

    静态测试主要针对程序的结构进行，检测程序结构是否符合设计要求。现在流行的一些测试软件都能提供一种称为"可逆性工程"的功能，即通过原程序得到类关系图和函数功能调用关系图，例如International Software Automation 公司的Panorama-2 forWindows95、Rational公司的Rose C++ Analyzer等，将"可逆性工程"得到的结果与OOD的结果相比较，检测程序结构和实现上是否有缺陷。换句话说，通过这种方法检测OOP是否达到了设计要求。

    动态测试设计测试用例时，通常需要上述的功能调用结构图、类关系图或者实体关系图为参考，确定不需要被重复测试的部分，从而优化测试用例，减少测试工作量，使得进行的测试能够达到一定覆盖标准。测试所要达到的覆盖标准可以是：达到类所有的服务要求或服务提供的一定覆盖率；依据类间传递的消息，达到对所有执行线程的一定覆盖率；达到类的所有状态的一定覆盖率等。同时也可以考虑使用现有的一些测试工具来得到程序代码执行的覆盖率。

    具体设计测试用例，可参考下列步骤：

    先选定检测的类，参考OOD分析结果，仔细出类的状态和相应的行为，类或成员函数间传递的消息，输入或输出的界定等。
    确定覆盖标准。
    利用结构关系图确定待测类的所有关联。
    根据程序中类的对象构造测试用例，确认使用什么输入激发类的状态、使用类的服务和期望产生什么行为等。
    值得注意，设计测试用例时，不但要设计确认类功能满足的输入，还应该有意识的设计一些被禁止的例子，确认类是否有不合法的行为产生，如发送与类状态不相适应的消息，要求不相适应的服务等。根据具体情况，动态的集成测试，有时也可以通过系统测试完成。