（3）性能测试和调整的费用较高；

　　（4）低效的系统资源确认和监控。

　　7、可能解决方案

　　7.1 并行结构的构件测试

　　构件测试的并行体系结构（PACT）方法不是测试技术，但更适合是定义测试构件的结构的软件结构。该体系结构的目标是最小化建立和维护个体测试用例的需求努力。PACT的基础是抽象类集合，提供基本的功能，能被每个具体的测试类继承。通过抽象类，包括公共异常捕获和公共输人和输出设备。

　　7.2 基于耦合的构件集成测试

　　这种方法利用测试构件间的耦合关系来达到对构件软件集成测试的目的。构件间的耦合关系主要产生于构件之间的依赖，构件之问的通信，以及构件之间的协作等。基于构件耦合的软件测试充分性如：所有的耦合覆盖，所有的数据耦合覆盖，所有的控制耦合覆盖等。

　　7.3 基于缺陷的软件构件测试

　　基于缺陷的构件软件测试要考虑下面问题：

　　（1）对每个构件，尽力去选择相应的测试数据以便暴露存在于那个构件中的某个缺陷；

　　（2）突变测试（）控制效力；

　　（3）缺陷约束问题，即如果突变存在的话，确定保证突变暴露的必要条件，而不是按照传统的方法希望测试者选择测试数据去消灭突变。

　　8、构件软件测试充分性

　　构件软件的测试充分性。其余两个专门用于判断构件软件的充分性，它们是反分解公理和反合成公理。针对构件软件的特殊性，Rosen Blum提出一种衡量构件软件测试的可适用的基于子域的充分性标准，其中C—adequate—for—P标准用于构件的单元测试，C—adequate—O13一M用于组合构件的集成测试；Keren建立了另外一种衡量构件软件测试充分性的标准，它通过方法覆盖和意外覆盖来度量测试用例的充分性。

　　9、结论

　　构件软件测试技术在构件生产者方面和构件测试者方面均已取得了进展。但是由于构件软件技术本身还处在一个发展和完善阶段，构件软件开发本身还存在这样那样的问题，例如，到目前为止还没有哪一种构件描述语言能够全面完整地描述构件系统，构件软件开发的国际标准还有待出炉并应进一步完善。构件软件测试标准虽然已经有了初稿，但其中的不完善是显而易见的。通用的构件软件测试过程也需要明确和进一步开发。所有这些问题决定了构件软件技术在展示它巨大魅力的同时，也向人们提出了一个一个的挑战。