基于XML的COM構(gòu)件自動(dòng)化測(cè)試技術(shù)研究

PAGEPAGEI摘要隨著構(gòu)件的廣泛應(yīng)用，基于構(gòu)件的軟件工程也應(yīng)運(yùn)而生，其目標(biāo)是在一個(gè)框架內(nèi)用即插即用的軟件構(gòu)件——定制構(gòu)造或者是商業(yè)成品（CommercialOff-The-Shelf，COTS）構(gòu)件——組成應(yīng)用系統(tǒng)。基于構(gòu)件的方法使得大型分布式軟件系統(tǒng)的開(kāi)發(fā)和維護(hù)變得更為簡(jiǎn)單，可以提高軟件的復(fù)用性和軟件開(kāi)發(fā)效率。但是，復(fù)用質(zhì)量低下的軟件構(gòu)件可能會(huì)起到相反的作用，不合理的使用高質(zhì)量的軟件構(gòu)件也可能帶來(lái)災(zāi)難性的后果。因此需要對(duì)構(gòu)件進(jìn)行測(cè)試。使用軟件測(cè)試自動(dòng)化技術(shù)提高軟件測(cè)試的效率已經(jīng)成為軟件測(cè)試發(fā)展的必然趨勢(shì)，構(gòu)件的自動(dòng)測(cè)試也成為一個(gè)必不可少的環(huán)節(jié)。但傳統(tǒng)的自動(dòng)測(cè)試技術(shù)，由于其設(shè)計(jì)模式的局限性，已經(jīng)不能適用于構(gòu)件的自動(dòng)測(cè)試。因此，迫切需要研究COTS構(gòu)件自動(dòng)化測(cè)試技術(shù)?；赬ML的COM構(gòu)件自動(dòng)化測(cè)試技術(shù)是對(duì)第三方COM構(gòu)件進(jìn)行自動(dòng)化測(cè)試的有效技術(shù)。該技術(shù)主要包括COM構(gòu)件測(cè)試自動(dòng)化框架和實(shí)現(xiàn)該框架的COM構(gòu)件自動(dòng)化測(cè)試工具COMCAT(COMComponentAutomatedTest)。整個(gè)框架主要由構(gòu)件測(cè)試元數(shù)據(jù)自動(dòng)提取與描述、構(gòu)件測(cè)試腳本自動(dòng)生成、構(gòu)件測(cè)試腳本自動(dòng)執(zhí)行、構(gòu)件測(cè)試結(jié)果自動(dòng)驗(yàn)證與記錄四個(gè)環(huán)節(jié)組成。XML技術(shù)被充分應(yīng)用到構(gòu)件測(cè)試自動(dòng)化的各個(gè)環(huán)節(jié)。該框架將面向?qū)ο髥卧獪y(cè)試自動(dòng)化框架xUnit與數(shù)據(jù)驅(qū)動(dòng)的測(cè)試框架加以結(jié)合，并且做了改進(jìn)。該框架還從構(gòu)件使用者和測(cè)試者的角度設(shè)計(jì)了內(nèi)涵豐富的構(gòu)件元數(shù)據(jù)，并且針對(duì)COM構(gòu)件，通過(guò)訪問(wèn)類(lèi)型庫(kù)來(lái)自動(dòng)獲取構(gòu)件結(jié)構(gòu)信息元數(shù)據(jù)，并用XML描述。該框架還綜合運(yùn)用多種技術(shù)輔助實(shí)現(xiàn)測(cè)試過(guò)程的自動(dòng)化。實(shí)驗(yàn)表明，該技術(shù)有效、自動(dòng)化程度較高、投入回報(bào)率較高。關(guān)鍵詞：構(gòu)件測(cè)試，測(cè)試自動(dòng)化，自動(dòng)化測(cè)試工具，元數(shù)據(jù)，類(lèi)型庫(kù)

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國(guó)內(nèi)外研究現(xiàn)狀 (2)1.3本文主要內(nèi)容及組織 (2)2構(gòu)件測(cè)試及其自動(dòng)化2.1基于構(gòu)件的開(kāi)發(fā) (2)2.2構(gòu)件測(cè)試方法 (2)2.3構(gòu)件測(cè)試的自動(dòng)化及其工具 (2)2.4本章小結(jié) (2)3COM構(gòu)件測(cè)試自動(dòng)化框架3.1測(cè)試自動(dòng)化總體框架 (2)3.2XML語(yǔ)言與構(gòu)件測(cè)試自動(dòng)化 (2)3.3測(cè)試腳本生成自動(dòng)化 (2)3.4測(cè)試程序運(yùn)行自動(dòng)化 (2)3.5本章小結(jié) (2)4COM構(gòu)件測(cè)試元數(shù)據(jù)4.1構(gòu)件元數(shù)據(jù) (2)4.2COM構(gòu)件的類(lèi)型信息及其提取 (2)4.3類(lèi)型信息的描述與展現(xiàn) (2)4.4本章小結(jié) (2)5第三方COM構(gòu)件自動(dòng)化測(cè)試工具的實(shí)現(xiàn)5.1自動(dòng)化測(cè)試工具的實(shí)現(xiàn) (2)5.2實(shí)驗(yàn) (2)5.3本章小結(jié) (2)6總結(jié)與展望6.1論文總結(jié) (2)6.2進(jìn)一步工作展望 (2)致謝 (2)參考文獻(xiàn) (2)1緒論1.1研究課題的背景與意義自從1968年NATO會(huì)議首次提出“軟件危機(jī)”以來(lái)，軟件工程己經(jīng)取得大進(jìn)展，然而這一危機(jī)并沒(méi)有消失。隨著計(jì)算機(jī)應(yīng)用領(lǐng)域的迅速擴(kuò)大，軟件及復(fù)雜性的不斷提高，軟件危機(jī)愈加明顯地暴露出來(lái)，提高軟件生產(chǎn)率成為產(chǎn)業(yè)的當(dāng)務(wù)之急。要解決這個(gè)問(wèn)題，軟件復(fù)用無(wú)疑是一個(gè)有效的方法。軟件復(fù)用(SoftwareReuse)是將已有軟件的各種有關(guān)知識(shí)用于建立新的軟件,以縮減軟件開(kāi)發(fā)和維護(hù)的花費(fèi)[1]。它的主要思想是，將軟件看成是由不同功能部分的“組件”所組成的有機(jī)體，每一個(gè)組件在設(shè)計(jì)編寫(xiě)時(shí)可以被設(shè)計(jì)成完成同類(lèi)工作的通用工具。這樣，如果建立了可以完成各種工作的組件，編寫(xiě)特定軟件的工作就變成將各種不同組件組織連接起來(lái)的簡(jiǎn)單問(wèn)題，這對(duì)于軟件產(chǎn)品的最終質(zhì)量和維護(hù)工作都有本質(zhì)性的改變。從早期的子函數(shù)到后來(lái)的面向?qū)ο蟮念?lèi)的概念，軟件復(fù)用的粒度逐漸變大。但是以類(lèi)為封裝單位的復(fù)用不能解決異構(gòu)互操作問(wèn)題。構(gòu)件可以將一組類(lèi)的組合進(jìn)行封裝，隱藏具體的實(shí)現(xiàn)細(xì)節(jié)，通過(guò)接口向外界提供服務(wù)。構(gòu)件可以將復(fù)用提高到更高的復(fù)用層次。進(jìn)入20世紀(jì)90年代以后，越來(lái)越多的軟件開(kāi)發(fā)組織在系統(tǒng)開(kāi)發(fā)過(guò)程中，開(kāi)始采用可復(fù)用的軟件構(gòu)件[2]。ClemenzSzyperski[3]認(rèn)為構(gòu)件是“一個(gè)軟件單元，具有一組契約或合同規(guī)定的接口。構(gòu)件與它所在的環(huán)境/上下文有清晰的依賴(lài)關(guān)系，并且僅僅與此相關(guān)。構(gòu)件可以被獨(dú)立配置，以便由第三方進(jìn)行合成（新的軟件）。一個(gè)廣為接受的定義是：構(gòu)件是具有符合特定協(xié)議的接口的組合單元，它的上下文依賴(lài)性是完全顯式的，構(gòu)件可以被獨(dú)立地部署，并由第三方組合。在與其它構(gòu)件組合時(shí)，不需要修改構(gòu)件的源代碼，只需要修改構(gòu)件的接口和屬性。構(gòu)件的接口分為兩種：一種是構(gòu)件可以向外界提供的服務(wù)的接口，其它構(gòu)件可以通過(guò)這些接口來(lái)調(diào)用構(gòu)件提供的服務(wù)；另一種是構(gòu)件期望從其它構(gòu)件獲得服務(wù)的接口[2]。目前，工業(yè)界主要有三個(gè)不同的構(gòu)件規(guī)范，即SUN公司的EJB，Microsoft公司的COM/DCOM[4]，對(duì)象管理組織OMG的CORBA[5]。這些技術(shù)提供了從構(gòu)件開(kāi)發(fā)應(yīng)用系統(tǒng)的通信與協(xié)同。其中微軟的COM構(gòu)件應(yīng)用十分廣泛，包括Windows操作系統(tǒng)和Office辦公套件都大量使用了COM構(gòu)件[6]。COM的全稱(chēng)是ComponentObjectModel，也就是構(gòu)件對(duì)象模型。COM是一個(gè)二進(jìn)制的標(biāo)準(zhǔn)，COM標(biāo)準(zhǔn)包括規(guī)范和實(shí)現(xiàn)兩大部分。規(guī)范部分定義了構(gòu)件和構(gòu)件之間通信的機(jī)制，這些規(guī)范不依賴(lài)于任何特定的語(yǔ)言和操作系統(tǒng)，只要按照規(guī)范，任何語(yǔ)言都可使用。COM標(biāo)準(zhǔn)的實(shí)現(xiàn)部分是COM庫(kù)。COM庫(kù)為COM規(guī)范的具體實(shí)現(xiàn)提供了一些核心服務(wù)。一般是在Windows平臺(tái)下，并且被Microsoft推出的開(kāi)發(fā)工具和類(lèi)庫(kù)支持。COM標(biāo)準(zhǔn)詳細(xì)規(guī)定了一個(gè)COM構(gòu)件所應(yīng)具有的內(nèi)存結(jié)構(gòu)。COM對(duì)象間的交互完全基于對(duì)此內(nèi)存結(jié)構(gòu)的操作。因此可以在很大程度上忽略不同編程語(yǔ)言，應(yīng)用環(huán)境之間的差別，解決了重新編譯重新發(fā)行的問(wèn)題[7]。COM用接口的概念對(duì)構(gòu)件的功能屬性進(jìn)行完全的封裝。與構(gòu)件的通信必須通過(guò)接口進(jìn)行。接口不僅僅是一個(gè)邏輯上的概念，而且也存在著與之相對(duì)應(yīng)的物理內(nèi)存結(jié)構(gòu)——虛表(VTABLE)。一個(gè)對(duì)象可以對(duì)應(yīng)多個(gè)接口，一個(gè)接口也可以由多個(gè)對(duì)象所實(shí)現(xiàn)，表現(xiàn)出靈活的多態(tài)性。COM接口同時(shí)也為版本管理提供了方便。當(dāng)使用新版本的構(gòu)件替換老版本時(shí)，只要該構(gòu)件實(shí)現(xiàn)了舊版本的接口（通過(guò)包容、聚合等手段），就保證了其與原用軟件系統(tǒng)的兼容。同時(shí)新增功能（新的接口）又可被自然地使用。接口完全封裝了內(nèi)部功能、屬性的具體實(shí)現(xiàn)，使得COM對(duì)象對(duì)外表現(xiàn)為“黑盒”結(jié)構(gòu)，完全吻合面向?qū)ο笙到y(tǒng)所要求的“強(qiáng)內(nèi)聚性”。但由于對(duì)接口的過(guò)多強(qiáng)調(diào)，COM構(gòu)件一般不具備廣泛提倡的“弱耦合性”的特點(diǎn)。總之，COM的設(shè)計(jì)思想是構(gòu)件化構(gòu)建軟件，軟件由多個(gè)經(jīng)過(guò)編譯的二進(jìn)制形式的構(gòu)件構(gòu)成(DLL或EXE形式)，因此軟件的更新就可以通過(guò)更新軟件的某一個(gè)構(gòu)件來(lái)實(shí)現(xiàn)，軟件的實(shí)現(xiàn)可通過(guò)多個(gè)構(gòu)件搭建而成。這個(gè)思想是借鑒了硬件開(kāi)發(fā)中的模塊化思想——在其它的工程領(lǐng)域，構(gòu)件的概念已經(jīng)得到了廣泛的接受與使用[8]。而基于COM的復(fù)用思想是：以接口的標(biāo)準(zhǔn)化推動(dòng)服務(wù)的標(biāo)準(zhǔn)化，為復(fù)用軟件的開(kāi)發(fā)和使用建立規(guī)范。在構(gòu)件廣泛應(yīng)用的潮流中，基于構(gòu)件的軟件工程（Component-BasedSoftwareEngineering，CBSE）[9,10]這個(gè)新領(lǐng)域也應(yīng)運(yùn)而生，其目標(biāo)是在一個(gè)框架內(nèi)用即插即用的軟件構(gòu)件（定制構(gòu)造或者是商業(yè)成品（CommercialOff-The-Shelf，COTS）構(gòu)件[11-13]）組成應(yīng)用系統(tǒng)?；跇?gòu)件的軟件工程，包括COTS構(gòu)件的使用，可以減少?gòu)念^開(kāi)始的軟件開(kāi)發(fā)中常常碰到的一些問(wèn)題。特別是COTS的使用，被視作一種既能增加可靠性與生產(chǎn)力，又能減少大型系統(tǒng)的交付時(shí)間的方式?；跇?gòu)件的方法使得大型分布式軟件系統(tǒng)的開(kāi)發(fā)和維護(hù)變得更為簡(jiǎn)單，可以提高軟件的復(fù)用性和軟件開(kāi)發(fā)效率。但是，過(guò)多依賴(lài)復(fù)用也帶來(lái)了新的問(wèn)題，復(fù)用質(zhì)量低下的軟件構(gòu)件可能會(huì)起到相反的作用，不合理的使用高質(zhì)量的軟件構(gòu)件也可能帶來(lái)災(zāi)難性的后果，如阿麗亞娜5號(hào)火箭發(fā)射失敗就是由于未對(duì)構(gòu)件進(jìn)行升級(jí)就復(fù)用造成的[14]。Adrita指出構(gòu)件失效產(chǎn)生的后果大于測(cè)試的費(fèi)用時(shí)，就要進(jìn)行測(cè)試。而構(gòu)件測(cè)試與傳統(tǒng)的軟件測(cè)試相比，還有其特殊性[15]：（1）構(gòu)件測(cè)試的語(yǔ)言無(wú)關(guān)性、跨平臺(tái)?？缙脚_(tái)的調(diào)用會(huì)有許多問(wèn)題。而且不同語(yǔ)言和系統(tǒng)的環(huán)境，也會(huì)造成對(duì)構(gòu)件的理解上的歧義。例如：當(dāng)構(gòu)件的接口函數(shù)的實(shí)現(xiàn)部分是從其它基類(lèi)繼承來(lái)且還有開(kāi)發(fā)者的部分代碼時(shí)，這樣跨平臺(tái)測(cè)試，當(dāng)返回錯(cuò)誤結(jié)果時(shí)，無(wú)法確定是繼承關(guān)系錯(cuò)誤還是開(kāi)發(fā)的代碼錯(cuò)誤[16]。（2）構(gòu)件的嚴(yán)格封裝性。封裝帶來(lái)測(cè)試的障礙。與面向?qū)ο蠛徒Y(jié)構(gòu)化軟件的測(cè)試不同，接口測(cè)試是構(gòu)件測(cè)試的首要任務(wù)。因?yàn)闃?gòu)件的全局?jǐn)?shù)據(jù)是不允許直接訪問(wèn)的，構(gòu)件內(nèi)的數(shù)據(jù)訪問(wèn)一般用Get和Set方法。構(gòu)件的接口對(duì)客戶是可見(jiàn)的，但由于接口的說(shuō)明沒(méi)有強(qiáng)制性要求，因此并非所有的接口都有詳細(xì)說(shuō)明。構(gòu)件測(cè)試要求有一種途徑能訪問(wèn)到所有的屬性和方法，以便測(cè)試到所有的構(gòu)件狀態(tài)。（3）構(gòu)件是二進(jìn)制代碼級(jí)的復(fù)用。與傳統(tǒng)軟件的源代碼復(fù)用不同，構(gòu)件是二進(jìn)制代碼復(fù)用。構(gòu)件的使用者未必了解構(gòu)件的源代碼，而構(gòu)件供應(yīng)商一般僅提供構(gòu)件的說(shuō)明。尤其是對(duì)于COTS構(gòu)件，出于商業(yè)機(jī)密考慮，COTS構(gòu)件的源代碼通常是不可得的。另外，由于構(gòu)件的描述文檔也不是特別詳細(xì)，在開(kāi)發(fā)高可靠的軟件系統(tǒng)時(shí)通常需要構(gòu)件的源代碼和詳細(xì)的描述文檔，而且構(gòu)件使用者對(duì)構(gòu)件功能的理解也會(huì)與構(gòu)件開(kāi)發(fā)者有出入，這就給構(gòu)件測(cè)試帶來(lái)了難題。（4）構(gòu)件以代碼復(fù)用為目標(biāo)。代碼的復(fù)用率越高，代碼的效益也越高，這一目標(biāo)決定了構(gòu)件的健壯性和穩(wěn)定性要求比其它軟件更高。構(gòu)件的故障不僅影響到開(kāi)發(fā)企業(yè)，還影響到以構(gòu)件為平臺(tái)的二級(jí)或更多級(jí)的開(kāi)發(fā)商甚至是使用者，這就要求對(duì)構(gòu)件進(jìn)行更加充分、更加嚴(yán)格的測(cè)試，減少程序的錯(cuò)誤。隨著軟件規(guī)模的增加，測(cè)試工作量的增大，軟件開(kāi)發(fā)周期的縮短，使用軟件測(cè)試自動(dòng)化技術(shù)提高軟件測(cè)試的速度和效率就成為了軟件測(cè)試發(fā)展的必然趨勢(shì)。使用軟件測(cè)試自動(dòng)化技術(shù)能完成許多手工測(cè)試無(wú)法實(shí)現(xiàn)或難以實(shí)現(xiàn)的測(cè)試。正確、合理地實(shí)施自動(dòng)化測(cè)試，能夠快速、徹底地對(duì)軟件進(jìn)行測(cè)試，從而提高軟件質(zhì)量，節(jié)省經(jīng)費(fèi)，縮短產(chǎn)品發(fā)布周期。另外，自動(dòng)化測(cè)試還能排除一些人為的因素(如遺漏、失誤等等)。自動(dòng)測(cè)試技術(shù)是測(cè)試技術(shù)的一個(gè)分支，它的研究重點(diǎn)是如何最大可能地進(jìn)行自動(dòng)化測(cè)試、在哪些方面可以進(jìn)行自動(dòng)化以及自動(dòng)測(cè)試工具的開(kāi)發(fā)和使用[17]。目前應(yīng)用的軟件測(cè)試工具種類(lèi)很多，如企業(yè)級(jí)測(cè)試工具WinRunner，性能負(fù)載測(cè)試工具Load-Runner，單元測(cè)試工具CPPUnit、JUnit等，都具備一定的自動(dòng)測(cè)試能力。但從測(cè)試原理來(lái)看，它們所進(jìn)行的都是基于源代碼的測(cè)試，測(cè)試人員如果使用這些工具編制自動(dòng)測(cè)試程序，不但要熟悉測(cè)試對(duì)象的源代碼，而且經(jīng)常需要調(diào)試測(cè)試腳本，不可避免地造成了工時(shí)的延長(zhǎng)和交流的冗余[18]。隨著構(gòu)件技術(shù)的發(fā)展，構(gòu)件的自動(dòng)測(cè)試成為一個(gè)必不可少的環(huán)節(jié)。但傳統(tǒng)的自動(dòng)測(cè)試工具，由于其設(shè)計(jì)模式[3]的局限性，已經(jīng)不能適用于構(gòu)件的自動(dòng)測(cè)試。它們具有如下缺陷：測(cè)試工具不能獨(dú)立完成整個(gè)測(cè)試過(guò)程；編寫(xiě)測(cè)試用例是一項(xiàng)繁瑣的任務(wù)；測(cè)試腳本常常需要編寫(xiě)和調(diào)試[19]；仍然采用基于源代碼的測(cè)試模式，要求待測(cè)的構(gòu)件提供特定的測(cè)試接口，或者在實(shí)現(xiàn)代碼中嵌入測(cè)試語(yǔ)句，未考慮到COTS構(gòu)件具有的接口不變性和源碼隱藏的特點(diǎn)。它們都不能滿足構(gòu)件的自動(dòng)測(cè)試的需求。因此，迫切需要開(kāi)發(fā)COTS構(gòu)件自動(dòng)化測(cè)試工具。1.2國(guó)內(nèi)外研究現(xiàn)狀1.2.1構(gòu)件測(cè)試的理論基礎(chǔ)當(dāng)前，國(guó)內(nèi)外研究機(jī)構(gòu)在構(gòu)件可能存在的缺陷、構(gòu)件的可測(cè)性、構(gòu)件測(cè)試的目標(biāo)、內(nèi)容、測(cè)試中要解決的問(wèn)題等方面都做了一定的研究，為構(gòu)件測(cè)試的進(jìn)一步研究打下了理論基礎(chǔ)。構(gòu)件軟件集成中會(huì)遇到的兩類(lèi)缺陷：服務(wù)相關(guān)的缺陷(service-related)和結(jié)構(gòu)相關(guān)(structure-related)的缺陷[20]。服務(wù)相關(guān)的缺陷可能是語(yǔ)法缺陷、語(yǔ)義缺陷和非功能缺陷；結(jié)構(gòu)相關(guān)的缺陷(即與系統(tǒng)結(jié)構(gòu)相關(guān)的缺陷)可能來(lái)源于有問(wèn)題的連接件，有問(wèn)題的公共基礎(chǔ)設(shè)施和有問(wèn)題的拓?fù)浣Y(jié)構(gòu)[21]。構(gòu)件的可測(cè)試性是設(shè)計(jì)和測(cè)試軟件程序及構(gòu)件的重要概念之一。運(yùn)用具有良好的可測(cè)試性的程序和構(gòu)件來(lái)構(gòu)建軟件，可以簡(jiǎn)化測(cè)試操作、減少測(cè)試開(kāi)銷(xiāo)、提高軟件質(zhì)量[22]。在構(gòu)件工程中，有幾種不同的構(gòu)件可測(cè)試性的觀點(diǎn)，包括構(gòu)件可觀察性(observability)、構(gòu)件可跟蹤性(traceability)、構(gòu)件可控制性(controllability)和構(gòu)件易理解性(understandability)。(1)構(gòu)件的可觀察性:對(duì)構(gòu)件的操作行為、輸入?yún)?shù)和輸出能較容易地進(jìn)行觀察,設(shè)計(jì)和定義構(gòu)件接口在決定構(gòu)件的可觀察性方面扮演著主要角色。(2)構(gòu)件的可跟蹤性:構(gòu)件應(yīng)具有跟蹤其屬性和行為的狀態(tài)的能力。以前稱(chēng)為行為的可跟蹤性,是構(gòu)件易于跟蹤其外部和內(nèi)部行為；后來(lái)則稱(chēng)為跟蹤的可控制性,是構(gòu)件具有易于定制跟蹤功能的能力。(3)構(gòu)件的可控制性:對(duì)于一個(gè)構(gòu)件的輸入/輸出、操作和行為能較容易地進(jìn)行控制。(4)構(gòu)件的可理解性:構(gòu)件提供多少信息及如何呈現(xiàn)[21]。構(gòu)件測(cè)試的最終目標(biāo)是[23]：(1)檢查構(gòu)件與軟件規(guī)范是否一致，并完成其功能需求；(2)檢查實(shí)現(xiàn)的系統(tǒng)是否反映了規(guī)范中所描述的結(jié)構(gòu)和交互需求(假定這些需求是正確而且完整的)。與傳統(tǒng)軟件測(cè)試相似，構(gòu)件軟件測(cè)試的基本內(nèi)容包括:(1)單元測(cè)試:軟件系統(tǒng)中每一個(gè)單個(gè)的構(gòu)件都經(jīng)過(guò)測(cè)試；(2)集成測(cè)試:對(duì)由已測(cè)試過(guò)的構(gòu)件集成的子系統(tǒng)作為一個(gè)實(shí)體進(jìn)行測(cè)試；(3)系統(tǒng)測(cè)試:對(duì)由已測(cè)試過(guò)的子系統(tǒng)形成的系統(tǒng)作為一個(gè)實(shí)體進(jìn)行測(cè)試；(4)回歸測(cè)試:對(duì)軟件系統(tǒng)所作的任何修改以后都必須進(jìn)行相應(yīng)的重新測(cè)試。對(duì)于測(cè)試中要解決的問(wèn)題，Harrold[24]認(rèn)為應(yīng)該從構(gòu)件提供者和構(gòu)件使用者兩個(gè)不同的角度來(lái)看待。構(gòu)件的提供者認(rèn)為構(gòu)件相對(duì)于使用構(gòu)件的環(huán)境是獨(dú)立的，所以要用與上下文獨(dú)立的方式測(cè)試構(gòu)件所有的功能。相反，構(gòu)件使用者開(kāi)發(fā)的應(yīng)用程序提供了構(gòu)件的運(yùn)行環(huán)境，所以構(gòu)件使用者不把構(gòu)件看成獨(dú)立的單元，僅僅考慮與應(yīng)用程序相關(guān)的構(gòu)件功能。另一個(gè)重要的區(qū)別是提供者有構(gòu)件的源代碼，而使用者則通常沒(méi)有構(gòu)件的源代碼[25]。構(gòu)件開(kāi)發(fā)者面臨的測(cè)試問(wèn)題有：(1)測(cè)試充分性判據(jù)(testadequacycriteria)的可擴(kuò)展性(scalability)：由于復(fù)雜性問(wèn)題和組合爆炸問(wèn)題，對(duì)小規(guī)模程序適用的判據(jù)對(duì)大規(guī)模程序不一定適用。(2)測(cè)試數(shù)據(jù)的產(chǎn)生：由于同樣的原因，難以產(chǎn)生合適的測(cè)試輸入，使得對(duì)低層次元素(如分支——定義使用對(duì)，需求功能可看作是高層元素)難以達(dá)到較高的覆蓋率。(3)如何配置構(gòu)件的測(cè)試環(huán)境：對(duì)單個(gè)構(gòu)件進(jìn)行測(cè)試的環(huán)境，與構(gòu)件在實(shí)際系統(tǒng)中運(yùn)行的環(huán)境可能不同。(4)構(gòu)造測(cè)試驅(qū)動(dòng)器和打樁技術(shù)：傳統(tǒng)的技術(shù)是面向特定的工程。但是構(gòu)件的多樣性和其功能的專(zhuān)用化使得傳統(tǒng)的技術(shù)達(dá)不到應(yīng)有的效力。(5)構(gòu)件測(cè)試的可重用性：對(duì)構(gòu)件的測(cè)試應(yīng)該是可重用的。構(gòu)件使用者面臨的測(cè)試問(wèn)題有：(1)測(cè)試充分性判據(jù)的可擴(kuò)展性問(wèn)題依然存在。(2)構(gòu)件的測(cè)試順序：如果軟件采用分層結(jié)構(gòu)，可以先測(cè)試底層構(gòu)件，因?yàn)椴恍枰渌麡?gòu)件提供服務(wù)；然后再測(cè)試高層構(gòu)件，所調(diào)用到的其他構(gòu)件都是經(jīng)過(guò)測(cè)試的。如果不是分層結(jié)構(gòu)，可能就難以確定測(cè)試的順序。(3)冗余測(cè)試問(wèn)題：通常先對(duì)構(gòu)件進(jìn)行單獨(dú)測(cè)試，然后使用相同的充分性判據(jù)進(jìn)行集成測(cè)試，這就導(dǎo)致有些測(cè)試是重復(fù)的。(4)源代碼是否可用：源代碼可用與否導(dǎo)致不同的系統(tǒng)測(cè)試方法。(5)編程語(yǔ)言、操作系統(tǒng)平臺(tái)、硬件結(jié)構(gòu)的混雜性(heterogeneity)：系統(tǒng)使用的構(gòu)件可能是用不同語(yǔ)言編寫(xiě)的，運(yùn)行在不同的平臺(tái)上，這就要求測(cè)試方法和工具與平臺(tái)和語(yǔ)言無(wú)關(guān)。此外，構(gòu)件使用者還面臨測(cè)試分布式軟件時(shí)的監(jiān)控問(wèn)題、事件重構(gòu)、構(gòu)件的競(jìng)爭(zhēng)和死鎖、多線程問(wèn)題、容錯(cuò)測(cè)試問(wèn)題等。1.2.2軟件自動(dòng)化測(cè)試目前構(gòu)件的自動(dòng)化測(cè)試技術(shù)還不成熟，因此主要沿用傳統(tǒng)的軟件自動(dòng)化測(cè)試技術(shù)。對(duì)于后者，國(guó)內(nèi)外已經(jīng)做了一些研究，并且引入了自動(dòng)化測(cè)試框架，還開(kāi)發(fā)了不少自動(dòng)化測(cè)試工具。軟件測(cè)試自動(dòng)化實(shí)現(xiàn)的原理和方法主要有：直接對(duì)代碼進(jìn)行靜態(tài)和動(dòng)態(tài)分析、測(cè)試過(guò)程的捕獲和回放、測(cè)試腳本技術(shù)[26]。（1）代碼分析代碼分析類(lèi)似于高級(jí)語(yǔ)言編譯系統(tǒng)，一般針對(duì)不同的高級(jí)語(yǔ)言去構(gòu)造分析工具，在工具中定義類(lèi)、對(duì)象、函數(shù)、變量等定義規(guī)則、語(yǔ)法規(guī)則；在分析時(shí)對(duì)代碼進(jìn)行語(yǔ)法掃描,找出不符合編碼規(guī)范的地方；根據(jù)某種質(zhì)量模型評(píng)價(jià)代碼質(zhì)量，生成系統(tǒng)的調(diào)用關(guān)系圖等。（2）捕獲和回放代碼分析是一種白盒測(cè)試的自動(dòng)化方法，捕獲和回放則是一種黑盒測(cè)試的自動(dòng)化方法。捕獲是將用戶每一步操作都記錄下來(lái)。這種記錄的方式有兩種：程序用戶界面的像素坐標(biāo)或程序顯示對(duì)象(窗口、按鈕、滾動(dòng)條等)的位置，以及相對(duì)應(yīng)的操作、狀態(tài)變化或是屬性變化。所有的記錄轉(zhuǎn)換為一種腳本語(yǔ)言所描述的過(guò)程，以模擬用戶的操作?；胤艜r(shí)，將腳本語(yǔ)言所描述的過(guò)程轉(zhuǎn)換為屏幕上的操作,然后將被測(cè)系統(tǒng)的輸出記錄下來(lái)同預(yù)先給定的標(biāo)準(zhǔn)結(jié)果比較。 （3）腳本技術(shù)腳本是一組測(cè)試工具執(zhí)行的指令集合,也是計(jì)算機(jī)程序的一種形式。腳本可以通過(guò)錄制測(cè)試的操作產(chǎn)生,然后再做修改,也可以直接用腳本語(yǔ)言編寫(xiě)腳本。一般的自動(dòng)化測(cè)試包括以下基本過(guò)程[27]：（1）測(cè)試設(shè)計(jì)。測(cè)試設(shè)計(jì)包含設(shè)計(jì)測(cè)試用例、測(cè)試環(huán)境等。在有些自動(dòng)化測(cè)試中，測(cè)試用例是測(cè)試人員手工生成的，部分是自動(dòng)生成的。（2）腳本生成。根據(jù)測(cè)試設(shè)計(jì)生成需要進(jìn)行的測(cè)試腳本，有些高度自動(dòng)化的測(cè)試工具能夠根據(jù)軟件以前運(yùn)行的情況自動(dòng)地錄制測(cè)試用例。（3）腳本運(yùn)行。腳本運(yùn)行也叫做腳本回放，對(duì)生成的腳本進(jìn)行運(yùn)行。（4）結(jié)果比較。主要是分析腳本運(yùn)行的結(jié)果是否符合規(guī)范，以此來(lái)決定測(cè)試是否通過(guò)。（5）測(cè)試報(bào)告生成。對(duì)測(cè)試結(jié)果進(jìn)行分類(lèi)整理，生成相關(guān)的測(cè)試報(bào)告。對(duì)不能通過(guò)的測(cè)試結(jié)果進(jìn)行分析、分類(lèi)、記錄和通報(bào)，讓相關(guān)的測(cè)試人員和開(kāi)發(fā)人員了解測(cè)試結(jié)果。近年來(lái)，自動(dòng)化測(cè)試框架逐漸成為熱點(diǎn)。它是由一些假設(shè)、概念和為自動(dòng)化測(cè)試提供的實(shí)踐組成的集合。它可以減少實(shí)現(xiàn)和維護(hù)的成本，使測(cè)試人員可以把精力集中在應(yīng)用程序的測(cè)試用例設(shè)計(jì)上，而不是開(kāi)發(fā)測(cè)試[28]。常用的有以下五種自動(dòng)化測(cè)試框架[29,30]：（1）測(cè)試腳本模塊化框架這是通過(guò)創(chuàng)建小的獨(dú)立的腳本來(lái)代表被測(cè)試應(yīng)用程序的模塊和函數(shù)，然后用一種分層的方式將這些小腳本組成更大的測(cè)試，從而實(shí)現(xiàn)一個(gè)特定的測(cè)試用例。（2）測(cè)試庫(kù)構(gòu)架框架測(cè)試庫(kù)構(gòu)架框架和測(cè)試腳本模塊化框架非常相似，但是它把被測(cè)應(yīng)用程序分成過(guò)程和函數(shù)，而不是腳本。這種框架要求創(chuàng)建庫(kù)文件來(lái)代表被測(cè)應(yīng)用程序模塊、零件或函數(shù)，然后這些庫(kù)文件被測(cè)試用例腳本直接調(diào)用。（3）數(shù)據(jù)驅(qū)動(dòng)測(cè)試框架將數(shù)據(jù)驅(qū)動(dòng)腳本技術(shù)運(yùn)用到自動(dòng)化測(cè)試框架中就形成了數(shù)據(jù)驅(qū)動(dòng)測(cè)試框架。這種框架從某個(gè)數(shù)據(jù)文件(例如ODBC源文件、Excel文件、.CSV文件、ADO對(duì)象文件等)中讀取輸入、輸出的測(cè)試數(shù)據(jù)，然后通過(guò)變量傳入事先錄制好的或手工編寫(xiě)的測(cè)試腳本中。其中，這些變量被用作傳遞(輸入/輸出)用來(lái)驗(yàn)證應(yīng)用程序的測(cè)試數(shù)據(jù)。（4）關(guān)鍵字驅(qū)動(dòng)測(cè)試框架這有時(shí)候也稱(chēng)為表驅(qū)動(dòng)自動(dòng)化測(cè)試框架，它是對(duì)數(shù)據(jù)驅(qū)動(dòng)自動(dòng)化測(cè)試的有效改進(jìn)和補(bǔ)充。這個(gè)框架需要開(kāi)發(fā)數(shù)據(jù)表和關(guān)鍵字。這些數(shù)據(jù)表和關(guān)鍵字獨(dú)立于執(zhí)行它們的測(cè)試自動(dòng)化工具，并可以用來(lái)“驅(qū)動(dòng)”待測(cè)應(yīng)用程序和數(shù)據(jù)的測(cè)試腳本代碼，使自動(dòng)化測(cè)試框架獨(dú)立于應(yīng)用程序。在一個(gè)關(guān)鍵字驅(qū)動(dòng)測(cè)試中，把待測(cè)應(yīng)用程序的功能和每個(gè)測(cè)試用例的執(zhí)行步驟一起寫(xiě)到一個(gè)表中。（5）混合測(cè)試自動(dòng)化框架最普遍的執(zhí)行框架是上面介紹的所有技術(shù)的一個(gè)結(jié)合,取其長(zhǎng)處,彌補(bǔ)其不足。在自動(dòng)化測(cè)試工具方面，主要有以下幾類(lèi)：（1）靜態(tài)分析工具用于分析設(shè)計(jì)模型、源代碼或其他源程序中包含的信息,能夠生成相關(guān)數(shù)據(jù)流、邏輯流或者質(zhì)量指標(biāo)等信息[31,32]。常用的如McCabeVisualQualityToolSet、LogiScope、TestWork/Advisor等。（2）測(cè)試數(shù)據(jù)生成工具獲取測(cè)試活動(dòng)中使用的數(shù)據(jù)，并且通過(guò)轉(zhuǎn)化、析取、變換或捕捉現(xiàn)有數(shù)據(jù)作為依據(jù)，自動(dòng)為測(cè)試程序生成可靠的測(cè)試數(shù)據(jù)。目前典型的測(cè)試數(shù)據(jù)生成工具有：SoftTest、PanoramaC/C++測(cè)試數(shù)據(jù)生成工具、ParasoftC++Test等。（3）測(cè)試評(píng)估工具用于動(dòng)態(tài)測(cè)試過(guò)程中對(duì)測(cè)試的內(nèi)容及測(cè)試覆蓋性進(jìn)行評(píng)測(cè)，為測(cè)試的充分性提供依據(jù)。常見(jiàn)的測(cè)試評(píng)估工具有：ATAC、PureCoverage、TestWorks/Coverage等。（4）集成化測(cè)試系統(tǒng)它將多種測(cè)試工具融為一體,是一種功能較強(qiáng)的測(cè)試工具。常見(jiàn)的有：SADAT、MicrosoftTestforWindows、ParasoftInsure++等。（5）測(cè)試管理工具它能夠用于輔助測(cè)試活動(dòng)或工作的計(jì)劃、設(shè)計(jì)、實(shí)施、執(zhí)行、評(píng)估和管理。目前,比較有代表性的測(cè)試管理工具主要有：RAIDS、TestStudio、TestDirector等。1.3本文主要內(nèi)容及組織本文主要討論了第三方COM構(gòu)件的測(cè)試自動(dòng)化技術(shù)，基于XML描述的COM構(gòu)件元數(shù)據(jù)——類(lèi)型信息，利用類(lèi)xUnit單元測(cè)試框架進(jìn)行測(cè)試，并實(shí)現(xiàn)了COM構(gòu)件自動(dòng)化測(cè)試工具原型COMCAT(COMComponentAutomatedTest)。基于上述研究?jī)?nèi)容，本文各章組織如下：第1章概述了COM構(gòu)件測(cè)試自動(dòng)化的研究背景和意義，并介紹了國(guó)內(nèi)外目前在與此相關(guān)的構(gòu)件測(cè)試和軟件自動(dòng)化測(cè)試方面所做的基礎(chǔ)性工作。第2章詳細(xì)介紹了構(gòu)件的開(kāi)發(fā)、測(cè)試方法、測(cè)試自動(dòng)化的途徑和工具的開(kāi)發(fā)。第3章在現(xiàn)有構(gòu)件測(cè)試及其自動(dòng)化研究的基礎(chǔ)上，進(jìn)行比較、分析，考慮到第三方COM構(gòu)件的特點(diǎn)，設(shè)計(jì)了一套COM構(gòu)件自動(dòng)化測(cè)試的框架，介紹了該測(cè)試框架的整個(gè)流程及其中各步驟中所使用的主要方法和技術(shù)。第4章重點(diǎn)介紹了針對(duì)第三方COM構(gòu)件的源碼未知、文檔缺乏的難點(diǎn)，采用的自動(dòng)從類(lèi)型庫(kù)中提取COM構(gòu)件類(lèi)型信息，并以組織良好、可擴(kuò)展性強(qiáng)的XML文檔擴(kuò)展、描述，以友好的樹(shù)形視圖展現(xiàn)的技術(shù)，其中類(lèi)型信息為測(cè)試提供了依據(jù)，而XML文檔便于自動(dòng)化測(cè)試過(guò)程。第5章對(duì)前面設(shè)計(jì)的COM構(gòu)件測(cè)試自動(dòng)化框架進(jìn)行了實(shí)現(xiàn)，開(kāi)發(fā)了自動(dòng)化測(cè)試工具原型COMCAT，給出了其系統(tǒng)結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)、模塊設(shè)計(jì)與實(shí)現(xiàn)，并進(jìn)行了實(shí)驗(yàn)分析。第6章對(duì)全文進(jìn)行總結(jié)并展望了未來(lái)的工作。最后是致謝和參考文獻(xiàn)。

2構(gòu)件測(cè)試及其自動(dòng)化2.1基于構(gòu)件的開(kāi)發(fā)隨著網(wǎng)絡(luò)和軟件技術(shù)的不斷發(fā)展，基于構(gòu)件的軟件開(kāi)發(fā)(Component-BasedSoftwareDevelopment，CBSD)受到人們的高度重視，它是一種在模塊化系統(tǒng)、結(jié)構(gòu)化設(shè)計(jì)和面向?qū)ο蠹夹g(shù)的基礎(chǔ)上發(fā)展起來(lái)的新的軟件開(kāi)發(fā)方法。CBSD是在一定構(gòu)件模型的支持下，復(fù)用構(gòu)件庫(kù)中的一個(gè)或多個(gè)構(gòu)件，通過(guò)組合手段高效率、高質(zhì)量地構(gòu)造應(yīng)用軟件系統(tǒng)的過(guò)程[9]。CBSD通過(guò)提高系統(tǒng)的可擴(kuò)展性和可維護(hù)性來(lái)減少軟件開(kāi)發(fā)的費(fèi)用，更快的整合系統(tǒng)，并能有效的降低大型系統(tǒng)的維護(hù)和升級(jí)壓力[33]?；跇?gòu)件的軟件開(kāi)發(fā)過(guò)程與傳統(tǒng)的面向過(guò)程或面向?qū)ο蟮能浖_(kāi)發(fā)過(guò)程有所不同。傳統(tǒng)的軟件開(kāi)發(fā)過(guò)程或面向?qū)ο蟮能浖_(kāi)發(fā)過(guò)程是圍繞用戶需求進(jìn)行需求分析和設(shè)計(jì)，軟件完全根據(jù)用戶的需求定制，稱(chēng)之為基于需求的軟件開(kāi)發(fā)過(guò)程。而基于構(gòu)件的軟件開(kāi)發(fā)過(guò)程，由于從商業(yè)市場(chǎng)上購(gòu)買(mǎi)的構(gòu)件并不是為某一個(gè)固定用戶定制的，或者構(gòu)件實(shí)現(xiàn)的功能并不是完全與用戶的要求相吻合，因此，基于構(gòu)件的軟件開(kāi)發(fā)過(guò)程是在用戶需求、軟件設(shè)計(jì)、項(xiàng)目管理和構(gòu)件市場(chǎng)之間的一個(gè)平衡過(guò)程。面向構(gòu)件的軟件開(kāi)發(fā)是指軟件體系結(jié)構(gòu)可重組以及軟件成分可重用的系統(tǒng)開(kāi)發(fā)方法。從工程化與過(guò)程管理的角度講，面向構(gòu)件的軟件開(kāi)發(fā)過(guò)程可定義為4個(gè)階段：[34]（1）分析階段。從特定應(yīng)用需求出發(fā)，通過(guò)領(lǐng)域分析，進(jìn)行共性需求識(shí)別、領(lǐng)域?qū)ο蟪橄蠛皖I(lǐng)域知識(shí)獲取，建立概念層的領(lǐng)域模型，產(chǎn)生應(yīng)用系統(tǒng)的需求規(guī)格說(shuō)明，這一階段的成果是領(lǐng)域模型。（2）設(shè)計(jì)階段。設(shè)計(jì)階段的主要任務(wù)是基于領(lǐng)域模型尋求軟件解決方案，包括構(gòu)架設(shè)計(jì)模型和構(gòu)件設(shè)計(jì)模型。在這一階段中，首先檢索構(gòu)架庫(kù)中存放的面向特定領(lǐng)域的構(gòu)架，尋找可復(fù)用的構(gòu)架，或者對(duì)其進(jìn)行必要的適應(yīng)性修改；在無(wú)可復(fù)用構(gòu)架時(shí)，創(chuàng)造適合該應(yīng)用環(huán)境的新構(gòu)架，并進(jìn)行標(biāo)準(zhǔn)化描述后入庫(kù)，以備將來(lái)的復(fù)用。然后，在構(gòu)架的指導(dǎo)下，把系統(tǒng)功能分解到相應(yīng)的構(gòu)件和連接件，并定義系統(tǒng)中構(gòu)件之間的關(guān)系。這一階段的成果是構(gòu)架模型和構(gòu)件模型。（3）實(shí)現(xiàn)階段。根據(jù)領(lǐng)域應(yīng)用開(kāi)發(fā)或直接重用的需要，進(jìn)行領(lǐng)域?qū)崿F(xiàn)。包括領(lǐng)域構(gòu)件的識(shí)別、設(shè)計(jì)、編碼和測(cè)試等局部過(guò)程集成，系統(tǒng)構(gòu)件的分類(lèi)、檢索、引用和構(gòu)件庫(kù)的維護(hù)，領(lǐng)域構(gòu)件與系統(tǒng)構(gòu)件的演化、實(shí)例化、組合和應(yīng)用原型的動(dòng)態(tài)生成等領(lǐng)域框架整體集成，從而建立符合領(lǐng)域應(yīng)用的各種物理模型。這一階段的成果是軟件構(gòu)架和代碼級(jí)別的構(gòu)件。（4）集成階段。通過(guò)對(duì)實(shí)現(xiàn)階段所生成的產(chǎn)品進(jìn)行組裝和運(yùn)行模擬(正向)、設(shè)計(jì)優(yōu)化(逆向)等措施，針對(duì)領(lǐng)域軟件原型進(jìn)行可用性評(píng)價(jià)和可重構(gòu)性驗(yàn)證，并對(duì)符合確認(rèn)測(cè)試條件的應(yīng)用系統(tǒng)進(jìn)行全局封裝和使用規(guī)范生成，最終獲得一個(gè)真正構(gòu)件化的目標(biāo)系統(tǒng)。隨著CBSD的逐漸成熟，網(wǎng)絡(luò)上出現(xiàn)了大量的COTS構(gòu)件產(chǎn)品，在基于COTS構(gòu)件的系統(tǒng)開(kāi)發(fā)中，系統(tǒng)開(kāi)發(fā)的觀念被組裝和集成現(xiàn)有構(gòu)件的觀念所取代，CBSD強(qiáng)調(diào)以構(gòu)件集成為中心進(jìn)行系統(tǒng)的構(gòu)造。2.2構(gòu)件測(cè)試方法對(duì)應(yīng)于構(gòu)件的測(cè)試，應(yīng)從接口、信息和實(shí)現(xiàn)三個(gè)方面加以實(shí)施。構(gòu)件測(cè)試可以分為接口測(cè)試、狀態(tài)測(cè)試與實(shí)現(xiàn)測(cè)試[35]。構(gòu)件的接口測(cè)試實(shí)際上是驗(yàn)證構(gòu)件對(duì)外需求接口與提供接口是否與構(gòu)件規(guī)范說(shuō)明一致，功能是否正確，是否通過(guò)接口實(shí)現(xiàn)與其它構(gòu)件的交互。構(gòu)件的狀態(tài)測(cè)試是驗(yàn)證構(gòu)件內(nèi)部狀態(tài)是否正確，在各種條件下包含的屬性、變量值是否刻畫(huà)了構(gòu)件的當(dāng)前狀態(tài)。構(gòu)件的實(shí)現(xiàn)測(cè)試是驗(yàn)證構(gòu)件功能實(shí)現(xiàn)的正確性、健壯性。在大多數(shù)情況下，對(duì)一個(gè)構(gòu)件的測(cè)試，不僅僅是測(cè)試其接口、狀態(tài)或?qū)崿F(xiàn),往往是三者都要加以測(cè)試，并且每一種測(cè)試與其它兩種測(cè)試是相輔相成的：構(gòu)件通過(guò)接口對(duì)外提供的功能是否正確，顯然要取決于其狀態(tài)和實(shí)現(xiàn)；構(gòu)件的狀態(tài)往往通過(guò)接口體現(xiàn)；構(gòu)件的實(shí)現(xiàn)建立在構(gòu)件的接口規(guī)范基礎(chǔ)上，并且可以改變構(gòu)件的狀態(tài)。三種測(cè)試只是測(cè)試出發(fā)點(diǎn)的不同側(cè)重因素，在實(shí)際測(cè)試中，是融合在一起的。對(duì)于任何工程產(chǎn)品都可以使用黑盒測(cè)試或白盒測(cè)試兩種方法之一進(jìn)行測(cè)試。軟件的黑盒測(cè)試意味著測(cè)試要在軟件的接口處進(jìn)行。這種方法是把測(cè)試對(duì)象看作一個(gè)黑盒子，測(cè)試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說(shuō)明書(shū)，檢查程序的功能是否符合它的功能說(shuō)明。軟件的白盒測(cè)試是對(duì)軟件的過(guò)程性細(xì)節(jié)做細(xì)致的檢查。這種方法是把測(cè)試對(duì)象看作一個(gè)打開(kāi)的盒子，它允許測(cè)試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計(jì)或選擇測(cè)試用例，對(duì)程序所有邏輯路徑進(jìn)行測(cè)試。通過(guò)在不同點(diǎn)檢查程序狀態(tài)，確定實(shí)際狀態(tài)是否與預(yù)期的狀態(tài)一致。從構(gòu)件接口測(cè)試的角度出發(fā)，往往采用黑盒測(cè)試方法，通過(guò)接口調(diào)用輸入數(shù)據(jù)得到結(jié)果，進(jìn)行與接口規(guī)范的比較得到測(cè)試報(bào)告。在設(shè)計(jì)接口測(cè)試輸入?yún)?shù)時(shí)，除了使用傳統(tǒng)的等價(jià)類(lèi)劃分、邊界值分析等方法外,還要考慮到接口的前置條件和后置條件等約束。從構(gòu)件狀態(tài)與實(shí)現(xiàn)角度出發(fā)，采用白盒測(cè)試方法，通過(guò)分析構(gòu)件的結(jié)構(gòu)組成和實(shí)現(xiàn)細(xì)節(jié)產(chǎn)生測(cè)試用例，然后加以測(cè)試。構(gòu)件測(cè)試與傳統(tǒng)測(cè)試過(guò)程中的單元測(cè)試大體類(lèi)似，由那些驗(yàn)證構(gòu)件的實(shí)現(xiàn)與構(gòu)件的規(guī)格說(shuō)明書(shū)描述是否一致的相關(guān)活動(dòng)組成。傳統(tǒng)的軟件單元測(cè)試是在開(kāi)發(fā)時(shí)由開(kāi)發(fā)人員或者是專(zhuān)門(mén)的測(cè)試人員進(jìn)行的，常見(jiàn)的單元測(cè)試方法有根據(jù)前置條件和后置條件設(shè)計(jì)測(cè)試用例以及根據(jù)程序運(yùn)行狀態(tài)轉(zhuǎn)換圖來(lái)構(gòu)建測(cè)試用例等方法。構(gòu)件軟件單元測(cè)試的現(xiàn)有研究方法多是在現(xiàn)有單元測(cè)試方法的基礎(chǔ)上，針對(duì)構(gòu)件的特點(diǎn)進(jìn)行了一定的改進(jìn)。目前用于構(gòu)件測(cè)試的主要方法有以下幾種[2]：（1）構(gòu)件驗(yàn)證構(gòu)件驗(yàn)證[36](CertificationofComponent)方法，首先對(duì)構(gòu)件進(jìn)行基于系統(tǒng)運(yùn)行剖面的黑箱測(cè)試，確保構(gòu)件完成應(yīng)有的功能，如果達(dá)不到就不使用它；然后把構(gòu)件放進(jìn)系統(tǒng)中，進(jìn)行系統(tǒng)級(jí)的錯(cuò)誤注入，目的是揭示特定構(gòu)件失效會(huì)對(duì)系統(tǒng)造成多大的危害，如果系統(tǒng)能經(jīng)得起考驗(yàn)就認(rèn)定可以使用該構(gòu)件，否則要對(duì)構(gòu)件進(jìn)行包裝(wrap)，限制某些功能的使用，再重新放進(jìn)系統(tǒng)進(jìn)行驗(yàn)證。僅僅對(duì)構(gòu)件進(jìn)行黑箱測(cè)試不足以保證可靠性，某些安全性問(wèn)題(如惡意代碼、Trojan木馬)也難以檢測(cè)出來(lái)。如何提供足夠的測(cè)試用例進(jìn)行系統(tǒng)測(cè)試也是個(gè)大問(wèn)題。（2）內(nèi)置測(cè)試(built-intest)內(nèi)置測(cè)試方法[37]通過(guò)在構(gòu)件的源代碼中添加了用于內(nèi)置測(cè)試的函數(shù)，事實(shí)上成為一種特殊的構(gòu)件，這種構(gòu)件運(yùn)行時(shí)具有兩種模式：正常模式及維護(hù)模式。維護(hù)模式下可以調(diào)用構(gòu)件內(nèi)置的測(cè)試函數(shù)來(lái)測(cè)試構(gòu)件，正常模式下不會(huì)調(diào)用內(nèi)置的測(cè)試函數(shù)。這種方法增強(qiáng)了構(gòu)件的可測(cè)試性，簡(jiǎn)化了構(gòu)件維護(hù)的正確性、可適應(yīng)性、完整性、可預(yù)防性和重設(shè)計(jì)性，而且適應(yīng)范圍廣，除了構(gòu)件外，還適用于類(lèi)和對(duì)象，但是該方法需要構(gòu)件源代碼。（3）回溯測(cè)試方法(Retrospectors)回溯測(cè)試方法[38]利用Retrospectors來(lái)記錄構(gòu)件執(zhí)行的歷史信息，以便測(cè)試者可以利用這些測(cè)試信息。構(gòu)件中的Retro類(lèi)與JavaBeans中的內(nèi)省類(lèi)(IntrospectorClass)相似。具有Retro類(lèi)的構(gòu)件有三種不同的模式：設(shè)計(jì)時(shí)模式、測(cè)試時(shí)模式和執(zhí)行時(shí)模式。構(gòu)件中的Retrospector可以手工創(chuàng)建，也可以通過(guò)為構(gòu)件添加一種所謂的Retro-spec規(guī)約來(lái)自動(dòng)生成。該方法的優(yōu)點(diǎn)在于，即使沒(méi)有源代碼，構(gòu)件使用者也可以使用代碼覆蓋分析的方法測(cè)試構(gòu)件，因?yàn)闃?gòu)件內(nèi)部的Retrospector可以記錄構(gòu)件的執(zhí)行情況。但由于該方法不是構(gòu)件的標(biāo)準(zhǔn)，構(gòu)件提供者不一定提供這項(xiàng)功能。（4）構(gòu)件包裝方法(Wrapper)構(gòu)件包裝方法[39]通過(guò)為構(gòu)件添加一層保護(hù)的包裝層，以探測(cè)構(gòu)件執(zhí)行時(shí)的錯(cuò)誤及異常行為，并提供異常處理機(jī)制。這種保護(hù)型的包裝層能夠處理典型的構(gòu)件運(yùn)行錯(cuò)誤，比如缺少信號(hào)、信號(hào)的變化范圍超過(guò)了規(guī)定的限度，信號(hào)振動(dòng)等。該方法可以提高商業(yè)構(gòu)件的可靠性。該方法的局限性在于設(shè)計(jì)、實(shí)現(xiàn)及評(píng)估構(gòu)件包裝層可能是代價(jià)不菲的，而且構(gòu)件包裝層不能過(guò)于復(fù)雜，否則就可能與提高構(gòu)件的可靠性的初衷相反。（5）TDSTDS（Technologies，Developmentframeworks，andqualityassuranceSchemes）方法[40]的第一步確定構(gòu)件的接口；第二步，確定接口中提供的方法（method）和異常處理（exception），哪些是必須進(jìn)行覆蓋的；第三步，確定這些方法和異常處理函數(shù)的參數(shù)，用突變算子(mutantoperators)對(duì)其進(jìn)行處理；第四步，根據(jù)構(gòu)件需求(requirementofthecomponent)創(chuàng)建測(cè)試集(testset)，然后運(yùn)行測(cè)試；第五步，去除測(cè)試中發(fā)現(xiàn)的錯(cuò)誤(error)；第六步，擴(kuò)充測(cè)試集達(dá)到100％的接口覆蓋率(interface-basedcoveragemeasure)。這個(gè)方法的特點(diǎn)是提出了構(gòu)件軟件測(cè)試的充分性條件，并由此生成、檢驗(yàn)測(cè)試用例；但提出的測(cè)試充分性條件還需要與傳統(tǒng)的測(cè)試充分性條件進(jìn)行比較，例如對(duì)比不同的方法，看誰(shuí)能更有效地檢測(cè)出軟件中播種的錯(cuò)誤(seedederror)。（6）構(gòu)件元數(shù)據(jù)方法（Componentmetadataway）構(gòu)件元數(shù)據(jù)方法[41]是利用構(gòu)件的開(kāi)發(fā)者提供的構(gòu)件元數(shù)據(jù)meta-data來(lái)分析和測(cè)試構(gòu)件，這些數(shù)據(jù)包含不同種類(lèi)的信息并且有明確的上下文環(huán)境，由構(gòu)件提供者在開(kāi)發(fā)構(gòu)件時(shí)嵌入這些信息，構(gòu)件提供者還可以根據(jù)構(gòu)件使用者的需要，增加相應(yīng)的信息。構(gòu)件元數(shù)據(jù)既可以描述構(gòu)件的靜態(tài)特性，也可以描述其動(dòng)態(tài)特性，可以看作是大多數(shù)構(gòu)件模型中的內(nèi)省機(jī)制的一般形式。構(gòu)件使用者在測(cè)試構(gòu)件時(shí)，可以通過(guò)訪問(wèn)構(gòu)件元數(shù)據(jù)獲得相應(yīng)的信息。該方法增加了程序分析的精確度，為構(gòu)件使用者測(cè)試構(gòu)件提供了方便性。目前的構(gòu)件標(biāo)準(zhǔn)DCOM和EJB已經(jīng)提供了通過(guò)元數(shù)據(jù)來(lái)為構(gòu)件使用者提供附加信息的機(jī)制，但是制定相應(yīng)獨(dú)立于構(gòu)件開(kāi)發(fā)者的構(gòu)件元數(shù)據(jù)的標(biāo)準(zhǔn)比較困難，缺乏第三方構(gòu)件提供者的支持，目前該方法還只能用來(lái)測(cè)試小型程序。（7）序列生成技術(shù)序列生成技術(shù)[42](sequencegenerationtechnique)，這種方法是兩層結(jié)構(gòu)(phase)：①是對(duì)每個(gè)構(gòu)件單獨(dú)考慮并定義methodsequences，包含三步，用數(shù)據(jù)流方法分析構(gòu)件包含的方法，然后使用符號(hào)執(zhí)行技術(shù)得到每個(gè)方法的形式化規(guī)約，最后利用前兩步得到的信息進(jìn)行自動(dòng)推導(dǎo)得到方法調(diào)用序列。通過(guò)執(zhí)行所有的方法序列就可以測(cè)試這個(gè)構(gòu)件；②通過(guò)把每個(gè)構(gòu)件的methodsequence結(jié)合起來(lái)，研究漸增集成測(cè)試問(wèn)題。通過(guò)分析構(gòu)件之間的依賴(lài)關(guān)系，按照添加附加代碼最少的原則確定集成的順序，然后按照這個(gè)順序成對(duì)集成構(gòu)件(客戶和服務(wù)器)。使用一種backward-chained推導(dǎo)方法生成methodsequences。這種方法的優(yōu)點(diǎn)是考慮到了構(gòu)件集成的順序，可以減少重復(fù)測(cè)試。但是隨著被測(cè)軟件規(guī)模的擴(kuò)大，方法的復(fù)雜度可能會(huì)大大增加。（8）程序切片、控制依賴(lài)性分析和數(shù)據(jù)流測(cè)試程序切片、控制依賴(lài)性分析和數(shù)據(jù)流測(cè)試法[43](Anapproachuseprogramslicing，control-dependenceanalysisanddata-flowtesting)，首先由構(gòu)件的提供者對(duì)構(gòu)件進(jìn)行充分測(cè)試，并提供summaryinformation；構(gòu)件使用者通過(guò)得到的summaryinformation可以進(jìn)行有效的系統(tǒng)測(cè)試，而不需要得到構(gòu)件的源代碼。作者舉了三個(gè)應(yīng)用方向，程序切片(programslicing)、控制依賴(lài)性分析(control-dependenceanalysis)和數(shù)據(jù)流測(cè)試。根據(jù)構(gòu)件提供者提供的不同附加信息，構(gòu)件使用者可以進(jìn)行不同領(lǐng)域的分析。這種方法的缺點(diǎn)是summaryinformation并不屬于任何現(xiàn)有構(gòu)件規(guī)范的標(biāo)準(zhǔn)，要得到構(gòu)件提供者的支持難度比較大。2.3構(gòu)件測(cè)試的自動(dòng)化及其工具隨著構(gòu)件軟件的復(fù)雜性增加，基于構(gòu)件的自動(dòng)測(cè)試生成變得越來(lái)越復(fù)雜。原因是：構(gòu)件支持GUI使其增加了難度；構(gòu)件支持多媒體使其增加了復(fù)雜度；分布式的構(gòu)件更增加了其通信等方面的難度。因此，作為一個(gè)好的基于構(gòu)件的自動(dòng)測(cè)試工具，下面的功能是測(cè)試人員真正需要的：定義好的黑盒測(cè)試模型和充分的測(cè)試標(biāo)準(zhǔn)、系統(tǒng)的方法和工具支持基于領(lǐng)域的測(cè)試生成[44]。構(gòu)件的開(kāi)發(fā)者可沿用已經(jīng)產(chǎn)品化的面向?qū)ο筌浖y(cè)試工具對(duì)構(gòu)件進(jìn)行單元測(cè)試,這些工具有C++Test，Panorama++和ParaSoftJTest等。構(gòu)件測(cè)試可把探針模型和構(gòu)件有效地結(jié)合起來(lái)，然后可用上述測(cè)試工具[45]。專(zhuān)門(mén)的構(gòu)件測(cè)試工具主要有：1、Microsoft系列的OLE/COMViewer、OLEclientOLEserver測(cè)試系列、ActiveXcontroltest等。這些工具都是黑盒測(cè)試工具。2、JavaBean系列的工具。構(gòu)件測(cè)試工具還很不成熟，主要用于構(gòu)件的黑盒測(cè)試。2.4本章小結(jié)本章詳細(xì)介紹了構(gòu)件技術(shù)，包括CBSD這種新的軟件開(kāi)發(fā)方法及其過(guò)程，然后介紹了構(gòu)件的測(cè)試方法，將其分為接口、狀態(tài)和實(shí)現(xiàn)三種類(lèi)型的測(cè)試，并與黑盒測(cè)試、白盒測(cè)試相結(jié)合，接著對(duì)于構(gòu)件測(cè)試，將其與傳統(tǒng)的單元測(cè)試類(lèi)比，介紹了構(gòu)件驗(yàn)證、內(nèi)置測(cè)試、回溯測(cè)試方法等目前的主要研究成果，最后談到了構(gòu)件自動(dòng)化測(cè)試工具的目標(biāo)和現(xiàn)有的一些構(gòu)件測(cè)試工具。通過(guò)這章的介紹可以看出：增強(qiáng)構(gòu)件的可測(cè)試性；建立通用的、可重用的測(cè)試平臺(tái)；實(shí)現(xiàn)構(gòu)件的測(cè)試方法，開(kāi)發(fā)出真正專(zhuān)門(mén)、有效的構(gòu)件自動(dòng)化測(cè)試工具，這些都是亟待解決的問(wèn)題。

3COM構(gòu)件測(cè)試自動(dòng)化框架3.1測(cè)試自動(dòng)化總體框架對(duì)于軟件構(gòu)件測(cè)試，英國(guó)標(biāo)準(zhǔn)委員會(huì)（BritishStandard）已經(jīng)制定了標(biāo)準(zhǔn)BS7925-2，該標(biāo)準(zhǔn)旨在幫助測(cè)試人員提高測(cè)試過(guò)程的質(zhì)量，在此基礎(chǔ)上提高軟件的質(zhì)量[46]。它描述了軟件構(gòu)件的通用動(dòng)態(tài)測(cè)試過(guò)程、測(cè)試用例設(shè)計(jì)技術(shù)和測(cè)試度量技術(shù)。標(biāo)準(zhǔn)BS7925-2盡管現(xiàn)在是由英國(guó)標(biāo)準(zhǔn)協(xié)會(huì)BSI出版的，但是填補(bǔ)了目前軟件工程領(lǐng)域中構(gòu)件測(cè)試相關(guān)的空白，未來(lái)可能成為國(guó)際標(biāo)準(zhǔn)。該測(cè)試標(biāo)準(zhǔn)給出的通用動(dòng)態(tài)測(cè)試過(guò)程如圖3.1所示。本文主要研究其中的構(gòu)件測(cè)試規(guī)格說(shuō)明和構(gòu)件測(cè)試執(zhí)行部分。構(gòu)件測(cè)試結(jié)果的驗(yàn)證與記錄也可實(shí)現(xiàn)自動(dòng)化。上面提到的標(biāo)準(zhǔn)BS7925-2規(guī)定每個(gè)將要被測(cè)試的構(gòu)件都須有規(guī)格說(shuō)明，以使得有可能從給定的輸入集合獲得期望的輸出。盡管發(fā)布構(gòu)件二進(jìn)制代碼的同時(shí)一般都有相應(yīng)的構(gòu)件文檔說(shuō)明以方便構(gòu)件的使用者，但是這些構(gòu)件的規(guī)格說(shuō)明可能并不是特定用于測(cè)試目的，再加上現(xiàn)在COTS構(gòu)件的大量使用，出于商業(yè)利益考慮，往往并不詳細(xì)，不能為構(gòu)件使用者測(cè)試構(gòu)件提供足夠的幫助。而且這些規(guī)格說(shuō)明很少是形式化的，這也不利于測(cè)試過(guò)程的自動(dòng)化。為了得到一份相對(duì)比較詳細(xì)的構(gòu)件測(cè)試規(guī)格說(shuō)明，有必要擴(kuò)展規(guī)格說(shuō)明的內(nèi)容，自動(dòng)提取、生成構(gòu)件與測(cè)試相關(guān)的元數(shù)據(jù)，并加以形式化描述。這樣形成的文檔將成為構(gòu)件開(kāi)發(fā)方所提供的構(gòu)件文檔說(shuō)明的重要補(bǔ)充。為了實(shí)現(xiàn)構(gòu)件測(cè)試執(zhí)行的自動(dòng)化，本文沿用現(xiàn)有的軟件自動(dòng)化測(cè)試技術(shù)。由于第三方構(gòu)件是二進(jìn)制復(fù)用，使用方得不到構(gòu)件的源代碼，構(gòu)件對(duì)使用方而言是黑盒，無(wú)法進(jìn)行代碼分析。又若采用捕獲/回放方法，那么將會(huì)擁有大量測(cè)試腳本，并且當(dāng)構(gòu)件版本升級(jí)時(shí)，相應(yīng)的測(cè)試腳本也必須重新錄制。因此測(cè)試執(zhí)行的自動(dòng)化將采用前面第一章提到的測(cè)試腳本技術(shù)。這就可以分為測(cè)試腳本的自動(dòng)生成與測(cè)試腳本的自動(dòng)運(yùn)行。其中前者是建立在測(cè)試規(guī)格說(shuō)明的基礎(chǔ)上的，后者應(yīng)當(dāng)能夠自動(dòng)讀取獨(dú)立的測(cè)試用例數(shù)據(jù)。由此可得該構(gòu)件測(cè)試自動(dòng)化框架的整個(gè)流程，如圖3.2所示。圖3.1通用構(gòu)件測(cè)試過(guò)程示意圖圖3.2構(gòu)件測(cè)試自動(dòng)化框架的總體流程在整個(gè)流程中的多個(gè)環(huán)節(jié)都將使用XML語(yǔ)言，因此，接下來(lái)將先對(duì)XML語(yǔ)言及其在構(gòu)件測(cè)試自動(dòng)化中的應(yīng)用作一介紹。3.2XML語(yǔ)言與構(gòu)件測(cè)試自動(dòng)化3.2.1XML語(yǔ)言及其優(yōu)點(diǎn)XML(ExtensibleMarkupLnaguage：可擴(kuò)展標(biāo)記語(yǔ)言)是由W3C(WorldWideWeb：萬(wàn)維網(wǎng)聯(lián)盟)定義的一種語(yǔ)言，該聯(lián)盟為互聯(lián)網(wǎng)制定標(biāo)準(zhǔn)。XML的數(shù)據(jù)格式表達(dá)能力很強(qiáng)，幾乎所有的數(shù)據(jù)結(jié)構(gòu)都可以用XML的形式表達(dá)出來(lái)，并且可以在任何平臺(tái)上采用XML語(yǔ)言進(jìn)行程序開(kāi)發(fā)。XML是一套定義語(yǔ)義標(biāo)記的規(guī)則，這些標(biāo)記將文檔分成許多部件并對(duì)這些部件加以標(biāo)識(shí)。它也是元標(biāo)記語(yǔ)言，即定義了用于定義其他與特定領(lǐng)域有關(guān)的、語(yǔ)義的、結(jié)構(gòu)化的標(biāo)記語(yǔ)言的句法語(yǔ)言。XML文檔內(nèi)容的基本單元是元素，它的語(yǔ)法格式如下：<標(biāo)簽>文本內(nèi)容<標(biāo)簽>元素由起始標(biāo)簽、元素內(nèi)容和結(jié)束標(biāo)簽組成。用戶把要描述的數(shù)據(jù)對(duì)象放在起始標(biāo)簽和結(jié)束標(biāo)簽之間。無(wú)論文本內(nèi)容有多長(zhǎng)或者多么復(fù)雜，XML元素中還可以再嵌套別的元素，這樣使相關(guān)信息構(gòu)成等級(jí)結(jié)構(gòu)。除了元素，XML文檔中能出現(xiàn)的有效對(duì)象是：處理指令、注釋、根元素、子元素和屬性。XML1.0規(guī)定了XML文檔的結(jié)構(gòu)和定義，提供了對(duì)存儲(chǔ)布局和邏輯結(jié)構(gòu)加以限制的機(jī)制。所有的XML文檔都必須符合XML的語(yǔ)法限制(SyntaxConstraint)，要求格式良好(well-formed)；在特定的應(yīng)用中，數(shù)據(jù)本身具有含義上、數(shù)據(jù)類(lèi)型上和數(shù)據(jù)關(guān)聯(lián)上的限制，也就是語(yǔ)義限制(SemanticConstraint)，即要求文檔是有效的(valid)。其中XML文檔的有效性是指一個(gè)XML文檔應(yīng)當(dāng)遵守DTD或是Schema的規(guī)定。有效的XML文檔肯定是格式良好的。XML文檔的基本結(jié)構(gòu)由序言部分和一個(gè)根元素組成。序言包括了XML聲明和DTD(或者是XMLSchema)，DTD和XMLSchema都是用來(lái)描述XML文檔結(jié)構(gòu)的，也就是描述元素和屬性是如何聯(lián)系在一起的。（1）DTD：定義數(shù)據(jù)如何被格式化。它必須定義XML文檔所允許的每個(gè)元素、每個(gè)屬性以及每個(gè)元素可以接受的屬性值、每個(gè)元素的嵌套和事件以及任何可能的外部實(shí)體。XML通過(guò)DTD定義數(shù)據(jù)的結(jié)構(gòu)，使這些數(shù)據(jù)被許多不同的程序以多種方式使用。（2）XMLSchema：是W3C為了彌補(bǔ)DTD存在的問(wèn)題和局限性而推出的一個(gè)工作草案。除了能更精確地處理XML結(jié)構(gòu)約束的表示之外，XMLSchema還可以為約束數(shù)據(jù)的處理提供一個(gè)XML樣式。Schema實(shí)際上是XML文檔，這些文檔帶有標(biāo)準(zhǔn)格式，并且是有效的。XMLSchema與DTD相比具有許多優(yōu)勢(shì)：XMLSchema是一個(gè)XML文檔，這意味著可以像處理任何其它文檔一樣處理模式；XMLSchema支持更多的數(shù)據(jù)類(lèi)型，還可擴(kuò)展出新的數(shù)據(jù)類(lèi)型；XMLSchema還有更強(qiáng)的表達(dá)能力。XML將SGML的豐富功能與HTML的易用性結(jié)合起來(lái)，以一種開(kāi)放的自我描述方式定義數(shù)據(jù)結(jié)構(gòu)，在描述數(shù)據(jù)內(nèi)容的同時(shí)能突出對(duì)結(jié)構(gòu)的描述，從而體現(xiàn)出數(shù)據(jù)之間的關(guān)系。下面來(lái)介紹XML幾個(gè)主要的優(yōu)點(diǎn)：（1）簡(jiǎn)便的數(shù)據(jù)交換。在XML中，數(shù)據(jù)和標(biāo)記均以可配置的文本格式保存?？梢杂肵ML編輯器編寫(xiě)XML文檔，一旦某些地方有錯(cuò)誤，完全可以直接檢查和修改文檔。同時(shí)，對(duì)于大量的數(shù)據(jù)，使用XML還是高效的。（2）自定制標(biāo)記語(yǔ)言?？梢允褂肵ML定制自己的標(biāo)記語(yǔ)言，這反映出XML強(qiáng)大的功能，例如化學(xué)標(biāo)記語(yǔ)言(CML)，允許用圖形描述復(fù)雜的分子式。不僅如此，當(dāng)別人基于XML創(chuàng)建了標(biāo)記語(yǔ)言，還可以很容易的添加使用這個(gè)擴(kuò)展。（3）自描述數(shù)據(jù)。XML在基本水平上使用的是非常簡(jiǎn)單的數(shù)據(jù)格式?？梢杂?00%的純ASCII文本來(lái)書(shū)寫(xiě)，也可以用幾種其他定義好的格式來(lái)書(shū)寫(xiě)。ASCII文本是幾乎不會(huì)“磨損”的，丟失一些字節(jié)甚至是相當(dāng)多的字節(jié)，剩下的數(shù)據(jù)還是可以讀取的。從高水平上來(lái)說(shuō)，XML是自描述的。（4）結(jié)構(gòu)化和綜合性的數(shù)據(jù)。XML的另一個(gè)功能強(qiáng)大之處在于，使用者不僅可以指定數(shù)據(jù)，還可以指定數(shù)據(jù)的結(jié)構(gòu)，并可以將不同的元素組合成其它的元素。這一點(diǎn)對(duì)于處理重要的復(fù)雜數(shù)據(jù)極為重要。3.2.2XML文檔的讀寫(xiě)這里介紹兩個(gè)XML文檔讀寫(xiě)的API（應(yīng)用編程接口）標(biāo)準(zhǔn)：SAX和DOM。（1）SAX(SimpleAPIforXML)：SAX是讀取和操作XML數(shù)據(jù)的快速、輕量的方法。SAX是一個(gè)基于事件的處理器，允許處理元素、屬性以及出現(xiàn)在原先文檔中的其他數(shù)據(jù)。由于具有這樣一種體系結(jié)構(gòu)，SAX是一個(gè)只讀的系統(tǒng)，但是那并不會(huì)阻止使用數(shù)據(jù)。這種處理的優(yōu)點(diǎn)非常類(lèi)似于流媒體的優(yōu)點(diǎn)。分析能夠立即開(kāi)始，而不是等待所有的數(shù)據(jù)被處理。而且，由于應(yīng)用程序只是在讀取數(shù)據(jù)時(shí)檢查數(shù)據(jù)，因此不需要將數(shù)據(jù)存儲(chǔ)在內(nèi)存中。這對(duì)于大型文檔來(lái)說(shuō)是個(gè)巨大的優(yōu)點(diǎn)。事實(shí)上，應(yīng)用程序甚至不必解析整個(gè)文檔；它可以在某個(gè)條件得到滿足時(shí)停止解析。一般來(lái)說(shuō)，SAX比DOM快許多。（2）DOM（DocumentObjectModel：文檔對(duì)象模型）：是以層次結(jié)構(gòu)組織的節(jié)點(diǎn)或信息片斷的集合。這個(gè)層次結(jié)構(gòu)允許開(kāi)發(fā)人員在樹(shù)中導(dǎo)航以尋找特定信息。分析該結(jié)構(gòu)通常需要加載整個(gè)文檔和構(gòu)造層次結(jié)構(gòu)，然后才能做任何工作。由于它是基于信息層次的，因而DOM被認(rèn)為是基于樹(shù)或基于對(duì)象的。DOM是設(shè)計(jì)用于使用XML數(shù)據(jù)的、與語(yǔ)言和平臺(tái)無(wú)關(guān)的API。這是一個(gè)基于樹(shù)的API，它將所有數(shù)據(jù)作為節(jié)點(diǎn)的父子層次加載到內(nèi)存中，這些節(jié)點(diǎn)可以是元素、文本、屬性或其他節(jié)點(diǎn)類(lèi)型。DOMAPI允許開(kāi)發(fā)人員讀取、創(chuàng)建和編輯XML數(shù)據(jù)。DOM提供了一組豐富的功能，可以用這些功能來(lái)解釋和操作XML文檔，但使用它們是有代價(jià)的。DOM存在以下幾個(gè)問(wèn)題：DOM構(gòu)建整個(gè)文檔駐留內(nèi)存的樹(shù)，如果文檔很大，就會(huì)要求有極大的內(nèi)存；DOM創(chuàng)建表示原始文檔中每個(gè)東西的對(duì)象，包括元素、文本、屬性和空格，如果只需關(guān)注原始文檔的一小部分，那么創(chuàng)建那些永遠(yuǎn)不被使用的對(duì)象是極其浪費(fèi)的；DOM解析器必須在代碼取得控制權(quán)之前讀取整個(gè)文檔，這對(duì)于非常大的文檔，會(huì)引起顯著的延遲。這些僅僅是由文檔對(duì)象模型的設(shè)計(jì)引起的問(wèn)題，撇開(kāi)這些問(wèn)題，DOMAPI是解析XML文檔非常有用的方法。3.2.3XML在構(gòu)件測(cè)試自動(dòng)化框架中的應(yīng)用XML由于其所具有的上述優(yōu)點(diǎn)，特別適合于提高構(gòu)件測(cè)試的自動(dòng)化水平。它貫穿了本章所設(shè)計(jì)的構(gòu)件測(cè)試自動(dòng)化框架的整個(gè)流程，如圖3.3所示。圖3.3基于XML的構(gòu)件測(cè)試自動(dòng)化框架文檔關(guān)系圖下面對(duì)各個(gè)XML文檔逐一作介紹。（1）構(gòu)件測(cè)試元數(shù)據(jù)XML文件本文所要提出的構(gòu)件元數(shù)據(jù)的表示方式，其目的是：獲得構(gòu)件足夠豐富而且形式規(guī)范的信息，并能以一種通用的方式讓構(gòu)件使用者獲取測(cè)試所需的信息，進(jìn)而方便測(cè)試的自動(dòng)化。元數(shù)據(jù)具有一定的通用性，需要用一種標(biāo)準(zhǔn)的形式來(lái)描述，以滿足不同用戶的測(cè)試需求。目的是探索一種合適的構(gòu)件元數(shù)據(jù)表示方式。該構(gòu)件元數(shù)據(jù)表示方式適合描述構(gòu)件元數(shù)據(jù)信息，并且這種表示方式應(yīng)該可以讓構(gòu)件使用者或者計(jì)算機(jī)工具很方便處理構(gòu)件元數(shù)據(jù)。XML語(yǔ)言具有前面所提到的很多優(yōu)點(diǎn)，并且其具有很好的擴(kuò)展性，數(shù)據(jù)搜索準(zhǔn)確，軟硬件平臺(tái)無(wú)關(guān)，可以為不同的應(yīng)用程序所共享，在XML文件中定義的描述符還可以用于構(gòu)件自動(dòng)化測(cè)試的過(guò)程。因此，本文采用XML描述構(gòu)件元數(shù)據(jù)。使用XML文件格式表示的構(gòu)件元數(shù)據(jù)可以跨平臺(tái)共享和交換，實(shí)現(xiàn)了信息的可移植性，提高了構(gòu)件數(shù)據(jù)交換的通用性，也便于從中提取與測(cè)試相關(guān)的數(shù)據(jù)以及加工處理構(gòu)件元數(shù)據(jù)，為構(gòu)件測(cè)試方法的研究提供了有力的支持。有關(guān)構(gòu)件的元數(shù)據(jù)及其XML文檔的設(shè)計(jì)，將在下一章詳細(xì)介紹。（2）構(gòu)件測(cè)試用例XML文件在進(jìn)行構(gòu)件測(cè)試的時(shí)候，必須根據(jù)構(gòu)件測(cè)試規(guī)格說(shuō)明確定測(cè)試目標(biāo)，即測(cè)試需求的集合，再根據(jù)這些測(cè)試需求可以精心構(gòu)造出一組測(cè)試用例。這組測(cè)試用例的數(shù)量和質(zhì)量將決定構(gòu)件測(cè)試的成本和有效性。在本文設(shè)計(jì)的構(gòu)件測(cè)試自動(dòng)化框架中，構(gòu)件測(cè)試規(guī)格說(shuō)明是由自動(dòng)提取的構(gòu)件元數(shù)據(jù)輔助生成的，因此，構(gòu)件測(cè)試用例也應(yīng)當(dāng)是參考構(gòu)件元數(shù)據(jù)進(jìn)行設(shè)計(jì)。當(dāng)然，構(gòu)件開(kāi)發(fā)方也提供了一份構(gòu)件測(cè)試規(guī)格說(shuō)明，其中有一些指定的輸入和預(yù)期輸出，可以直接作為測(cè)試用例。但是，構(gòu)件開(kāi)發(fā)方提供的文檔通常是不詳細(xì)的，而為了可靠地使用構(gòu)件，必須對(duì)構(gòu)件進(jìn)行充分的測(cè)試，需要大量、有效的測(cè)試用例，這就只能依靠分析構(gòu)件的元數(shù)據(jù)來(lái)進(jìn)行設(shè)計(jì)。因此，構(gòu)件元數(shù)據(jù)才是設(shè)計(jì)測(cè)試用例的主要依據(jù)。傳統(tǒng)的手工軟件測(cè)試方法，測(cè)試用例一般用WORD文檔或Excel表的形式表示，測(cè)試人員對(duì)照測(cè)試用例逐個(gè)執(zhí)行。而要實(shí)現(xiàn)構(gòu)件測(cè)試的自動(dòng)化，必須使測(cè)試驅(qū)動(dòng)程序能夠直接讀取測(cè)試用例文件，并自動(dòng)執(zhí)行。XML語(yǔ)言強(qiáng)大的數(shù)據(jù)描述能力和方便快捷的解析手段，使XML語(yǔ)言成為構(gòu)件測(cè)試的最佳用例描述語(yǔ)言。對(duì)于COM構(gòu)件來(lái)說(shuō)，構(gòu)件的接口結(jié)構(gòu)信息是非常重要的元數(shù)據(jù)。而COTS構(gòu)件通常是源代碼不可得、文檔不詳細(xì)的，因此只能采用對(duì)接口的黑盒測(cè)試策略來(lái)設(shè)計(jì)測(cè)試用例。常用的基于接口參數(shù)的黑盒測(cè)試用例選取方法是對(duì)每個(gè)接口參數(shù)采用邊界值分析法和等價(jià)類(lèi)劃分法等選取一組測(cè)試用例，然后在這些取值組合中隨機(jī)選取一組測(cè)試用例。如：對(duì)整型可取其默認(rèn)值、典型值、邊界值和邊界附近的值，對(duì)字符串型則可對(duì)其長(zhǎng)度取邊界值。另外，有時(shí)預(yù)期輸出無(wú)法得到，如對(duì)字符串長(zhǎng)度越界取值輸入時(shí)，可觀察構(gòu)件執(zhí)行時(shí)是否拋出異常。這樣產(chǎn)生的測(cè)試用例從兩個(gè)方面來(lái)講是不完備的：測(cè)試用例僅覆蓋了單個(gè)參數(shù)的邊界值情況，對(duì)于多個(gè)參數(shù)組合的情況沒(méi)有考慮；測(cè)試用例僅覆蓋了單個(gè)接口的測(cè)試情況，沒(méi)有考慮多個(gè)接口組合構(gòu)成測(cè)試場(chǎng)景的情況。這種方法產(chǎn)生的測(cè)試用例雖然不是完備的，但簡(jiǎn)單易行，在一定程度上減少了設(shè)計(jì)測(cè)試用例的工作量。下面給出一個(gè)實(shí)現(xiàn)了加法計(jì)算的簡(jiǎn)單COM構(gòu)件simple.dll的測(cè)試用例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>其中，一個(gè)COM構(gòu)件對(duì)應(yīng)一個(gè)TestSuites，每個(gè)CoClass對(duì)應(yīng)一個(gè)TestSuite，每個(gè)待測(cè)試的方法對(duì)應(yīng)多個(gè)測(cè)試用例。每個(gè)測(cè)試用例給出一組輸入?yún)?shù)和預(yù)期輸出參數(shù)（預(yù)期輸出參數(shù)也可為空），每個(gè)參數(shù)指出其名字和類(lèi)型。此測(cè)試用例XML文件中的輸入?yún)?shù)和預(yù)期輸出參數(shù)既可以自動(dòng)生成也可手動(dòng)填寫(xiě)，測(cè)試驅(qū)動(dòng)程序讀取測(cè)試用例到測(cè)試腳本中時(shí)可以使用前面提到的XML文檔讀寫(xiě)的API，簡(jiǎn)單方便。（3）測(cè)試日志XML文件測(cè)試日志是對(duì)測(cè)試結(jié)果的描述，記錄測(cè)試的執(zhí)行情況，測(cè)試人員通過(guò)察看測(cè)試日志來(lái)確定測(cè)試是否通過(guò)。測(cè)試日志采用XML語(yǔ)言來(lái)表示。測(cè)試日志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>日志中，每次構(gòu)件的測(cè)試都給出時(shí)間戳，即完成測(cè)試時(shí)的準(zhǔn)確日期、時(shí)間。接下來(lái)，對(duì)每個(gè)被測(cè)方法，給出報(bào)告，包括方法名、方法所屬的接口名、實(shí)現(xiàn)該接口的CoClass名、測(cè)試時(shí)的輸入和輸出參數(shù)、測(cè)試的結(jié)果狀態(tài)。其中，輸入和輸出參數(shù)的描述與測(cè)試用例XML文檔中的相似，只不過(guò)輸出參數(shù)為實(shí)際輸出值，而不是指期望值。如果測(cè)試中發(fā)生意外的異常，日志還將記錄異常的類(lèi)型和描述信息。測(cè)試的結(jié)果狀態(tài)則包括通過(guò)（Passed）、忽略（Ignored）、失?。‵ailed），分別對(duì)應(yīng)于輸出符合期望、方法跳過(guò)未測(cè)試、輸出不符合期望或發(fā)生意外異常三種情況。最后給出此次構(gòu)件測(cè)試的摘要，包括測(cè)試方法總數(shù)、通過(guò)數(shù)、忽略數(shù)和失敗數(shù)。測(cè)試者既可對(duì)單個(gè)方法失敗分析原因、采取措施，又可對(duì)該構(gòu)件的整體質(zhì)量有個(gè)大致的了解。（4）測(cè)試項(xiàng)目配置XML文件測(cè)試項(xiàng)目配置文件用于組織項(xiàng)目中各種文件的路徑信息，相當(dāng)于測(cè)試項(xiàng)目的全局環(huán)境變量，也用XML格式對(duì)其描述：<?xmlversion="1.0"encoding="utf-8"?><Configuration> <ProjectPathdirectory-name=""/> <COMComponentfile-name=""/> <ComponentMetadatafile-name=""/> <TestCasefile-name=""/> <TestScriptfile-name=""/> <TestLogfile-name=""/></Configuration>其中保存了項(xiàng)目路徑、COM構(gòu)件、構(gòu)件元數(shù)據(jù)、測(cè)試用例、測(cè)試腳本、測(cè)試日志的引用信息。在構(gòu)件測(cè)試自動(dòng)化框架的流程中，各個(gè)階段都需要對(duì)其中的內(nèi)容進(jìn)行讀寫(xiě)。3.3測(cè)試腳本生成自動(dòng)化3.3.1構(gòu)件單元測(cè)試框架要在測(cè)試自動(dòng)化框架下進(jìn)行基于腳本的測(cè)試，設(shè)計(jì)什么樣的測(cè)試腳本就取決于本文所選取的測(cè)試自動(dòng)化框架。在單元測(cè)試領(lǐng)域最有名的這樣的框架就是xUnit框架。本文的構(gòu)件測(cè)試自動(dòng)化框架也將主要基于xUnit框架。xUnit框架是測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（Test-DrivenDevelopment，TDD）軟件開(kāi)發(fā)方法中首先推出的。測(cè)試驅(qū)動(dòng)開(kāi)發(fā)是近年來(lái)興起的一種軟件開(kāi)發(fā)方法。TDD是極限編程（eXtremeProgramming，XP）思想的一種主要實(shí)踐，可以讓開(kāi)發(fā)人員有效地開(kāi)發(fā)出高品質(zhì)、經(jīng)過(guò)完整測(cè)試的程序。“測(cè)試先行”是TDD的重要思想。TDD一改傳統(tǒng)開(kāi)發(fā)模式中單元測(cè)試在編寫(xiě)代碼之后進(jìn)行，將單元測(cè)試移到正式編碼之前，以不斷的測(cè)試來(lái)推動(dòng)代碼的開(kāi)發(fā)，這樣，既簡(jiǎn)化了代碼、降低了開(kāi)銷(xiāo)，又保證了軟件質(zhì)量、提高了開(kāi)發(fā)效率。測(cè)試框架是TDD的關(guān)鍵，尤其是在需要用大量測(cè)試來(lái)實(shí)現(xiàn)需求的情況下。如果完全靠手工來(lái)執(zhí)行測(cè)試，會(huì)變成一個(gè)花費(fèi)大量時(shí)間而且單調(diào)無(wú)味的工作。利用測(cè)試框架對(duì)測(cè)試進(jìn)行自動(dòng)驗(yàn)收，可以讓開(kāi)發(fā)人員簡(jiǎn)單地進(jìn)入測(cè)試接口，輸入相關(guān)的輸入并得到期望的輸出。TDD在實(shí)際應(yīng)用中，關(guān)注的是函數(shù)的入口與出口，而不是函數(shù)的內(nèi)部邏輯本身。xUnit框架是自動(dòng)化手寫(xiě)腳本的開(kāi)源測(cè)試自動(dòng)化框架家族。隨著xUnit框架和TDD開(kāi)發(fā)方法越來(lái)越流行，使得目前大多數(shù)廣泛使用的編程語(yǔ)言都至少有xUnit的一種實(shí)現(xiàn)，比較流行的有JUnit（Java），SUnit（Smalltalk），CppUnit（C++），NUnit（所有.NET語(yǔ)言），runit（Ruby），PyUnit（Python），VbUnit（VisualBasic）等。xUnit框架的總體設(shè)計(jì)依賴(lài)于幾個(gè)組成部分：（1）測(cè)試固定設(shè)施（TestFixture）測(cè)試固定設(shè)施是一個(gè)測(cè)試運(yùn)行所需的前置條件或狀態(tài)的集合，也被稱(chēng)作測(cè)試上下文。通常它至少包含所測(cè)試的方法所屬類(lèi)的一個(gè)實(shí)例。（2）測(cè)試套裝（TestSuites）一個(gè)測(cè)試套裝就是共享相同的固定設(shè)施的測(cè)試的集合。（3）測(cè)試執(zhí)行（TestExecution）一個(gè)單獨(dú)的單元測(cè)試的執(zhí)行如下進(jìn)行：setupsetup();……/*測(cè)試主體*/……teardown();setup()和teardown()方法用來(lái)初始化和清理測(cè)試固定設(shè)施。（4）斷言（Assertions）斷言是驗(yàn)證被測(cè)試單元行為的函數(shù)或宏。它被用于構(gòu)造自檢查的測(cè)試。典型的斷言失敗將拋出一個(gè)異常，同時(shí)退出當(dāng)前測(cè)試的執(zhí)行。另外還有測(cè)試驅(qū)動(dòng)（TestRunner），它負(fù)責(zé)驅(qū)動(dòng)TestSuites的執(zhí)行。主要有圖形和命令行兩種方式。它要進(jìn)行測(cè)試方法發(fā)現(xiàn)，選擇一個(gè)或多個(gè)測(cè)試運(yùn)行。所有xUnit家族成員都實(shí)現(xiàn)了基本特征集合，它們提供了執(zhí)行下面任務(wù)的方式：（1）指定一個(gè)測(cè)試為測(cè)試方法；（2）以斷言方法調(diào)用的形式在測(cè)試方法中指出期望的結(jié)果，通過(guò)比較實(shí)際輸出與期望結(jié)果是否相等，對(duì)測(cè)試結(jié)果進(jìn)行驗(yàn)證；（3）將多個(gè)測(cè)試集中到可一次運(yùn)行的測(cè)試套裝（TestSuite）中；（4）運(yùn)行一個(gè)或多個(gè)測(cè)試來(lái)獲得測(cè)試運(yùn)行結(jié)果報(bào)告。每個(gè)測(cè)試由一個(gè)實(shí)現(xiàn)了四階段測(cè)試的測(cè)試方法表示，如圖3.4所示。這是從測(cè)試者視角所見(jiàn)到的靜態(tài)測(cè)試結(jié)構(gòu)，是“編譯時(shí)視圖”。四階段為：（1）建立（Setup）建立測(cè)試固定設(shè)施（TestFixture）。（2）執(zhí)行（Exercise） 通過(guò)與公共或私有接口中的方法交互運(yùn)行被測(cè)軟件（SoftwareUnderTest，SUT）。（3）驗(yàn)證（Verify）通過(guò)調(diào)用斷言方法驗(yàn)證期望結(jié)果是否出現(xiàn)。圖3.4xUnit框架四階段測(cè)試（4）拆卸（Teardown）拆卸測(cè)試固定設(shè)施。對(duì)構(gòu)件中方法的測(cè)試通常有著相同的測(cè)試邏輯和稍有不同的系統(tǒng)輸入，因此考慮將測(cè)試邏輯與測(cè)試用例相分離，這樣一來(lái)，既獲得了較好的測(cè)試覆蓋，又能最小化需要編寫(xiě)與維護(hù)的測(cè)試代碼量。因此，不能簡(jiǎn)單地依賴(lài)于xUnit框架。本文設(shè)計(jì)的構(gòu)件測(cè)試自動(dòng)化框架將對(duì)xUnit框架進(jìn)行改進(jìn)，把xUnit框架與前文提到的數(shù)據(jù)驅(qū)動(dòng)測(cè)試的策略結(jié)合起來(lái)。數(shù)據(jù)驅(qū)動(dòng)的測(cè)試框架定義了一種用于測(cè)試的高級(jí)語(yǔ)言，并用數(shù)據(jù)驅(qū)動(dòng)測(cè)試解釋器實(shí)現(xiàn)該語(yǔ)言，讀取測(cè)試用例數(shù)據(jù)，執(zhí)行測(cè)試。Fit就是一種開(kāi)源的數(shù)據(jù)驅(qū)動(dòng)的測(cè)試框架。Fit通常被用來(lái)自動(dòng)化用戶測(cè)試。Fit包含兩部分：框架、用戶建立的固定設(shè)施。Fit框架是一個(gè)通用的數(shù)據(jù)驅(qū)動(dòng)測(cè)試的解釋器，它讀取輸入文件并找到其中全部表格。Fit固定設(shè)施則是Fit調(diào)用的適配器，來(lái)解釋數(shù)據(jù)表格并調(diào)用被測(cè)軟件的方法。xUnit框架是單元測(cè)試框架，而數(shù)據(jù)驅(qū)動(dòng)的測(cè)試框架則適合于用戶測(cè)試。第三方COM構(gòu)件則需要用戶對(duì)其進(jìn)行黑盒單元測(cè)試，因此將二者結(jié)合切實(shí)可行。為了應(yīng)用數(shù)據(jù)驅(qū)動(dòng)的測(cè)試策略，本框架設(shè)計(jì)了單獨(dú)的測(cè)試用例XML文件，用來(lái)存儲(chǔ)輸入和期望值。這些數(shù)據(jù)將被傳遞到測(cè)試腳本中。這樣，原先的測(cè)試就成為參數(shù)化測(cè)試，由測(cè)試驅(qū)動(dòng)擔(dān)當(dāng)數(shù)據(jù)驅(qū)動(dòng)測(cè)試解釋器的角色，向測(cè)試腳本傳遞參數(shù)，包括輸入值和期望值。而共同的測(cè)試邏輯則包括測(cè)試方法的調(diào)用和斷言的調(diào)用。在具體實(shí)現(xiàn)兩者的結(jié)合時(shí)，最簡(jiǎn)單的方法是在測(cè)試方法中包含一個(gè)循環(huán)來(lái)從測(cè)試用例文件中讀取輸入數(shù)據(jù)值和期望結(jié)果的集合。但這將導(dǎo)致一個(gè)單獨(dú)的測(cè)試用例對(duì)象帶有許多斷言。由此而來(lái)的結(jié)果是：（1）執(zhí)行的所有測(cè)試用例將被視作一個(gè)測(cè)試，這樣將減少執(zhí)行的測(cè)試的計(jì)數(shù)。（2）測(cè)試將在第一個(gè)失敗處停止。這正是xUnit框架對(duì)于用戶測(cè)試存在的不足。這個(gè)缺點(diǎn)飽受那些想使用xUnit自動(dòng)化多步用戶測(cè)試的人們的批評(píng)。用xUnit框架進(jìn)行構(gòu)件測(cè)試，對(duì)于