Use Cases的工業接受
Use Cases第一次被正式的描述是在6年前（1992年），從那以后它就被最主要的面向對象的方法采用，同時作為描述現在和將來的操作模式的有用技術被商業再生工程團體（Business Process ReEngineering Community）采用。
Use Cases最近它們自己取得在UML（Unified Modeling Language）中有效的地位和位置而得到了突出的進步。UML已經被OMG（對象管理組織）計劃做為對象系統的標準語言。
什么是Use Cases？
Use Cases本身是用戶或其它系統與正在設計的系統的一個交互，是為了達到一個目標。術語Actor（行為者）是用來描述有這個目標的人或系統，這個術語是用來強調有這個目標的任何人或系統。目標的本身是用行為動詞開始的短語表達的，如：“Customer : place order”、“Clerk : reorder stock”等。
情節的角色
在Use Cases中不同的情節顯示了目標怎樣成功或失敗，成功的情節是目標達到了，失敗的情節是目標沒有達到。這個的好處是因為目標總結了系統的各種使用的意圖，用戶能看到被設想怎樣地使用這個系統，并且不必等到出現第一個原型或是比較糟糕的等到系統被開發出來才發現什么時候系統并不全面地支持他們的目標。
Use Cases將做成多大？
試圖決定Use Case的大小是一個很有趣的話題，處理這件事的一個方法是將Use Case的大小跟它的意圖和范圍關聯起來，對于一個真正大的范圍來說，一個Use Case并不要在一個系統中處理那么多，但這些系統都用于同一商業領域，稱為Business Use Case，它把整個公司看作一個黑盒和Actor關于公司目標的說明。這些Business Use Case的情節不容許假定任何公司內部的結構，一個客戶將向公司下一個定單而不是客戶服務部門。
對于系統發展而言，Use Case的范圍限制一個單一的系統，這是Use Cases最通常的形式，我們稱之為System Use Case，它把整個系統看作是一個黑盒，它不指定任何內部結構并且僅受限于問題域的語言描述。
Use Cases的另一范圍是設計子系統和系統內部組件的，稱為Implementation Use Cases，它把組件看作一個黑盒，并且這些Actors是區分它的成員。例如：可能會用Implementation Use Cases去說明應用系統中email組件的需求。
給出了這些分類，關于Use Case的大小話題變得容易了，設計這些項的范圍來調整整個大小。幫助系統設計者，每個Use Case只描述沒有大的分支的行為的單個線索。違背這個規定，Use Case看起來通常是不準確的或含糊的，作為測試說明的資源和參考，它也是很難使用的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
