軟體測試學習教程—軟體測試基礎理論五

　　在上一篇文章中介紹了有關軟體測試常用的技術，今天筆者繼續來和大家分享。

 

　　需求的重要性，在軟體測試過程中，從需求分析開始到整合測試階段引入測試手段，能發現所有缺陷的80% ；系統測試階段引入測試手段，能發現剩餘缺陷中 80% 的缺陷；在執行維護階段經過長時間、大量執行軟體後，能夠發現最後剩餘的 20% 缺陷

 

　　軟體需求的定義，IEEE 軟體工程標準詞彙表（ 1997 年）中定義需求為：

 

　　（1 ）使用者解決問題或達到目標所需的條件或權能（ Capability ）

 

　　（2 ）系統或系統部件要滿足合同、標準、規範或其它正式規定文件所需具有的條件或權能（ 3 ）一種反映上面（ 1 ）或（ 2 ）所描述的條件或權能的文件說明。需求是指明必須實現什麼的規格說明。它描述了系統的行為、特性或屬性，是在開發過程中對系統的約束。

 

　　軟體需求的層次：使用者需求（user requirement ）文件描述了使用者使用產品必須要完成的任務，這在使用例項（ use case ）文件或方案指令碼（ scenario ）說明中予以說明。業務需求（ business requirement ）反映了組織機構或客戶對系統、產品高層次的目標要求，它們在專案檢視與範圍文件中予以說明。功能需求（ functional requirement ）定義了開發人員必須實現的軟體功能，使得使用者能完成他們的任務，從而滿足了業務需求。

 

　　軟體需求主要包括兩個方面：需求開發和需求管理。需求開發可進一步分為四個階段：

 

　　1. 需求獲取階段

 

　　2. 需求分析階段

 

　　3. 編寫需求規格階段

 

　　4. 需求驗證階段

 

　　軟體需求規格說明的特點：

 

　　1. 完整性，不能遺漏任何必要的需求資訊。遺漏需求將很難查出。注重使用者的任務而不是系統的功能將有助於你避免不完整性。如果知道缺少某項資訊，用 TBD （“待確定”）作為標準標識來標明這項缺漏。在開始開發之前，必須解決需求中所有的 TBD 項；

 

　　2 。一致性，一致性是指與其它軟體需求或高層（系統，業務）需求不相矛盾。在開發前必須解決所有需求間的不一致部分。只有進行一番調查研究，才能知道某一項需求是否確實正確；

 

　　3. 可修改性，在必要時或為維護每一需求變更歷史記錄時，應該修訂 SRS 。這就要求每項需求要獨立標出，並與別的需求區別開來，從而無二義性。每項需求只應在 SRS 中出現一次。這樣更改時易於保持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟體需求規格說明更容易修改

 

　　4. 可跟蹤性，應能在每項軟體需求與它的根源和設計元素、原始碼、測試用例之間建立起連結鏈，這種可跟蹤性要求每項需求以一種結構化的，粒度好（ fine-grained ）的方式編寫並單獨標明，而不是大段大段的敘述。

 

　　這是今天筆者和大家分享的知識，在後續的文章中，筆者會繼續帶著大家來學習。