TMap和Rational統一過程(5)

　　組織

　　迭代化系統開發已經在一個項目的組織中有了重要地位，并且對于測試組織也是這樣。本文并不詳細說明這些，因為這是在RUP中詳細說明的。然而，特定于RUP就是測試角色。RUP有許多測試角色：

　　測試經理

　　測試分析師

　　測試員

　　測試設計師

　　這些角色覆蓋了測試流程的所有活動。

　　前三個角色主要對應于TMap測試經理和測試員的兩個描述。RUP的測試分析師角色部分包括TMap測試經理的任務，部分包括TMap測試員的任務，并且特別確定了那些測試需要被執行，這些測試的(邏輯)設計，以及測試執行的最終結果的評價。

　　RUP的測試設計師角色定義并實現了測試方法，包括技術、工件和過程。這個角色的重點是在測試自動化上;因此，這個角色也可以稱作“測試構架師”或“測試自動化構架師”?；蚨嗷蛏倏蓪Ρ鹊腡Map角色是方法支持和TAKT構架師。

　　技術

　　TMap有多個技術特性，包括測試策略開發、測試點分析、測試的易測性復審和許多測試規格說明技術和檢查單。這些技術沒有在RUP中描述，但是他們可以毫無問題地應用到RUP測試項目中。

　　以下各節將描述有關測試策略開發和測試規格說明技術的許多RUP特定的提示。

　　測試策略

　　測試策略需要集中在盡可能早地查找出最重要的缺陷上，并且以最低的成本。對于測試策略的開發，TMap描述的技術是足夠的。下面描述了許多不同的額外提示，這需要被考慮到有關測試策略的開發上。

　　系統開發的重復特性意味著，產品第一次不會被完成，但會持續地進展。每一次進展發生得時間很短，并會受限于時間。

　　測試人員經常會抱怨，分配給他們的時間太少了：例如，“要在這么短的時間內測試那么多內容。”換句話說，開發人員抱怨，他們同樣受限于時間太少，不能按照期限交付產品。項目經理不能允許開發人員在測試的成本上花費時間。因此，測試過程的提前管理并應用一種基于風險的方法，如TMap所描述的，是必須的。例如，不允許額外的功能被合并到最終的構建中，通常應當是同意的。

　　另外一個問題可以在許多連續進展中發現。在產品已經經歷多次演變后，仍然是按照早先需求同意的進行嗎?產品的一部分將準備好，并且需要制訂有關定義下一個周期變化內容的協議。風險是，在早先的周期中接受和同意的部分還可以變更，并且沒有文檔化。這種情形被認為是回歸。

　　項目經理通常不提供測試人員進行此回歸的任務?；貧w測試需要在一個合格的基礎上執行，以一次次地確認系統的工作。

　　測試人員的另一項工作是幫助最終用戶作出正確的覺定，并且在評估新的產品版本時不要忘記部分內容。要完成這個，測試人員可以使用要評估內容的檢查單。測試人員也可以利用他的專門技術和經驗，來確定薄弱點和高風險區域。最終用戶的職責就是決定產品是否能接受。測試人員的職責是確定概覽時很明顯的缺點。

　　測試規格說明技術

　　可用的測試基礎會極大地影響測試規格說明技術的選擇。在RUP中，不用說，UML為這些技術提供了基礎。UML作為一種傳統建模技術的普及給許多人提出了建議，已有的測試規格說明技術同意需要被更改;他們相信，測試技術只能用在傳統的建模技術上。這是一個誤解。對于傳統的建模技術，例如實體關系圖或數據流程圖，沒有可用的特定測試技術會過時。同意地，沒有特定的測試技術可用于用例圖或類圖。通常，測試技術使用了功能描述、數據確認和屏幕布局，以及在哪里找到這些描述是不重要的，

　　在設計一個基于UML的測試腳本時，需要執行在TMap中所描述的步驟。在確定測試情形時，邏輯測試用例被首先定義，然后被轉換到物理測試用例。最后，在收集到初始需要的測試數據之后，執行測試的順序在一個測試腳本中確定。表7提供了可用測試規格說明技術的一個概述。

　　表7：可用的測試規格說明技術

　　如表7所示，UML的一個重要部分是用例。它們在高層次上描述系統的功能?；谶@些用例，測試可以在一個受限層次上進行，因為用例只描述執行者和系統的交互。交互的準確內容和它們發生的頻繁程度并不強調。

　　用例和用例圖可以用于測試系統的以下方面：

　　事件的預期順序。(需要)在系統中執行操作的順序。

　　例外事件或特定事件。例如，在系統的非預期操作或不正確使用下，系統的反應。

　　所有的關聯和依賴用例和執行者之間，以及用例之間

　　當執行基于用例的測試時，最明顯的技術是過程循環測試(或規則測試)。然后基于用例圖來設計測試路徑，通過這些，所有相關關系和可能的選擇至少要一次通過。測試路徑的數量取決于測試標準(有關更多信息，請參見TMap)。

　　為了能夠依靠用例來測試，除了用例描述和用例圖之外，還需要有關特定方面的額外信息。特別是，缺乏需要將邏輯測試用例轉換成物理測試用例的信息，需要如下問題的回答：

　　參與一個用例的所有變量的范圍是什么?

　　在不同的用例變量之間存在哪些輸入和輸出關系?一個用例觸發什么，前置或后置條件是什么?

　　有不同用例之間的順序依賴嗎?

　　所需的額外信息需要在類和約束、類圖和順序圖的描述中確定。

　　作為一個例子，了解相關變量的內容是重要的。特別是，一個人必須理解影響一個用例結果的不同輸入可能性。一個用例可能的實例數量取決于這些變量。例如，償還抵押貸款的變量可以是不同的償還方式或一個客戶可以允許有的抵押貸款數量。

　　此外，需要額外的信息在更高的質量級別測試。例如：

　　要開發一個測試策略和計劃，了解哪些用例對于系統功能是至關緊要的，哪些不是，這是很重要的。除此之外，要注意了解每個用例的相關執行次數。換句話說，用例以何種頻率在系統中使用?當不能從文檔中取得額外信息時，在客戶組織中的系統專家和/或最終用戶應當提供這些問題的答案。

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