軟件測試之用例分析

自從1992年 Ivar Jacobson 發表了關于如何使用用例，從系統用戶的角度來提取軟件需求的方法的論文之后，這種方法已經逐漸流行起來。但是有一個最常見的問題是：當我得到了用例之后，如何才能把他們用代碼實現出來？本文由兩部份組成，將會用一個實際的案例來說明這一點。如何從用例中提取需求，并加以分析，進一步將其轉化為可以直接進行編碼的格式。我希望能夠把這一過程講清楚，這樣你在當前的，或是下一個軟件項目中就可以使用它們了！

　　IBM Rational Unified Process(RUP) 提倡通過用例來提取系統中可操作的需求。 1 軟件需求說明書，即 Software Requirements Specification (SRS)，包括軟件的所有需求，其中包括很多相關的文檔。用例就是其中的一個重要部分。 SRS主要包括以下幾部分：

　　用例模型，包括：

　　用例圖：可視化的描述系統用戶，和系統為用戶提供的服務。

　　角色定義：用文字描述系統功能，和系統所需的服務。

　　用例描述：用文字描述系統提供的主要功能。

　　軟件補充規格文檔：這個文檔包括了整個系統相關的各種需求，和一些與對系統用戶和用例都不直接相關的隱藏需求。
　　在RUP方法中，這個需求文檔是后續的分析和設計工作的起點。不同的開發方式，對項目的推動力是不同的，也就會產生不同的文檔。如果軟件發布之后，你還總是在不停的修補缺陷，你很可能根本沒有需求文檔。只能從Bug報告中看出，軟件已經和最開始設計的樣子不一樣了。如果你在維護或者改進一個軟件版本（比如增加一項新功能），你可能有一兩個用例，他們描述了這些新功能和用戶之間如何交互，但是你不會有軟件補充規格文檔，因為這些功能之外的部分并沒有改變。

　　在這里，用一個虛構的軟件項目"green-field" 作為例子。這是一個面向對象的軟件項目，使用UML來描述系統中的各種概念與關系。讀者需要具有對象和類的基礎知識，熟悉UML 版本1.x 或者2.0中的類圖、順序圖和協作圖。

用例分析活動

　　下面我們討論一下RUP中的用例分析。如圖1所示，將RUP中結構分析的結果整合起來。

　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　圖1： 結構分析的工作流程(early Elaboration)

　　顯而易見，嚴格來說的話，軟件開發過程應該側重于企業系統級的架構設計，以及軟件重用。但是基于以下三點原因，在這里我不會長篇大論的講述結構分析：

　　我的目標不是結構分析設計，而是面向開發人員的更底層的日常工作。

　　這不是一本專著，沒有那么多篇幅來講述結構分析。

　　根據我多年在軟件架構和軟件過程方面的咨詢經驗來看，只有很少的軟件開發組織能夠很規范的進行結構分析。如果你正在從事結構分析，你一定曾經經歷過本文中的一些內容。對一個新的，或是一個大型的軟件項目來說，采用結構分析是明智的選擇。但是如果你不太熟悉結構分析，本文的內容將會對你有所裨益。
用例分析的目的：

　　找出用例中的執行流程、事件的各個類。

　　通過實現用例，把用例的行為指定到具體的類。

　　找出類的責任、屬性和他們相互的關系。

　　規范地確定系統中各用例的職責。
　　我們也可以認為，用例分析的目標，就是把我們對用例的理解，轉變為與業務一致的形式，實現需求的價值。在用例設計的時候，我們把業務概念抽象成類、對象、關系、組件、接口等等，這些都與目標系統直接對應。

原文轉自：http://www.anti-gravitydesign.com