第一章 什么是高質量的用例
1.1 為什么要使用用例
用例提供了一種用于構建故事的半形式框架；
在每個用例和所有描述層次中，用例都描述了錯誤情況的系統需求；
雖然本質上是一種功能分解技術，但用例已經成為面向對象軟件開發的一個流行元素；
用例提供了可以在其上處理其他項目信息的骨架：
項目經理根據用例進行估計和發布進度；
數據及業務規則制定人員可以把自己的需求和所需用例聯系起來；
用戶界面設計人員可以進行設計，并將其與相關用例聯系起來；
測試人員可以根據用例中描述的成功和失敗情況構建測試場景（測試用例）；
1.2 編寫用例容易出現的問題
用戶界面太多，用戶界面應屬于設計范疇，鼠標、按鍵等內容不應出現在用例中；
較低目標層次上的用例太多，無法展示系統將會給其最終用戶提供什么功能；
使用用例表示非行為信息，性能需求、業務規則等不要在用例中描述；
太冗長，最好在3~9步；
目標實現不完整，尤其是錯誤處理；
句子片斷，主、謂、賓盡量完整；
1.3 為什么使用用例模式語言
描述了用例的質量標志及其編寫過程，提供了能夠經受時間考驗的用例改進建議；在評審用例初稿和改進其質量的過程中，這個工具能起到很大作用。
1.4 什么是模式
模式是質量標志和策略；
1.5 使用模式語言時錯誤觀念
模式提供了一個關于其自身和模式內容的完整方法；只起補充作用
使用模式肯定會成功；
模式為老問題提供了新的解決方案；只是經常出現的問題的通用可靠方案
模式適用于所有情況；僅是處于某種上下文中的問題的解決方案
1.6 模式組織
|
模式分類 |
子類 |
|
開發模式 |
團隊組織：判斷和改進用例團隊組織方式的質量的模式； |
| 過程：判斷和改進團隊用來創建用例的方法質量的模式； | |
| 編輯：隨著潛在需求的變化和編寫人員知識的增加，判斷和改進單個用例的質量； | |
|
結構模式 |
用例集：判斷和改進用例集質量的模式； |
| 用例：判斷和改進單個用力質量的模式； | |
| 場景和步驟：判斷和改進用力場景以及這些場景中的步驟質量的模式； | |
| 用例關系：判斷和改進集合中用例之間的結構關系質量的模式； |
1.7 用例的讀者和編寫者
有兩組不同的認閱讀和使用用例：（1）最終用戶或業務專家；（2）程序員。
用例編寫組必須包括：
至少一位具有編程背景的認，以獲得描述所要求的準確性和精度；
至少一位熟知業務規則的認；
至少一位熟知在實際中如何使用系統的認；
第二章 團隊
2.1 SmallWritingTeam
原因：
用例要求具有不同觀點和專業知識的人編寫；
將一大組人聚集在一起是困難的；
理論上，在用例上投入的人越多，就能越快的完成用例編寫工作；
大的團隊會變得低效；
大型編寫團隊可能會通過集體討論的形式開發用例，添加許多不必要的特性；
所以：
一個由2人或3人組成的團隊足夠小，容易交流和達成一致；
可以使用幾個SmallWritingTeam，但應當制定一位用例設計師，以保證所有用例與愿景一致。
最終目的是使過程保持在可管理狀態，大的團隊將在管理上投入更多的精力。
2.2 ParticipatingAudience
沒有涉眾提供的信息和反饋，就不能滿足他們的需要；盡可能使客戶和內部涉眾積極參與用例開發過程。
2.3 BalancedTeam
由一些個性相似、意見相同的個人組成的團隊開發用例，可能會得到一組缺乏創見、范圍狹窄的用例，這種用例不能滿足每個人的需要。
因此，為小組配備具有不同專長的人員，以維護開發過程中涉眾的利益，確保團隊中包括開發人員和最終用戶。
最大好處是使編寫人員在用例中使用常見的、可理解的術語。
第三章 過程
編寫好的用例是極其個性化的，每個人都有他自己的風格，每個組織都有根據自己的文化和業務需要做事情的方式，因此，沒有創建用例的通用過程。
3.1 BreadthBeforeDepth
原因：
需求收集是一個發現過程，用例編寫是一個迭代過程；
人們很早就開始編寫用例的細節；
人們浪費了精力或陷入了太多的細節，通常都會失去重點，無法描述所有可能的擴展條件；
從早期獲得概述是有益的；
最初編寫的細節越多，在了解系統后必須進行的改變也就越多；
所以：
通過首先開發用例的概述來保存精力，然后逐步增加細節，并行開發一組相關用例。
完成概述用例后，隨著對系統了解的增多，不斷提高用例精度，避免突然開發完所有用例或一次只開發一個用例的傾向。
3.2 SpiralDevelopment（螺旋式開發）
原因：
理解系統的行為可能會花掉大量時間，要求漸進式分析；
拖延是昂貴的。要盡快完成用例的編寫；
對需求進行分析后，需求很可能會發生變化；
需求成本的錯誤是昂貴的；
所以：
以一種迭代的，寬度優先的方式開發用例，每次迭代都會提高用例集的準確性和精度。
基本過程：
從簡單的東西開始，如一個參與者/用例列表；
簡要描述用力主場景，即高層用例，以包含用例的主要范圍；
擴展摘要的子集，并填充細節；
評審并調整；
3.3 MultipleForms
不同的項目需要不同程度的形式化，每個人對模板都有不同的偏好，要求每個人都使用相同的用例模板只會起到相反的作用。
原因：
每個人的個性、經驗和經受的鍛煉不同，每個開發組織都有其特有的人員、歷史和文化；
不同的項目有不同的需要；
不同的編寫團隊需要不同程度的規范和嚴格度；
在組織中使用公共的編寫形式有助于交流；
在同一個項目上使用不同的模板不是一個好主意；
因此：根據項目相關的風險性、項目特點，和所涉及到的人員選擇用例的編寫格式，并在該項目的開發過程中的組織內部使用。
3.4 TowTireReview（評審）
許多人都可能需要評審用例，這是一件昂貴耗時的事情。
原因：
對于驗證和確認編寫及內容來說，評審是必要的；
涉眾在用例上有一種既得利益；
使每個人參與編寫過程非常昂貴、麻煩并且緩慢；
如果僅由一個小的編寫組進行評審，就不會考慮所有涉眾的利益；
評審可能是昂貴的、乏味的、耗時的。
所以：
進行兩種類型的評審：第一種是由較小的內部小組進行的評審，可能要重復進行很多次；第二種是由整個團隊進行的評審，可能只進行一次。
3.5 QuittingTime
開發一個超出了涉眾和開發人員需要的用例模型不僅浪費資源，而且會拖延項目進度。
原因：
忽視重要需求的巨大恐懼使構建人員和涉眾延長了需求收集活動；
大多數人可以用一種合理的模糊性工作，即不言自明；
詳細講述謊言并不能使他們更為精確；
所以：
在用例完整并且符合參與者的需要后，停止開發用例；
用例模型完整性的檢驗：完整、可讀、邏輯上正確、對開發人員足夠詳細。
是否識別了所有的參與者和目標并將其編成了文檔？
客戶及其代表是否承認用例集是完整的，而且每個用例都是可讀的和正確的？
設計人員是否能夠實現這些用例？
3.6 WriterLicense
小的格式差別并不重要，解決了所有系統問題后，及時還存在一些格式問題，也可以停止編寫；
文章來源于領測軟件測試網 http://www.kjueaiud.com/