【优秀硕士论文参考】基于xml的com构件自动化测试技术研究

分类号学号学校代码10487密级硕士学位论文基于XML的COM构件自动化测试技术研究学位申请人学科专业计算机软件与理论指导教师答辩日期2008年5月28日THERESEARCHONCOMCOMPONENTTESTAUTOMATIONBASEDONXML独创性声明本人声明所呈交的学位论文是我个人在导师指导下进行的研究工作及取得的研究成果。尽我所知，除文中已经标明引用的内容外，本论文不包含任何其他个人或集体已经发表或撰写过的研究成果。对本文的研究做出贡献的个人和集体，均已在文中以明确方式标明。本人完全意识到，本声明的法律结果由本人承担。学位论文作者签名日期2008年月日学位论文版权使用授权书本学位论文作者完全了解学校有关保留、使用学位论文的规定，即学校有权保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅。本人授权华中科技大学可以将本学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。保密，在_年解密后适用本授权书。不保密。（请在以上方框内打“”）学位论文作者签名指导教师签名本论文属于日期2008年月日日期2008年月日摘要随着构件的广泛应用，基于构件的软件工程也应运而生，其目标是在一个框架内用即插即用的软件构件定制构造或者是商业成品（COMMERCIALOFFTHESHELF，COTS）构件组成应用系统。基于构件的方法使得大型分布式软件系统的开发和维护变得更为简单，可以提高软件的复用性和软件开发效率。但是，复用质量低下的软件构件可能会起到相反的作用，不合理的使用高质量的软件构件也可能带来灾难性的后果。因此需要对构件进行测试。使用软件测试自动化技术提高软件测试的效率已经成为软件测试发展的必然趋势，构件的自动测试也成为一个必不可少的环节。但传统的自动测试技术，由于其设计模式的局限性，已经不能适用于构件的自动测试。因此，迫切需要研究COTS构件自动化测试技术。基于XML的COM构件自动化测试技术是对第三方COM构件进行自动化测试的有效技术。该技术主要包括COM构件测试自动化框架和实现该框架的COM构件自动化测试工具COMCATCOMCOMPONENTAUTOMATEDTEST。整个框架主要由构件测试元数据自动提取与描述、构件测试脚本自动生成、构件测试脚本自动执行、构件测试结果自动验证与记录四个环节组成。XML技术被充分应用到构件测试自动化的各个环节。该框架将面向对象单元测试自动化框架XUNIT与数据驱动的测试框架加以结合，并且做了改进。该框架还从构件使用者和测试者的角度设计了内涵丰富的构件元数据，并且针对COM构件，通过访问类型库来自动获取构件结构信息元数据，并用XML描述。该框架还综合运用多种技术辅助实现测试过程的自动化。实验表明，该技术有效、自动化程度较高、投入回报率较高。关键词构件测试，测试自动化，自动化测试工具，元数据，类型库ABSTRACTWITHTHEWIDELYADOPTIONOFTHECOMPONENTS,COMPONENTBASEDSOFTWAREENGINEERINGEMERGESASTHETIMESREQUIREITSGOALISTOASSEMBLYAPPLICATIONSYSTEMSUSINGPLUGANDPLAYSOFTWARECOMPONENTSWHICHAREEITHERCUSTOMBUILTORCOTSCOMMERCIALOFFTHESHELFINAFRAMEWORKCOMPONENTBASEDMETHODMAKESTHEDEVELOPMENTANDMAINTENANCEOFLARGEDISTRIBUTEDSOFTWARESYSTEMSEASIERANDITCANINCREASETHESOFTWAREREUSABILITYANDDEVELOPMENTEFFICIENCYHOWEVER,REUSINGSOFTWARECOMPONENTSOFINFERIORQUALITYMAYHAVETHEREVERSEIMPACT,ANDREUSINGSOFTWARECOMPONENTSOFSUPERIORQUALITYINCORRECTLYMAYALSOBRINGDISASTROUSEFFECTSOCOMPONENTSNEEDTOBETESTEDAPPLYINGSOFTWARETESTAUTOMATIONTECHNIQUESTOIMPROVETHEEFFICIENCYOFSOFTWARETESTINGHASBECOMETHEINEVITABLEDEVELOPMENTTRENDOFSOFTWARETESTING,ANDTESTAUTOMATIONOFTHECOMPONENTSHASALSOBECOMEANECESSARYSECTIONBUTDUETOTHELIMITATIONOFDESIGNPATTERN,CONVENTIONALTESTAUTOMATIONTECHNIQUESCANNOTADAPTTOTESTAUTOMATIONOFTHECOMPONENTSSOTHERESEARCHONCOTSCOMPONENTSTESTAUTOMATIONTECHNIQUESISBADLYNEEDEDXMLBASEDCOMCOMPONENTSTESTAUTOMATIONTECHNIQUESAREEFFECTIVETESTAUTOMATIONTECHNIQUESONTHIRDPARTYCOMCOMPONENTSITMAINLYINCLUDESCOMCOMPONENTTESTAUTOMATIONFRAMEWORKANDCOMCOMPONENTAUTOMATEDTESTINGTOOLCOMCATCOMCOMPONENTAUTOMATEDTESTWHICHIMPLEMENTSTHATFRAMEWORKTHEWHOLEFRAMEWORKISCOMPOSEDOFFOURSECTIONS,WHICHARE,COMPONENTTESTMETADATAAUTOMATEDRETRIEVALANDDESCRIPTION,COMPONENTTESTSCRIPTAUTOMATEDGENERATING,COMPONENTTESTSCRIPTAUTOMATEDEXECUTING,COMPONENTTESTRESULTSAUTOMATEDVERIFICATIONANDLOGGINGXMLTECHNIQUESAREFULLYAPPLIEDTOEVERYSECTIONOFCOMPONENTTESTAUTOMATIONTHEFRAMEWORKCOMBINESOBJECTORIENTEDUNITTESTAUTOMATIONFRAMEWORKXUNITANDDATADRIVENTESTFRAMEWORKTOGETHERANDMAKESSOMEIMPROVEMENTSITALSODESIGNSCOMPONENTMETADATAWITHPLENTYOFCONTENTFROMCOMPONENTUSERSANDTESTERSVIEWESPECIALLYFORCOMCOMPONENTS,ITRETRIEVESCOMPONENTMETADATAABOUTSTRUCTURALINFORMATIONAUTOMATICALLYBYACCESSINGTYPELIBRARYANDDESCRIBESTHATWITHXMLITALSOSYNTHETICALLYUTILIZESSEVERALTECHNIQUESTOASSISTACCOMPLISHINGTHEAUTOMATIONOFTESTPROCESSANEXPERIMENTINDICATESTHATTHESETECHNIQUESAREEFFECTIVEANDOFHIGHDEGREEOFAUTOMATIONANDHIGHRETURNONINVESTMENTKEYWORDSCOMPONENTTESTINGTESTAUTOMATIONAUTOMATEDTESTINGTOOLMETADATATYPELIBRARY目录摘要IIABSTRACTII1绪论11研究课题的背景与意义212国内外研究现状213本文主要内容及组织22构件测试及其自动化21基于构件的开发222构件测试方法223构件测试的自动化及其工具224本章小结23COM构件测试自动化框架31测试自动化总体框架232XML语言与构件测试自动化233测试脚本生成自动化234测试程序运行自动化235本章小结24COM构件测试元数据41构件元数据242COM构件的类型信息及其提取243类型信息的描述与展现244本章小结25第三方COM构件自动化测试工具的实现51自动化测试工具的实现252实验253本章小结26总结与展望61论文总结262进一步工作展望2致谢2参考文献21绪论11研究课题的背景与意义自从1968年NATO会议首次提出“软件危机”以来，软件工程己经取得大进展，然而这一危机并没有消失。随着计算机应用领域的迅速扩大，软件及复杂性的不断提高，软件危机愈加明显地暴露出来，提高软件生产率成为产业的当务之急。要解决这个问题，软件复用无疑是一个有效的方法。软件复用SOFTWAREREUSE是将已有软件的各种有关知识用于建立新的软件,以缩减软件开发和维护的花费1。它的主要思想是，将软件看成是由不同功能部分的“组件”所组成的有机体，每一个组件在设计编写时可以被设计成完成同类工作的通用工具。这样，如果建立了可以完成各种工作的组件，编写特定软件的工作就变成将各种不同组件组织连接起来的简单问题，这对于软件产品的最终质量和维护工作都有本质性的改变。从早期的子函数到后来的面向对象的类的概念，软件复用的粒度逐渐变大。但是以类为封装单位的复用不能解决异构互操作问题。构件可以将一组类的组合进行封装，隐藏具体的实现细节，通过接口向外界提供服务。构件可以将复用提高到更高的复用层次。进入20世纪90年代以后，越来越多的软件开发组织在系统开发过程中，开始采用可复用的软件构件2。CLEMENZSZYPERSKI3认为构件是“一个软件单元，具有一组契约或合同规定的接口。构件与它所在的环境/上下文有清晰的依赖关系，并且仅仅与此相关。构件可以被独立配置，以便由第三方进行合成（新的软件）。一个广为接受的定义是构件是具有符合特定协议的接口的组合单元，它的上下文依赖性是完全显式的，构件可以被独立地部署，并由第三方组合。在与其它构件组合时，不需要修改构件的源代码，只需要修改构件的接口和属性。构件的接口分为两种一种是构件可以向外界提供的服务的接口，其它构件可以通过这些接口来调用构件提供的服务；另一种是构件期望从其它构件获得服务的接口2。目前，工业界主要有三个不同的构件规范，即SUN公司的EJB，MICROSOFT公司的COM/DCOM4，对象管理组织OMG的CORBA5。这些技术提供了从构件开发应用系统的通信与协同。其中微软的COM构件应用十分广泛，包括WINDOWS操作系统和OFFICE办公套件都大量使用了COM构件6。COM的全称是COMPONENTOBJECTMODEL，也就是构件对象模型。COM是一个二进制的标准，COM标准包括规范和实现两大部分。规范部分定义了构件和构件之间通信的机制，这些规范不依赖于任何特定的语言和操作系统，只要按照规范，任何语言都可使用。COM标准的实现部分是COM库。COM库为COM规范的具体实现提供了一些核心服务。一般是在WINDOWS平台下，并且被MICROSOFT推出的开发工具和类库支持。COM标准详细规定了一个COM构件所应具有的内存结构。COM对象间的交互完全基于对此内存结构的操作。因此可以在很大程度上忽略不同编程语言，应用环境之间的差别，解决了重新编译重新发行的问题7。COM用接口的概念对构件的功能属性进行完全的封装。与构件的通信必须通过接口进行。接口不仅仅是一个逻辑上的概念，而且也存在着与之相对应的物理内存结构虚表VTABLE。一个对象可以对应多个接口，一个接口也可以由多个对象所实现，表现出灵活的多态性。COM接口同时也为版本管理提供了方便。当使用新版本的构件替换老版本时，只要该构件实现了旧版本的接口（通过包容、聚合等手段），就保证了其与原用软件系统的兼容。同时新增功能（新的接口）又可被自然地使用。接口完全封装了内部功能、属性的具体实现，使得COM对象对外表现为“黑盒”结构，完全吻合面向对象系统所要求的“强内聚性”。但由于对接口的过多强调，COM构件一般不具备广泛提倡的“弱耦合性”的特点。总之，COM的设计思想是构件化构建软件，软件由多个经过编译的二进制形式的构件构成DLL或EXE形式，因此软件的更新就可以通过更新软件的某一个构件来实现，软件的实现可通过多个构件搭建而成。这个思想是借鉴了硬件开发中的模块化思想在其它的工程领域，构件的概念已经得到了广泛的接受与使用8。而基于COM的复用思想是以接口的标准化推动服务的标准化，为复用软件的开发和使用建立规范。在构件广泛应用的潮流中，基于构件的软件工程（COMPONENTBASEDSOFTWAREENGINEERING，CBSE）9,10这个新领域也应运而生，其目标是在一个框架内用即插即用的软件构件（定制构造或者是商业成品（COMMERCIALOFFTHESHELF，COTS）构件1113）组成应用系统。基于构件的软件工程，包括COTS构件的使用，可以减少从头开始的软件开发中常常碰到的一些问题。特别是COTS的使用，被视作一种既能增加可靠性与生产力，又能减少大型系统的交付时间的方式。基于构件的方法使得大型分布式软件系统的开发和维护变得更为简单，可以提高软件的复用性和软件开发效率。但是，过多依赖复用也带来了新的问题，复用质量低下的软件构件可能会起到相反的作用，不合理的使用高质量的软件构件也可能带来灾难性的后果，如阿丽亚娜5号火箭发射失败就是由于未对构件进行升级就复用造成的14。ADRITA指出构件失效产生的后果大于测试的费用时，就要进行测试。而构件测试与传统的软件测试相比，还有其特殊性15（1）构件测试的语言无关性、跨平台。跨平台的调用会有许多问题。而且不同语言和系统的环境，也会造成对构件的理解上的歧义。例如当构件的接口函数的实现部分是从其它基类继承来且还有开发者的部分代码时，这样跨平台测试，当返回错误结果时，无法确定是继承关系错误还是开发的代码错误16。（2）构件的严格封装性。封装带来测试的障碍。与面向对象和结构化软件的测试不同，接口测试是构件测试的首要任务。因为构件的全局数据是不允许直接访问的，构件内的数据访问一般用GET和SET方法。构件的接口对客户是可见的，但由于接口的说明没有强制性要求，因此并非所有的接口都有详细说明。构件测试要求有一种途径能访问到所有的属性和方法，以便测试到所有的构件状态。（3）构件是二进制代码级的复用。与传统软件的源代码复用不同，构件是二进制代码复用。构件的使用者未必了解构件的源代码，而构件供应商一般仅提供构件的说明。尤其是对于COTS构件，出于商业机密考虑，COTS构件的源代码通常是不可得的。另外，由于构件的描述文档也不是特别详细，在开发高可靠的软件系统时通常需要构件的源代码和详细的描述文档，而且构件使用者对构件功能的理解也会与构件开发者有出入，这就给构件测试带来了难题。（4）构件以代码复用为目标。代码的复用率越高，代码的效益也越高，这一目标决定了构件的健壮性和稳定性要求比其它软件更高。构件的故障不仅影响到开发企业，还影响到以构件为平台的二级或更多级的开发商甚至是使用者，这就要求对构件进行更加充分、更加严格的测试，减少程序的错误。随着软件规模的增加，测试工作量的增大，软件开发周期的缩短，使用软件测试自动化技术提高软件测试的速度和效率就成为了软件测试发展的必然趋势。使用软件测试自动化技术能完成许多手工测试无法实现或难以实现的测试。正确、合理地实施自动化测试，能够快速、彻底地对软件进行测试，从而提高软件质量，节省经费，缩短产品发布周期。另外，自动化测试还能排除一些人为的因素如遗漏、失误等等。自动测试技术是测试技术的一个分支，它的研究重点是如何最大可能地进行自动化测试、在哪些方面可以进行自动化以及自动测试工具的开发和使用17。目前应用的软件测试工具种类很多，如企业级测试工具WINRUNNER，性能负载测试工具LOADRUNNER，单元测试工具CPPUNIT、JUNIT等，都具备一定的自动测试能力。但从测试原理来看，它们所进行的都是基于源代码的测试，测试人员如果使用这些工具编制自动测试程序，不但要熟悉测试对象的源代码，而且经常需要调试测试脚本，不可避免地造成了工时的延长和交流的冗余18。随着构件技术的发展，构件的自动测试成为一个必不可少的环节。但传统的自动测试工具，由于其设计模式3的局限性，已经不能适用于构件的自动测试。它们具有如下缺陷测试工具不能独立完成整个测试过程；编写测试用例是一项繁琐的任务；测试脚本常常需要编写和调试19；仍然采用基于源代码的测试模式，要求待测的构件提供特定的测试接口，或者在实现代码中嵌入测试语句，未考虑到COTS构件具有的接口不变性和源码隐藏的特点。它们都不能满足构件的自动测试的需求。因此，迫切需要开发COTS构件自动化测试工具。12国内外研究现状121构件测试的理论基础当前，国内外研究机构在构件可能存在的缺陷、构件的可测性、构件测试的目标、内容、测试中要解决的问题等方面都做了一定的研究，为构件测试的进一步研究打下了理论基础。构件软件集成中会遇到的两类缺陷服务相关的缺陷SERVICERELATED和结构相关STRUCTURERELATED的缺陷20。服务相关的缺陷可能是语法缺陷、语义缺陷和非功能缺陷；结构相关的缺陷即与系统结构相关的缺陷可能来源于有问题的连接件，有问题的公共基础设施和有问题的拓扑结构21。构件的可测试性是设计和测试软件程序及构件的重要概念之一。运用具有良好的可测试性的程序和构件来构建软件，可以简化测试操作、减少测试开销、提高软件质量22。在构件工程中，有几种不同的构件可测试性的观点，包括构件可观察性OBSERVABILITY、构件可跟踪性TRACEABILITY、构件可控制性CONTROLLABILITY和构件易理解性UNDERSTANDABILITY。1构件的可观察性对构件的操作行为、输入参数和输出能较容易地进行观察,设计和定义构件接口在决定构件的可观察性方面扮演着主要角色。2构件的可跟踪性构件应具有跟踪其属性和行为的状态的能力。以前称为行为的可跟踪性,是构件易于跟踪其外部和内部行为；后来则称为跟踪的可控制性,是构件具有易于定制跟踪功能的能力。3构件的可控制性对于一个构件的输入/输出、操作和行为能较容易地进行控制。4构件的可理解性构件提供多少信息及如何呈现21。构件测试的最终目标是231检查构件与软件规范是否一致，并完成其功能需求；2检查实现的系统是否反映了规范中所描述的结构和交互需求假定这些需求是正确而且完整的。与传统软件测试相似，构件软件测试的基本内容包括1单元测试软件系统中每一个单个的构件都经过测试；2集成测试对由已测试过的构件集成的子系统作为一个实体进行测试；3系统测试对由已测试过的子系统形成的系统作为一个实体进行测试；4回归测试对软件系统所作的任何修改以后都必须进行相应的重新测试。对于测试中要解决的问题，HARROLD24认为应该从构件提供者和构件使用者两个不同的角度来看待。构件的提供者认为构件相对于使用构件的环境是独立的，所以要用与上下文独立的方式测试构件所有的功能。相反，构件使用者开发的应用程序提供了构件的运行环境，所以构件使用者不把构件看成独立的单元，仅仅考虑与应用程序相关的构件功能。另一个重要的区别是提供者有构件的源代码，而使用者则通常没有构件的源代码25。构件开发者面临的测试问题有1测试充分性判据TESTADEQUACYCRITERIA的可扩展性SCALABILITY由于复杂性问题和组合爆炸问题，对小规模程序适用的判据对大规模程序不一定适用。2测试数据的产生由于同样的原因，难以产生合适的测试输入，使得对低层次元素如分支定义使用对，需求功能可看作是高层元素难以达到较高的覆盖率。3如何配置构件的测试环境对单个构件进行测试的环境，与构件在实际系统中运行的环境可能不同。4构造测试驱动器和打桩技术传统的技术是面向特定的工程。但是构件的多样性和其功能的专用化使得传统的技术达不到应有的效力。5构件测试的可重用性对构件的测试应该是可重用的。构件使用者面临的测试问题有1测试充分性判据的可扩展性问题依然存在。2构件的测试顺序如果软件采用分层结构，可以先测试底层构件，因为不需要其他构件提供服务；然后再测试高层构件，所调用到的其他构件都是经过测试的。如果不是分层结构，可能就难以确定测试的顺序。3冗余测试问题通常先对构件进行单独测试，然后使用相同的充分性判据进行集成测试，这就导致有些测试是重复的。4源代码是否可用源代码可用与否导致不同的系统测试方法。5编程语言、操作系统平台、硬件结构的混杂性HETEROGENEITY系统使用的构件可能是用不同语言编写的，运行在不同的平台上，这就要求测试方法和工具与平台和语言无关。此外，构件使用者还面临测试分布式软件时的监控问题、事件重构、构件的竞争和死锁、多线程问题、容错测试问题等。122软件自动化测试目前构件的自动化测试技术还不成熟，因此主要沿用传统的软件自动化测试技术。对于后者，国内外已经做了一些研究，并且引入了自动化测试框架，还开发了不少自动化测试工具。软件测试自动化实现的原理和方法主要有直接对代码进行静态和动态分析、测试过程的捕获和回放、测试脚本技术26。（1）代码分析代码分析类似于高级语言编译系统，一般针对不同的高级语言去构造分析工具，在工具中定义类、对象、函数、变量等定义规则、语法规则；在分析时对代码进行语法扫描,找出不符合编码规范的地方；根据某种质量模型评价代码质量，生成系统的调用关系图等。（2）捕获和回放代码分析是一种白盒测试的自动化方法，捕获和回放则是一种黑盒测试的自动化方法。捕获是将用户每一步操作都记录下来。这种记录的方式有两种程序用户界面的像素坐标或程序显示对象窗口、按钮、滚动条等的位置，以及相对应的操作、状态变化或是属性变化。所有的记录转换为一种脚本语言所描述的过程，以模拟用户的操作。回放时，将脚本语言所描述的过程转换为屏幕上的操作,然后将被测系统的输出记录下来同预先给定的标准结果比较。（3）脚本技术脚本是一组测试工具执行的指令集合,也是计算机程序的一种形式。脚本可以通过录制测试的操作产生,然后再做修改,也可以直接用脚本语言编写脚本。一般的自动化测试包括以下基本过程27（1）测试设计。测试设计包含设计测试用例、测试环境等。在有些自动化测试中，测试用例是测试人员手工生成的，部分是自动生成的。（2）脚本生成。根据测试设计生成需要进行的测试脚本，有些高度自动化的测试工具能够根据软件以前运行的情况自动地录制测试用例。（3）脚本运行。脚本运行也叫做脚本回放，对生成的脚本进行运行。（4）结果比较。主要是分析脚本运行的结果是否符合规范，以此来决定测试是否通过。（5）测试报告生成。对测试结果进行分类整理，生成相关的测试报告。对不能通过的测试结果进行分析、分类、记录和通报，让相关的测试人员和开发人员了解测试结果。近年来，自动化测试框架逐渐成为热点。它是由一些假设、概念和为自动化测试提供的实践组成的集合。它可以减少实现和维护的成本，使测试人员可以把精力集中在应用程序的测试用例设计上，而不是开发测试28。常用的有以下五种自动化测试框架29,30（1）测试脚本模块化框架这是通过创建小的独立的脚本来代表被测试应用程序的模块和函数，然后用一种分层的方式将这些小脚本组成更大的测试，从而实现一个特定的测试用例。（2）测试库构架框架测试库构架框架和测试脚本模块化框架非常相似，但是它把被测应用程序分成过程和函数，而不是脚本。这种框架要求创建库文件来代表被测应用程序模块、零件或函数，然后这些库文件被测试用例脚本直接调用。（3）数据驱动测试框架将数据驱动脚本技术运用到自动化测试框架中就形成了数据驱动测试框架。这种框架从某个数据文件例如ODBC源文件、EXCEL文件、CSV文件、ADO对象文件等中读取输入、输出的测试数据，然后通过变量传入事先录制好的或手工编写的测试脚本中。其中，这些变量被用作传递输入/输出用来验证应用程序的测试数据。（4）关键字驱动测试框架这有时候也称为表驱动自动化测试框架，它是对数据驱动自动化测试的有效改进和补充。这个框架需要开发数据表和关键字。这些数据表和关键字独立于执行它们的测试自动化工具，并可以用来“驱动”待测应用程序和数据的测试脚本代码，使自动化测试框架独立于应用程序。在一个关键字驱动测试中，把待测应用程序的功能和每个测试用例的执行步骤一起写到一个表中。（5）混合测试自动化框架最普遍的执行框架是上面介绍的所有技术的一个结合,取其长处,弥补其不足。在自动化测试工具方面，主要有以下几类（1）静态分析工具用于分析设计模型、源代码或其他源程序中包含的信息,能够生成相关数据流、逻辑流或者质量指标等信息31,32。常用的如MCCABEVISUALQUALITYTOOLSET、LOGISCOPE、TESTWORK/ADVISOR等。（2）测试数据生成工具获取测试活动中使用的数据，并且通过转化、析取、变换或捕捉现有数据作为依据，自动为测试程序生成可靠的测试数据。目前典型的测试数据生成工具有SOFTTEST、PANORAMAC/C测试数据生成工具、PARASOFTCTEST等。（3）测试评估工具用于动态测试过程中对测试的内容及测试覆盖性进行评测，为测试的充分性提供依据。常见的测试评估工具有ATAC、PURECOVERAGE、TESTWORKS/COVERAGE等。（4）集成化测试系统它将多种测试工具融为一体,是一种功能较强的测试工具。常见的有SADAT、MICROSOFTTESTFORWINDOWS、PARASOFTINSURE等。（5）测试管理工具它能够用于辅助测试活动或工作的计划、设计、实施、执行、评估和管理。目前,比较有代表性的测试管理工具主要有RAIDS、TESTSTUDIO、TESTDIRECTOR等。13本文主要内容及组织本文主要讨论了第三方COM构件的测试自动化技术，基于XML描述的COM构件元数据类型信息，利用类XUNIT单元测试框架进行测试，并实现了COM构件自动化测试工具原型COMCATCOMCOMPONENTAUTOMATEDTEST。基于上述研究内容，本文各章组织如下第1章概述了COM构件测试自动化的研究背景和意义，并介绍了国内外目前在与此相关的构件测试和软件自动化测试方面所做的基础性工作。第2章详细介绍了构件的开发、测试方法、测试自动化的途径和工具的开发。第3章在现有构件测试及其自动化研究的基础上，进行比较、分析，考虑到第三方COM构件的特点，设计了一套COM构件自动化测试的框架，介绍了该测试框架的整个流程及其中各步骤中所使用的主要方法和技术。第4章重点介绍了针对第三方COM构件的源码未知、文档缺乏的难点，采用的自动从类型库中提取COM构件类型信息，并以组织良好、可扩展性强的XML文档扩展、描述，以友好的树形视图展现的技术，其中类型信息为测试提供了依据，而XML文档便于自动化测试过程。第5章对前面设计的COM构件测试自动化框架进行了实现，开发了自动化测试工具原型COMCAT，给出了其系统结构、数据结构、模块设计与实现，并进行了实验分析。第6章对全文进行总结并展望了未来的工作。最后是致谢和参考文献。2构件测试及其自动化21基于构件的开发随着网络和软件技术的不断发展，基于构件的软件开发COMPONENTBASEDSOFTWAREDEVELOPMENT，CBSD受到人们的高度重视，它是一种在模块化系统、结构化设计和面向对象技术的基础上发展起来的新的软件开发方法。CBSD是在一定构件模型的支持下，复用构件库中的一个或多个构件，通过组合手段高效率、高质量地构造应用软件系统的过程9。CBSD通过提高系统的可扩展性和可维护性来减少软件开发的费用，更快的整合系统，并能有效的降低大型系统的维护和升级压力33。基于构件的软件开发过程与传统的面向过程或面向对象的软件开发过程有所不同。传统的软件开发过程或面向对象的软件开发过程是围绕用户需求进行需求分析和设计，软件完全根据用户的需求定制，称之为基于需求的软件开发过程。而基于构件的软件开发过程，由于从商业市场上购买的构件并不是为某一个固定用户定制的，或者构件实现的功能并不是完全与用户的要求相吻合，因此，基于构件的软件开发过程是在用户需求、软件设计、项目管理和构件市场之间的一个平衡过程。面向构件的软件开发是指软件体系结构可重组以及软件成分可重用的系统开发方法。从工程化与过程管理的角度讲，面向构件的软件开发过程可定义为4个阶段34（1）分析阶段。从特定应用需求出发，通过领域分析，进行共性需求识别、领域对象抽象和领域知识获取，建立概念层的领域模型，产生应用系统的需求规格说明，这一阶段的成果是领域模型。（2）设计阶段。设计阶段的主要任务是基于领域模型寻求软件解决方案，包括构架设计模型和构件设计模型。在这一阶段中，首先检索构架库中存放的面向特定领域的构架，寻找可复用的构架，或者对其进行必要的适应性修改；在无可复用构架时，创造适合该应用环境的新构架，并进行标准化描述后入库，以备将来的复用。然后，在构架的指导下，把系统功能分解到相应的构件和连接件，并定义系统中构件之间的关系。这一阶段的成果是构架模型和构件模型。（3）实现阶段。根据领域应用开发或直接重用的需要，进行领域实现。包括领域构件的识别、设计、编码和测试等局部过程集成，系统构件的分类、检索、引用和构件库的维护，领域构件与系统构件的演化、实例化、组合和应用原型的动态生成等领域框架整体集成，从而建立符合领域应用的各种物理模型。这一阶段的成果是软件构架和代码级别的构件。（4）集成阶段。通过对实现阶段所生成的产品进行组装和运行模拟正向、设计优化逆向等措施，针对领域软件原型进行可用性评价和可重构性验证，并对符合确认测试条件的应用系统进行全局封装和使用规范生成，最终获得一个真正构件化的目标系统。随着CBSD的逐渐成熟，网络上出现了大量的COTS构件产品，在基于COTS构件的系统开发中，系统开发的观念被组装和集成现有构件的观念所取代，CBSD强调以构件集成为中心进行系统的构造。22构件测试方法对应于构件的测试，应从接口、信息和实现三个方面加以实施。构件测试可以分为接口测试、状态测试与实现测试35。构件的接口测试实际上是验证构件对外需求接口与提供接口是否与构件规范说明一致，功能是否正确，是否通过接口实现与其它构件的交互。构件的状态测试是验证构件内部状态是否正确，在各种条件下包含的属性、变量值是否刻画了构件的当前状态。构件的实现测试是验证构件功能实现的正确性、健壮性。在大多数情况下，对一个构件的测试，不仅仅是测试其接口、状态或实现,往往是三者都要加以测试，并且每一种测试与其它两种测试是相辅相成的构件通过接口对外提供的功能是否正确，显然要取决于其状态和实现；构件的状态往往通过接口体现；构件的实现建立在构件的接口规范基础上，并且可以改变构件的状态。三种测试只是测试出发点的不同侧重因素，在实际测试中，是融合在一起的。对于任何工程产品都可以使用黑盒测试或白盒测试两种方法之一进行测试。软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看作一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看作一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。从构件接口测试的角度出发，往往采用黑盒测试方法，通过接口调用输入数据得到结果，进行与接口规范的比较得到测试报告。在设计接口测试输入参数时，除了使用传统的等价类划分、边界值分析等方法外,还要考虑到接口的前置条件和后置条件等约束。从构件状态与实现角度出发，采用白盒测试方法，通过分析构件的结构组成和实现细节产生测试用例，然后加以测试。构件测试与传统测试过程中的单元测试大体类似，由那些验证构件的实现与构件的规格说明书描述是否一致的相关活动组成。传统的软件单元测试是在开发时由开发人员或者是专门的测试人员进行的，常见的单元测试方法有根据前置条件和后置条件设计测试用例以及根据程序运行状态转换图来构建测试用例等方法。构件软件单元测试的现有研究方法多是在现有单元测试方法的基础上，针对构件的特点进行了一定的改进。目前用于构件测试的主要方法有以下几种2（1）构件验证构件验证36CERTIFICATIONOFCOMPONENT方法，首先对构件进行基于系统运行剖面的黑箱测试，确保构件完成应有的功能，如果达不到就不使用它；然后把构件放进系统中，进行系统级的错误注入，目的是揭示特定构件失效会对系统造成多大的危害，如果系统能经得起考验就认定可以使用该构件，否则要对构件进行包装WRAP，限制某些功能的使用，再重新放进系统进行验证。仅仅对构件进行黑箱测试不足以保证可靠性，某些安全性问题如恶意代码、TROJAN木马也难以检测出来。如何提供足够的测试用例进行系统测试也是个大问题。（2）内置测试BUILTINTEST内置测试方法37通过在构件的源代码中添加了用于内置测试的函数，事实上成为一种特殊的构件，这种构件运行时具有两种模式正常模式及维护模式。维护模式下可以调用构件内置的测试函数来测试构件，正常模式下不会调用内置的测试函数。这种方法增强了构件的可测试性，简化了构件维护的正确性、可适应性、完整性、可预防性和重设计性，而且适应范围广，除了构件外，还适用于类和对象，但是该方法需要构件源代码。（3）回溯测试方法RETROSPECTORS回溯测试方法38利用RETROSPECTORS来记录构件执行的历史信息，以便测试者可以利用这些测试信息。构件中的RETRO类与JAVABEANS中的内省类INTROSPECTORCLASS相似。具有RETRO类的构件有三种不同的模式设计时模式、测试时模式和执行时模式。构件中的RETROSPECTOR可以手工创建，也可以通过为构件添加一种所谓的RETROSPEC规约来自动生成。该方法的优点在于，即使没有源代码，构件使用者也可以使用代码覆盖分析的方法测试构件，因为构件内部的RETROSPECTOR可以记录构件的执行情况。但由于该方法不是构件的标准，构件提供者不一定提供这项功能。（4）构件包装方法WRAPPER构件包装方法39通过为构件添加一层保护的包装层，以探测构件执行时的错误及异常行为，并提供异常处理机制。这种保护型的包装层能够处理典型的构件运行错误，比如缺少信号、信号的变化范围超过了规定的限度，信号振动等。该方法可以提高商业构件的可靠性。该方法的局限性在于设计、实现及评估构件包装层可能是代价不菲的，而且构件包装层不能过于复杂，否则就可能与提高构件的可靠性的初衷相反。（5）TDSTDS（TECHNOLOGIES，DEVELOPMENTFRAMEWORKS，ANDQUALITYASSURANCESCHEMES）方法40的第一步确定构件的接口；第二步，确定接口中提供的方法（METHOD）和异常处理（EXCEPTION），哪些是必须进行覆盖的；第三步，确定这些方法和异常处理函数的参数，用突变算子MUTANTOPERATORS对其进行处理；第四步，根据构件需求REQUIREMENTOFTHECOMPONENT创建测试集TESTSET，然后运行测试；第五步，去除测试中发现的错误ERROR；第六步，扩充测试集达到100的接口覆盖率INTERFACEBASEDCOVERAGEMEASURE。这个方法的特点是提出了构件软件测试的充分性条件，并由此生成、检验测试用例；但提出的测试充分性条件还需要与传统的测试充分性条件进行比较，例如对比不同的方法，看谁能更有效地检测出软件中播种的错误SEEDEDERROR。（6）构件元数据方法（COMPONENTMETADATAWAY）构件元数据方法41是利用构件的开发者提供的构件元数据METADATA来分析和测试构件，这些数据包含不同种类的信息并且有明确的上下文环境，由构件提供者在开发构件时嵌入这些信息，构件提供者还可以根据构件使用者的需要，增加相应的信息。构件元数据既可以描述构件的静态特性，也可以描述其动态特性，可以看作是大多数构件模型中的内省机制的一般形式。构件使用者在测试构件时，可以通过访问构件元数据获得相应的信息。该方法增加了程序分析的精确度，为构件使用者测试构件提供了方便性。目前的构件标准DCOM和EJB已经提供了通过元数据来为构件使用者提供附加信息的机制，但是制定相应独立于构件开发者的构件元数据的标准比较困难，缺乏第三方构件提供者的支持，目前该方法还只能用来测试小型程序。（7）序列生成技术序列生成技术42SEQUENCEGENERATIONTECHNIQUE，这种方法是两层结构PHASE是对每个构件单独考虑并定义METHODSEQUENCES，包含三步，用数据流方法分析构件包含的方法，然后使用符号执行技术得到每个方法的形式化规约，最后利用前两步得到的信息进行自动推导得到方法调用序列。通过执行所有的方法序列就可以测试这个构件；通过把每个构件的METHODSEQUENCE结合起来，研究渐增集成测试问题。通过分析构件之间的依赖关系，按照添加附加代码最少的原则确定集成的顺序，然后按照这个顺序成对集成构件客户和服务器。使用一种BACKWARDCHAINED推导方法生成METHODSEQUENCES。这种方法的优点是考虑到了构件集成的顺序，可以减少重复测试。但是随着被测软件规模的扩大，方法的复杂度可能会大大增加。（8）程序切片、控制依赖性分析和数据流测试程序切片、控制依赖性分析和数据流测试法43ANAPPROACHUSEPROGRAMSLICING，CONTROLDEPENDENCEANALYSISANDDATAFLOWTESTING，首先由构件的提供者对构件进行充分测试，并提供SUMMARYINFORMATION；构件使用者通过得到的SUMMARYINFORMATION可以进行有效的系统测试，而不需要得到构件的源代码。作者举了三个应用方向，程序切片PROGRAMSLICING、控制依赖性分析CONTROLDEPENDENCEANALYSIS和数据流测试。根据构件提供者提供的不同附加信息，构件使用者可以进行不同领域的分析。这种方法的缺点是SUMMARYINFORMATION并不属于任何现有构件规范的标准，要得到构件提供者的支持难度比较大。23构件测试的自动化及其工具随着构件软件的复杂性增加，基于构件的自动测试生成变得越来越复杂。原因是构件支持GUI使其增加了难度；构件支持多媒体使其增加了复杂度；分布式的构件更增加了其通信等方面的难度。因此，作为一个好的基于构件的自动测试工具，下面的功能是测试人员真正需要的定义好的黑盒测试模型和充分的测试标准、系统的方法和工具支持基于领域的测试生成44。构件的开发者可沿用已经产品化的面向对象软件测试工具对构件进行单元测试,这些工具有CTEST，PANORAMA和PARASOFTJTEST等。构件测试可把探针模型和构件有效地结合起来，然后可用上述测试工具45。专门的构件测试工具主要有1、MICROSOFT系列的OLE/COMVIEWER、OLECLIENTOLESERVER测试系列、ACTIVEXCONTROLTEST等。这些工具都是黑盒测试工具。2、JAVABEAN系列的工具。构件测试工具还很不成熟，主要用于构件的黑盒测试。24本章小结本章详细介绍了构件技术，包括CBSD这种新的软件开发方法及其过程，然后介绍了构件的测试方法，将其分为接口、状态和实现三种类型的测试，并与黑盒测试、白盒测试相结合，接着对于构件测试，将其与传统的单元测试类比，介绍了构件验证、内置测试、回溯测试方法等目前的主要研究成果，最后谈到了构件自动化测试工具的目标和现有的一些构件测试工具。通过这章的介绍可以看出增强构件的可测试性；建立通用的、可重用的测试平台；实现构件的测试方法，开发出真正专门、有效的构件自动化测试工具，这些都是亟待解决的问题。3COM构件测试自动化框架31测试自动化总体框架对于软件构件测试，英国标准委员会（BRITISHSTANDARD）已经制定了标准BS79252，该标准旨在帮助测试人员提高测试过程的质量，在此基础上提高软件的质量46。它描述了软件构件的通用动态测试过程、测试用例设计技术和测试度量技术。标准BS79252尽管现在是由英国标准协会BSI出版的，但是填补了目前软件工程领域中构件测试相关的空白，未来可能成为国际标准。该测试标准给出的通用动态测试过程如图31所示。本文主要研究其中的构件测试规格说明和构件测试执行部分。构件测试结果的验证与记录也可实现自动化。上面提到的标准BS79252规定每个将要被测试的构件都须有规格说明，以使得有可能从给定的输入集合获得期望的输出。尽管发布构件二进制代码的同时一般都有相应的构件文档说明以方便构件的使用者，但是这些构件的规格说明可能并不是特定用于测试目的，再加上现在COTS构件的大量使用，出于商业利益考虑，往往并不详细，不能为构件使用者测试构件提供足够的帮助。而且这些规格说明很少是形式化的，这也不利于测试过程的自动化。为了得到一份相对比较详细的构件测试规格说明，有必要扩展规格说明的内容，自动提取、生成构件与测试相关的元数据，并加以形式化描述。这样形成的文档将成为构件开发方所提供的构件文档说明的重要补充。为了实现构件测试执行的自动化，本文沿用现有的软件自动化测试技术。由于第三方构件是二进制复用，使用方得不到构件的源代码，构件对使用方而言是黑盒，无法进行代码分析。又若采用捕获/回放方法，那么将会拥有大量测试脚本，并且当构件版本升级时，相应的测试脚本也必须重新录制。因此测试执行的自动化将采用前面第一章提到的测试脚本技术。这就可以分为测试脚本的自动生成与测试脚本的自动运行。其中前者是建立在测试规格说明的基础上的，后者应当能够自动读取独立的测试用例数据。由此可得该构件测试自动化框架的整个流程，如图32所示。开始构件测试计划构件测试规格说明构件测试执行构件测试记录检查构件测试完成度结束图31通用构件测试过程示意图待测构件构件测试元数据自动提取与描述构件测试脚本自动生成构件测试脚本自动运行构件测试结果自动验证与记录图32构件测试自动化框架的总体流程在整个流程中的多个环节都将使用XML语言，因此，接下来将先对XML语言及其在构件测试自动化中的应用作一介绍。32XML语言与构件测试自动化321XML语言及其优点XMLEXTENSIBLEMARKUPLNAGUAGE可扩展标记语言是由W3CWORLDWIDEWEB万维网联盟定义的一种语言，该联盟为互联网制定标准。XML的数据格式表达能力很强，几乎所有的数据结构都可以用XML的形式表达出来，并且可以在任何平台上采用XML语言进行程序开发。XML是一套定义语义标记的规则，这些标记将文档分成许多部件并对这些部件加