TMap和Rational統一過程(4)

　　將易測性作為開發團隊的一個議程項目并不是TMap中要明確的，但是這將被證明是一個非常有價值的活動。例如，討論的目標需要被確定下來，并且驅動程序要被開發團隊開發出來。然后這個活動需要被添加到談到的TMap活動中。

　　注意到在TMap階段中沒有很明確的測試活動，這是很重要的，然而，這在RUP工作流中是一種情況。取決于必要性，一個人可以選擇維護這個或不維護。

　　規格說明

　　TMap規格說明階段可以被映射到RUP中的測試和評價，如表4所示。這個RUP步驟合并了重要的TMap階段-規格說明和執行。

　　表4：TMap規格說明階段可以被映射到RUP中的測試和評價

　　對于不熟悉RUP步驟“測試和評價”的讀者，可以在圖7中看到描述。

　　圖7：RUP步驟“測試和評價”

　　RUP強調，規格說明和測試用例的執行可以是并行的活動，讓我們討論一下如何從一個TMap的觀點來處理這個問題。

　　在RUP的“測試和評價”階段，一個測試分析師確定在像“確定測試思想”和“定義測試細節”這樣的活動中的一個邏輯級別上的測試用例。然后測試人員將這些轉換成物理的測試用例和測試腳本：分別是，“實施測試”和“實施測試集”。

　　RUP按照一種有別于TMap的方式來定義一個測試腳本。按照RUP，一個測試腳本是一個單個測試用例的實現;TMap認為一個測試腳本是按照一個有效的方式執行的許多動作和檢查點。在RUP中，這被稱作是一個測試集，并且可以與測試自動化關聯起來。本文參考的是TMap術語，除非RUP的術語表示更清晰。RUP測試可以是手工和自動化測試。

　　應當注意，在確定測試用例中，RUP不強調測試規格技術的使用或必需的測試基礎。不幸地是，這會降低系統文檔的重要性，盡管RUP不規定適合于測試基礎的不同系統文檔。例子是用例、用例模型、業務規則、類、類圖、序列圖、數據模型和補充規約。不同的TMap需求規格技術非常適合于建立基于RUP系統文檔的測試用例(也可以參見下面的“技術”一節)。

　　活動確定測試思想，可以在多個RUP步驟中發現，很少可以映射到TMap內。取決于測試思想的詳細程度，這種映射可以在準備階段中的測試技術選擇中或在規格說明階段的測試用例規格說明中發現。當需要時，可以創建并維護一個測試思想的列表。

　　在此階段中的第五個活動，說明測試對象和基礎結構的復審，可以被映射到RUP的確認構建穩定性中。有關于這個活動的說明可以在下一節有關執行的部分中找到。

　　在TMap中，“建立基礎結構”是規格說明的一部分。RUP將這部分內容方式了支持活動-支持開發中。

　　執行

　　TMap活動提到以下是執行階段的部分，并被映射凹相應的RUP活動，如表5所示。

　　表5：TMap執行階段映射到RUP

　　對于不熟悉RUP步驟-確認構建穩定性的讀者，在圖8中進行了描述。

　　圖8：RUP步驟-確認構建穩定性

　　作為執行活動的第一個步驟，復審測試對象或基本結構是RUP步驟-確認構建穩定性的一部分。注意RUP，這個步驟是在定義評價任務之后立即開始的，這與TMap計劃階段多少有些同義。在確認構建穩定性中，已提交的軟件版本(構建)被測試穩定性;換句話說，這足以開始進行測試執行嗎?因此，按照TMap，這個步驟不比規格說明和預測試執行內容要少。每個迭代都可以提交多個構建，盡管通常不是每個構建都要進行此步驟。此測試可以被(部分地)自動化。

　　當我們嚴格遵循RUP時，這意味著我們在軟件交付前拋棄了測試用例的規格說明，因為這發生在軟件交付之后。這樣的缺點是，不會鼓勵先于交付而完成測試準備，并且作為將不必要的測試活動放在項目的關鍵路徑上的結果?？赡艿膬烖c是，軟件和文檔被同步的可能性更高，測試用例不會基于過期的文檔來設計，以及設計和執行同時進行在人時方面會更有效率。 5

　　在TMap中執行預先測試的小步驟比在RUP中強調要詳細得多。在許多情況下，延遲測試用例規格說明的優點直到第一次構建交付之后才會大于缺點。對于此，更靈活的解釋和下一步驟，測試和評價，可以很容易地消除這些對象。如果還沒有交付任何構建，確認構建穩定性就不能執行。然而，下一步驟可以開始。在這個步驟中，測試用例只能指定，但還沒有執行。圖9顯示了這會如何發生。

　　圖9：可選擇的工作流順序

　　TMap執行階段的剩余活動可以放在測試和評價中，和規格說明的大多少活動一樣。按照這種方式，測試人員執行他們的測試用例，并在“執行測試集”中分析有關預期結果的缺陷。

　　完成

　　TMap完成階段的活動及其與RUP的對照如表6所示。

　　表6：TMap完成階段及其與RUP的對照

　　前三個完成活動可以被很好地映射到RUP的完成可接受任務中，這在圖10進行了描述。然而，在TMap中，與RUP的改善測試資產有一些重迭。

　　圖10：RUP步驟-改善測試資產

　　“完成可接受任務”產生了工件-測試評價總結，其包含測試對象和測試過程的一個評價。“改善測試資產”用一般方式描述了測試件的維護和改善。這包括測試的維護，測試環境的管理，以及自動化測試的維護。對這種執行測試的方式推薦的調整也可以從這個步驟進行，這取決于測試評價總結。除了第四個TMap活動，保存測試件，這個RUP步驟也包含測試過程的評價。在TMap中的另外一個步驟正在解放測試團隊。在RUP方法的正式工作中，這常常是不必要的。

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