基于构件的软件测试方法概述

摘要：构件技术成为当前软件工程中的发展方向，构件的软件测试成为软件测试中的一个新的研究领域。本文对构件技术做了简单的介绍后，对构件测试中遇到的困难和问题做了比较详细的描述，并介绍了目前过内外在构件测试方面的一些成果现状。

关键字：软件测试；构件技术；构件测试

中图分类号：TP311文献标识码：A文章编号：1009-3044(2008)14-20952-02

1 软件构件技术

自上个80年代以来，面向对象技术的发展与应用，在提高软件可重用性方面起了积极的推动作用，软件重用已经成软件工程技术的一个重要目标，成为开发出高效、低成本、可重用软件系统的重要的现实途径。当今软件开发技术的主流已是基于软件构件技术。只要遵循软件构件模型规范，各个软件开发商就可以用自己方便的程序语言去实现可重用的软件构件，应用程序开发人员就有可能实现在计算机硬件领域早已实现的梦想：挑选构件，组合成新的应用软件系统。oscarNierstrasz提出[1]：Applieations=Components + seripts即应用软件就是构件和构件描述组成。

2 传统的软件测试

2.1 软件测试的重要性、目的和原则

为了能够保证交付的软件使客户满意，需要在软件开发、集成和形成系统之后进行充分、全面、有效的测试，软件测试是保证软件质量的重要手段。

测试过程贯穿在软件开发的整个生命周期过程，覆盖范围是很广泛的，包括需求分析，设计文档、程序代码等。目前比较侠义的理解是软件测试就是对程序代码的测试。

Grenford.J.Myers[2] 就软件的测试目的提出了如下的观点：(1)软件测试是程序的执行过程，目的在于发现缺陷；(2)一个好的测试用例在于能发现至今未发现的缺陷；(3)一个成功的测试是发现了至今未发现的多个缺陷的测试。因而，测试的目的是在资源消耗合理的情况下，发现尽可能多的缺陷和错误。

软件测试中应该遵循主要原则包括：(1)应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭；(2)测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成；(3)序员应避免检查自己的程序；(4)在设计测试用例时，应当包括合理的输入条件和不合理的输入条件；(5)充分重视测试中的群集现象；(6)严格执行测试计划，排除测试的随意性；(7)应当对每一个测试结果做全面的检查；(8)妥善的保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便[3]。

2.2 传统的软件测试主要方法和技术

通常依照如下方法对软件测试进行分类：

(1) 软件开发过程中的测试：包括单元测试；集成测试；系统测试； 验收测试。

(2) 软件产品测试。测试对象是已经或即将产品化的软件。包括：功能测试；性能测试；β测试；Benchmark测试。

(3) 专门的软件测试：包括可靠性测试；标准符合性测试；互操作性测试；安全性测试；强度测试。

3 构件测试方法概述

3.1 构件测试技术发展现状

构件测试技术发展历史并不长，构件继承了传统软件的特点，与传统软件相比又具有一定的特殊性，所以构件软件的测试技术也相应的继承了传统软件测试技术中适用的部分，同时又具有传统软件测试所不具备的特性。

正是这些特殊性决定了构件软件的测试方式、方法在某些方面具有自己的特点。为此，在传统软件测试技术的基础上，对构件软件测试技术进行挖掘和开拓成为构件软件测试领域的一项主要研究内容，并有了一定的发展。

构件软件作为软件的一种，是软件技术发展的新阶段，面临着更加复杂的开发模式，为此需要对构件软件进行一系列的测试，从而保证构件软件的质量要求。

3.2 构件测试面临的主要问题

基于构件的软件开发所面对的测试单元是构件产品，作为构件开发方来说可以针对构件的源码进行测试，而对于构件的使用方来说往往构件的源码是不可知的也很难与构件的开发者进行交流。这一差异导致构件的测试与传统的软件测试相比具有了新的问题，包括：

3.2.1 构件生产者所面临的测试问题

(1) 构件的应用环境复杂多变，作为构件开发者难以考虑所有的构件可能运行的环境，因而也就不能对构件进行充分的测试；(2)构件软件测试集的组合爆炸问题导致测试工作量非常大，却难以覆盖所有的测试点[4]；(3)构件的测试环境配置困难重重，构件生产者不可能搭建构件使用的确切环境；(4)构件测试的可重复性；(5)构件测试工具缺乏。

3.2.2 构件使用者面临的测试问题

(1)很难获得软件的源程序，因而不能对构件的内部细节有详细的了解，从而对构件的测试带有一定的盲目性；(2)测试数据的产生：由于同样的原因，难以产生合适的测试输入，使得对底层元素难以达到较高的覆盖率；(3)组合爆炸问题依然存在，导致测试困难；(4)集成测试中有可能对构件单元测试中的测试点造成重复测试，从而造成测试冗余性；(5)构件测试的可重用性：对构件的测试应该是可重用的；(6)构件测试工具的缺乏。

3.3 构件测试与传统的软件测试的主要区别

构件与传统软件从系统设计开始就是不同的，传统软件开发从需求分析、软件设计到编写代码一直到测试都是软件公司独立完成的，所以具有比较清晰的脉络，也能得到软件的内部细节信息。

基于构件的软件开发采用的模式也是从需求分析开始的，但是组成软件的基本单元不再是传统的软件模块（比如类），而是来自于第三方的软件构件。从而面向构件的软件开发技术面对的主要问题是如何选择以及组装软件构件[5]，经过充分的测试，最终形成软件产品。

因此，传统软件测试的软件设计详细信息和软件的源代码都是可以得到的，脉络十分清晰。软件构件的测试以及软件构件产品集成测试和系统测试需要寻找合适的构件产品并组装，而构件设计以及内部代码对于构件使用者来说是不可见的。

传统软件测试理论和方法技术都比较成熟，构件测试的测试方法和测试技术部分可以采用传统的软件测试。但是构件测试具有自己的特点，需要区别对待，根据构件的新特性研究构件的测试方法。

3.4 国内外构件测试的研究现状

国外及国内在构件测试方面的研究已经取得一定的成果，例如：Freedman提出了构件的可测性理论[6]；Jerry[7]提出了构件可跟踪性以及构件可理解性；浙江大学提出界面构件关联图的测试方法，等等

从国内外构件测试技术研究的现状来看，具体的软件构件测试方法主要有以下几种：

(1) 基于元数据的构件测试

这种测试方法由构件开发者提供包含构件信息的元数据，这些元数据覆盖了构件各个方面的信息。构件测试者提取元数据中的信息并根据这些信息来制定合理的测试用例，然后对构件进行测试。由于这些元数据具有明确的构件使用上下文信息，所以通过元数据提供的数据对构件进行测试具有明确的目标和清晰的测试切入点。不过元数据的制定比较困难。

(2) 软件构件流程图

使用数据流和控制流的方法，利用从构件中获取的信息将构件数据和信息的交互做成交互图，然后根据此交互图来制定测试用例。

(3) 错误注入的构件测试

通过对程序进行错误注入来观察构件失效或产生错误的状态下对整个系统的影响。通过对构件功能的限制来发现系统入侵情况下构件的运行状态以及由此而产生的对整个软件系统的危害。

(4) 测试序列技术

该方法对构件间的交互进行测试，通过应用需求分离出构件交互的序列并不断集成直到生成整个应用系统，因而可以看作是一个渐进的测试过程。但是随着系统中构件数目和规模的增加，这种测试的难度也逐渐的增加。

4 总结

随着构件技术成为当前软件工程中的热点发展方向，构件的软件测试成为软件测试中的一个新的研究领域。本文对构件技术做了简单的介绍后，对构件测试中遇到的困难和问题做了比较详细的描述，并介绍了目前过内外在构件测试方面的一些成果现状。所做的工作属于项目组系统实现的前期熟悉工作的组成部分。

参考文献：

[1] Osear Nierstrasz,Theo Dirk Meijler.Research direetions in software composition[J].ACM computing surveys,1995,27(2):262-264.

[2] Grenford J Myers.The Art of Software Testing[M].2nd Edition.2004:147.

[3] 郑人杰.实用软件工程[M].2版.北京:清华大学出版社,1999:169.

[4] 李延春.软件构件技术的现状与未来[J].计算机工程与应用,2003,3(1):86-96.

[5] 艾萍.软件构件组装基础研究[J].计算机工程与设计,2003(12):6-27.

[6] R S Freedman.Testablility of software Components[J].IEEE Transaction on Software Engineering,1991,6(17).

[7] Jerry Gao,Eugene,Simon Shim,et al.Monitoring Software Components and Component-based Software[C].Proc 24th Annual International Conforance on Computer Software an Applications,2000.