1、軟件的易測試性設計

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

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

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

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

　　2、構件測試

　　當前社會的信息化過程對軟件的開發方法與生產能力提出了新的要求，軟件復用是提高軟件產品質量與生產效率的關鍵技術。軟件構件概念的提出為軟件復用提供了技術基礎。構件的高可靠性是構件能被成功復用的前提。構件測試是保障和提高構件的可靠性的重要手段。構件的開發者和復用者必須對構件進行充分的測試，以確保它在新的環境中工作正常。

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

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

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

　　3、Web Services 測試

　　隨著軟件產業模式從以產品為中心的制造業轉變為以客戶為中心的服務業，WWW 從2層體系轉變為3 層體系，B2B 從復雜專用的連接轉變為簡單通用的連接，分布計算中間件從Intranet 擴展到Internet ，CORBA、COM及EJB 等中間件技術已不能適應這些發展需求，因而導致了新型中間件技術Web Services 的產生。

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

　　當前的WSDL 信息包括輸入P輸出的數量、每個輸入和輸出的變量類型、輸入的順序和輸出返回的順序和一個Web Service 應當如何調用的信息。但是，為了執行Web Services 的黑盒測試和回歸測試，以上信息是遠遠不夠的。

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