1、面向?qū)ο筌浖y(cè)試綜述摘要：面向?qū)ο蟮能浖y(cè)試是面向?qū)ο筌浖_(kāi)發(fā)的不可缺少的一環(huán)，是保證軟件質(zhì)量、提高軟件可靠性的關(guān)鍵。結(jié)合傳統(tǒng)軟件測(cè)試的方法和技術(shù)，并針對(duì)面向?qū)ο筌浖哂械奶卣?，將面向?qū)ο筌浖y(cè)試層次 劃分為三層：類測(cè)試、類簇測(cè)試和系統(tǒng)測(cè)試。本文闡述了面向?qū)ο筌浖y(cè)試的基本原理及意義以及它與傳統(tǒng)軟件測(cè)試的區(qū)別，討論了幾種已有的面向?qū)ο蟮能浖y(cè)試工具。關(guān)鍵詞：軟件測(cè)試;類測(cè)試;測(cè)試工具;Abstract:Object-oriented software testing is indispensable to the development of object-oriented software

2、,and is the key to software quality and reliability.Combining with the method and technique of traditional testing,and according to the characteristics of object-oriented software,divides hiberarchy of object-oriented software testing into three layers: class testing,class cluster testing,system tes

3、ting. This paper describes the basic principles and the significance of object-oriented software testing.It also says the distinction of the traditional software testing and the object-oriented software testing.，and it discusses several existing object-oriented software testing tools.Keywords:softwa

4、re testing;class testing;testing tools;1、引言軟件測(cè)試在軟件生存期中占有非常突出的重要位置。測(cè)試的目的就是在軟件投入生產(chǎn)性運(yùn)行之前，盡可能多地發(fā)現(xiàn)軟件中的錯(cuò)誤。 隨著軟件的質(zhì)量和可靠性越來(lái)越受到人們的關(guān)注，軟件測(cè)試作與之相應(yīng)的重要保障手段之一也越來(lái)越得到重視。自20世紀(jì)80年代以來(lái)，面向?qū)ο蠓椒ê图夹g(shù)的研究已遍及計(jì)算機(jī)軟件、硬件和應(yīng)用各領(lǐng)域，在軟件工程領(lǐng)域更是得到了廣泛的重視，但研究的重點(diǎn)和成果主要集中于面向?qū)ο蠓治雠c技術(shù)方法學(xué)領(lǐng)域（即軟件的開(kāi)發(fā)前期），而面向?qū)ο筌浖y(cè)試技術(shù)的研究還比較薄弱。面向?qū)ο筌浖姆忾]性、繼承性、多態(tài)性和動(dòng)態(tài)連接等特性使面向?qū)ο?/p>

5、軟件測(cè)試不能完全采用傳統(tǒng)的測(cè)試思想和方法，面向?qū)ο筌浖y(cè)試的研究成為十分緊迫的任務(wù)。國(guó)內(nèi)外面向?qū)ο筌浖y(cè)試目前還處于探索性的研究階段，其層次的劃分還未達(dá)成共識(shí)，但一般地，從面向?qū)ο蟪绦虻慕Y(jié)構(gòu)出發(fā)，將面向?qū)ο筌浖臏y(cè)試分為四個(gè)層次：方法測(cè)試、類測(cè)試、類簇測(cè)試、系統(tǒng)測(cè)試。其中方法測(cè)試和系統(tǒng)測(cè)試可采用傳統(tǒng)的測(cè)試進(jìn)行測(cè)試，但類測(cè)試和類簇測(cè)試是面向?qū)ο鬁y(cè)試過(guò)程所特有的，不能直接使用傳統(tǒng)測(cè)試方法。目前，有關(guān)類簇測(cè)試的研究還很少，面向?qū)ο筌浖y(cè)試的研究主要集中于類測(cè)試。2 、軟件測(cè)試技術(shù)軟件測(cè)試就是“為了發(fā)現(xiàn)程序中的錯(cuò)誤而執(zhí)行程序的過(guò)程”，所以為了發(fā)現(xiàn)程序中的錯(cuò)誤，力求設(shè)計(jì)出最能暴露錯(cuò)誤的測(cè)試方案。所以軟件

6、測(cè)試決不能證明程序是正確的。即使經(jīng)過(guò)了最嚴(yán)格的測(cè)試之后，仍然可能還有沒(méi)被發(fā)現(xiàn)的錯(cuò)誤潛藏在程序中。測(cè)試只能查找出程序中的錯(cuò)誤，不能證明程序中沒(méi)有錯(cuò)誤。2.1軟件測(cè)試的方法2.2.1 黑盒測(cè)試黑盒測(cè)試又稱為功能測(cè)試，是一種面向設(shè)計(jì)的測(cè)試。這種測(cè)試在完全不考慮測(cè)試對(duì)象內(nèi)部結(jié)構(gòu)的情況下，把被測(cè)程序當(dāng)作一個(gè)黑盒，根據(jù)程序的功能和外部特性得到測(cè)試數(shù)據(jù)。進(jìn)行黑盒測(cè)試在所必須具備的文檔有產(chǎn)品描述、用戶文檔及安裝指令。軟件的黑盒測(cè)試被用來(lái)證實(shí)軟件功能的正確性和可操作性。2.2.2 白盒測(cè)試白盒測(cè)試是假定測(cè)試對(duì)象的內(nèi)部是已知的，允許測(cè)試者檢查測(cè)試對(duì)象的內(nèi)部結(jié)構(gòu)，并使用其結(jié)構(gòu)信息來(lái)設(shè)計(jì)測(cè)試安全和測(cè)試對(duì)象是否滿足規(guī)范

7、的要求，測(cè)試者可以完全不考慮測(cè)試對(duì)象的功能。進(jìn)行白盒測(cè)試所具備的文檔有設(shè)計(jì)文檔和程序文檔。2.2 傳統(tǒng)軟件測(cè)試的步驟傳統(tǒng)的軟件測(cè)試過(guò)程可以按四個(gè)步驟進(jìn)行，即單元測(cè)試、集成測(cè)試、確認(rèn)測(cè)試和系統(tǒng)測(cè)試。2.3.1 單元測(cè)試單元測(cè)試是完成對(duì)最小軟件設(shè)計(jì)單位程序模塊，進(jìn)行正確性檢驗(yàn)的測(cè)試工作，其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種錯(cuò)誤。單元測(cè)試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測(cè)試用例，即采用白盒測(cè)試方法，而且多個(gè)模塊并行地進(jìn)行單元測(cè)試。2.3.2 集成測(cè)試在每個(gè)模塊完成單元測(cè)試以后，需要按照設(shè)計(jì)時(shí)畫(huà)出的結(jié)構(gòu)圖，把它們連接起來(lái)，進(jìn)行集成測(cè)試。2.3.3 確認(rèn)測(cè)試確認(rèn)測(cè)試的任務(wù)就是進(jìn)一步檢查軟件的功能和性能是否

8、與用戶要求的一樣。它通過(guò)一系列證明軟件功能和需求一致的黑盒測(cè)試來(lái)完成。2.3.4 系統(tǒng)測(cè)試系統(tǒng)測(cè)試是將已經(jīng)通過(guò)確認(rèn)測(cè)試的軟件，作為整個(gè)基于計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其它系統(tǒng)元素結(jié)合在一起，在實(shí)際運(yùn)行環(huán)境下，對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的集成測(cè)試和確認(rèn)測(cè)試。系統(tǒng)測(cè)試的目的在于通過(guò)與系統(tǒng)的需求定義作比較，發(fā)現(xiàn)軟件與系統(tǒng)定義不符合或與之矛盾的地方。3 、面向?qū)ο蟮能浖y(cè)試在面向?qū)ο蠓治鲈O(shè)計(jì)方法中，基本的構(gòu)成是類和對(duì)象。對(duì)象是封裝了描述其屬性的數(shù)據(jù)（對(duì)象的狀態(tài)）以及可以對(duì)這些數(shù)據(jù)實(shí)施的操作，對(duì)象之間通過(guò)改善消息相互協(xié)作。類是一組相似對(duì)象的描述，描述了該類對(duì)象所具有的

9、共同特征。面向?qū)ο蟮某绦蛟O(shè)計(jì)又提供了信息隱蔽、繼承、金礦和動(dòng)態(tài)綁定等機(jī)制。這種軟件開(kāi)發(fā)方法固有的特性，給軟件測(cè)試?yán)碚?、技術(shù)、方法等方面帶來(lái)了巨大的影響，使得傳統(tǒng)的軟件測(cè)試方法以及測(cè)試工具已不能為面向?qū)ο蟮能浖峁┝己玫闹С帧?.1 面向?qū)ο筌浖y(cè)試的特點(diǎn)面向?qū)ο蟪绦蚪Y(jié)構(gòu)不再是傳統(tǒng)的功能模塊結(jié)構(gòu)，作為一個(gè)整體，原有集成測(cè)試所要求的逐步將開(kāi)發(fā)的模塊搭建在一起進(jìn)行測(cè)試的方法已成為不可能。面向?qū)ο筌浖仐壛藗鹘y(tǒng)的開(kāi)發(fā)模式，對(duì)每個(gè)開(kāi)發(fā)階段都有不同以往的要求和結(jié)果,已經(jīng)不可能用功能細(xì)化的觀點(diǎn)來(lái)檢測(cè)面向?qū)ο蠓治龊驮O(shè)計(jì)的結(jié)果。傳統(tǒng)的測(cè)試模型對(duì)面向?qū)ο筌浖呀?jīng)不再適用。3.2面向?qū)ο蟮奶攸c(diǎn)對(duì)軟件測(cè)試的影響3.2

10、.1基本構(gòu)造模塊在面向?qū)ο笙到y(tǒng)中，系統(tǒng)的基本構(gòu)造模塊是封裝了數(shù)據(jù)和方法的類和對(duì)象，而不再是一個(gè)個(gè)能完成特定功能的功能模塊。每個(gè)對(duì)象有自己的生存周期，有自己的狀態(tài)。消息是對(duì)象之間相互請(qǐng)求或協(xié)作的途徑，是外界使用對(duì)象方法及獲取對(duì)象狀態(tài)的唯一方式。對(duì)象的功能是在消息的觸發(fā)下，由對(duì)象所屬類中定義的方法與相關(guān)對(duì)象的合作共同完成的，且在不同狀態(tài)下對(duì)消息的響應(yīng)可能完全不同。工作過(guò)程中對(duì)象的狀態(tài)可能被改變，產(chǎn)生新的狀態(tài)。對(duì)象中的數(shù)據(jù)和方法是一個(gè)有機(jī)的整體，測(cè)試過(guò)程中不能僅僅檢查輸入數(shù)據(jù)產(chǎn)生的輸出結(jié)果是否與預(yù)期的吻合，還要考慮對(duì)象的狀態(tài)。模塊測(cè)試的概念已不適用于對(duì)象的測(cè)試。3.2.2系統(tǒng)功能實(shí)現(xiàn)在面向?qū)ο笙到y(tǒng)中

11、，系統(tǒng)的功能體現(xiàn)在對(duì)象間的協(xié)作上，而不再是簡(jiǎn)單的過(guò)程調(diào)用關(guān)系，面向?qū)ο蟪绦虻膱?zhí)行實(shí)際上是執(zhí)行一個(gè)由消息連接起來(lái)的方法序列，方法的實(shí)現(xiàn)與所屬對(duì)象本身的狀態(tài)有關(guān)，各方法之間可能有相互作用。為實(shí)現(xiàn)某一特定的功能，有可能要激活調(diào)用屬于不同對(duì)象類的多個(gè)成員函數(shù)，形成成員函數(shù)的啟用鏈。顯然，基于功能分解的自頂向下或自底向上的集成測(cè)試策略并不適用于以面向?qū)ο蠓椒?gòu)造的軟件。3.2.3信息隱蔽與封裝性類的重要特征之一是信息隱蔽與封裝性。它把數(shù)據(jù)和操縱數(shù)據(jù)的方法封裝在一起，限制對(duì)象屬性對(duì)外的可見(jiàn)性和外界對(duì)它的操作權(quán)限，這在一定程度上避免了不合理的操作并能有效地阻止錯(cuò)誤的擴(kuò)散，也減輕了維護(hù)工作量，但卻給測(cè)試帶來(lái)了

12、困難。為了檢查私有(private)和模塊處理對(duì)象類處理保護(hù)(Protected)的函數(shù)及數(shù)據(jù)，測(cè)試時(shí)往往要在類定義中添加一些專門的函數(shù)。另一方面，面向?qū)ο筌浖到y(tǒng)運(yùn)行時(shí)由一組協(xié)調(diào)工作的對(duì)象組成，對(duì)象具有一定的狀態(tài)，測(cè)試應(yīng)涉及對(duì)象的初態(tài)、輸人、輸出、對(duì)象的終態(tài)，信息隱蔽機(jī)制給對(duì)象狀態(tài)的觀察、測(cè)試用例的生成、測(cè)試點(diǎn)的選取等帶來(lái)了障礙，測(cè)試者往往要添加一些表明對(duì)象內(nèi)部狀態(tài)的函數(shù)。因此，信息隱蔽與封裝性加大了測(cè)試的難度。3.2.4繼承 繼承也是面向?qū)ο笳Z(yǔ)言中的一個(gè)本質(zhì)特征。繼承可用于一般與特殊關(guān)系，并目方便 編碼。但繼承削弱了封裝性，產(chǎn)生了類似于非面向?qū)ο笳Z(yǔ)言中全局?jǐn)?shù)據(jù)的錯(cuò)誤風(fēng)險(xiǎn)

13、。由 于繼承的作用，一個(gè)函數(shù)可能被封裝在具有繼承關(guān)系的多個(gè)類中，子類中還可以對(duì)繼承 的特征進(jìn)行覆蓋或重定義。多態(tài)性和動(dòng)態(tài)綁定多態(tài)性和動(dòng)態(tài)綁定是面向?qū)ο蠓椒ǖ年P(guān)鍵特性之一。同一消息可以根據(jù)接收消息對(duì)象的不同采用多種不同的行為方式，這就是多態(tài)的概念。如根據(jù)當(dāng)前指針引用的對(duì)象類型來(lái)決定使用正確的方法，這就是多態(tài)性行為操作。運(yùn)行時(shí)系統(tǒng)能自動(dòng)為給定消息選擇合適的實(shí)現(xiàn)代碼、這給程序員提供了高度柔性、問(wèn)題抽象和易于維護(hù)。但多態(tài)性和動(dòng)態(tài)綁定所帶來(lái)的不確定性，使得傳統(tǒng)測(cè)試實(shí)踐中的靜態(tài)分析法遇到了不可逾越的障礙。而且它們也增加了系統(tǒng)運(yùn)行中可能的執(zhí)行路徑，加大了測(cè)試用例的選取難度和數(shù)量。3.2面

14、向?qū)ο蟮臏y(cè)試與傳統(tǒng)測(cè)試的比較傳統(tǒng)軟件測(cè)試技術(shù)是面向過(guò)程的測(cè)試，是從輸入/處理/輸出的角度檢驗(yàn)一個(gè)函數(shù)或過(guò)程能否正確工作。而面向?qū)ο筌浖y(cè)試是針對(duì)相互協(xié)作而又彼此獨(dú)立的對(duì)象的測(cè)試。面向?qū)ο筌浖_(kāi)發(fā)的測(cè)試目標(biāo)與傳統(tǒng)的軟件開(kāi)發(fā)方法相同，都是為了確保軟件能正確地和一致地解決待解決的問(wèn)題，但由于過(guò)程性測(cè)試方法沒(méi)有考慮到面向?qū)ο筌浖臏y(cè)試所要涉及的類、繼承和多態(tài)性，因此這兩者是有很大不同的。測(cè)試單元的不同傳統(tǒng)軟件的基本構(gòu)成單元為功能模塊，每個(gè)功能模塊一般能獨(dú)立地完成一個(gè)特定的功能。而在面向?qū)ο蟮能浖校締卧欠庋b了數(shù)據(jù)和方法的類和對(duì)象。對(duì)象是類的實(shí)例，有自己的角色，并在系統(tǒng)中承擔(dān)特定的責(zé)任。對(duì)象有自己

15、的生存周期和狀態(tài)，狀態(tài)可以演變。對(duì)象的功能是在消息的觸發(fā)下，實(shí)現(xiàn)對(duì)象中若干方法的合成以及與其它對(duì)象的合作。對(duì)象中的數(shù)據(jù)和方法是一個(gè)有機(jī)整體，功能測(cè)試的概念不適用于對(duì)象的測(cè)試。系統(tǒng)構(gòu)成不同傳統(tǒng)的軟件系統(tǒng)是由一個(gè)個(gè)功能模塊通過(guò)過(guò)程調(diào)用關(guān)系組合而成的。而在面向?qū)ο蟮南到y(tǒng)中，系統(tǒng)的功能體現(xiàn)在對(duì)象間的協(xié)作上，相同的功能可能駐留在不同的對(duì)象中，操作序列是由對(duì)象間的消息傳遞決定的。傳統(tǒng)意義上的功能實(shí)現(xiàn)不再是靠子功能的調(diào)用序列完成的，而是在對(duì)象之間合作的基礎(chǔ)上完成的。不同對(duì)象有自己不同狀態(tài)，而且，同一對(duì)象在不同狀態(tài)下對(duì)消息的響應(yīng)可能完全不同。因此，面向?qū)ο蟮募蓽y(cè)試已不屬于功能集成測(cè)試。3.3面向?qū)ο筌浖y(cè)試

16、的層次劃分軟件測(cè)試層次是基于測(cè)試復(fù)雜性分解的思想，是軟件測(cè)試的一種基本模式。面向?qū)ο蟪绦虻慕Y(jié)構(gòu)不再是傳統(tǒng)的功能模塊結(jié)構(gòu)，作為一個(gè)整體，原有集成測(cè)試所要求的逐步將開(kāi)發(fā)的模塊組裝在一起進(jìn)行測(cè)試的方法已成為不可能。而且，面向?qū)ο筌浖仐壛藗鹘y(tǒng)的開(kāi)發(fā)模式，對(duì)每個(gè)開(kāi)發(fā)階段都有不同以往的要求和結(jié)果，已經(jīng)不可能用功能細(xì)化的觀點(diǎn)來(lái)檢測(cè)面向?qū)ο蠓治龊驮O(shè)計(jì)的結(jié)果。因此，傳統(tǒng)的測(cè)試模型對(duì)面向?qū)ο筌浖呀?jīng)不再適用。目前，對(duì)面向?qū)ο筌浖y(cè)試的層次劃分尚未達(dá)成共識(shí)。一般地，將面向?qū)ο筌浖臏y(cè)試分為3個(gè)層次：類測(cè)試、類簇測(cè)試、系統(tǒng)測(cè)試。3.3.1類測(cè)試面向?qū)ο筌浖念悳y(cè)試與傳統(tǒng)的單元測(cè)試相對(duì)應(yīng)，但和傳統(tǒng)的單元測(cè)試不一樣1。

17、類包含一組不同的操作，并且某特殊操作可能作為一組不同類的一部分存在。同時(shí)，一個(gè)對(duì)象有它自己的狀態(tài)和依賴于狀態(tài)的行為，對(duì)象操作既與對(duì)象的狀態(tài)有關(guān)，但也可能改變對(duì)象的狀態(tài)。所以，類操作時(shí)不僅要將操作作為類的一部分，同時(shí)要把對(duì)象與其狀態(tài)結(jié)合起來(lái)，進(jìn)行對(duì)象狀態(tài)行為的測(cè)試。類測(cè)試可以分為以下三個(gè)部分：(1) 基于方法的測(cè)試：測(cè)試類中的每個(gè)方法。(2) 基于狀態(tài)的測(cè)試：考察類的實(shí)例在其生命周期各個(gè)狀態(tài)下的情況。(3) 基于響應(yīng)的狀態(tài)測(cè)試：從類和對(duì)象的責(zé)任出發(fā)，以外界向?qū)ο蟾纳铺囟ǖ南⑿蛄衼?lái)測(cè)試對(duì)象?；诜?wù)的類測(cè)試主要考察封裝在類中的一個(gè)方法對(duì)數(shù)據(jù)進(jìn)行的操作。Kung等人提出的塊分支圖（Block Br

18、anch Diagram,簡(jiǎn)稱BBD）是一種比較好的方法測(cè)試模型（如圖1所示）。方法f的BBD是一個(gè)一元組，BBD=Du,Dd,P,Fe,G;Du=di|dif引用的全局?jǐn)?shù)據(jù)或類數(shù)據(jù);Dd=di|dif修改的全局?jǐn)?shù)據(jù)或類數(shù)據(jù);P=X11,X22,Xnn,Xn+1n+1f的參數(shù)表和函數(shù)返回值，i為輸入、輸出，或（輸入、輸出）;若Xn+1缺省，則無(wú)返回值;F=fi|fi被f調(diào)用的其他服務(wù);G是一個(gè)有向圖，叫做塊體。它是按照控制流圖的思想修改f的程序流程圖而來(lái)的，表示f的控制結(jié)構(gòu)中的符合條件判斷被分解，每個(gè)判斷框只有單個(gè)條件。3.3.2類簇測(cè)試類簇是一組相互合作的類。類簇測(cè)試主要考察一組協(xié)同操作的類

19、之間的相互作用，測(cè)試重點(diǎn)在類之間的邏輯關(guān)系關(guān)聯(lián)、繼承、聚合、多態(tài)，檢驗(yàn)類之間的相互配合。其測(cè)試用例可由多種方案結(jié)合生成。如根據(jù)類的繼承關(guān)系圖來(lái)縱向檢查類，同時(shí)又根據(jù)對(duì)象之間方法的相互作用來(lái)模量檢查類的關(guān)系。(1) 關(guān)聯(lián)和聚合關(guān)系的測(cè)試：將具有關(guān)聯(lián)和聚合關(guān)系的類組裝在一起，選擇其中主動(dòng)發(fā)送消息的類的測(cè)試用例為此測(cè)試的用例，加載驅(qū)動(dòng)程序運(yùn)行測(cè)試用例，檢驗(yàn)類間的傳遞與響應(yīng)。(2) 繼承關(guān)系的測(cè)試：和根據(jù)Weyuker的測(cè)試充分性公理對(duì)該問(wèn)題進(jìn)行了討論，認(rèn)為子類中方法和重定義的方法都必須在子類的環(huán)境中重新測(cè)試，對(duì)被繼承的方法是充分的測(cè)試數(shù)據(jù)集，對(duì)重定義的方法未必是充分的。對(duì)繼承關(guān)系的測(cè)試主要是對(duì)派生類

20、繼承部分的測(cè)試，它可重用父類的測(cè)試用例，利用回歸測(cè)試進(jìn)行，對(duì)派生類的非繼承部分需重新設(shè)計(jì)測(cè)試用例進(jìn)行類測(cè)試。(3) 多態(tài)/動(dòng)態(tài)綁定的測(cè)試：多態(tài)/動(dòng)態(tài)綁定顯著增加了系統(tǒng)運(yùn)行中可能的執(zhí)行路徑。由于多態(tài)/動(dòng)態(tài)綁定所帶來(lái)的不確定性，使得涉及多態(tài)實(shí)例變量的測(cè)試用例大幅度增長(zhǎng)。多態(tài)/動(dòng)態(tài)綁定實(shí)例變量的每一種可能取值應(yīng)至少在測(cè)試用例中出現(xiàn)一次。3.3.3系統(tǒng)測(cè)試系統(tǒng)測(cè)試是對(duì)所有類和主程序構(gòu)成的整個(gè)系統(tǒng)進(jìn)行整體測(cè)試，以驗(yàn)證軟件系統(tǒng)的正確性和性能指標(biāo)等滿足規(guī)格說(shuō)明書(shū)和任務(wù)書(shū)所指定的要求。它與傳統(tǒng)的系統(tǒng)測(cè)試一樣，可套用傳統(tǒng)的系統(tǒng)測(cè)試方法，區(qū)別僅豐于測(cè)試用例的形式有所不同，測(cè)試用例可以從對(duì)象行為模型和作為對(duì)象分析的

21、一部分的事件流圖中導(dǎo)出。3.4 面向?qū)ο筌浖臏y(cè)試方法53.4.1基于狀態(tài)的測(cè)試基于狀態(tài)的測(cè)試以類的有限狀態(tài)機(jī)模型 ( F S M ) 和其狀態(tài)轉(zhuǎn)換圖為依據(jù), 這種模型可以由軟件的代碼或規(guī)約生成, 也可采用如UM L 的狀態(tài)圖 。采用此方法進(jìn)行測(cè)試時(shí), 主要檢查由初態(tài)是否能正確地到達(dá)圖中的各個(gè)狀態(tài), 以及各個(gè)狀態(tài)之間的遷移是否能正確實(shí)現(xiàn) 。這種方法可以充分測(cè)試類中的各個(gè)方法和可能的狀態(tài), 符合類測(cè)試的特點(diǎn), 因此是當(dāng)前類測(cè)試中用得較多 、 研究得也較多的方法之一, 但其難點(diǎn)主要在于如何確定被測(cè)對(duì)象是否達(dá)到了正確的狀態(tài) ?；跔顟B(tài)的測(cè)試可以很容易地推廣到類簇測(cè)試, 只要我們能夠?yàn)轭惔亟⑦@樣的狀

22、態(tài)模型 ?；诜椒ㄐ蛄械臏y(cè)試面向?qū)ο蟪绦蛑蟹椒ǖ恼{(diào)用是有一定次序的, 如果違反了這個(gè)次序就會(huì)產(chǎn)生錯(cuò)誤 。方法序列規(guī)范Mtss(Method Sequence Specification)就是這樣一種規(guī)范, 它規(guī)定了類或類簇中方法的執(zhí)行順序, 如哪些方法必須按先后次序執(zhí)行, 哪些方法可以并發(fā)執(zhí)行等等 。 依據(jù)這樣的規(guī)約, 我們可以為類或類簇產(chǎn)生一些消息序列, 檢驗(yàn)這些類或類簇中的方法是否能夠正確地交互 。 文2 中較為詳細(xì)地介紹了Mtss產(chǎn)生測(cè)試用例的原理, 并根據(jù)一定的準(zhǔn)則對(duì)所產(chǎn)生的消息序列進(jìn)行了劃分, 另外還采用顛倒次序 、 遺漏和冗余等方法由正確的消息序列生成錯(cuò)誤的消息序列, 以測(cè)試程序的

23、健壯性 。 由于該方法沒(méi)有能夠考慮類的狀態(tài), 因此采用它進(jìn)行的測(cè)試是不完全的 。 這種方法常常與別的測(cè)試方法結(jié)合使用 。3.4.3基UML的測(cè)試 UML為面向?qū)ο筌浖峁┝藦?qiáng)大的建模工具, 同時(shí)它也可以作為測(cè)試的依據(jù).下面介紹的是幾種已被應(yīng)用于面向?qū)ο筌浖y(cè)試的UML模型: (1) 類圖3: 類圖描述了組成面向?qū)ο蟪绦虻母鱾€(gè)類之間的關(guān)系, 包括聯(lián)系、聚集、重?cái)?shù)、子類型和遞歸包含等.依據(jù)類圖可以確定各個(gè)類之間的層次關(guān)系，從而決定對(duì)類進(jìn)行測(cè)試的順序。 另外, 采用類圖可以生成檢驗(yàn)類之間關(guān)系是否正確實(shí)現(xiàn)的測(cè)試用例。(2) 順序圖3:順序圖描述對(duì)象之間動(dòng)態(tài)的交互關(guān)系, 著重體現(xiàn)對(duì)象間消息傳遞的時(shí)間順序

24、, 因此它可以作為類簇測(cè)試的依據(jù)。順序圖可以轉(zhuǎn)換為流程圖, 這種流程圖表示了對(duì)象間消息傳遞的順序, 與程序流程圖在形式上極為類似, 也包括了順序、分支和循環(huán)等 。采用基本路徑法可導(dǎo)出流程圖的基本路徑集, 路徑集中的每一條路徑都是一個(gè)消息序列, 即測(cè)試用例。(3) 狀態(tài)圖: 通常被用在基于狀態(tài)的測(cè)試中 。(4) 用例圖4:用例圖一般被用在系統(tǒng)測(cè)試中, 圖中的每一個(gè)用例都可以轉(zhuǎn)換為一個(gè)狀態(tài)模型, 然后參照狀態(tài)測(cè)試的方法進(jìn)行測(cè)試。4、軟件測(cè)試工具軟件測(cè)試是保證軟件系統(tǒng)正確性的一個(gè)重要手段,也是計(jì)算機(jī)軟件工程方法和技術(shù)的一個(gè)主要組成部分。但是,隨著軟件規(guī)模的增長(zhǎng)和程序設(shè)計(jì)語(yǔ)言的迅速發(fā)展,其低效率、高消

25、耗的特點(diǎn)卻使軟件測(cè)試工作變得越來(lái)越復(fù)雜。正是由于這種復(fù)雜性,用手工方法對(duì)軟件進(jìn)行測(cè)試,不僅容易出錯(cuò),在現(xiàn)實(shí)中也不可行。開(kāi)發(fā)軟件測(cè)試工具的目的就在于將復(fù)雜的測(cè)試工作自動(dòng)化或半自動(dòng)化,減少測(cè)試開(kāi)銷,同時(shí)大大增加在有限時(shí)間內(nèi)的測(cè)試。4.1 JunitJUnit是一個(gè)開(kāi)源的java單元測(cè)試框架。在1997年，由 Erich Gamma 和 Kent Beck 開(kāi)發(fā)完成。Junit測(cè)試是程序員測(cè)試，即所謂白盒測(cè)試，因?yàn)槌绦騿T知道被測(cè)試的軟件如果完成功能和完成什么樣的功能。Junit是一套框架繼承TestCase類，就可以用Junit進(jìn)行自動(dòng)測(cè)試了。4.2 Functional TesterRationa

26、l Functional Tester 是一個(gè)面向?qū)ο蟮淖詣?dòng)測(cè)試工具，它可以使您測(cè)試多種應(yīng)用程序。您可以通過(guò)記錄對(duì)應(yīng)用程序的測(cè)試來(lái)快速地生成腳本，并且您可以測(cè)試應(yīng)用程序中的任意對(duì)象，包括對(duì)象的屬性和數(shù)據(jù)。Rational Functional Tester 為您提供一個(gè)選擇腳本語(yǔ)言和開(kāi)發(fā)環(huán)境的機(jī)會(huì) Eclipse 框架中的 Java? 或者 Microsoft Visual Studio .NET 開(kāi)發(fā)環(huán)境中的 Microsoft Visual Basic .NET。將 Rational Functional Tester 集成到您的開(kāi)發(fā)平臺(tái)中可以把您帶到一個(gè)新的效率級(jí)別上。這是一個(gè)巨大的優(yōu)勢(shì)

27、，因?yàn)檫M(jìn)行安裝后，Rational Functional Tester 就成為您的本地開(kāi)發(fā)環(huán)境中的一個(gè)無(wú)縫部分。Rational Functional Tester 提供記錄和回放功能，并存儲(chǔ)Java 或 .NET 源代碼的記錄腳本。其允許您實(shí)際上不做任何工作就能創(chuàng)建可重復(fù)的測(cè)試腳本，也允許您使用您的程序設(shè)計(jì)技術(shù)用您本地的開(kāi)發(fā)語(yǔ)言來(lái)增強(qiáng)腳本以滿足具體的需求。4.3 PureLoadPureLoad正是一款基于Java開(kāi)發(fā)的網(wǎng)絡(luò)負(fù)壓測(cè)試工具，它的Script代碼完全使用XML，所以，這些代碼的編寫很簡(jiǎn)單，可以測(cè)試各種C/S程序，如SMTP Server等。它的測(cè)試報(bào)表包含文字和圖形并可以輸出為H

28、TML文件。由于是基于Java的軟件，所以，可以通過(guò)Java Beans API來(lái)增強(qiáng)軟件功能。 4.4 JMeter它最初被設(shè)計(jì)用于Web 應(yīng)用測(cè)試但后來(lái)擴(kuò)展到其他測(cè)試領(lǐng)域。Apache JMeter 可以用于對(duì)靜態(tài)的和動(dòng)態(tài)的資源（文件，Servlet，Perl 腳本，Java 對(duì)象，數(shù)據(jù)庫(kù)和查詢，F(xiàn)TP服務(wù)器等等）的性能進(jìn)行測(cè)試。它可以用于對(duì)服務(wù)器，網(wǎng)絡(luò) 或?qū)ο竽M繁重的負(fù)載來(lái)測(cè)試它們的強(qiáng)度或分析不同壓力類型下的整體性能。你可以 使用它做性能的圖形分析或在大并發(fā)負(fù)載測(cè)試你的服務(wù)器/腳本/對(duì)象。Apache JMeter 的特性包括：能夠?qū)?HTTP 和 FTP 服務(wù)器進(jìn)行壓力和性能測(cè)試，

29、也可以對(duì)任何數(shù)據(jù)庫(kù)進(jìn)行同樣的測(cè)試（通過(guò) JDBC）。 完全的可移植性和 100 純 Java。 完全 Swing 和輕量組件支持（預(yù)編譯的 JAR 使用javax.swing.*)包。 完全多線程 框架允許通過(guò)多個(gè)線程并發(fā)取樣和 通過(guò)單獨(dú)的線程組對(duì)不同的功能同時(shí)取樣。 精心的 GUI 設(shè)計(jì)允許快速操作和更精確的計(jì)時(shí)。 緩存和離線分析/回放測(cè)試結(jié)果。 高可擴(kuò)展性： 可鏈接的取樣器允許無(wú)限制的測(cè)試能力。 各種負(fù)載統(tǒng)計(jì)表和可鏈接的計(jì)時(shí)器可供選擇。 數(shù)據(jù)分析和可視化插件提供了很好的可擴(kuò)展性以及 以及個(gè)性化。 具有提供動(dòng)態(tài)輸入到測(cè)試的功能（包括 JavaScript）。 支持腳本變成的取樣器（在1.9.

30、2 及以上版本支持 BeanShell）。 4.5 TestDirector基于WEB的測(cè)試管理工具，他能夠讓你系統(tǒng)地控制整個(gè)測(cè)試過(guò)程，并創(chuàng)建整個(gè)測(cè)試工作流的框架和基礎(chǔ)，使整個(gè)測(cè)試管理過(guò)程變得更為簡(jiǎn)單和有組織。他能夠幫助你維護(hù)一個(gè)測(cè)試工程數(shù)據(jù)庫(kù)，并且能夠覆蓋你的應(yīng)用程序功能性的各個(gè)方面。T并且還為你提供了直觀和有效的方式來(lái)計(jì)劃和執(zhí)行測(cè)試集、收集測(cè)試結(jié)果并分析數(shù)據(jù)。還專門提供了一個(gè)完善的缺陷跟蹤系統(tǒng)。并可以同Mercury公司的測(cè)試工具、第三方或者自主開(kāi)發(fā)的測(cè)試工具、需求和配置管理工具、建模工具的整合功能。你可以通過(guò)他進(jìn)行需求定義、測(cè)試計(jì)劃、測(cè)試執(zhí)行和缺陷跟蹤，即整個(gè)測(cè)試過(guò)程的各個(gè)階段。 4.6

31、 BugzillaBuzilla 是一個(gè) BUG 管理工具。作為一個(gè)產(chǎn)品缺陷的記錄及跟蹤工具，它能夠?yàn)槟憬⒁粋€(gè)完善的 Bug 跟蹤體系，包括報(bào)告 Bug、查詢 Bug 記錄并產(chǎn)生報(bào)表、處理解決、管理員系統(tǒng)初始化和設(shè)置四部分。并具有如下特點(diǎn)： 1、基于Web 方式，安裝簡(jiǎn)單、運(yùn)行方便快捷、管理安全。 2、有利于缺陷的清楚傳達(dá)。本系統(tǒng)使用數(shù)據(jù)庫(kù)進(jìn)行管理，提供全面詳盡的報(bào)告輸入項(xiàng)，產(chǎn)生標(biāo)準(zhǔn)化的 Bug 報(bào)告。 提供大量的分析選項(xiàng)和強(qiáng)大的查詢匹配能力，能根據(jù)各種條件組合進(jìn)行 Bug 統(tǒng)計(jì)。當(dāng)錯(cuò)誤在它的生命周期中變化時(shí)，開(kāi)發(fā)人員、測(cè)人員、及管理人員將及時(shí)獲得動(dòng)態(tài)的變化信息，允許你獲取歷史紀(jì)錄，并在檢查錯(cuò)誤的狀態(tài)時(shí)參考這一記錄。 3、系統(tǒng)靈活，強(qiáng)大的可配置能力。Buzilla工具可以對(duì)軟件產(chǎn)品設(shè)定不同的模塊，并針對(duì)不同的模塊設(shè)定制定的開(kāi)發(fā)人員和測(cè)試人員；這樣可以實(shí)現(xiàn)提交報(bào)告時(shí)自動(dòng)發(fā)給指定的責(zé)任人；并可設(shè)定不同的小組，權(quán)限也可劃分。設(shè)定不同的用戶對(duì) Bug 記錄的操作權(quán)限不同，可有效