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

PAGEPAGEI摘要随着构件的广泛应用，基于构件的软件工程也应运而生，其目标是在一个框架内用即插即用的软件构件——定制构造或者是商业成品（CommercialOff-The-Shelf，COTS）构件——组成应用系统。基于构件的方法使得大型分布式软件系统的开发和维护变得更为简单，可以提高软件的复用性和软件开发效率。但是，复用质量低下的软件构件可能会起到相反的作用，不合理的使用高质量的软件构件也可能带来灾难性的后果。因此需要对构件进行测试。使用软件测试自动化技术提高软件测试的效率已经成为软件测试发展的必然趋势，构件的自动测试也成为一个必不可少的环节。但传统的自动测试技术，由于其设计模式的局限性，已经不能适用于构件的自动测试。因此，迫切需要研究COTS构件自动化测试技术。基于XML的COM构件自动化测试技术是对第三方COM构件进行自动化测试的有效技术。该技术主要包括COM构件测试自动化框架和实现该框架的COM构件自动化测试工具COMCAT(COMComponentAutomatedTest)。整个框架主要由构件测试元数据自动提取与描述、构件测试脚本自动生成、构件测试脚本自动执行、构件测试结果自动验证与记录四个环节组成。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.ItmainlyincludesCOMcomponenttestautomationframeworkandCOMcomponentautomatedtestingtoolCOMCAT(COMComponentAutomatedTest)whichimplementsthatframework.Thewholeframeworkiscomposedoffoursections,whichare,componenttestmetadataautomatedretrievalanddescription,componenttestscriptautomatedgenerating,componenttestscriptautomatedexecuting,componenttestresultsautomatedverificationandlogging.XMLtechniquesarefullyappliedtoeverysectionofcomponenttestautomation.Theframeworkcombinesobject-orientedunittestautomationframeworkxUnitanddata-driventestframeworktogetherandmakessomeimprovements.Italsodesignscomponentmetadatawithplentyofcontentfromcomponentusersandtesters’view.EspeciallyforCOMcomponents,itretrievescomponentmetadataaboutstructuralinformationautomaticallybyaccessingtypelibraryanddescribesthatwithXML.Italsosyntheticallyutilizesseveraltechniquestoassistaccomplishingtheautomationoftestprocess.Anexperimentindicatesthatthesetechniquesareeffectiveandofhighdegreeofautomationandhighreturnoninvestment.Keywords:ComponentTesting;TestAutomation;AutomatedTestingTool;Metadata;TypeLibrary目录TOC\o"1-2"\h\z\u摘要 IIAbstract II1HYPERLINK绪论1.1研究课题的背景与意义 (2)1.2国内外研究现状 (2)1.3本文主要内容及组织 (2)2构件测试及其自动化2.1基于构件的开发 (2)2.2构件测试方法 (2)2.3构件测试的自动化及其工具 (2)2.4本章小结 (2)3COM构件测试自动化框架3.1测试自动化总体框架 (2)3.2XML语言与构件测试自动化 (2)3.3测试脚本生成自动化 (2)3.4测试程序运行自动化 (2)3.5本章小结 (2)4COM构件测试元数据4.1构件元数据 (2)4.2COM构件的类型信息及其提取 (2)4.3类型信息的描述与展现 (2)4.4本章小结 (2)5第三方COM构件自动化测试工具的实现5.1自动化测试工具的实现 (2)5.2实验 (2)5.3本章小结 (2)6总结与展望6.1论文总结 (2)6.2进一步工作展望 (2)致谢 (2)参考文献 (2)1绪论1.1研究课题的背景与意义自从1968年NATO会议首次提出“软件危机”以来，软件工程己经取得大进展，然而这一危机并没有消失。随着计算机应用领域的迅速扩大，软件及复杂性的不断提高，软件危机愈加明显地暴露出来，提高软件生产率成为产业的当务之急。要解决这个问题，软件复用无疑是一个有效的方法。软件复用(SoftwareReuse)是将已有软件的各种有关知识用于建立新的软件,以缩减软件开发和维护的花费[1]。它的主要思想是，将软件看成是由不同功能部分的“组件”所组成的有机体，每一个组件在设计编写时可以被设计成完成同类工作的通用工具。这样，如果建立了可以完成各种工作的组件，编写特定软件的工作就变成将各种不同组件组织连接起来的简单问题，这对于软件产品的最终质量和维护工作都有本质性的改变。从早期的子函数到后来的面向对象的类的概念，软件复用的粒度逐渐变大。但是以类为封装单位的复用不能解决异构互操作问题。构件可以将一组类的组合进行封装，隐藏具体的实现细节，通过接口向外界提供服务。构件可以将复用提高到更高的复用层次。进入20世纪90年代以后，越来越多的软件开发组织在系统开发过程中，开始采用可复用的软件构件[2]。ClemenzSzyperski[3]认为构件是“一个软件单元，具有一组契约或合同规定的接口。构件与它所在的环境/上下文有清晰的依赖关系，并且仅仅与此相关。构件可以被独立配置，以便由第三方进行合成（新的软件）。一个广为接受的定义是：构件是具有符合特定协议的接口的组合单元，它的上下文依赖性是完全显式的，构件可以被独立地部署，并由第三方组合。在与其它构件组合时，不需要修改构件的源代码，只需要修改构件的接口和属性。构件的接口分为两种：一种是构件可以向外界提供的服务的接口，其它构件可以通过这些接口来调用构件提供的服务；另一种是构件期望从其它构件获得服务的接口[2]。目前，工业界主要有三个不同的构件规范，即SUN公司的EJB，Microsoft公司的COM/DCOM[4]，对象管理组织OMG的CORBA[5]。这些技术提供了从构件开发应用系统的通信与协同。其中微软的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的复用思想是：以接口的标准化推动服务的标准化，为复用软件的开发和使用建立规范。在构件广泛应用的潮流中，基于构件的软件工程（Component-BasedSoftwareEngineering，CBSE）[9,10]这个新领域也应运而生，其目标是在一个框架内用即插即用的软件构件（定制构造或者是商业成品（CommercialOff-The-Shelf，COTS）构件[11-13]）组成应用系统。基于构件的软件工程，包括COTS构件的使用，可以减少从头开始的软件开发中常常碰到的一些问题。特别是COTS的使用，被视作一种既能增加可靠性与生产力，又能减少大型系统的交付时间的方式。基于构件的方法使得大型分布式软件系统的开发和维护变得更为简单，可以提高软件的复用性和软件开发效率。但是，过多依赖复用也带来了新的问题，复用质量低下的软件构件可能会起到相反的作用，不合理的使用高质量的软件构件也可能带来灾难性的后果，如阿丽亚娜5号火箭发射失败就是由于未对构件进行升级就复用造成的[14]。Adrita指出构件失效产生的后果大于测试的费用时，就要进行测试。而构件测试与传统的软件测试相比，还有其特殊性[15]：（1）构件测试的语言无关性、跨平台。跨平台的调用会有许多问题。而且不同语言和系统的环境，也会造成对构件的理解上的歧义。例如：当构件的接口函数的实现部分是从其它基类继承来且还有开发者的部分代码时，这样跨平台测试，当返回错误结果时，无法确定是继承关系错误还是开发的代码错误[16]。（2）构件的严格封装性。封装带来测试的障碍。与面向对象和结构化软件的测试不同，接口测试是构件测试的首要任务。因为构件的全局数据是不允许直接访问的，构件内的数据访问一般用Get和Set方法。构件的接口对客户是可见的，但由于接口的说明没有强制性要求，因此并非所有的接口都有详细说明。构件测试要求有一种途径能访问到所有的属性和方法，以便测试到所有的构件状态。（3）构件是二进制代码级的复用。与传统软件的源代码复用不同，构件是二进制代码复用。构件的使用者未必了解构件的源代码，而构件供应商一般仅提供构件的说明。尤其是对于COTS构件，出于商业机密考虑，COTS构件的源代码通常是不可得的。另外，由于构件的描述文档也不是特别详细，在开发高可靠的软件系统时通常需要构件的源代码和详细的描述文档，而且构件使用者对构件功能的理解也会与构件开发者有出入，这就给构件测试带来了难题。（4）构件以代码复用为目标。代码的复用率越高，代码的效益也越高，这一目标决定了构件的健壮性和稳定性要求比其它软件更高。构件的故障不仅影响到开发企业，还影响到以构件为平台的二级或更多级的开发商甚至是使用者，这就要求对构件进行更加充分、更加严格的测试，减少程序的错误。随着软件规模的增加，测试工作量的增大，软件开发周期的缩短，使用软件测试自动化技术提高软件测试的速度和效率就成为了软件测试发展的必然趋势。使用软件测试自动化技术能完成许多手工测试无法实现或难以实现的测试。正确、合理地实施自动化测试，能够快速、彻底地对软件进行测试，从而提高软件质量，节省经费，缩短产品发布周期。另外，自动化测试还能排除一些人为的因素(如遗漏、失误等等)。自动测试技术是测试技术的一个分支，它的研究重点是如何最大可能地进行自动化测试、在哪些方面可以进行自动化以及自动测试工具的开发和使用[17]。目前应用的软件测试工具种类很多，如企业级测试工具WinRunner，性能负载测试工具Load-Runner，单元测试工具CPPUnit、JUnit等，都具备一定的自动测试能力。但从测试原理来看，它们所进行的都是基于源代码的测试，测试人员如果使用这些工具编制自动测试程序，不但要熟悉测试对象的源代码，而且经常需要调试测试脚本，不可避免地造成了工时的延长和交流的冗余[18]。随着构件技术的发展，构件的自动测试成为一个必不可少的环节。但传统的自动测试工具，由于其设计模式[3]的局限性，已经不能适用于构件的自动测试。它们具有如下缺陷：测试工具不能独立完成整个测试过程；编写测试用例是一项繁琐的任务；测试脚本常常需要编写和调试[19]；仍然采用基于源代码的测试模式，要求待测的构件提供特定的测试接口，或者在实现代码中嵌入测试语句，未考虑到COTS构件具有的接口不变性和源码隐藏的特点。它们都不能满足构件的自动测试的需求。因此，迫切需要开发COTS构件自动化测试工具。1.2国内外研究现状1.2.1构件测试的理论基础当前，国内外研究机构在构件可能存在的缺陷、构件的可测性、构件测试的目标、内容、测试中要解决的问题等方面都做了一定的研究，为构件测试的进一步研究打下了理论基础。构件软件集成中会遇到的两类缺陷：服务相关的缺陷(service-related)和结构相关(structure-related)的缺陷[20]。服务相关的缺陷可能是语法缺陷、语义缺陷和非功能缺陷；结构相关的缺陷(即与系统结构相关的缺陷)可能来源于有问题的连接件，有问题的公共基础设施和有问题的拓扑结构[21]。构件的可测试性是设计和测试软件程序及构件的重要概念之一。运用具有良好的可测试性的程序和构件来构建软件，可以简化测试操作、减少测试开销、提高软件质量[22]。在构件工程中，有几种不同的构件可测试性的观点，包括构件可观察性(observability)、构件可跟踪性(traceability)、构件可控制性(controllability)和构件易理解性(understandability)。(1)构件的可观察性:对构件的操作行为、输入参数和输出能较容易地进行观察,设计和定义构件接口在决定构件的可观察性方面扮演着主要角色。(2)构件的可跟踪性:构件应具有跟踪其属性和行为的状态的能力。以前称为行为的可跟踪性,是构件易于跟踪其外部和内部行为；后来则称为跟踪的可控制性,是构件具有易于定制跟踪功能的能力。(3)构件的可控制性:对于一个构件的输入/输出、操作和行为能较容易地进行控制。(4)构件的可理解性:构件提供多少信息及如何呈现[21]。构件测试的最终目标是[23]：(1)检查构件与软件规范是否一致，并完成其功能需求；(2)检查实现的系统是否反映了规范中所描述的结构和交互需求(假定这些需求是正确而且完整的)。与传统软件测试相似，构件软件测试的基本内容包括:(1)单元测试:软件系统中每一个单个的构件都经过测试；(2)集成测试:对由已测试过的构件集成的子系统作为一个实体进行测试；(3)系统测试:对由已测试过的子系统形成的系统作为一个实体进行测试；(4)回归测试:对软件系统所作的任何修改以后都必须进行相应的重新测试。对于测试中要解决的问题，Harrold[24]认为应该从构件提供者和构件使用者两个不同的角度来看待。构件的提供者认为构件相对于使用构件的环境是独立的，所以要用与上下文独立的方式测试构件所有的功能。相反，构件使用者开发的应用程序提供了构件的运行环境，所以构件使用者不把构件看成独立的单元，仅仅考虑与应用程序相关的构件功能。另一个重要的区别是提供者有构件的源代码，而使用者则通常没有构件的源代码[25]。构件开发者面临的测试问题有：(1)测试充分性判据(testadequacycriteria)的可扩展性(scalability)：由于复杂性问题和组合爆炸问题，对小规模程序适用的判据对大规模程序不一定适用。(2)测试数据的产生：由于同样的原因，难以产生合适的测试输入，使得对低层次元素(如分支——定义使用对，需求功能可看作是高层元素)难以达到较高的覆盖率。(3)如何配置构件的测试环境：对单个构件进行测试的环境，与构件在实际系统中运行的环境可能不同。(4)构造测试驱动器和打桩技术：传统的技术是面向特定的工程。但是构件的多样性和其功能的专用化使得传统的技术达不到应有的效力。(5)构件测试的可重用性：对构件的测试应该是可重用的。构件使用者面临的测试问题有：(1)测试充分性判据的可扩展性问题依然存在。(2)构件的测试顺序：如果软件采用分层结构，可以先测试底层构件，因为不需要其他构件提供服务；然后再测试高层构件，所调用到的其他构件都是经过测试的。如果不是分层结构，可能就难以确定测试的顺序。(3)冗余测试问题：通常先对构件进行单独测试，然后使用相同的充分性判据进行集成测试，这就导致有些测试是重复的。(4)源代码是否可用：源代码可用与否导致不同的系统测试方法。(5)编程语言、操作系统平台、硬件结构的混杂性(heterogeneity)：系统使用的构件可能是用不同语言编写的，运行在不同的平台上，这就要求测试方法和工具与平台和语言无关。此外，构件使用者还面临测试分布式软件时的监控问题、事件重构、构件的竞争和死锁、多线程问题、容错测试问题等。1.2.2软件自动化测试目前构件的自动化测试技术还不成熟，因此主要沿用传统的软件自动化测试技术。对于后者，国内外已经做了一些研究，并且引入了自动化测试框架，还开发了不少自动化测试工具。软件测试自动化实现的原理和方法主要有：直接对代码进行静态和动态分析、测试过程的捕获和回放、测试脚本技术[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++测试数据生成工具、ParasoftC++Test等。（3）测试评估工具用于动态测试过程中对测试的内容及测试覆盖性进行评测，为测试的充分性提供依据。常见的测试评估工具有：ATAC、PureCoverage、TestWorks/Coverage等。（4）集成化测试系统它将多种测试工具融为一体,是一种功能较强的测试工具。常见的有：SADAT、MicrosoftTestforWindows、ParasoftInsure++等。（5）测试管理工具它能够用于辅助测试活动或工作的计划、设计、实施、执行、评估和管理。目前,比较有代表性的测试管理工具主要有：RAIDS、TestStudio、TestDirector等。1.3本文主要内容及组织本文主要讨论了第三方COM构件的测试自动化技术，基于XML描述的COM构件元数据——类型信息，利用类xUnit单元测试框架进行测试，并实现了COM构件自动化测试工具原型COMCAT(COMComponentAutomatedTest)。基于上述研究内容，本文各章组织如下：第1章概述了COM构件测试自动化的研究背景和意义，并介绍了国内外目前在与此相关的构件测试和软件自动化测试方面所做的基础性工作。第2章详细介绍了构件的开发、测试方法、测试自动化的途径和工具的开发。第3章在现有构件测试及其自动化研究的基础上，进行比较、分析，考虑到第三方COM构件的特点，设计了一套COM构件自动化测试的框架，介绍了该测试框架的整个流程及其中各步骤中所使用的主要方法和技术。第4章重点介绍了针对第三方COM构件的源码未知、文档缺乏的难点，采用的自动从类型库中提取COM构件类型信息，并以组织良好、可扩展性强的XML文档扩展、描述，以友好的树形视图展现的技术，其中类型信息为测试提供了依据，而XML文档便于自动化测试过程。第5章对前面设计的COM构件测试自动化框架进行了实现，开发了自动化测试工具原型COMCAT，给出了其系统结构、数据结构、模块设计与实现，并进行了实验分析。第6章对全文进行总结并展望了未来的工作。最后是致谢和参考文献。

2构件测试及其自动化2.1基于构件的开发随着网络和软件技术的不断发展，基于构件的软件开发(Component-BasedSoftwareDevelopment，CBSD)受到人们的高度重视，它是一种在模块化系统、结构化设计和面向对象技术的基础上发展起来的新的软件开发方法。CBSD是在一定构件模型的支持下，复用构件库中的一个或多个构件，通过组合手段高效率、高质量地构造应用软件系统的过程[9]。CBSD通过提高系统的可扩展性和可维护性来减少软件开发的费用，更快的整合系统，并能有效的降低大型系统的维护和升级压力[33]。基于构件的软件开发过程与传统的面向过程或面向对象的软件开发过程有所不同。传统的软件开发过程或面向对象的软件开发过程是围绕用户需求进行需求分析和设计，软件完全根据用户的需求定制，称之为基于需求的软件开发过程。而基于构件的软件开发过程，由于从商业市场上购买的构件并不是为某一个固定用户定制的，或者构件实现的功能并不是完全与用户的要求相吻合，因此，基于构件的软件开发过程是在用户需求、软件设计、项目管理和构件市场之间的一个平衡过程。面向构件的软件开发是指软件体系结构可重组以及软件成分可重用的系统开发方法。从工程化与过程管理的角度讲，面向构件的软件开发过程可定义为4个阶段：[34]（1）分析阶段。从特定应用需求出发，通过领域分析，进行共性需求识别、领域对象抽象和领域知识获取，建立概念层的领域模型，产生应用系统的需求规格说明，这一阶段的成果是领域模型。（2）设计阶段。设计阶段的主要任务是基于领域模型寻求软件解决方案，包括构架设计模型和构件设计模型。在这一阶段中，首先检索构架库中存放的面向特定领域的构架，寻找可复用的构架，或者对其进行必要的适应性修改；在无可复用构架时，创造适合该应用环境的新构架，并进行标准化描述后入库，以备将来的复用。然后，在构架的指导下，把系统功能分解到相应的构件和连接件，并定义系统中构件之间的关系。这一阶段的成果是构架模型和构件模型。（3）实现阶段。根据领域应用开发或直接重用的需要，进行领域实现。包括领域构件的识别、设计、编码和测试等局部过程集成，系统构件的分类、检索、引用和构件库的维护，领域构件与系统构件的演化、实例化、组合和应用原型的动态生成等领域框架整体集成，从而建立符合领域应用的各种物理模型。这一阶段的成果是软件构架和代码级别的构件。（4）集成阶段。通过对实现阶段所生成的产品进行组装和运行模拟(正向)、设计优化(逆向)等措施，针对领域软件原型进行可用性评价和可重构性验证，并对符合确认测试条件的应用系统进行全局封装和使用规范生成，最终获得一个真正构件化的目标系统。随着CBSD的逐渐成熟，网络上出现了大量的COTS构件产品，在基于COTS构件的系统开发中，系统开发的观念被组装和集成现有构件的观念所取代，CBSD强调以构件集成为中心进行系统的构造。2.2构件测试方法对应于构件的测试，应从接口、信息和实现三个方面加以实施。构件测试可以分为接口测试、状态测试与实现测试[35]。构件的接口测试实际上是验证构件对外需求接口与提供接口是否与构件规范说明一致，功能是否正确，是否通过接口实现与其它构件的交互。构件的状态测试是验证构件内部状态是否正确，在各种条件下包含的属性、变量值是否刻画了构件的当前状态。构件的实现测试是验证构件功能实现的正确性、健壮性。在大多数情况下，对一个构件的测试，不仅仅是测试其接口、状态或实现,往往是三者都要加以测试，并且每一种测试与其它两种测试是相辅相成的：构件通过接口对外提供的功能是否正确，显然要取决于其状态和实现；构件的状态往往通过接口体现；构件的实现建立在构件的接口规范基础上，并且可以改变构件的状态。三种测试只是测试出发点的不同侧重因素，在实际测试中，是融合在一起的。对于任何工程产品都可以使用黑盒测试或白盒测试两种方法之一进行测试。软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看作一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看作一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。从构件接口测试的角度出发，往往采用黑盒测试方法，通过接口调用输入数据得到结果，进行与接口规范的比较得到测试报告。在设计接口测试输入参数时，除了使用传统的等价类划分、边界值分析等方法外,还要考虑到接口的前置条件和后置条件等约束。从构件状态与实现角度出发，采用白盒测试方法，通过分析构件的结构组成和实现细节产生测试用例，然后加以测试。构件测试与传统测试过程中的单元测试大体类似，由那些验证构件的实现与构件的规格说明书描述是否一致的相关活动组成。传统的软件单元测试是在开发时由开发人员或者是专门的测试人员进行的，常见的单元测试方法有根据前置条件和后置条件设计测试用例以及根据程序运行状态转换图来构建测试用例等方法。构件软件单元测试的现有研究方法多是在现有单元测试方法的基础上，针对构件的特点进行了一定的改进。目前用于构件测试的主要方法有以下几种[2]：（1）构件验证构件验证[36](CertificationofComponent)方法，首先对构件进行基于系统运行剖面的黑箱测试，确保构件完成应有的功能，如果达不到就不使用它；然后把构件放进系统中，进行系统级的错误注入，目的是揭示特定构件失效会对系统造成多大的危害，如果系统能经得起考验就认定可以使用该构件，否则要对构件进行包装(wrap)，限制某些功能的使用，再重新放进系统进行验证。仅仅对构件进行黑箱测试不足以保证可靠性，某些安全性问题(如恶意代码、Trojan木马)也难以检测出来。如何提供足够的测试用例进行系统测试也是个大问题。（2）内置测试(built-intest)内置测试方法[37]通过在构件的源代码中添加了用于内置测试的函数，事实上成为一种特殊的构件，这种构件运行时具有两种模式：正常模式及维护模式。维护模式下可以调用构件内置的测试函数来测试构件，正常模式下不会调用内置的测试函数。这种方法增强了构件的可测试性，简化了构件维护的正确性、可适应性、完整性、可预防性和重设计性，而且适应范围广，除了构件外，还适用于类和对象，但是该方法需要构件源代码。（3）回溯测试方法(Retrospectors)回溯测试方法[38]利用Retrospectors来记录构件执行的历史信息，以便测试者可以利用这些测试信息。构件中的Retro类与JavaBeans中的内省类(IntrospectorClass)相似。具有Retro类的构件有三种不同的模式：设计时模式、测试时模式和执行时模式。构件中的Retrospector可以手工创建，也可以通过为构件添加一种所谓的Retro-spec规约来自动生成。该方法的优点在于，即使没有源代码，构件使用者也可以使用代码覆盖分析的方法测试构件，因为构件内部的Retrospector可以记录构件的执行情况。但由于该方法不是构件的标准，构件提供者不一定提供这项功能。（4）构件包装方法(Wrapper)构件包装方法[39]通过为构件添加一层保护的包装层，以探测构件执行时的错误及异常行为，并提供异常处理机制。这种保护型的包装层能够处理典型的构件运行错误，比如缺少信号、信号的变化范围超过了规定的限度，信号振动等。该方法可以提高商业构件的可靠性。该方法的局限性在于设计、实现及评估构件包装层可能是代价不菲的，而且构件包装层不能过于复杂，否则就可能与提高构件的可靠性的初衷相反。（5）TDSTDS（Technologies，Developmentframeworks，andqualityassuranceSchemes）方法[40]的第一步确定构件的接口；第二步，确定接口中提供的方法（method）和异常处理（exception），哪些是必须进行覆盖的；第三步，确定这些方法和异常处理函数的参数，用突变算子(mutantoperators)对其进行处理；第四步，根据构件需求(requirementofthecomponent)创建测试集(testset)，然后运行测试；第五步，去除测试中发现的错误(error)；第六步，扩充测试集达到100％的接口覆盖率(interface-basedcoveragemeasure)。这个方法的特点是提出了构件软件测试的充分性条件，并由此生成、检验测试用例；但提出的测试充分性条件还需要与传统的测试充分性条件进行比较，例如对比不同的方法，看谁能更有效地检测出软件中播种的错误(seedederror)。（6）构件元数据方法（Componentmetadataway）构件元数据方法[41]是利用构件的开发者提供的构件元数据meta-data来分析和测试构件，这些数据包含不同种类的信息并且有明确的上下文环境，由构件提供者在开发构件时嵌入这些信息，构件提供者还可以根据构件使用者的需要，增加相应的信息。构件元数据既可以描述构件的静态特性，也可以描述其动态特性，可以看作是大多数构件模型中的内省机制的一般形式。构件使用者在测试构件时，可以通过访问构件元数据获得相应的信息。该方法增加了程序分析的精确度，为构件使用者测试构件提供了方便性。目前的构件标准DCOM和EJB已经提供了通过元数据来为构件使用者提供附加信息的机制，但是制定相应独立于构件开发者的构件元数据的标准比较困难，缺乏第三方构件提供者的支持，目前该方法还只能用来测试小型程序。（7）序列生成技术序列生成技术[42](sequencegenerationtechnique)，这种方法是两层结构(phase)：①是对每个构件单独考虑并定义methodsequences，包含三步，用数据流方法分析构件包含的方法，然后使用符号执行技术得到每个方法的形式化规约，最后利用前两步得到的信息进行自动推导得到方法调用序列。通过执行所有的方法序列就可以测试这个构件；②通过把每个构件的methodsequence结合起来，研究渐增集成测试问题。通过分析构件之间的依赖关系，按照添加附加代码最少的原则确定集成的顺序，然后按照这个顺序成对集成构件(客户和服务器)。使用一种backward-chained推导方法生成methodsequences。这种方法的优点是考虑到了构件集成的顺序，可以减少重复测试。但是随着被测软件规模的扩大，方法的复杂度可能会大大增加。（8）程序切片、控制依赖性分析和数据流测试程序切片、控制依赖性分析和数据流测试法[43](Anapproachuseprogramslicing，control-dependenceanalysisanddata-flowtesting)，首先由构件的提供者对构件进行充分测试，并提供summaryinformation；构件使用者通过得到的summaryinformation可以进行有效的系统测试，而不需要得到构件的源代码。作者举了三个应用方向，程序切片(programslicing)、控制依赖性分析(control-dependenceanalysis)和数据流测试。根据构件提供者提供的不同附加信息，构件使用者可以进行不同领域的分析。这种方法的缺点是summaryinformation并不属于任何现有构件规范的标准，要得到构件提供者的支持难度比较大。2.3构件测试的自动化及其工具随着构件软件的复杂性增加，基于构件的自动测试生成变得越来越复杂。原因是：构件支持GUI使其增加了难度；构件支持多媒体使其增加了复杂度；分布式的构件更增加了其通信等方面的难度。因此，作为一个好的基于构件的自动测试工具，下面的功能是测试人员真正需要的：定义好的黑盒测试模型和充分的测试标准、系统的方法和工具支持基于领域的测试生成[44]。构件的开发者可沿用已经产品化的面向对象软件测试工具对构件进行单元测试,这些工具有C++Test，Panorama++和ParaSoftJTest等。构件测试可把探针模型和构件有效地结合起来，然后可用上述测试工具[45]。专门的构件测试工具主要有：1、Microsoft系列的OLE/COMViewer、OLEclientOLEserver测试系列、ActiveXcontroltest等。这些工具都是黑盒测试工具。2、JavaBean系列的工具。构件测试工具还很不成熟，主要用于构件的黑盒测试。2.4本章小结本章详细介绍了构件技术，包括CBSD这种新的软件开发方法及其过程，然后介绍了构件的测试方法，将其分为接口、状态和实现三种类型的测试，并与黑盒测试、白盒测试相结合，接着对于构件测试，将其与传统的单元测试类比，介绍了构件验证、内置测试、回溯测试方法等目前的主要研究成果，最后谈到了构件自动化测试工具的目标和现有的一些构件测试工具。通过这章的介绍可以看出：增强构件的可测试性；建立通用的、可重用的测试平台；实现构件的测试方法，开发出真正专门、有效的构件自动化测试工具，这些都是亟待解决的问题。

3COM构件测试自动化框架3.1测试自动化总体框架对于软件构件测试，英国标准委员会（BritishStandard）已经制定了标准BS7925-2，该标准旨在帮助测试人员提高测试过程的质量，在此基础上提高软件的质量[46]。它描述了软件构件的通用动态测试过程、测试用例设计技术和测试度量技术。标准BS7925-2尽管现在是由英国标准协会BSI出版的，但是填补了目前软件工程领域中构件测试相关的空白，未来可能成为国际标准。该测试标准给出的通用动态测试过程如图3.1所示。本文主要研究其中的构件测试规格说明和构件测试执行部分。构件测试结果的验证与记录也可实现自动化。上面提到的标准BS7925-2规定每个将要被测试的构件都须有规格说明，以使得有可能从给定的输入集合获得期望的输出。尽管发布构件二进制代码的同时一般都有相应的构件文档说明以方便构件的使用者，但是这些构件的规格说明可能并不是特定用于测试目的，再加上现在COTS构件的大量使用，出于商业利益考虑，往往并不详细，不能为构件使用者测试构件提供足够的帮助。而且这些规格说明很少是形式化的，这也不利于测试过程的自动化。为了得到一份相对比较详细的构件测试规格说明，有必要扩展规格说明的内容，自动提取、生成构件与测试相关的元数据，并加以形式化描述。这样形成的文档将成为构件开发方所提供的构件文档说明的重要补充。为了实现构件测试执行的自动化，本文沿用现有的软件自动化测试技术。由于第三方构件是二进制复用，使用方得不到构件的源代码，构件对使用方而言是黑盒，无法进行代码分析。又若采用捕获/回放方法，那么将会拥有大量测试脚本，并且当构件版本升级时，相应的测试脚本也必须重新录制。因此测试执行的自动化将采用前面第一章提到的测试脚本技术。这就可以分为测试脚本的自动生成与测试脚本的自动运行。其中前者是建立在测试规格说明的基础上的，后者应当能够自动读取独立的测试用例数据。由此可得该构件测试自动化框架的整个流程，如图3.2所示。图3.1通用构件测试过程示意图图3.2构件测试自动化框架的总体流程在整个流程中的多个环节都将使用XML语言，因此，接下来将先对XML语言及其在构件测试自动化中的应用作一介绍。3.2XML语言与构件测试自动化3.2.1XML语言及其优点XML(ExtensibleMarkupLnaguage：可扩展标记语言)是由W3C(WorldWideWeb：万维网联盟)定义的一种语言，该联盟为互联网制定标准。XML的数据格式表达能力很强，几乎所有的数据结构都可以用XML的形式表达出来，并且可以在任何平台上采用XML语言进行程序开发。XML是一套定义语义标记的规则，这些标记将文档分成许多部件并对这些部件加以标识。它也是元标记语言，即定义了用于定义其他与特定领域有关的、语义的、结构化的标记语言的句法语言。XML文档内容的基本单元是元素，它的语法格式如下：<标签>文本内容<标签>元素由起始标签、元素内容和结束标签组成。用户把要描述的数据对象放在起始标签和结束标签之间。无论文本内容有多长或者多么复杂，XML元素中还可以再嵌套别的元素，这样使相关信息构成等级结构。除了元素，XML文档中能出现的有效对象是：处理指令、注释、根元素、子元素和属性。XML1.0规定了XML文档的结构和定义，提供了对存储布局和逻辑结构加以限制的机制。所有的XML文档都必须符合XML的语法限制(SyntaxConstraint)，要求格式良好(well-formed)；在特定的应用中，数据本身具有含义上、数据类型上和数据关联上的限制，也就是语义限制(SemanticConstraint)，即要求文档是有效的(valid)。其中XML文档的有效性是指一个XML文档应当遵守DTD或是Schema的规定。有效的XML文档肯定是格式良好的。XML文档的基本结构由序言部分和一个根元素组成。序言包括了XML声明和DTD(或者是XMLSchema)，DTD和XMLSchema都是用来描述XML文档结构的，也就是描述元素和属性是如何联系在一起的。（1）DTD：定义数据如何被格式化。它必须定义XML文档所允许的每个元素、每个属性以及每个元素可以接受的属性值、每个元素的嵌套和事件以及任何可能的外部实体。XML通过DTD定义数据的结构，使这些数据被许多不同的程序以多种方式使用。（2）XMLSchema：是W3C为了弥补DTD存在的问题和局限性而推出的一个工作草案。除了能更精确地处理XML结构约束的表示之外，XMLSchema还可以为约束数据的处理提供一个XML样式。Schema实际上是XML文档，这些文档带有标准格式，并且是有效的。XMLSchema与DTD相比具有许多优势：XMLSchema是一个XML文档，这意味着可以像处理任何其它文档一样处理模式；XMLSchema支持更多的数据类型，还可扩展出新的数据类型；XMLSchema还有更强的表达能力。XML将SGML的丰富功能与HTML的易用性结合起来，以一种开放的自我描述方式定义数据结构，在描述数据内容的同时能突出对结构的描述，从而体现出数据之间的关系。下面来介绍XML几个主要的优点：（1）简便的数据交换。在XML中，数据和标记均以可配置的文本格式保存。可以用XML编辑器编写XML文档，一旦某些地方有错误，完全可以直接检查和修改文档。同时，对于大量的数据，使用XML还是高效的。（2）自定制标记语言。可以使用XML定制自己的标记语言，这反映出XML强大的功能，例如化学标记语言(CML)，允许用图形描述复杂的分子式。不仅如此，当别人基于XML创建了标记语言，还可以很容易的添加使用这个扩展。（3）自描述数据。XML在基本水平上使用的是非常简单的数据格式。可以用100%的纯ASCII文本来书写，也可以用几种其他定义好的格式来书写。ASCII文本是几乎不会“磨损”的，丢失一些字节甚至是相当多的字节，剩下的数据还是可以读取的。从高水平上来说，XML是自描述的。（4）结构化和综合性的数据。XML的另一个功能强大之处在于，使用者不仅可以指定数据，还可以指定数据的结构，并可以将不同的元素组合成其它的元素。这一点对于处理重要的复杂数据极为重要。3.2.2XML文档的读写这里介绍两个XML文档读写的API（应用编程接口）标准：SAX和DOM。（1）SAX(SimpleAPIforXML)：SAX是读取和操作XML数据的快速、轻量的方法。SAX是一个基于事件的处理器，允许处理元素、属性以及出现在原先文档中的其他数据。由于具有这样一种体系结构，SAX是一个只读的系统，但是那并不会阻止使用数据。这种处理的优点非常类似于流媒体的优点。分析能够立即开始，而不是等待所有的数据被处理。而且，由于应用程序只是在读取数据时检查数据，因此不需要将数据存储在内存中。这对于大型文档来说是个巨大的优点。事实上，应用程序甚至不必解析整个文档；它可以在某个条件得到满足时停止解析。一般来说，SAX比DOM快许多。（2）DOM（DocumentObjectModel：文档对象模型）：是以层次结构组织的节点或信息片断的集合。这个层次结构允许开发人员在树中导航以寻找特定信息。分析该结构通常需要加载整个文档和构造层次结构，然后才能做任何工作。由于它是基于信息层次的，因而DOM被认为是基于树或基于对象的。DOM是设计用于使用XML数据的、与语言和平台无关的API。这是一个基于树的API，它将所有数据作为节点的父子层次加载到内存中，这些节点可以是元素、文本、属性或其他节点类型。DOMAPI允许开发人员读取、创建和编辑XML数据。DOM提供了一组丰富的功能，可以用这些功能来解释和操作XML文档，但使用它们是有代价的。DOM存在以下几个问题：DOM构建整个文档驻留内存的树，如果文档很大，就会要求有极大的内存；DOM创建表示原始文档中每个东西的对象，包括元素、文本、属性和空格，如果只需关注原始文档的一小部分，那么创建那些永远不被使用的对象是极其浪费的；DOM解析器必须在代码取得控制权之前读取整个文档，这对于非常大的文档，会引起显著的延迟。这些仅仅是由文档对象模型的设计引起的问题，撇开这些问题，DOMAPI是解析XML文档非常有用的方法。3.2.3XML在构件测试自动化框架中的应用XML由于其所具有的上述优点，特别适合于提高构件测试的自动化水平。它贯穿了本章所设计的构件测试自动化框架的整个流程，如图3.3所示。图3.3基于XML的构件测试自动化框架文档关系图下面对各个XML文档逐一作介绍。（1）构件测试元数据XML文件本文所要提出的构件元数据的表示方式，其目的是：获得构件足够丰富而且形式规范的信息，并能以一种通用的方式让构件使用者获取测试所需的信息，进而方便测试的自动化。元数据具有一定的通用性，需要用一种标准的形式来描述，以满足不同用户的测试需求。目的是探索一种合适的构件元数据表示方式。该构件元数据表示方式适合描述构件元数据信息，并且这种表示方式应该可以让构件使用者或者计算机工具很方便处理构件元数据。XML语言具有前面所提到的很多优点，并且其具有很好的扩展性，数据搜索准确，软硬件平台无关，可以为不同的应用程序所共享，在XML文件中定义的描述符还可以用于构件自动化测试的过程。因此，本文采用XML描述构件元数据。使用XML文件格式表示的构件元数据可以跨平台共享和交换，实现了信息的可移植性，提高了构件数据交换的通用性，也便于从中提取与测试相关的数据以及加工处理构件元数据，为构件测试方法的研究提供了有力的支持。有关构件的元数据及其XML文档的设计，将在下一章详细介绍。（2）构件测试用例XML文件在进行构件测试的时候，必须根据构件测试规格说明确定测试目标，即测试需求的集合，再根据这些测试需求可以精心构造出一组测试用例。这组测试用例的数量和质量将决定构件测试的成本和有效性。在本文设计的构件测试自动化框架中，构件测试规格说明是由自动提取的构件元数据辅助生成的，因此，构件测试用例也应当是参考构件元数据进行设计。当然，构件开发方也提供了一份构件测试规格说明，其中有一些指定的输入和预期输出，可以直接作为测试用例。但是，构件开发方提供的文档通常是不详细的，而为了可靠地使用构件，必须对构件进行充分的测试，需要大量、有效的测试用例，这就只能依靠分析构件的元数据来进行设计。因此，构件元数据才是设计测试用例的主要依据。传统的手工软件测试方法，测试用例一般用WORD文档或Excel表的形式表示，测试人员对照测试用例逐个执行。而要实现构件测试的自动化，必须使测试驱动程序能够直接读取测试用例文件，并自动执行。XML语言强大的数据描述能力和方便快捷的解析手段，使XML语言成为构件测试的最佳用例描述语言。对于COM构件来说，构件的接口结构信息是非常重要的元数据。而COTS构件通常是源代码不可得、文档不详细的，因此只能采用对接口的黑盒测试策略来设计测试用例。常用的基于接口参数的黑盒测试用例选取方法是对每个接口参数采用边界值分析法和等价类划分法等选取一组测试用例，然后在这些取值组合中随机选取一组测试用例。如：对整型可取其默认值、典型值、边界值和边界附近的值，对字符串型则可对其长度取边界值。另外，有时预期输出无法得到，如对字符串长度越界取值输入时，可观察构件执行时是否抛出异常。这样产生的测试用例从两个方面来讲是不完备的：测试用例仅覆盖了单个参数的边界值情况，对于多个参数组合的情况没有考虑；测试用例仅覆盖了单个接口的测试情况，没有考虑多个接口组合构成测试场景的情况。这种方法产生的测试用例虽然不是完备的，但简单易行，在一定程度上减少了设计测试用例的工作量。下面给出一个实现了加法计算的简单COM构件simple.dll的测试用例XML文件：<?xmlversion="1.0"encoding="utf-8"?><TestSuitescomponent-name="simple.dll"> <TestSuitecoclass-name="CMath"> <TestMethodinterface-name="IArithmetic"method-name="Add"> <TestCase> <In> <Parametername="p1"type="long"> 1 </Parameter> <Parametername="p2"type="long"> 2 </Parameter> </In> <Out> <Parametername="sum"type="long"> <ExpectedValue> 3 </ExpectedValue> </Parameter> </Out> </TestCase> <TestCase> <In> <Parametername="p1"type="long"> -1 </Parameter> <Parametername="p2"type="long"> 1 </Parameter> </In> <Out> <Parametername="sum"type="long"> <ExpectedValue> 0 </ExpectedValue> </Parameter> </Out> </TestCase> </TestMethod> <TestMethodinterface-name=""method-name=""> <TestCase></TestCase> </TestMethod> </TestSuite></TestSuites>其中，一个COM构件对应一个TestSuites，每个CoClass对应一个TestSuite，每个待测试的方法对应多个测试用例。每个测试用例给出一组输入参数和预期输出参数（预期输出参数也可为空），每个参数指出其名字和类型。此测试用例XML文件中的输入参数和预期输出参数既可以自动生成也可手动填写，测试驱动程序读取测试用例到测试脚本中时可以使用前面提到的XML文档读写的API，简单方便。（3）测试日志XML文件测试日志是对测试结果的描述，记录测试的执行情况，测试人员通过察看测试日志来确定测试是否通过。测试日志采用XML语言来表示。测试日志XML文件如下所示：<?xmlversion="1.0"encoding="utf-8"?><Log> <TimeStamp> <Date/> <Time/> </TimeStamp> <Content> <Testcoclass-name=""interface-name=""method-name=""> <Input> <Parameter/> </Input> <Output> <Parameter/> </Output> <UnexpectedException> <Type> EXCEPTION_ACCESS_VIOLATION </Type> <Description/> </UnexpectedException> <Status> Failed </Status> </Test> <Test/> <Summary> <TestsCount/> <PassedCount/> <IgnoredCount/> <FailedCount/> </Summary> </Content></Log>日志中，每次构件的测试都给出时间戳，即完成测试时的准确日期、时间。接下来，对每个被测方法，给出报告，包括方法名、方法所属的接口名、实现该接口的CoClass名、测试时的输入和输出参数、测试的结果状态。其中，输入和输出参数的描述与测试用例XML文档中的相似，只不过输出参数为实际输出值，而不是指期望值。如果测试中发生意外的异常，日志还将记录异常的类型和描述信息。测试的结果状态则包括通过（Passed）、忽略（Ignored）、失败（Failed），分别对应于输出符合期望、方法跳过未测试、输出不符合期望或发生意外异常三种情况。最后给出此次构件测试的摘要，包括测试方法总数、通过数、忽略数和失败数。测试者既可对单个方法失败分析原因、采取措施，又可对该构件的整体质量有个大致的了解。（4）测试项目配置XML文件测试项目配置文件用于组织项目中各种文件的路径信息，相当于测试项目的全局环境变量，也用XML格式对其描述：<?xmlversion="1.0"encoding="utf-8"?><Configuration> <ProjectPathdirectory-name=""/> <COMComponentfile-name=""/> <ComponentMetadatafile-name=""/> <TestCasefile-name=""/> <TestScriptfile-name=""/> <TestLogfile-name=""/></Configuration>其中保存了项目路径、COM构件、构件元数据、测试用例、测试脚本、测试日志的引用信息。在构件测试自动化框架的流程中，各个阶段都需要对其中的内容进行读写。3.3测试脚本生成自动化3.3.1构件单元测试框架要在测试自动化框架下进行基于脚本的测试，设计什么样的测试脚本就取决于本文所选取的测试自动化框架。在单元测试领域最有名的这样的框架就是xUnit框架。本文的构件测试自动化框架也将主要基于xUnit框架。xUnit框架是测试驱动开发（Test-DrivenDevelopment，TDD）软件开发方法中首先推出的。测试驱动开发是近年来兴起的一种软件开发方法。TDD是极限编程（eXtremeProgramming，XP）思想的一种主要实践，可以让开发人员有效地开发出高品质、经过完整测试的程序。“测试先行”是TDD的重要思想。TDD一改传统开发模式中单元测试在编写代码之后进行，将单元测试移到正式编码之前，以不断的测试来推动代码的开发，这样，既简化了代码、降低了开销，又保证了软件质量、提高了开发效率。测试框架是TDD的关键，尤其是在需要用大量测试来实现需求的情况下。如果完全靠手工来执行测试，会变成一个花费大量时间而且单调无味的工作。利用测试框架对测试进行自动验收，可以让开发人员简单地进入测试接口，输入相关的输入并得到期望的输出。TDD在实际应用中，关注的是函数的入口与出口，而不是函数的内部逻辑本身。xUnit框架是自动化手写脚本的开源测试自动化框架家族。随着xUnit框架和TDD开发方法越来越流行，使得目前大多数广泛使用的编程语言都至少有xUnit的一种实现，比较流行的有JUnit（Java），SUnit（Smalltalk），CppUnit（C++），NUnit（所有.NET语言），runit（Ruby），PyUnit（Python），VbUnit（VisualBasic）等。xUnit框架的总体设计依赖于几个组成部分：（1）测试固定设施（TestFixture）测试固定设施是一个测试运行所需的前置条件或状态的集合，也被称作测试上下文。通常它至少包含所测试的方法所属类的一个实例。（2）测试套装（TestSuites）一个测试套装就是共享相同的固定设施的测试的集合。（3）测试执行（TestExecution）一个单独的单元测试的执行如下进行：setupsetup();……/*测试主体*/……teardown();setup()和teardown()方法用来初始化和清理测试固定设施。（4）断言（Assertions）断言是验证被测试单元行为的函数或宏。它被用于构造自检查的测试。典型的断言失败将抛出一个异常，同时退出当前测试的执行。另外还有测试驱动（TestRunner），它负责驱动TestSuites的执行。主要有图形和命令行两种方式。它要进行测试方法发现，选择一个或多个测试运行。所有xUnit家族成员都实现了基本特征集合，它们提供了执行下面任务的方式：（1）指定一个测试为测试方法；（2）以断言方法调用的形式在测试方法中指出期望的结果，通过比较实际输出与期望结果是否相等，对测试结果进行验证；（3）将多个测试集中到可一次运行的测试套装（TestSuite）中；（4）运行一个或多个测试来获得测试运行结果报告。每个测试由一个实现了四阶段测试的测试方法表示，如图3.4所示。这是从测试者视角所见到的静态测试结构，是“编译时视图”。四阶段为：（1）建立（Setup）建立测试固定设施（TestFixture）。（2）执行（Exercise） 通过与公共或私有接口中的方法交互运行被测软件（SoftwareUnderTest，SUT）。（3）验证（Verify）通过调用断言方法验证期望结果是否出现。图3.4xUnit框架四阶段测试（4）拆卸（Teardown）拆卸测试固定设施。对构件中方法的测试通常有着相同的测试逻辑和稍有不同的系统输入，因此考虑将测试逻辑与测试用例相分离，这样一来，既获得了较好的测试覆盖，又能最小化需要编写与维护的测试代码量。因此，不能简单地依赖于xUnit框架。本文设计的构件测试自动化框架将对xUnit框架进行改进，把xUnit框架与前文提到的数据驱动测试的策略结合起来。数据驱动的测试框架定义了一种用于测试的高级语言，并用数据驱动测试解释器实现该语言，读取测试用例数据，执行测试。Fit就是一种开源的数据驱动的测试框架。Fit通常被用来自动化用户测试。Fit包含两部分：框架、用户建立的固定设施。Fit框架是一个通用的数据驱动测试的解释器，它读取输入文件并找到其中全部表格。Fit固定设施则是Fit调用的适配器，来解释数据表格并调用被测软件的方法。xUnit框架是单元测试框架，而数据驱动的测试框架则适合于用户测试。第三方COM构件则需要用户对其进行黑盒单元测试，因此将二者结合切实可行。为了应用数据驱动的测试策略，本框架设计了单独的测试用例XML文件，用来存储输入和期望值。这些数据将被传递到测试脚本中。这样，原先的测试就成为参数化测试，由测试驱动担当数据驱动测试解释器的角色，向测试脚本传递参数，包括输入值和期望值。而共同的测试逻辑则包括测试方法的调用和断言的调用。在具体实现两者的结合时，最简单的方法是在测试方法中包含一个循环来从测试用例文件中读取输入数据值和期望结果的集合。但这将导致一个单独的测试用例对象带有许多断言。由此而来的结果是：（1）执行的所有测试用例将被视作一个测试，这样将减少执行的测试的计数。（2）测试将在第一个失败处停止。这正是xUnit框架对于用户测试存在的不足。这个缺点饱受那些想使用xUnit自动化多步用户测试的人们的批评。用xUnit框架进行构件测试，对于