5.3 基于UML的构件集成测试模型

　　这种测试模型使用UML顺序图和协作图提取存在于系统中两个构件接口交互时的可能缺陷。它把基于UML开发过程和测试过程连接起来。UML测试模型由节点（它表示集成目标）和消息流（它表示节点间交互）构成。

　　5.4 构件内置测试

　　内置测试（BIT：Built—in test）是一种新的软件构件，作为成员函数被清晰地描述在软件的源代码中，用来提高软件的易维护性。基于BIT，易维护的软件提出两种操作模式：正常模式和维护模式。在正常的模式中，软件和常规的系统具有同样的行为。在维护模式中，通过在相应的构件中调用作为成员函数的BIT来激发BIT。

　　5.5 使用ADL语言定义和测试构件

　　这是一种针对软件构件单元测试的方法，它使用一种规约语言ADL（Assert definition language）来

　　对软件构件的期望的行为进行形式地文档化，而ADL特别适用于测试。另一种相关的语言是TDD（Test data descripriori），用于系统地描述即将被测试的软件构件的测试数据。

　　5.6 回顾评论法

　　在回顾评论法中，回顾器（Retrospector）和构件一起用于有效地测试构件。回顾器记录构件的执行和历史，并为软件测试者提供可利用的测试信息。构件中的Retro类和Java Beans中的Intro—spector类相似。Retro构件有三种模式一设计时间模式、测试时间模式和运行时间模式。

　　6、构件软件测试的问题和挑战

　　6.1 单个构件测试中的问题

　　单个构件测试中要考虑以下问题：构件测试的可重用性问题；构件测试的适应性问题；软件构件的可测试性问题；能否创建通用的测试床；构造测试驱动所需的费用昂贵；特定的认证过程和测试过程；特定的构件测试套件和测试驱动管理等。

　　6.2 构件集成中的问题

　　在一个基于构件的软件产品线上，软件产品基于一定量的软件构件被制造出来。事实上，这些产品是按特殊的需求集对构件进行定制和集成的结果。有两种因素影响到构件集成的复杂性。第一种是包含的构件数量。另一种是构件的定制能力。虽然目前的集成途径，如递增式集成，能适用于构件集成，但工程师仍需要新的有效的集成方法和系统工具来支持构件集成。

　　（1）形成基于构件测试套件比较困难；

　　（2）构造集成环境所需费用；

　　（3）缺乏构件集成测试模型和测试标准。

　　6.3 基于构件软件的系统测试中的问题

　　系统测试通常集中于检查系统行为，包括性能测试、压力测试、恢复测试和安装测试。在基于构件程序的开发过程中，我们已看到了几个与系统测试相关的问题。

　　（1）理解系统行为比较困难；

　　（2）错误隔离、跟踪和调试困难；