軟件測試之分布式對象測試 軟件測試方法
如今很少有設計單個進程在單個處理機卜執行的系統,為了獲得靈活性和伸展性,許多系統都被設計成多個充分獨立的部件,每個部件可以存在于一個獨立的進程中而整個統的運行會根據需要啟動多個進程。如果這些進程不是分布在一臺機器上,而是分布在多臺機器上,借助于計算機通信或網絡實現它們相互之間的協作,從而構成一個分布式的系統??蛻魴C/服務器模是一種簡單的分布式系統,在這種模璀中??蛻魴C和服務器部件被設計成存在于獨立的進程中服務器提供數據計算、處理、存儲等管理工作,客戶端接受用戶的輸入、請求、顯示結等工作兩者分工不同。隨著計算機技術的發展,現在可以構造一個分布式的服務器集群,通過并行技術實現復雜的或巨量的計算:也可以構造沒有服務器的、分布式的、由客戶端構成的對等網絡fP2P)系統。
分布式對象的概念和特點
線程是一個操作系統進程內能夠獨證運行的內容,它擁有自己的計數器和本地數據。線程是能夠被調度執行的最小單位。而向對象語言通過隱藏接口的屬性或在某些情況下使線程對對象做出反應,以此提供一些簡單的同步手段。這就意味著在對象接口中蚓步是可見的(如Javasynchomize關鍵字),而傳遞消息是同步中最關鍵的一環。在這種情況下,類測試并不能發現很多同步錯誤,只有當一系列對象交互作用時才真正有機會發現錯誤。 當軟件包含多個并發進程時,其特點是不確定性,完全地重復運行一個測試是很困難的。線程準確的執行是由操作系統安排的,與系統測試無關的程序變化可能會影響測試中的系統線程執行順序。這就意味著如果出現失敗,缺陷就必須被隔離并修復,并重新測試。不能因為在一個特定執行中沒有發生錯誤就肯定缺陷被消除了,我們必須使用下列技術之一來進行測試。
· 在類的層次上進行更徹底的測試。對用來產生分布式對象的類進行設計檢查,應該確定類設計中是否提供了恰當的同步機制。動態類測試應該確定在受控制的測試環境中同步是省常。
· 在記錄事件發生順序的同時,執行大量的測試用倒。這就增大了執行所有順序的可能性。而努力想友現的問題正是來源于事件執行的順序。如果一執行所有的順序,就能找到這些問題。
· 指定標準的測試環境。從一臺盡可能簡單的機器開始,包括盡可能少的網絡、調制解調器或其他共享設備互聯。并確定應用程序能夠在這個平臺L運行。然后安裝一套基本的應用程序,它將一直在此機器上運行。每個測試用例都應該描述在標準環境下所做的任何修改。還要包括進程開始的順序。標準環境下的程序調試應允許測試者控制線程的創建、執行和刪除的順序。環境越大,共享和網絡化的程度越高,要保持環境的一致性就更難。不論在哪我們都應該有測試實驗室,并把測試機器與公共網絡的其他部分隔離,這些機器專用于測試進程。
2測試中需要注意的情況
· 局部故障。由于以分布式系統為主的機器上的軟件或硬件可能出錯,分布式系統的部分代 碼也許就不能執行,而運行在單一機器上的應用程序是不會遇到這類問題的。局部出錯的司能性使我們應考慮針對網絡連接的斷開、失靈或關閉網絡上的一個節點而發生故障的這類測試。這一點可以在前面提到的實驗室進行實現。
· 超時。當一個請求發送到另一個系統時,|_【】9絡系統通過設置定時器來避免死鎖。如果在指定的時間內沒有得到任何的回應,系統就放棄這個請求。這可能是由于系統的死鎖,或是網絡上的機器太忙以致反映的時間比規定的時間要長a當出現請求被回答或未被回答時,軟件應該能夠做出正確的反映。當然在這兩種情況下, 反映是爿i同的。在網絡機器匕運行測試時,測試必須加載多種配置。
· 結構的動態性。分布式系統通常具有依靠多種機器的加載來改變自身配置的能力, 比如特定請求的動態定向。系統的設計要允許多種機器參與進來,而且系統也需要根據大量的配置來重復測試。如果存在一組大量日B置,對這些配置進行全部測試是可行的。另外,可以使用比如正交陣列測試系統這樣的技術來選擇一套特殊的測試配置。
· 線程。作為時間調度的計算單元,引進了線程的概念。在設計中,基本的權衡是
以線程的數量為中心。增加線程的數量可以簡化一定的算法和技術,但線程執行
的順序出現風險的機會更大。減少線程的數量可以減少這種順序問題,但會使軟
件更為刻板而且通常效率會更低。
· 同步。當兩個或兩個以上的線程都必須訪問一個存儲空間時,就需要一定的機制
來避免兩個線程相互沖突。而且兩個線程可能會同時對數據進行修改。一些語言
(如Java)提供了語言關鍵字來自動添加避免同時訪問的機制。而其他語言,如
c_-,則要求每個開發者必須自行構造以達到這一目的。在面向對象的語言中同
步會顯得更為簡單,因為這種機制局限于一般數據屬性的修改方法,而且有不止
一個特定的方法來避免實際數據的直接存取。
原文轉自:http://www.anti-gravitydesign.com