TMap和Rational統一過程

　　為什么你應當用TMap來補充Rational統一過程，或RUP中所描述的測試過程呢?畢竟，RUP承認有效測試的重要性，并將測試劃分成貫穿整個生命周期的質量驗證的一個重要的最佳實踐。而且，RUP強調在一個單獨的工作流中測試，這一點在2002版中進行了更新。(集中于測試，成了撰寫本文的推動因素之一。)并且，與其它系統開發方法比較，RUP提供了詳細的測試指導。

　　然而，與RUP一起實施TMap在許多方面提供極大的增值：

　　TMap是一種非常廣泛和完善的測試方法，但是在RUP中，測試只是許多方面之一。一種完善的方法，在所有范圍中都有詳細內容，例如技術的描述，在測試方面提供比RUP單獨提供的更廣泛的指導。

　　TMap在許多組織中都成為標準，測試人員非常熟悉它，并且許多測試人員受過TMap培訓，使用過工具和模板。當一個組織開始一個RUP項目時，為了盡可能取得最大效率，通常會嘗試使用大家都知道的方法。

　　測試的應用在RUP的2002版中更為困難。特別是如果你不知道選擇探索性測試的話。工作流程明細、活動和角色已經在很大程度上進行了擴展，但是這些方面之間的關系，對于那些通過更常規的測試方法來獲得測試經驗的人來說，比較難以理解。

　　我們希望這種方法為所有碰到此挑戰的測試人員提供一種實用的解決方案。本文并不強調迭代化系統開發項目給測試人員提出的挑戰。關于本主題的更多信息，讀者應該查閱TMap的iCBD版本。 1

　　由于本文重點強調一種明確的變化，所以假定讀者對TMap和RUP知識有一定的水平。

　　測試作為一個RUP的最佳實踐

　　按照RUP，測試是系統開發的一個重要部分。第五個最佳實踐(在IBM Rational是持續地質量保證)主要說明，所有的開發活動和工件都需要通過持續的測試和復審來檢查質量。這意味著測試不僅僅是軟件構建之后的一個階段。

　　在2002年以前，RUP的重點是在傳統的計劃、規格說明和測試的執行上，并且很大的一個重點是在測試自動化上。在2002版中，對測試流程進行了相當大的變化。2002版轉向了基于探索性測試的方法。認識系統，以及涉及和執行測試現在是并行活動。在此之后隱藏的基本原理是，由于系統文檔經常改變，不應當將重點放在設計和編寫基于文檔的測試用例這些耗時的任務上。理想情況下，設計和執行測試應當發生在軟件被交付的時候，并且系統文檔不應當被唯一地用作測試依據。 2

　　RUP測試方法是基于以下原理： 3

　　迭代化開發。測試是在整個迭代化開發周期中執行的，每次都有一個不同的目標，依照RUP這是大家都知道的一個任務。例如，測試在精化階段，可以集中在確認構架上，而在構建階段中，測試可以集中在查找最重要的軟件缺陷上。

　　在起始點最少的可用文檔。除了絕對必需的測試文檔，不應當產生更多的測試文檔。主測試計劃和測試工作的詳細計劃，應當是在測試執行之前所產生的所有文檔。

　　整體分析。整體分析集中在搜索一個問題或關注點的所有方面之間的關系上。在RUP中，這意味著，測試依據不僅僅來源于規格說明書，而是來源于一個原始信息集，包括那些沒有文檔化的。

　　測試自動化。工具在不同的測試活動中都會有幫助。

　　RUP確定了四級測試：單元測試、集成測試、系統測試和驗收測試。這些測試級別可以是并列的，這取決于主測試計劃(在項目級)和迭代測試計劃(在迭代級)。

　　主測試計劃和迭代測試計劃

　　RUP對整個項目使用一個主測試計劃，對每個迭代使用一個迭代測試計劃。測試經理在先啟階段草擬主測試計劃。盡管是從系統測試開始的，但為了排列這些測試級別，在這兩種情況中，計劃都有可能包括系統測試之外的其它測試級別。這兩個計劃在內容上有大量的相似之處。只有范圍和詳細的程度有區別。一個選擇是將迭代測試計劃與迭代計劃集成在一起。在這種情況下，測試的貢獻主要是在于指出了確定和執行測試用例所依據的需求。與此迭代相關的其它測試活動也被提出來了;例如，適當的測試工具的選擇或創建明確的指導方針。

　　單元測試(UT)

　　單元測試用于軟件的最小可測試單元。單元測試強調內部結構，例如邏輯和數據流，以及單元的功能和外部可見行為測試。

　　RUP中的單元測試是實現人員的明確任務，在對于新的或變更單元的每個迭代中，都是由實現人員來執行實現測試組件和子系統，以及執行單元測試這些活動。這就使得測試成為與此角色相關聯活動的主要部分。

　　盡管RUP包含了許多關于單元測試的指導方針，但是并沒有命名一個項目特定指導方針需要在其中被固化的工件。這就和例如設計和用例建模的指南形成了對比。理論上，單元測試的這些指南應當被包括在編程指南中，因為編程指南是記錄實現人員角色的其它指南的地方。指南的開發和執行是過程工程師們的共有責任，并且應當是與主測試計劃是一致的。

　　單元測試配置有一個或多個工具。對于單元測試，IBM Rational軟件提供了以下工具：

　　IBM Rational PurifyPlus。提供多平臺、獨立IDE的多種運行時分析能力--例如內存泄漏檢測，性能壓力，以及代碼覆蓋獨立--針對Java，C/C++，.NET語言和Visual Basic。

　　IBM Rational Software Architect 和 IBM Rational Application Developer for WebSphere Software。這些工具提供了Rational PurifyPlus針對Java語言中的所有功能，再加上其他功能，包括自動化組件測試、高級內存泄漏檢測，線程分析，以及執行流可視化。

　　IBM Rational Test RealTime。提供針對在嵌入式或運行時目標中執行的軟件的運行時分析和組件測試功能--從8位微芯片到64位運行時操作系統。

　　其它可能的工具包括像JUnit這樣的免費軟件，其用于在Java環境中大范圍的測試(軟件)單元的功能。工具的選擇取決于要測試的需求。例如，如果性能不是一部分需求，那么對于性能測試就不需要工具。

　　集成測試(IT)

　　集成測試取決于當軟件組件在被合并起來執行一個用例時，是否功能正確。實現人員將他的已單元測試過的組件提交到集成人員那里，集成人員將這些單元合并成一個中間構造。這種一步步的組件集成發生在自下至上的方式中，并且按照集成構建計劃規定的順序進行。在每一步之后，集成人員組成一個中間構造，被提交用于執行集成測試。主要目標是確定這些組件與已經集成組件之間的兼容性。結果，常常會執行集成構建計劃的一個子集。這種一步步的方法考慮到足夠的問題隔離和分析。

原文轉自：http://www.ibm.com/developerworks/cn/rational/rationaledge/content/feb05/koomen/