1、軟件的易測試性設(shè)計

　　Voas將軟件的易測試性定義為一定測試策略迫使軟件中存在的故障被暴露的概率。軟件的易測試性包括可觀察、可控制、可理解等幾個方面。軟件易測試性設(shè)計即是在軟件的設(shè)計和編碼中考慮測試問題，它借鑒了硬件易測試性設(shè)計的思想。為了減少測試集成電路的測試開銷，提高產(chǎn)品的質(zhì)量，工程師采用易測試性設(shè)計技術(shù)，即在集成電路上增加額外的引腳，通過這些引腳能夠在測試時探測集成電路的內(nèi)部，提高了可控制性和可觀察性。內(nèi)建式測試（Bulit-In Testing） 方法是一種易測試性設(shè)計技術(shù)，它在集成電路上引入測試電路或引腳，使得集成電路能夠工作在測試模式下，并且傳輸測試輸入，捕獲輸出。這種方法的進(jìn)一步擴(kuò)展是再增加測試輸入生成電路，從而避免外界的輸入。這是內(nèi)建式自測試概念。

　　軟件易測試性設(shè)計的目的是在不增加或者少增加軟件復(fù)雜性的基礎(chǔ)上，將易于測試的原則融合到設(shè)計和編碼之中。軟件易測試性設(shè)計符合軟件測試的一個原則：盡早開始軟件測試工作，不斷進(jìn)行軟件測試工作。軟件易測試性設(shè)計體現(xiàn)軟件測試的如下觀點：軟件產(chǎn)品的質(zhì)量是生產(chǎn)（包括分析、設(shè)計、編碼、測試） 出來的，而不是僅僅依靠軟件測試來保障。軟件易測試性設(shè)計也體現(xiàn)了軟件測試的一個發(fā)展趨勢：向軟件開發(fā)的前期發(fā)展，與軟件開發(fā)的設(shè)計和編碼階段相融合。易于測試的軟件本身所包含的缺陷也會減少。軟件易測試性設(shè)計將有效地提高軟件測試的效率和質(zhì)量，提高軟件設(shè)計和編程的質(zhì)量，進(jìn)而提高軟件產(chǎn)品的質(zhì)量。軟件的易測試性設(shè)計方法包括合約式設(shè)計（Design by Contract） 、內(nèi)，建式測試和內(nèi)建式自測試等幾種方法。

　　合約是管理對象之間的交互的一組規(guī)則。合約的來源是軟件的規(guī)約，它指明了軟件“做什么”而不涉及“怎樣做”。常見的合約類型包括：前置條件、后置條件、不變式、循環(huán)變式P不變式和軌跡等。合約表明了過程調(diào)用方（客戶方） 與實現(xiàn)方相互的職責(zé)和利益：客戶方只有在滿足前置條件的條件下才能調(diào)用對應(yīng)的過程；實現(xiàn)方承諾當(dāng)過程結(jié)束時，后置條件指明的工作將被完成，并且不變式仍然滿足。合約可用于區(qū)分軟件失效時的責(zé)任：如果前置條件被違反，則應(yīng)該在客戶方尋找錯誤；如果后置條件或不變式被違反，責(zé)任在實現(xiàn)方。合約有助于減少冗余的檢查代碼，提高軟件設(shè)計的效率和運行的性能；利用自動檢查合約的工具，能夠減輕用戶的負(fù)，減少用戶犯錯誤的機(jī)會；并且合約被違反時引發(fā)異常，便于近定位故障。常見的合約式設(shè)計方法是在程序代碼的注釋中提供軟件的合約，F(xiàn)在有一些對合約進(jìn)行自動檢查的工具，如針對Java 語言的iContract ， Jass ， JMSAssert 等工具。

　　軟件的內(nèi)建式測試方法是在程序中添加額外的測試機(jī)制，使軟件能夠工作在測試模式下。軟件的內(nèi)建式自測試方法是在此基礎(chǔ)上再增加測試用例生成機(jī)制。

　　2、構(gòu)件測試

　　當(dāng)前社會的信息化過程對軟件的開發(fā)方法與生產(chǎn)能力提出了新的要求，軟件復(fù)用是提高軟件產(chǎn)品質(zhì)量與生產(chǎn)效率的關(guān)鍵技術(shù)。軟件構(gòu)件概念的提出為軟件復(fù)用提供了技術(shù)基礎(chǔ)。構(gòu)件的高可靠性是構(gòu)件能被成功復(fù)用的前提。構(gòu)件測試是保障和提高構(gòu)件的可靠性的重要手段。構(gòu)件的開發(fā)者和復(fù)用者必須對構(gòu)件進(jìn)行充分的測試，以確保它在新的環(huán)境中工作正常。

　　與傳統(tǒng)的軟件測試相比，構(gòu)件測試有著自身的固有特點： （1） 不能對構(gòu)件的執(zhí)行環(huán)境和用戶的使用模式進(jìn)行完全準(zhǔn)確的預(yù)測，故構(gòu)件開發(fā)者不能完全、徹底地對構(gòu)件進(jìn)行測試，并且很難確定何時結(jié)束測試； （2） 構(gòu)件復(fù)用者和第三方測試人員通常無法得到構(gòu)件的源代碼及詳細(xì)的設(shè)計知識，通常只能對構(gòu)件進(jìn)行黑盒測試，即調(diào)用構(gòu)件的方法后只能通過觀察執(zhí)行的結(jié)果判斷構(gòu)件的行為是否正確，無法檢查執(zhí)行過程中的構(gòu)件的內(nèi)部狀態(tài)，使得構(gòu)件執(zhí)行過程中的一些故障被隱藏。這些困難對構(gòu)件測試提出了嚴(yán)峻的挑戰(zhàn)。

　　國際上于20 世紀(jì)90 年代后期對構(gòu)件測試開展了研究。近年來，出現(xiàn)了大量的文獻(xiàn)報道。構(gòu)件測試成為當(dāng)前軟件工程學(xué)術(shù)界和工業(yè)界的熱點問題之一。大體上，對構(gòu)件的測試可以從以下幾個方面來進(jìn)行分類。從構(gòu)件測試的內(nèi)容可分為：構(gòu)件內(nèi)部實現(xiàn)細(xì)節(jié)的測試，構(gòu)件接口的測試，構(gòu)件組裝（構(gòu)架） 的測試。從測試者與構(gòu)件的關(guān)系可分為：構(gòu)件開發(fā)者的測試（擁有構(gòu)件的源代碼）、構(gòu)件復(fù)用者和第三方的測試（沒有源代碼） 。從測試過程中所采用的技術(shù)手段可分為：基于變異測試的方法，基于構(gòu)件狀態(tài)機(jī)的方法，對構(gòu)件的回歸測試，以及構(gòu)件的易測試性設(shè)計等。

　　構(gòu)件測試一個重要的發(fā)展方向是基于合約的構(gòu)件易測試性設(shè)計。合約可以在運行時被檢查，便于捕獲構(gòu)件執(zhí)行過程中的一些故障，提高構(gòu)件的易測試性。因此，基于合約的構(gòu)件易測試性設(shè)計不僅為構(gòu)件開發(fā)者開發(fā)高質(zhì)量的構(gòu)件提供幫助，而且在構(gòu)件開發(fā)者與復(fù)用者之間架起一座橋梁，為構(gòu)件復(fù)用者的測試提供支持，也為構(gòu)件開發(fā)者捕獲錯誤提供便利，便于區(qū)分構(gòu)件開發(fā)者與復(fù)用者的責(zé)任。如果眾多的構(gòu)件開發(fā)者都采用合約式設(shè)計方法生產(chǎn)構(gòu)件，那么失效時很容易定位到構(gòu)件和其中的方法。為使基于合約的構(gòu)件易測試性設(shè)計方法能夠?qū)嵱，需要研究解決以下問題：構(gòu)件合約的描述、表達(dá)，構(gòu)件中合約的獲取，對構(gòu)件合約的自動檢查，以及針對構(gòu)件合約的軟件測試。

　　3、Web Services 測試

　　隨著軟件產(chǎn)業(yè)模式從以產(chǎn)品為中心的制造業(yè)轉(zhuǎn)變?yōu)橐钥蛻魹橹行牡姆⻊?wù)業(yè)，WWW 從2層體系轉(zhuǎn)變?yōu)? 層體系，B2B 從復(fù)雜專用的連接轉(zhuǎn)變?yōu)楹唵瓮ㄓ玫倪B接，分布計算中間件從Intranet 擴(kuò)展到Internet ，CORBA、COM及EJB 等中間件技術(shù)已不能適應(yīng)這些發(fā)展需求，因而導(dǎo)致了新型中間件技術(shù)Web Services 的產(chǎn)生。

　　當(dāng)前，Web Services 越來越受到人們的關(guān)注，它使用了包括SOAP、WSDL 和UDDI 在內(nèi)的標(biāo)準(zhǔn)協(xié)議。這些標(biāo)準(zhǔn)協(xié)議體現(xiàn)了互操作性，并用于應(yīng)用的開發(fā)及運行時Web Services 的選擇和調(diào)用。Web Services 的測試和評估對服務(wù)提供者和服務(wù)使用者來說都是相當(dāng)重要的。WebServices 的測試相當(dāng)于黑盒測試，可以獲得規(guī)約，卻不能得到設(shè)計或源代碼。Web Services 規(guī)約是用WSDL 寫的，而代碼是用Java 、C # 或其他編程語言寫的。

　　當(dāng)前的WSDL 信息包括輸入P輸出的數(shù)量、每個輸入和輸出的變量類型、輸入的順序和輸出返回的順序和一個Web Service 應(yīng)當(dāng)如何調(diào)用的信息。但是，為了執(zhí)行Web Services 的黑盒測試和回歸測試，以上信息是遠(yuǎn)遠(yuǎn)不夠的。

　　對用戶而言，通常需要合并多個Web Services 來滿足他們的需求，所謂的服務(wù)聚合是根據(jù)用戶的要求合并現(xiàn)存的Web Services。這時需要一種標(biāo)準(zhǔn)語言來描述不同的Web Services 是如何集成在一起的，即描述Web Services 流的語言。當(dāng)前有兩種常見的Web Services 流描述語言WSFL 和XLANG。如果讓用戶自己來描述Web Services 流，很可能會導(dǎo)致錯誤。在發(fā)現(xiàn)錯誤之前，流中的許多Web Services 已經(jīng)被調(diào)用了，其后果會導(dǎo)致事務(wù)回滾困難、引起網(wǎng)絡(luò)擁塞，從而造成資源浪費。