關鍵字：
軟體測試
與傳統測試類是否實現了要求的功能
5、 物件導向的單元測試
傳統的單元測試的物件是軟體設計的最小單位——模組。單元測試的依據是詳細設描述，單元測試應對模組內所有重要的控制路徑設計測試用例，以便發現模組內部的錯誤。單元測試多採用白盒測試技術，系統內多個模組可以並行地進行測試。
當考慮物件導向軟體時，單元的概念發生了變化。封裝驅動了類和物件的定義，這意味著每個類和類的例項(物件)包裝了屬性(資料)和操縱這些資料的操作。而不是個體的模組。最小的可測試單位是封裝的類或物件，類包含一組不同的操作，並且某特殊操作可能作為一組不同類的一部分存在，因此，單元測試的意義發生了較大變化。我們不再孤立地測試單個操作，而是將操作作為類的一部分。
6、 物件導向的整合測試
傳統的整合測試，有兩種方式通過整合完成的功能模組進行測。（一）自頂向下整合：自頂向下整合是構造程式結構的一種增量式方式，它從主控模組開始，按照軟體的控制層次結構，以深度優先或廣度優先的策略，逐步把各個模組整合在一起。（二）自底向上整合：自底向上測試是從「原子」模組（即軟體結構最低層的模組）開始組裝測試。
因為物件導向軟體沒有層次的控制結構，傳統的自頂向下和自底向上整合策略就沒有意義，此外，一次整合乙個操作到類中(傳統的增量整合方法)經常是不可能的，這是由於「構成類的成分的直接和間接的互動」。對oo軟體的整合測試有兩種不同策略，第一種稱為基於執行緒的測試，整合對回應系統的乙個輸入或事件所需的一組類，每個執行緒被整合並分別測試，應用回歸測試以保證沒有產生***。第二種稱為基於使用的測試，通過測試那些幾乎不使用伺服器類的類(稱為獨立類)而開始構造系統，在獨立類測試完成後，下一層的使用獨立類的類，稱為依賴類，被測試。這個依賴類層次的測試序列一直持續到構造完整個系統。
7、 物件導向的系統測試
通過單元測試和整合測試，僅能保證軟體開發的功能得以實現。但不能確認在實際執行時，它是否滿足使用者的需要。為此，對完成開發的軟體必須經過規範的系統測試。系統測試應該盡量搭建與使用者實際使用環境相同的測試平台，應該保證被測系統的完整性，對臨時沒有的系統裝置部件，也應有相應的模擬手段。系統測試時，應該參考ooa分析的結果，對應描述的物件、屬性和各種服務，檢測軟體是否能夠完全"再現"問題空間。系統測試不僅是檢測軟體的整體行為表現，從另乙個側面看，也是對軟體開發設計的再確認。
物件導向測試的整體目標——以最小的工作量發現最多的錯誤——和傳統軟體測試的目標是一致的，但是oo測試的策略和戰術有很大不同。測試的視角擴大到包括複審分析和設計模型，此外，測試的焦點從過程構件(模組)移向了類。
軟體測試與傳統測試不論是傳統的測試方法還是物件導向的測試方法，我們都應該遵循下列的原則：
1.應當把「盡早和不斷地測試」作為開發者的座右銘。
2.程式設計師應該避免檢查自己的程式，測試工作應該由獨立的專業的軟體測試機構來完成。
3.設計測試用例時，應該考慮到合法的輸入和不合法的輸入，以及各種邊界條件，特殊情況下要製造極端狀態和意外狀態，比如網路異常中斷、電源斷電等情況。
4.一定要注意測試中的錯誤集中發生現象，這和程式設計師的程式設計水平和習慣有很大的關係。
5.對測試錯誤結果一定要有乙個確認的過程。一般有a測試出來的錯誤，一定要有乙個b來確認，嚴重的錯誤可以召開評審會進行討論和分析。
6.制定嚴格的測試計畫，並把測試時間安排得盡量寬鬆，不要希望在極短的時間內完成乙個高水平的測試。
7.回歸測試的關聯性一定要引起充分的注意，修改乙個錯誤而引起更多錯誤出現的現象並不少見。
8.妥善儲存一切測試過程文件，意義是不言而喻的，測試的重現性往往要靠測試文件。
物件導向方法與物件導向測試
物件導向 object oriented，oo 方法認為，客觀世界是由各種物件組成的，任何事物都是物件，每乙個物件都有自己的運動規律和內部狀態，都屬於某個物件類，是該物件類的乙個元素。複雜的物件可由相對簡單的各種物件以某種方式而構成，不同物件的組合及相互作用就構成了系統。oo方法是當前的主流開發方法...
物件導向測試
物件導向測試層次 在物件導向測試中，通常分為三個層次，把類看做單元，分為類測試 整合測試和系統測試。物件導向的類測試 主要對類中的成員函式及成員函式間的互動進行測試 物件導向的整合測試 主要對系統內部的相互服務進行測試，如類間的訊息傳遞等 物件導向的系統測試 基於物件導向整合測試的最後階段的測試，主...
物件導向測試
依據物件導向開發模型，物件導向測試分為 物件導向分析 ooa 物件導向設計 ood 和物件導向開發 oop 三個階段 在設計測試用例選擇輸入資料時，可以基於以下兩個假設 1.如果函式 程式 對某一類輸入中的乙個資料正確執行，對同類中的其他輸入也能正確執行。2.如果函式 程式 對某一複雜度的輸入正確執...