模板
教程
環境
性能
功能
管理
TMap和Rational統一過程(6)
通過設計基于類描述的測試用例，一個人能夠在較深的級別上測試系統。實際上，許多內部對象不能之間被控制，這使得單獨測試它們不太可能。然后這些定義的測試用例只能通過將它們與測試用例合并來測試。
除了以上提到的測試規格說明技術之外，檢查單也被使用，它是基于經驗和系統的許多值得測試或復審的方面的。最終，測試基礎的不同的未文檔化的變量，像最終用戶的知識和經驗，可以用來補足文檔化的內容。
測試人員在開發過程早期所涉及的內容，特別是在開發人員和最終用戶之間的溝通過程中，在迭代系統開發中是及其重要的。也允許測試人員評估非文檔化的協議。
基礎結構
TMap的基礎，“基礎結構”，涉及到測試環境、工具和工作空間。對于一個RUP項目中的一個測試過程，只有工具支持是特定的，其它兩個都是“一切正常”。IBM Rational軟件提供幾個工具支持測試過程，如早先的“系統測試”一節中所描述。然而，測試自動化不是其自己的一個目標。特別是，使用記錄和回放工具--如Functional Tester 或 Robot--的功能驗收測試的自動化需要小心地被考慮。以下考慮對這種情況有影響：
在軟件以較小的方式經常變更，并且新的發布版本經常交付時，回歸測試的自動化就十分重要了。
測試的自動化要求開發期間的一個適度穩定的系統。如果不是這種情況，測試腳本就需要一次又一次地構建。穩定性會受到影響，例如，用戶界面的易變性和項目或迭代中系統分解的質量。
在迭代中測試的時限決定是否有充足的時間用于測試自動化。
是否能找到足夠的(高級)測試自動化人員?如果沒有，計劃能提供足夠的時間培訓人員嗎?
維護組織能夠接收自動化測試集嗎(在一個稍后的時間)?
驗收測試
要彌補RUP中驗收測試(AT)指南的不足，可以建議可能性：
將驗收測試組織和結構化為TMap所描述的。
將驗收測試與系統測試按照TMap描述的組織在一起，按本文檔所注明的那樣。
在第一個場景中，驗收測試是作為一個項目獨立實施的，其是獨立于其它RUP項目被執行的。一個設計良好的測試可以提供足夠的保證，系統可以按照產品的質量驗收。然而，這種類型的一個項目會降低系統開發過程的快速和迭代特性。如果組織發現，將采取迭代化開發的系統直接產品化的風險太高，就可以找到選擇這種方法的原因了。在第二個場景中，驗收測試按照與RUP迭代中的系統測試相同的方式來執行。在這種情況下，系統開發過程的迭代特性可以被維護，并且測試被組織起來，也稱為可能。
第三種組合是將驗收測試和系統測試集成到一個集成測試級別(IT)。實際上，這個步驟有太多不合需要的結果和風險，許多測試的質量和覆蓋度都不足。因此，這種選則就不推薦。所有這三種可能性的說明如圖11。
圖11：驗收測試的三種可能性
選擇的選項取決于具體情況。無論如何，主測試計劃需要確保，系統測試和驗收測試是有關測試覆蓋的補充。這意味著，在測試覆蓋中，不應當有任何不必要的覆蓋或缺口。
回頁首
參考文獻
Copeland, L.,Use Cases and testing: Testing UML models, Part 1," 來自STQE Letter, 2002年6月，在 www.stickyminds.com
IBM Rational 軟件(1997)，UML Summary 版本 1.0
IBM Rational軟件，不同的RUP白皮書，www.rational.com
Koomen, T., (2002) Testen van iCBD, www.tmap.net
Koomen, T., (2003) Exploratory testing and TMap, www.tmap.net
Kruchten, P. (2000), The Rational Unified Process, An Introduction, Second Edition, Addison-Wesley, ISBN: 0-201-70710-1
Pol, M., R. Teunissen, E. van Veenendaal (1999), Testen volgens TMap, Tutein Nolthenius,Hertogenbosch, ISBN: 90-72194-58-6
Szymkowiak, P., Kruchten, P. Testing: The RUP philosophy, The Rational Edge, February 2003.
回頁首
感謝
RUP2002版的產生得到了Sogeti工作組"TMap in RUP"的幫助。特別感謝Fedor Janssen, Richard Hakvoort, Loek Wilhelmus, Wim Bos, Andrsan Pelt, 和 Rob Baarda。Chris Dugardyn是IBM Rational的測試咨詢師，Rabo的Cees Dulfer也提供了有價值信息。我也將感謝Sogeti的Mark Tolsma，在準備用于本文寫作的材料上得到了他的幫助。
回頁首
附錄A：按照RUP和TMap的主測試計劃
下表全面對比了RUP MTP和TMap MTP。
回頁首
附錄B：RUP和TMap測試活動的詳細對比
下面的兩個表在詳細層次上對比了RUP和TMap的活動。第一個表說明了與RUP活動相連的每個階段的TMap活動。當沒有清晰的關系時，這個域已經被標記了一個問題標記(?)。請考慮，一個RUP活動可以出現在多個工作流上。在許多情況下，一個工作流的活動可以被映射到一個TMap活動上是很清楚的，但是相同的活動不能被映射到一個不同的工作流上。這種情況的一個例子是測試和評價中的“定義測試明細”，其可以被映射到TMap規格說明階段中的“準備測試規格說明”。相同的活動“定義測試明細”也出現在“改善測試資產”和“驗證測試方法”上。在這些情況下，匹配的TMap活動還沒有被填充。
原文轉自：http://www.ibm.com/developerworks/cn/rational/rationaledge/content/feb05/koomen/
