基于XML的COM构件自动化测试技术研究.docx

随着构件的广泛应用，基于构件的软件工程也应运而生，其目标是在一个框架内用即插即用的软件构件定制构造或者是商业成品(COmmerCialOff-The-Shelf,COTS)构件一一组成应用系统。基于构件的方法使得大型分布式软件系统的开发和维护变得更为简单，可以提高软件的复用性和软件开发效率。但是，复用质量低下的软件构件可能会起到相反的作用，不合理的使用高质量的软件构件也可能带来灾难性的后果。因此需要对构件进行测试。使用软件测试自动化技术提高软件测试的效率己经成为软件测试发展的必然趋势，构件的自动测试也成为一个必不可少的环节。但传统的自动测试技术，由于其设计模式的局限性，已经不能适用于构件的自动测试。因此，迫切需要研究CoTS构件自动化测试技术。基于XML的COM构件自动化测试技术是对第三方COM构件进行自动化测试的有效技术。该技术主要包括COM构件测试自动化框架和实现该框架的Cc)M构件自动化测试工具C0MCAT(C0MComponentAutomatedTest)0整个框架主要由构件测试元数据自动提取与描述、构件测试脚本自动生成、构件测试脚本自动执行、构件测试结果自动验证与记录四个环节组成。XML技术被充分应用到构件测试自动化的各个环节。该框架将面向对象单元测试自动化框架XUnit与数据驱动的测试框架加以结合，并且做了改进。该框架还从构件使用者和测试者的角度设计了内涵丰富的构件元数据，并且针对CoM构件，通过访问类型库来自动获取构件结构信息元数据，并用XML描述。该框架还综合运用多种技术辅助实现测试过程的自动化。实验表明，该技术有效、自动化程度较高、投入回报率较高。关键词：构件测试，测试自动化，自动化测试工具，元数据，类型库AbstractWiththewidelyadoptionofthecomponents,Component-BasedSoftwareEngineeringemergesasthetimesrequire.Itsgoalistoassemblyapplicationsystemsusingplug-and-playsoftwarecomponentswhichareeithercustom-builtorCOTS(CommercialOff-The-Shelf)inaframework.Component-basedmethodmakesthedevelopmentandmaintenanceoflargedistributedsoftwaresystemseasieranditcanincreasethesoftwarereusabilityanddevelopmentefficiency.However,reusingsoftwarecomponentsofinferiorqualitymayhavethereverseimpact,andreusingsoftwarecomponentsofsuperiorqualityincorrectlymayalsobringdisastrouseffect.Socomponentsneedtobetested.Applyingsoftwaretestautomationtechniquestoimprovetheefficiencyofsoftwaretestinghasbecometheinevitabledevelopmenttrendofsoftwaretesting,andtestautomationofthecomponentshasalsobecomeanecessarysection.Butduetothelimitationofdesignpattern,conventionaltestautomationtechniquescannotadapttotestautomationofthecomponents.SotheresearchonCOTScomponentstestautomationtechniquesisbadlyneeded.XML-basedCOMcomponentstestautomationtechniquesareeffectivetestautomationtechniquesonthird-partyCOMcomponents.ltmainlyincludesCOMcomponenttestautomationframeworkandCOMcomponentautomatedtestingtoolCOMCAT(COMComponentAutomatedTest)whichimplementsthatframework.Thewholeframeworkiscomposedoffoursections,whichare,componenttestmetadataautomatedretrievalanddescription,componenttestscriptautomatedgenerating,componenttestscriptautomatedexecuting,componenttestresultsautomatedverificationandlogging.XMLtechniquesarefullyappliedtoeverysectionofcomponenttestautomation.Theframeworkcombinesobject-orientedunittestautomationframeworkxUnitanddata-driventestframeworktogetherandmakessomeimprovements.ltalsodesignscomponentmetadatawithplentyofcontentfromcomponentusersandtesters'view.EspeciallyforCOMcomponents,itretrievescomponentmetadataaboutstructuralinformationautomaticallybyaccessingtypelibraryanddescribesthatwithXML.ltalsosyntheticallyutilizesseveraltechniquestoassistaccomplishingtheautomationoftestprocess.Anexperimentindicatesthatthesetechniquesareeffectiveandofhighdegreeofautomationandhighreturnoninvestment.Keywords:ComponentTestingiTestAutomationiAutomatedTestingTool;Metadata;TypeLibrary摘要IABSTRACTIll1绪论1.1 研究课题的背景与意义(1)1.2 国内外研究现状(4)1.3 本文主要内容及组织(9)2构件测试及其自动化1.1 基于构件的开发(10)1.2 构件测试方法(11)1.3 构件测试的自动化及其工具(15)1.4 本章小结(15)3 COM构件测试自动化框架3.1 测试自动化总体框架(16)3.2 XML语言与构件测试自动化(18)3.3 测试脚本生成自动化(26)3.4 测试程序运行自动化(34)3.5 本章小结(36)4 COM构件测试元数据4.1 构件元数据(37)42COM构件的类型信息及其提取(39)4.3 类型信息的描述与展现(41)4.4 本章小结(45)5第三方COM构件自动化测试工具的实现5.1 自动化测试工具的实现(46)5.2 实验(49)5.3 本章小结(54)6总结与展望6.1 论文总结(55)6.2 进一步工作展望(56)致谢(57)参考文献(59)1.1 研究课题的背景与意义自从1968年NATO会议首次提出“软件危机”以来，软件工程己经取得大进展，然而这一危机并没有消失。随着计算机应用领域的迅速扩大，软件及复杂性的不断提高，软件危机愈加明显地暴露出来，提高软件生产率成为产业的当务之急。要解决这个问题，软件复用无疑是一个有效的方法。软件复用(SOftWareReUSe)是将己有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的花费1。它的主要思想是，将软件看成是由不同功能部分的“组件”所组成的有机体，每一个组件在设计编写时可以被设计成完成同类工作的通用工具。这样，如果建立了可以完成各种工作的组件，编写特定软件的工作就变成将各种不同组件组织连接起来的简单问题，这对于软件产品的最终质量和维护工作都有本质性的改变。从早期的子函数到后来的面向对象的类的概念，软件复用的粒度逐渐变大。但是以类为封装单位的复用不能解决异构互操作问题。构件可以将一组类的组合进行封装，隐藏具体的实现细节，通过接口向外界提供服务。构件可以将复用提高到更高的复用层次。进入20世纪90年代以后，越来越多的软件开发组织在系统开发过程中，开始采用可复用的软件构件2。ClemenzSZyPerSkiF认为构件是“一个软件单元，具有一组契约或合同规定的接口。构件与它所在的环境/上下文有清晰的依赖关系，并且仅仅与此相关。构件可以被独立配置，以便由第三方进行合成(新的软件)。一个广为接受的定义是：构件是具有符合特定协议的接口的组合单元，它的上下文依赖性是完全显式的，构件可以被独立地部署，并由第三方组合。在与其它构件组合时，不需要修改构件的源代码，只需要修改构件的接口和属性。构件的接口分为两种：一种是构件可以向外界提供的服务的接口，其它构件可以通过这些接口来调用构件提供的服务；另一种是构件期望从其它构件获得服务的接口2。目前，工业界主要有三个不同的构件规范，即SUN公司的EJB,Microsoft公司的8M/D8M4,对象管理组织OMG的8RBAS°这些技术提供了从构件开发应用系统的通信与协同。其中微软的COM构件应用十分广泛，包括WindOWS操作系统和OffiCe办公套件都大量使用了COM构件0。COM的全称是ComponentObjectMode1,也就是构件对象模型。COM是一个二进制的标准，COM标准包括规范和实现两大部分。规范部分定义了构件和构件之间通信的机制，这些规范不依赖于任何特定的语言和操作系统，只要按照规范，任何语言都可使用。COM标准的实现部分是8M库。8M库为Cc)M规范的具体实现提供了一些核心服务。一般是在WindOWS平台下，并且被Microsoft推出的开发工具和类库支持。COM标准详细规定了一个COM构件所应具有的内存结构。COM对象间的交互完全基于对此内存结构的操作。因此可以在很大程度上忽略不同编程语言，应用环境之间的差别，解决了重新编译重新发行的问题7。COM用接口的概念对构件的功能属性进行完全的封装。与构件的通信必须通过接口进行。接口不仅仅是一个逻辑上的概念，而且也存在着与之相对应的物理内存结构虚表(VTABLE)。一个对象可以对应多个接口，一个接口也可以由多个对象所实现，表现出灵活的多态性。COM接口同时也为版本管理提供了方便。当使用新版本的构件替换老版本时，只要该构件实现了旧版本的接口(通过包容、聚合等手段)，就保证了其与原用软件系统的兼容。同时新增功能(新的接口)又可被自然地使用。接口完全封装了内部功能、属性的具体实现，使得COM对象对外表现为“黑盒”结构，完全吻合面向对象系统所要求的“强内聚性”。但由于对接口的过多强调，Cc)M构件一般不具备广泛提倡的“弱耦合性”的特点。总之，OOM的设计思想是构件化构建软件，软件由多个经过编译的二进制形式的构件构成(DLL或EXE形式)，因此软件的更新就可以通过更新软件的某一个构件来实现，软件的实现可通过多个构件搭建而成。这个思想是借鉴了硬件开发中的模块化思想一在其它的工程领域，构件的概念已经得到了广泛的接受与使用8o而基于8M的复用思想是：以接口的标准化推动服务的标准化，为复用软件的开发和使用建立规范。在构件广泛应用的潮流中，基于构件的软件工程(Component-BasedSoftwareEngineering,CBSE)9.10这个新领域也应运而生，其目标是在一个框架内用即插即用的软件构件(定制构造或者是商业成品(CommercialOff-The-Shelf,COTS)构件11-131)组成应用系统。基于构件的软件工程，包括COTS构件的使用，可以减少从头开始的软件开发中常常碰到的一些问题。特别是COTS的使用，被视作一种既能增加可靠性与生产力，又能减少大型系统的交付时间的方式。基于构件的方法使得大型分布式软件系统的开发和维护变得更为简单，可以提高软件的复用性和软件开发效率。但是，过多依赖复用也带来了新的问题，复用质量低下的软件构件可能会起到相反的作用，不合理的使用高质量的软件构件也可能带来灾难性的后果，如阿丽亚娜5号火箭发射失败就是由于未对构件进行升级就复用造成的14oAdrita指出构件失效产生的后果大于测试的费用时，就要进行测试。而构件测试与传统的软件测试相比，还有其特殊性15:(1)构件测试的语言无关性、跨平台。跨平台的调用会有许多问题。而且不同语言和系统的环境，也会造成对构件的理解上的歧义。例如：当构件的接口函数的实现部分是从其它基类继承来且还有开发者的部分代码时，这样跨平台测试，当返回错误结果时，无法确定是继承关系错误还是开发的代码错误10。(2)构件的严格封装性。封装带来测试的障碍。与面向对象和结构化软件的测试不同，接口测试是构件测试的首要任务。因为构件的全局数据是不允许直接访问的，构件内的数据访问一般用Get和Set方法。构件的接口对客户是可见的，但由于接口的说明没有强制性要求，因此并非所有的接口都有详细说明。构件测试要求有一种途径能访问到所有的属性和方法，以便测试到所有的构件状态。(3)构件是二进制代码级的复用。与传统软件的源代码复用不同，构件是二进制代码复用。构件的使用者未必了解构件的源代码，而构件供应商一般仅提供构件的说明。尤其是对于CoTS构件，出于商业机密考虑，CoTS构件的源代码通常是不可得的。另外，由于构件的描述文档也不是特别详细，在开发高可靠的软件系统时通常需要构件的源代码和详细的描述文档，而且构件使用者对构件功能的理解也会与构件开发者有出入，这就给构件测试带来了难题。(4)构件以代码复用为目标。代码的复用率越高，代码的效益也越高，这一目标决定了构件的健壮性和稳定性要求比其它软件更高。构件的故障不仅影响到开发企业，还影响到以构件为平台的二级或更多级的开发商甚至是使用者，这就要求对构件进行更加充分、更加严格的测试，减少程序的错误。随着软件规模的增加，测试工作量的增大，软件开发周期的缩短，使用软件测试自动化技术提高软件测试的速度和效率就成为了软件测试发展的必然趋势。使用软件测试自动化技术能完成许多手工测试无法实现或难以实现的测试。正确、合理地实施自动化测试，能够快速、彻底地对软件进行测试，从而提高软件质量，节省经费，缩短产品发布周期。另外，自动化测试还能排除一些人为的因素(如遗漏、失误等等)。自动测试技术是测试技术的一个分支，它的研究重点是如何最大可能地进行自动化测试、在哪些方面可以进行自动化以及自动测试工具的开发和使用17。目前应用的软件测试工具种类很多，如企业级测试工具WinRUnner,性能负载测试工具Load-RUnner,单元测试工具CPPUnit、JUnit等，都具备一定的自动测试能力。但从测试原理来看，它们所进行的都是基于源代码的测试，测试人员如果使用这些工具编制自动测试程序，不但要熟悉测试对象的源代码，而且经常需要调试测试脚本，不可避免地造成了工时的延长和交流的冗余18o随着构件技术的发展，构件的自动测试成为一个必不可少的环节。但传统的自动测试工具，由于其设计模式3的局限性，已经不能适用于构件的自动测试。它们具有如下缺陷：测试工具不能独立完成整个测试过程；编写测试用例是一项繁琐的任务；测试脚本常常需要编写和调试19;仍然采用基于源代码的测试模式，要求待测的构件提供特定的测试接口，或者在实现代码中嵌入测试语句，未考虑到COTS构件具有的接口不变性和源码隐藏的特点。它们都不能满足构件的自动测试的需求。因此，迫切需要开发COTS构件自动化测试工具。1.2 国内外研究现状1.2.1 构件测试的理论基础当前，国内外研究机构在构件可能存在的缺陷、构件的可测性、构件测试的目标、内容、测试中要解决的问题等方面都做了一定的研究，为构件测试的进一步研究打下了理论基础。构件软件集成中会遇到的两类缺陷：服务相关的缺陷(SerViCe-related)和结构相关(StrUCmre-related)的缺陷120。服务相关的缺陷可能是语法缺陷、语义缺陷和非功能缺陷；结构相关的缺陷(即与系统结构相关的缺陷)可能来源于有问题的连接件，有问题的公共基础设施和有问题的拓扑结构21o构件的可测试性是设计和测试软件程序及构件的重要概念之一。运用具有良好的可测试性的程序和构件来构建软件，可以简化测试操作、减少测试开销、提高软件质量22。在构件工程中，有几种不同的构件可测试性的观点，包括构件可观察性(observability)构件可跟踪性(traceability)、构件可控制性(COntrOnabiIity)和构件易理JWtt(Understandability)。(1)构件的可观察性：对构件的操作行为、输入参数和输出能较容易地进行观察，设计和定义构件接口在决定构件的可观察性方面扮演着主要角色。(2)构件的可跟踪性：构件应具有跟踪其属性和行为的状态的能力。以前称为行为的可跟踪性，是构件易于跟踪其外部和内部行为；后来则称为跟踪的可控制性，是构件具有易于定制跟踪功能的能力。(3)构件的可控制性：对于一个构件的输入/输出、操作和行为能较容易地进行控制。(4)构件的可理解性：构件提供多少信息及如何呈现21o构件测试的最终目标是23:(1)检查构件与软件规范是否一致，并完成其功能需求；(2)检查实现的系统是否反映了规范中所描述的结构和交互需求(假定这些需求是正确而且完整的)。与传统软件测试相似，构件软件测试的基本内容包括：(1)单元测试：软件系统中每一个单个的构件都经过测试；(2)集成测试：对由己测试过的构件集成的子系统作为一个实体进行测试；(3)系统测试：对由已测试过的子系统形成的系统作为一个实体进行测试；(4)回归测试：对软件系统所作的任何修改以后都必须进行相应的重新测试。对于测试中要解决的问题，HaIToIdl24)认为应该从构件提供者和构件使用者两个不同的角度来看待。构件的提供者认为构件相对于使用构件的环境是独立的，所以要用与上下文独立的方式测试构件所有的功能。相反，构件使用者开发的应用程序提供了构件的运行环境，所以构件使用者不把构件看成独立的单元，仅仅考虑与应用程序相关的构件功能。另一个重要的区别是提供者有构件的源代码，而使用者则通常没有构件的源代码25。构件开发者面临的测试问题有：测试充分性判据(testadequacyCriteria)的可扩展性(SCaIability):由于复杂性问题和组合爆炸问题，对小规模程序适用的判据对大规模程序不一定适用。(2)测试数据的产生：由于同样的原因，难以产生合适的测试输入，使得对低层次元素(如分支一一定义使用对，需求功能可看作是高层元素)难以达到较高的覆盖率。(3)如何配置构件的测试环境：对单个构件进行测试的环境，与构件在实际系统中运行的环境可能不同。(4)构造测试驱动器和打桩技术：传统的技术是面向特定的工程。但是构件的多样性和其功能的专用化使得传统的技术达不到应有的效力。(5)构件测试的可重用性：对构件的测试应该是可重用的。构件使用者面临的测试问题有：(1)测试充分性判据的可扩展性问题依然存在。(2)构件的测试顺序：如果软件采用分层结构，可以先测试底层构件，因为不需要其他构件提供服务；然后再测试高层构件，所调用到的其他构件都是经过测试的。如果不是分层结构，可能就难以确定测试的顺序。(3)冗余测试问题：通常先对构件进行单独测试，然后使用相同的充分性判据进行集成测试，这就导致有些测试是重复的。(4)源代码是否可用：源代码可用与否导致不同的系统测试方法。编程语言、操作系统平台、硬件结构的混杂性(heterogeneity):系统使用的构件可能是用不同语言编写的，运行在不同的平台上，这就要求测试方法和工具与平台和语言无关。此外，构件使用者还面临测试分布式软件时的监控问题、事件重构、构件的竞争和死锁、多线程问题、容错测试问题等。1.2.2 软件自动磔械目前构件的自动化测试技术还不成熟，因此主要沿用传统的软件自动化测试技术。对于后者，国内外已经做了一些研究，并且引入了自动化测试框架，还开发了不少自动化测试工具。软件测试自动化实现的原理和方法主要有：直接对代码进行静态和动态分析、测试过程的捕获和回放、测试脚本技术126。(1)代码分析代码分析类似于高级语言编译系统，一般针对不同的高级语言去构造分析工具，在工具中定义类、对象、函数、变量等定义规则、语法规则；在分析时对代码进行语法扫描，找出不符合编码规范的地方；根据某种质量模型评价代码质量，生成系统的调用关系图等。(2)捕获和回放代码分析是一种白盒测试的自动化方法，捕获和回放则是一种黑盒测试的自动化方法。捕获是将用户每一步操作都记录下来。这种记录的方式有两种：程序用户界面的像素坐标或程序显示对象(窗口、按钮、滚动条等)的位置，以及相对应的操作、状态变化或是属性变化。所有的记录转换为一种脚本语言所描述的过程，以模拟用户的操作。回放时，将脚本语言所描述的过程转换为屏幕上的操作，然后将被测系统的输出记录下来同预先给定的标准结果比较。(3)脚本技术脚本是一组测试工具执行的指令集合，也是计算机程序的一种形式。脚本可以通过录制测试的操作产生，然后再做修改，也可以直接用脚本语言编写脚本。一般的自动化测试包括以下基本过程127:(1)测试设计。测试设计包含设计测试用例、测试环境等。在有些自动化测试中，测试用例是测试人员手工生成的，部分是自动生成的。(2)脚本生成。根据测试设计生成需要进行的测试脚本，有些高度自动化的测试工具能够根据软件以前运行的情况自动地录制测试用例。(3)脚本运行。脚本运行也叫做脚本回放，对生成的脚本进行运行。(4)结果比较。主要是分析脚本运行的结果是否符合规范，以此来决定测试是否通过。(5)测试报告生成。对测试结果进行分类整理，生成相关的测试报告。对不能通过的测试结果进行分析、分类、记录和通报，让相关的测试人员和开发人员了解测试结果。近年来，自动化测试框架逐渐成为热点。它是由一些假设、概念和为自动化测试提供的实践组成的集合。它可以减少实现和维护的成本，使测试人员可以把精力集中在应用程序的测试用例设计上，而不是开发测试28。常用的有以下五种自动化测试框架29,30,(1)测试脚本模块化框架这是通过创建小的独立的脚本来代表被测试应用程序的模块和函数，然后用一种分层的方式将这些小脚本组成更大的测试，从而实现一个特定的测试用例。(2)测试库构架框架测试库构架框架和测试脚本模块化框架非常相似，但是它把被测应用程序分成过程和函数，而不是脚本。这种框架要求创建库文件来代表被测应用程序模块、零件或函数，然后这些库文件被测试用例脚本直接调用。(3)数据驱动测试框架将数据驱动脚本技术运用到自动化测试框架中就形成了数据驱动测试框架。这种框架从某个数据文件(例如ODBC源文件、Excel文件、.CSV文件、ADO对象文件等)中读取输入、输出的测试数据，然后通过变量传入事先录制好的或手工编写的测试脚本中。其中，这些变量被用作传递(输入/输出)用来验证应用程序的测试数据。(4)关键字驱动测试框架这有时候也称为表驱动自动化测试框架，它是对数据驱动自动化测试的有效改进和补充。这个框架需要开发数据表和关键字。这些数据表和关键字独立于执行它们的测试自动化工具，并可以用来“驱动”待测应用程序和数据的测试脚本代码，使自动化测试框架独立于应用程序。在一个关键字驱动测试中，把待测应用程序的功能和每个测试用例的执行步骤一起写到一个表中。(5)混合测试自动化框架最普遍的执行框架是上面介绍的所有技术的一个结合，取其长处，弥补其不足。在自动化测试工具方面，主要有以下几类：(1)静态分析工具用于分析设计模型、源代码或其他源程序中包含的信息，能够生成相关数据流、逻辑流或者质量指标等信息3132。常用的如MCCabeVisualQualityToolSetLOgiSCOpe、TestWorkAdvisor等。(2)测试数据生成工具获取测试活动中使用的数据，并且通过转化、析取、变换或捕捉现有数据作为依据，自动为测试程序生成可靠的测试数据。目前典型的测试数据生成工具有：SoftTest.PanoramaC/C+测试数据生成工具、ParasoftC+Test等。(3)测试评估工具用于动态测试过程中对测试的内容及测试覆盖性进行评测，为测试的充分性提供依据。常见的测试评估工具有：ATAC、PureCoverageTestWorks/Coverage等。(4)集成化测试系统它将多种测试工具融为一体，是一种功能较强的测试工具。常见的有：SADAT、MicrosoftTestforWindowsParaSOftlnSUre+等。(5)测试管理工具它能够用于辅助测试活动或工作的计划、设计、实施、执行、评估和管理。目前，比较有代表性的测试管理工具主要有：RAIDS、TestStudio、TestDireCtOr等。1.3 本文主要内容及组织本文主要讨论了第三方COM构件的测试自动化技术，基于XML描述的COM构件元数据一一类型信息，利用类XUnit单元测试框架进行测试，并实现了COM构件自动化测试工具原型COMCAT(COMComponentAutomatedTest)o基于上述研究内容，本文各章组织如下：第1章概述了CoM构件测试自动化的研究背景和意义，并介绍了国内外目前在与此相关的构件测试和软件自动化测试方面所做的基础性工作。第2章详细介绍了构件的开发、测试方法、测试自动化的途径和工具的开发。第3章在现有构件测试及其自动化研究的基础上，进行比较、分析，考虑到第三方Ce)M构件的特点，设计了一套CoM构件自动化测试的框架，介绍了该测试框架的整个流程及其中各步骤中所使用的主要方法和技术。第4章重点介绍了针对第三方CoM构件的源码未知、文档缺乏的难点，采用的自动从类型库中提取COM构件类型信息，并以组织良好、可扩展性强的XML文档扩展、描述，以友好的树形视图展现的技术，其中类型信息为测试提供了依据，而XML文档便于自动化测试过程。第5章对前面设计的CoM构件测试自动化框架进行了实现，开发了自动化测试工具原型COMCAT,给出了其系统结构、数据结构、模块设计与实现，并进行了实验分析。第6章对全文进行总结并展望了未来的工作。最后是致谢和参考文献。2构件测试及其自动化2.1基于构件的开发随着网络和软件技术的不断发展，基于构件的软件开发(Component-BasedSoftwareDevelopment,CBSD)受到人们的高度重视，它是一种在模块化系统、结构化设计和面向对象技术的基础上发展起来的新的软件开发方法。CBSD是在一定构件模型的支持下，复用构件库中的一个或多个构件，通过组合手段高效率、高质量地构造应用软件系统的过程19oCBSD通过提高系统的可扩展性和可维护性来减少软件开发的费用，更快的整合系统，并能有效的降低大型系统的维护和升级压力33。基于构件的软件开发过程与传统的面向过程或面向对象的软件开发过程有所不同。传统的软件开发过程或面向对象的软件开发过程是围绕用户需求进行需求分析和设计，软件完全根据用户的需求定制，称之为基于需求的软件开发过程。而基于构件的软件开发过程，由于从商业市场上购买的构件并不是为某一个固定用户定制的，或者构件实现的功能并不是完全与用户的要求相吻合，因此，基于构件的软件开发过程是在用户需求、软件设计、项目管理和构件市场之间的一个平衡过程。面向构件的软件开发是指软件体系结构可重组以及软件成分可重用的系统开发方法。从工程化与过程管理的角度讲，面向构件的软件开发过程可定义为4个阶段：34(1)分析阶段。从特定应用需求出发，通过领域分析，进行共性需求识别、领域对象抽象和领域知识获取，建立概念层的领域模型，产生应用系统的需求规格说明，这一阶段的成果是领域模型。(2)设计阶段。设计阶段的主要任务是基于领域模型寻求软件解决方案，包括构架设计模型和构件设计模型。在这一阶段中，首先检索构架库中存放的面向特定领域的构架，寻找可复用的构架，或者对其进行必要的适应性修改；在无可复用构架时，创造适合该应用环境的新构架，并进行标准化描述后入库，以备将来的复用。然后，在构架的指导下，把系统功能分解到相应的构件和连接件，并定义系统中构件之间的关系。这一阶段的成果是构架模型和构件模型。(3)实现阶段。根据领域应用开发或直接重用的需要，进行领域实现。包括领域构件的识别、设计、编码和测试等局部过程集成，系统构件的分类、检索、引用和构件库的维护，领域构件与系统构件的演化、实例化、组合和应用原型的动态生成等领域框架整体集成，从而建立符合领域应用的各种物理模型。这一阶段的成果是软件构架和代码级别的构件。(4)集成阶段。通过对实现阶段所生成的产品进行组装和运行模拟(正向)、设计优化(逆向)等措施，针对领域软件原型进行可用性评价和可重构性验证，并对符合确认测试条件的应用系统进行全局封装和使用规范生成，最终获得一个真正构件化的目标系统。随着CBSD的逐渐成熟，网络上出现了大量的Ce)TS构件产品，在基于CoTS构件的系统开发中，系统开发的观念被组装和集成现有构件的观念所取代，CBSD强调以构件集成为中心进行系统的构造。2.2构件测试方法对应于构件的测试，应从接口、信息和实现三个方面加以实施。构件测试可以分为接口测试、状态测试与实现测试35。构件的接口测试实际上是验证构件对外需求接口与提供接口是否与构件规范说明一致，功能是否正确，是否通过接口实现与其它构件的交互。构件的状态测试是验证构件内部状态是否正确，在各种条件下包含的属性、变量值是否刻画了构件的当前状态。构件的实现测试是验证构件功能实现的正确性、健壮性。在大多数情况下，对一个构件的测试，不仅仅是测试其接口、状态或实现，往往是三者都要加以测试，并且每一种测试与其它两种测试是相辅相成的：构件通过接口对外提供的功能是否正确，显然要取决于其状态和实现；构件的状态往往通过接口体现；构件的实现建立在构件的接口规范基础上，并且可以改变构件的状态。三种测试只是测试出发点的不同侧重因素，在实际测试中，是融合在一起的。对于任何工程产品都可以使用黑盒测试或白盒测试两种方法之一进行测试。软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看作一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看作一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。从构件接口测试的角度出发，往往采用黑盒测试方法，通过接口调用输入数据得到结果，进行与接口规范的比较得到测试报告。在设计接口测试输入参数时，除了使用传统的等价类划分、边界值分析等方法外，还要考虑到接口的前置条件和后置条件等约束。从构件状态与实现角度出发，采用白盒测试方法，通过分析构件的结构组成和实现细节产生测试用例，然后加以测试。构件测试与传统测试过程中的单元测试大体类似，由那些验证构件的实现与构件的规格说明书描述是否一致的相关活动组成。传统的软件单元测试是在开发时由开发人员或者是专门的测试人员进行的，常见的单元测试方法有根据前置条件和后置条件设计测试用例以及根据程序运行状态转换图来构建测试用例等方法。构件软件单元测试的现有研究方法多是在现有单元测试方法的基础上，针对构件的特点进行了一定的改进。目前用于构件测试的主要方法有以下几种2:(1)构件验证构件验证361(CertificationOfCOmPonent)方法，首先对构件进行基于系统运行剖面的黑箱测试，确保构件完成应有的功能，如果达不到就不使用它；然后把构件放进系统中，进行系统级的错误注入，目的是揭示特定构件失效会对系统造成多大的危害，如果系统能经得起考验就认定可以使用该构件，否则要对构件进行包装(WraP),限制某些功能的使用，再重新放进系统进行验证。仅仅对构件进行黑箱测试不足以保证可靠性，某些安全性问题(如恶意代码、Trojan木马)也难以检测出来。如何提供足够的测试用例进行系统测试也是个大问题。内置测试(built-intest)内置测试方法37通过在构件的源代码中添加了用于内置测试的函数，事实上成为一种特殊的构件，这种构件运行时具有两种模式：正常模式及维护模式。维护模式下可以调用构件内置的测试函数来测试构件，正常模式下不会调用内置的测试函数。这种方法增强了构件的可测试性，简化了构件维护的正确性、可适应性、完整性、可预防性和重设计性，而且适应范围广，除了构件外，还适用于类和对象，但是该方法需要构件源代码。(3)回溯测试方法(RetroSPeCtOrS)回溯测试方法138利用Retrospectors来记录构件执行的历史信息，以便测试者可以利用这些测试信息。构件中的RetTo类与JaVaBeanS中的内省类(InIroSPeCtOrCIaSS)相似。具有Retro类的构件有三种不同的模式：设计时模式、测试时模式和执行时模式。构件中的Retrospector可以手工创建，也可以通过为构件添加一种所谓的Retro-spec规约来自动生成。该方法的优点在于，即使没有源代码，构件使用者也可以使用代码覆盖分析的方法测试构件，因为构件内部的Retrospector可以记录构件的执行情况。但由于该方法不是构件的标准，构件提供者不一定提供这项功能。(4)构件包装方法(Wrapper)构件包装方法39通过为构件添加一层保护的包装层，以探测构件执行时的错误及异常行为，并提供异常处理机制。这种保护型的包装层能够处理典型的构件运行错误，比如缺少信号、信号的变化范围超过了规定的限度，信号振动等。该方法可以提高商业构件的可靠性。该方法的局限性在于设计、实现及评估构件包装层可能是代价不菲的，而且构件包装层不能过于复杂，否则就可能与提高构件的可靠性的初衷相反。(5)TDSTDS(Technologies,Developmentframeworks,andqualityassuranceSchemes)方法140的第一步确定构件的接口；第二步，确定接口中提供的方法(method)和异常处理(exception),哪些是必须进行覆盖的；第三步，确定这些方法和异常处理函数的参数，用突变算子