軟件測試需求分析與跟蹤

1.1  需求的重要性

1.1.1 軟件缺陷的8020原則

1)      在軟件測試過程中，從需求分析開始到集成測試階段引入測試手段，能發現所有缺陷的80%；系統測試階段引入測試手段，能發現剩余缺陷中80%的缺陷；在運行維護階段經過長時間、大量運行軟件后，能夠發現最后剩余的20%的缺陷。

 

 

 

1.2   軟件需求

1.2.1  軟件需求的定義

1） IEE軟件工程標准詞匯表( 1997年)中定義需求為:

 

(1)用戶解決問題或達到目標所需的條件或權能( Capability )

 

(2) 系統或系統部件要滿足合同、標准、規范或其它正式規定文檔所需具有的條件或權能。

(3)一種反映上面( 1 )或( 2 )所描述的條件或權能的文檔說明。

 

2)      需求是指明必須實現什么的規格說明。它描述了系統的行為、特性或屬性，是在開發過程中對系統的約束軟件需求的層次

 

1.2.2  軟件需求的層次

1)      用戶需求( user requirement )文檔描述了用戶使用產品必須要完成的任務，這在使用實例(use case )文檔或方案腳本( scenario )說明中予以說明

2)       業務需求( business requirement )反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明

3)       功能需求( functional requirement )定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求

 

 

 

1.2.3  軟件需求主要包括兩個方面：需求開發和需求管理

1.2.4  需求開發可進一步分為四個階段

1. 需求獲取階段
2. 需求分析階段
3. 編寫需求規格階段
4. 需求驗證階段

 

 

 

1.2.5  不適當的需求過程可能引發風險

1. 用戶不多導致產品無法被接受
2. 用戶需求的增加帶來過度的耗費和降低產品的質量
3. 模棱兩可的需求說明可能導致時間的浪費和返工
4. 用戶增加一些不必要的特性和開發人員畫蛇添足( gold. plating)
5. 過分簡略的需求說明以致遺漏某些關鍵需求
6. 忽略某類用戶的需求將導致眾多客戶的不滿
7. 不完善的需求說明使得項目計划和跟蹤無法准確進行

1.3   軟件需求規格說明書

1.3.1  軟件需求規格說明的特點

1)     完整性

不能遺漏任何必要的需求信息。遺漏需求將很難查出。注重用戶的任務而不是系統的功能將有助於你避免不完整性。如果知道缺少某項信息，用TBD( "待確定” ) 作為標准標識來標明這項缺漏。在開始開發之前，必須解決需求中所有的TBD項。

2)     一致性

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

3)     可修改性

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

4)    可跟蹤性

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

 

1.4   軟件測試需求跟蹤矩陣

1.4.1  什么是測試需求跟蹤矩陣

1. 需求樹的概念
2. 需求樹的好處
3. 閱讀理解各類需求
4. 結合界面原型圖理解軟件各部分功能
5. 從葉級別的功能點開始編寫矩陣
6. 保證每個功能點都有正反測試思路覆蓋,正反測試配比達到1 : 4(部分功能點沒有反向測試)
7. 只寫清測試思路和預期結果，不用具體展開
8. 寫好的測試需求跟蹤矩陣必須通過評審才算最終完成

1.4.2  編寫測試需求跟蹤矩陣的步驟

 

1.5   軟件測試需求

1.5.1  軟件測試需求分析目標

對軟件測試要解決的問題進行詳細的分析,弄清楚參與軟件測試活動的相關人員對軟件測試活動和交付物的要求，包括需要輸入什么數據，要得到什么結果，最后應輸出什么等。

 

1.5.2  軟件測試需求分析步驟

1. 根據軟件開發需求說明書逐條列出軟件開發需求,並判斷其可測試性
2. 形成可測試的描述並界定出測試范圍
3. 根據質量標准,逐條制定質量需求,即測試通過標准
4. 分析測試執行時需要實施的測試類型
5. 建立測試需求跟蹤矩陣，並輸入測試需求管理系統,對測試需求實施嚴格有效的管理