用例圖經常被分組來顯示涉眾們的需求集合(請看圖 1中的例子)。在這個圖中，任何一個直接與系統聯系的單位通常都被看作是一個“參與者”。一個參與者可以是一個人或者代表一個或者多個人的角色。它還可以是另一個計算機系統。一個參與者通常由一個“人性圖標”代表，即使當這個參與者是另一個計算機系統時也是這樣。每個用例都由一個橢圓形代表，用描述這個用例將要執行什么樣的行為的說明型陳述進行標注。這個陳述作為這個用例的名稱。它應該簡潔，但是描述的行為應該被執行。還可以繪制溝通連線來顯示參與者與用例之間的關系。
圖 1：用例圖
用例可以由用例描述來支持，包括關鍵屬性，比如先決條件，和一系列的事件。一個用例模型由這個用例的圖，參與者定義構成，也可能包括這個用例的描述。 6
一個團隊開發用例最初目的是，識別用戶涉眾們想要從這個系統中獲取的所有的核心功能。一旦他們確定了這些功能，這個團隊就可以開始展開每個關鍵功能相關的細節，他們也開始關注可能與每個被識別的用例相關的可選過程流程及例外條件。
在用例的開發過程中，通常假設這個核心功能將有一個正面的或者成功的結果。這通常被看作是“基本路徑”或者“快樂路徑”。例如，如果使用“搜索一個產品”，這個正面的結果將是被搜尋產品的結果。大量的可選擇流程，包括例外情況和錯誤，也可能存在。比如，如果這個產品沒有找到該怎么辦呢?或者，這個產品目錄所在的系統沒有反映該怎么辦呢?或者，一個消費者在這個搜索區域中鍵入了無效的信息該怎么辦呢?這些還是有效的路徑，應該在文檔中可以獲取。
用例文檔細節的層次和類型在不同的組織或者公司中有很大的區別，甚至從一個項目到同一個組織中的另一個項目也有很大的差別。這些差別可能會受到許多不同因素的影響，包括這個項目的預算或者范圍 (尤其當這個解決方案本質上是面向對象時)，可利用資源的技術組合，UML 的使用，以及 RUP 或者其它方法的使用。
正如上面所提到的，用例可能完全是不帶支持的基于文本的圖，或者它們可能僅僅使用簡單的用例圖來描述，如圖 1所示。根據對象管理組織， UML 2.0 有十三種不同類型的圖。 7 這些圖被分成了三個類別：結構圖，行為圖，以及交互圖。結構圖，比如類圖，代表靜態應用軟件的構架。行為圖，比如用例和活動圖，代表普通類型的行為。交互圖，比如一系列的圖，代表交互作用的不同方面。除了團隊可以生成的各種圖外，團隊還可以創建其它支持型工件，比如一個詞匯表或者特設需求文檔(例如，一個非功能型的需求)。 8
一個項目用例的開發通常被看作是促進需求收集過程的一種方法，從而加速應用軟件的開發。大多數出版物看起來似乎主要強調的用例的這些方面。而大多數軟件測試出版物并不會參考用例，實際上這些用例在許多區域的驅動改善方面，對測試組織具有極其重要的價值。
用例對測試組織的利益
正如我們在下面部分將要顯示的，用例為改善測試質量和效力提供了引人注目的利益。
估計估算
用例在測試估計領域提供了令人興奮的機會。John Smith 9 詳細說明了利用 Constructive Cost Model (COCOMO) 將一個用例轉化為源代碼行(SLOC) 的詳細過程，反之，利用這個信息開發 Rough Order of Magnitude (ROM) 的估計。 10 這種方法的成功是假定那個低層次工作產品，比如構架和數據設計，先前已經生成了。 11
另一個估計技術，用例功能點(UCFP) 評估，是功能點計算方法的改編。它與 COCOMO 方法有相同的風險。由于支持評估的這兩種比較舊的方法基礎存在一定的缺陷，想連接細節層次與分解之間的鴻溝，被認為是很難有效地被克服。然而，由于 ROM 估計有被鎖定的趨勢，并在項目早期考慮到了后果，因此任何提供可靠信息的并且與測試估計相關的工具，在此過程早期仍然有一定的價值。
這個用例點方法(UCPM) 似乎為有效測試估計提供了最高的潛能。這種方法的開發是建立在更新的設計方法基礎上的，而不是被更新來處理用例的使用的。1992年 Gustov Karner 介紹過，這個評估是由用例的元素驅動的。 12 通過一些修改，這個方法可以直接被測試組織所利用。 13 如果測試組織被越多黑盒、工作流所驅動，主要的用例文檔就越能有效地在估計中運用。因此，有了 UCPM 用戶的驗證或者系統的整合，團隊就能夠生成更精確的比其它測試階段更早的評估。由于任何估計工具或者方法都會依賴于輸入的準確度，歷史的估計數據，當它們逐漸變得可利用時，將在這些評估技術中提供更高的信任度。
開發輸入
用例能夠促進開發測試組織所依賴的更高質量的輸入和代碼。由于用例開始具體化，這些用戶或者參與者的需求也按照目的進行討論。這個過程迫使開發者將重點集中在所使用的開發模式外部的功能需求之上。 14 這個方法將開發人員拉進用戶的思維過程中 (比如，他們的目標)，開發人員就能看到這種環境下的需求。這個過程將促使開發人員更徹底地了解這個系統將希望做什么，因此，能夠向測試人員交付一個構建良好的解決方案。
盡管這個過程需要進一步的技術分析，但是這些用例能夠為可靠的測試要求的輸入到其它工作產品中而被分解。從這一點看，這些相關的或者黑盒情景已經被轉換成白盒工具。 15 分析設計建模輸出與驅動它的用例直接相連接。此外，用例驅動用戶體驗建模，為確保用戶界面在整個解決方案過程中的一致性設置了相應的階段。在面向對象的編程用例中，這些模型清楚地展示了連接到用例地類和方法。低層次文檔中任何變更的影響都能夠連接到返回到任何高層次用例。 16
可追溯性
在一個解決方案所有質量因素中最關鍵的是跟蹤開發和交付過程所有階段的需求能力。IEEE 引用從一個工件到另一個工件的連接元素，并用這種定義作為這個練習中單純證明。 17 用例能夠定義前任繼承者關系，并為驅動因素示例特征。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
