服务的

COTS 构件；另外一种是源代码具有可访问性的构件。当构件类型不同时，对测试方

法的选用也是不同的。

 

　　（一）对构件测试方法的分析

 

　　目前，对构件的测试主要是通过以下几个方法：

 

　　

1.基于构件使用规范说明的测试。以下方法都与构件开发方有着一定联系，本方法按照

构件运用方就应用环境与规范给予的数据当作测试用例，只局限于黑盒测试中来使用。

 

　　

2.内置测试。对于构件开发方，他们把有着可执行性的测试用例内置于构件内，同时当

作构件的常用功能，在构件集成于实际应用环境的情况下，对其中测试用例进行运行，进

而进行集成测试；

 

　　

3.元数据。针对在集成测试的时候，构件信息缺乏等一些问题，构件开发方将关于构件

的基本信息通过元数据这一合理形式，给予构件测试或者使用方，确保测试顺利地实施，

提升构件的可测试性是它的核心内容；

 

　　

4.可测试体系结构。由构件开发方会提供与构件相配套的可测试体系，这样构件使用方

在实施测试的情况下，能对测试用例进行直接执行，和上述各个方法相比，不同的是，该

测试信息通过规范的形式附加于构件之上，当运行的时候，没有占用内存

[3]。 

　　

5.证明策略。一般情况下，由于构件证明不同的承担方，构件证明主要包括以下几类：

首先是构件使用方构件证明，其次是第三方构件证明，最后为构件开发方构件证明。

 

　　（二）构件测试技术中存在的一些主要问题

 

　　对于构件集成测试，很难对其实施，主要有两方面的原因：异构性的存在以及相关信

息的缺少。针对异构性，其表现为：同一个构件处于相同规范下，具有不相同的实现方法；

不相同的构件能使用不同平台的不同程序语言进行实现；由于构件使用方与开发方两方很

少进行交换信息，便导致了信息缺乏，构件开发方主要对开发构件的应用环境没有足够了

解，所以，它进行的构件测试只可以面对假设的应用环境，但是实际环境和假设的环境之

间一定具有差别，在实际的应用中，各个构件在动态交互过程中可能会出现数据交换不能

有效兼容等问题。从另一方面，构件的源代码因为相对构件运用方法有着某些未知性，于是，

对其实施静态分析是很难进行的。更别说对相关数据依赖以及控制依赖关系的获得，进行有

关测试用例的构造，进行测试，确认出进行测试需要的充分性准则是很难的。所以，在构件

测试技术中，应该考虑以下几个问题：

 

　　

1.怎样利用系统方法对测试驱动程序与插针进行构建。对于构件测试驱动程序，其一定

是基于脚本的程序，同时仅仅对其黑盒功能进行执行。主要有基于场景以及规范的测试驱动