談:面向對象的軟件測試與傳統測試的比較[3]

關鍵字：軟件測試與傳統測試類是否實現了要求的功能 

　　5、 面向對象的單元測試 

　　傳統的單元測試的對象是軟件設計的最小單位——模塊。單元測試的依據是詳細設描述，單元測試應對模塊內所有重要的控制路徑設計測試用例，以便發現模塊內部的錯誤。單元測試多采用白盒測試技術，系統內多個模塊可以并行地進行測試。 

　　當考慮面向對象軟件時，單元的概念發生了變化。封裝驅動了類和對象的定義，這意味著每個類和類的實例(對象)包裝了屬性(數據)和操縱這些數據的操作。而不是個體的模塊。最小的可測試單位是封裝的類或對象，類包含一組不同的操作，并且某特殊操作可能作為一組不同類的一部分存在，因此，單元測試的意義發生了較大變化。我們不再孤立地測試單個操作，而是將操作作為類的一部分。 

　　6、 面向對象的集成測試 

　　傳統的集成測試，有兩種方式通過集成完成的功能模塊進行測。（一）自頂向下集成：自頂向下集成是構造程序結構的一種增量式方式，它從主控模塊開始，按照軟件的控制層次結構，以深度優先或廣度優先的策略，逐步把各個模塊集成在一起。（二）自底向上集成：自底向上測試是從“原子”模塊（即軟件結構最低層的模塊）開始組裝測試。 

　　因為面向對象軟件沒有層次的控制結構，傳統的自頂向下和自底向上集成策略就沒有意義，此外，一次集成一個操作到類中(傳統的增量集成方法)經常是不可能的，這是由于“構成類的成分的直接和間接的交互”。對OO軟件的集成測試有兩種不同策略，第一種稱為基于線程的測試，集成對回應系統的一個輸入或事件所需的一組類，每個線程被集成并分別測試，應用回歸測試以保證沒有產生副作用。第二種稱為基于使用的測試，通過測試那些幾乎不使用服務器類的類(稱為獨立類)而開始構造系統，在獨立類測試完成后，下一層的使用獨立類的類，稱為依賴類，被測試。這個依賴類層次的測試序列一直持續到構造完整個系統。 

　　7、 面向對象的系統測試 

　　通過單元測試和集成測試，僅能保證軟件開發的功能得以實現。但不能確認在實際運行時，它是否滿足用戶的需要。為此，對完成開發的軟件必須經過規范的系統測試。系統測試應該盡量搭建與用戶實際使用環境相同的測試平臺，應該保證被測系統的完整性，對臨時沒有的系統設備部件，也應有相應的模擬手段。系統測試時，應該參考OOA分析的結果，對應描述的對象、屬性和各種服務，檢測軟件是否能夠完全"再現"問題空間。系統測試不僅是檢測軟件的整體行為表現，從另一個側面看，也是對軟件開發設計的再確認。 

　　面向對象測試的整體目標——以最小的工作量發現最多的錯誤——和傳統軟件測試的目標是一致的，但是OO測試的策略和戰術有很大不同。測試的視角擴大到包括復審分析和設計模型，此外，測試的焦點從過程構件(模塊)移向了類。 

 

軟件測試與傳統測試不論是傳統的測試方法還是面向對象的測試方法，我們都應該遵循下列的原則： 

　　1.應當把“盡早和不斷地測試”作為開發者的座右銘。 

　　2.程序員應該避免檢查自己的程序，測試工作應該由獨立的專業的軟件測試機構來完成。 

　　3.設計測試用例時，應該考慮到合法的輸入和不合法的輸入，以及各種邊界條件，特殊情況下要制造極端狀態和意外狀態，比如網絡異常中斷、電源斷電等情況。 

　　4.一定要注意測試中的錯誤集中發生現象，這和程序員的編程水平和習慣有很大的關系。 

　　5.對測試錯誤結果一定要有一個確認的過程。一般有A測試出來的錯誤，一定要有一個B來確認，嚴重的錯誤可以召開評審會進行討論和分析。 

　　6.制定嚴格的測試計劃，并把測試時間安排得盡量寬松，不要希望在極短的時間內完成一個高水平的測試。 

　　7.回歸測試的關聯性一定要引起充分的注意，修改一個錯誤而引起更多錯誤出現的現象并不少見。 

　　8.妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現性往往要靠測試文檔。

原文轉自：http://www.kjueaiud.com