測試用例治理
1. OO-Test提供了在國內外市場上最全面的測試覆蓋分析能力，去滿足不同的測試覆蓋需求：
●類的測試覆蓋
●函數的測試覆蓋
●塊的覆蓋
●循環邊界的覆蓋
●分支的覆蓋
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
●段的覆蓋
●條件（判定）的覆蓋
●段--條件的覆蓋
2．TCA能確定每一個測試用例作用的范圍，通過給出的測試用例就能確定被測試的類，或函數，或段。這種功能對于評估測試用例的效率，和對于修改以后指定的類或函數或段的再測試是非常有用的。
3．此外，TCA能從初始測試用例中自動地抽取最小測試用例集，并對基于類的、函數的、分支的、塊的、段的覆蓋等等各自分別進行劃分。它可以對系統級的再測試節省大量的時間和費用。
練習新成員
1. 提供全面的靜態和動態系統分析的能力，能抽取各種信息及自動生成系統文檔，并且可以使被抽取的信息讓新成員聯機訪問，大大的節省了設計人員和工程師的時間。
2.通過提供最新的和精確的各種系統概貌圖和流程圖(包括數據結構、類繼續圖、函數調用圖和程序樹)，全局數據分析的具體報告，具體的程序邏輯圖和源代碼的控制流程圖，幫助他們了解系統和深入地理解代碼。
3.使用的GUI接口,使開發組的新成員輕易自我練習；具有一個從頂層到具體的代碼系統動態的和圖形化的表達能力；具有鏈接不同層次的結構圖和流程圖在一起的能力。
4.提供基于函數分析和流程圖化的能力與基于類分析和流程圖化的能力，使得一個面向對象的系統很輕易被透徹地了解。
單元測試的考慮單元測試是要檢驗程序最小單位（模塊）有無錯誤，它是在編碼完成后，首先要施行的測試工作。一般由編碼人員自己來完成，因而通常把單元測試看成是編碼步驟的附屬品。單元測試大多從程序的內部結構出發設計測試用例，即采用白盒測試方法，多個程序模塊可以并行地獨立開展測試工作。
單元測試是針對每個程序模塊，解決5個方面的問題：模塊接口、局部數據結構、邊界條件、獨立的路徑和錯誤處理。
1.模塊接口:
對模塊接口的測試，是檢查進出程序單元的數據流是否正確。對模塊接口數據流的測試必須在任何其他測試之前進行，因為假如不能確保數據正確地輸入和輸出的話，所有的測試都是沒有意義的。
2.局部數據結構:
在模塊工作過程中，必須測試其內部的數據能否保持完整性，包括內部數據的內容、形式及相互關系不發生錯誤。
3.獨立的路徑:
在單元測試中，最主要的測試是針對路徑的測試。測試用例必須能夠發現由于計算錯誤、不正確的判定或不正常的控制流而產生的錯誤。
4.邊界條件:
軟件經常在邊界地區發生問題。
5. 錯誤處理:
測試出錯處理的要點是模塊在工作中發生了錯誤，其中的出錯處理設施是否有效。
單元測試的過程
單元測試經常和代碼編寫同步進行，在完成了程序編寫、復查和語法正確性驗證后，就應進行單元測試用例設計。 在對每個模塊進行單元測試時，不能完全忽視它們和四周模塊的相互聯系。為模擬這一聯系，在進行單元測試時，需設置若干輔助測試模塊。輔助模塊有兩種，一種是驅動模塊（driver），用以模擬被測模塊的上級模塊。驅動模塊在單元測試中接受測試數據，把相關的數據傳送給被測模塊，啟動被測模塊，并打印出相應的結果。另一種是樁模塊（stub），用以模擬被測模塊工作過程中所調用的模塊。樁模塊由被測模塊調用，它們一般只進行很少的數據處理，例如打印入口和返回，以便于檢驗被測模塊與其下級模塊的接口。
驅動器和樁都是額外的開銷，這兩種模塊雖然在單元測試中必須編寫，但卻不作為最終的軟件產品提供用戶。假如驅動器和樁很簡單的話，那么開銷相對較低，然后，使用“簡單”的模塊是不可能進行足夠的單元測試的，模塊間接口的全面檢驗要推遲到集成測試時進行。進入討論組討論。
