软件构件的可测试性是决定构件质量的一个重要因素，建立具有良好可测试性的程序和构件总是可以简化测试操作，减少测试成本并提高软件质量。正如James Bach指出的那样，一组程序特征将会对软件的可测试性发生影响，这些特征包括可观察性、可跟踪性、可控制性、理解性等。

　　（1）构件的可观察性：对构件的操作行为、输人参数和输出能较容易地进行观察，设计和定义构件接口在决定构件的可观察性方面扮演着主要角色。

　　（2）构件的可跟踪性：构件应具有跟踪其属性和行为的状态的能力。以前称为行为的可跟踪性，是构件易于跟踪其外部和内部行为；后来则称为跟踪的可控制性，是构件具有易于定制跟踪功能的能力。

　　（3）构件的可控制性：对于一个构件的输入出、操作和行为能较容易地进行控制。

　　（4）构件的可理解性：构件提供多少信息及如何呈现。

　　4、构件软件的测试过程

　　根据构件测试标准L201，对任何给定的测试用例，构件测试过程应该包括下列活动：

　　（1）构件测试计划：它规定测试策略和项目构件测试计划是如何被用于要测试的构件。包括识别所有特定于某个测试策略的异常，以及要测试的构件在测试执行中与其交互的软件（如驱动和桩）；

　　（2）构件测试规约：使用测试计划活动中选择的测试用例设计技术来设计测试用例。测试规约应该包括测试目标、构件的初始状态、输入和期望的输出。每个涣9试用例的执行应该是可重复的；

　　（3）构件测试执行：即每个测试用例应该是可执行的；

　　（4）构件测试记录：每个测试用例的记录中均应该包含要测试构件和测试规约的明确的标识和版本记录。实际的输出也应该记录在案。这是因为所有特定的测试活动均将使用这些测试记录建立起来。另外，要比较实际的输出和期望的输出，记录并分析任何差异便于明确错误在哪，并建立早期的测试活动以便日后为移除这种规约差异和构件中缺陷排除奠定基础；

　　（5）检查构件测试是否完成：检查测试记录是否复合先前定义的测试完全标准。如果这些标准没有得到满足，必须重复早期的测试活动，测试过程从这点开始重新启动。也可能需要重复测试规约活动取进一步设计测试用例以满足测试覆盖目标。

　　5、构件软件的测试策略

　　5.1 构件认证技术

　　J．M．Vaos详细分析了构件的认证问题，认为：好的构件认证方法能保证构件获得应有的可靠性，这一过程尽量保证构件能满足开发者的需要。构件认证一般采用下列几个步骤：

　　（1）黑盒构件测试：这种测试重视的是测试用例的选择，而不是考虑软件的语法。黑盒测试需要为某个测试过程提供一个可执行的构件，一个输入和一个预言（oracle）。预言是一种通过检验每个输入的输出来确定失败是否发生的技术。黑盒测试强调预期的结果要和实际的结果匹配，它通常表现为功能测试或接口测试。

　　（2）系统级的缺陷注入技术：该方法实际上不是查找系统中的缺陷，而是在某个构件失败的情况下，通过在系统注入人为缺陷尽量去尽量演示系统的运行将是多么的糟糕。这种技术的典型代表如：接口传播分析（IPA）技术。

　　（3）可操作的系统测试（OST）：对系统级的缺陷注入技术而言，这个方法是值得提倡的，这是因为当一个商业构件被引入系统时，OST技术可用来检查系统的承受能力以及系统完成功能的情况。

　　（4）包装：包装概念是随着“基于可用性而非可靠性来使用构件”的需要产生的。软件包装的工作方式：把构件的功能限制在某些想要的方式中。

　　5.2 构件元数据方法

　　该方法提供的框架用概要信息（即构件元数据）来分析和测试构件。产生元数据的根据是基于不同种类的信息，这些信息依赖具体的上下文关系和具体的需要。构件开发者提供的每种构件元数据都有的格式和标记，并把在这种概要信息嵌入在软件构件中。构件测试人员通过这些元数据而不是访问源代码来分析和测试构件。