需求管理

2.1軟體測試需求概念

1， 軟體測試需求：以一個專案的觀點看待軟體測試工作，這個專案的範圍就是軟體測試需求，它定義了軟體測試工作的範圍，是進行其他測試活動的基礎。

軟體測試需求的內容： –功能測試需求

–效能測試需求

–可靠性測試需求

–國際化與本地化測試需求

–安全性測試需求

2，軟體需求管理

1) ]軟體需求的概念：軟體測試需求管理是要通過人為的和技術的手段、方法和流程，以保證和監督測試團隊明確測試軟體產品的目標。

定義1：軟體需求就是一個為軟體系統的需求進行啟發、組織、建檔的系統方法，一個建立和維護客戶和專案團隊之間關於變更系統需求所達成的一致性的過程。

定義2：一種獲取，組織並記錄系統需求的系統化方案，以及一個使客戶與專案團隊對不斷變更的系統需求達成並保持一的過程。

2) 軟體需求管理要求:

a) 軟體需求規格說明已文件化，並經評審後存檔。

b) 文件化的軟體需求規格說明受管理和控制。

c) 供軟體工程和管理使用的分配基線已建立，使軟體產品滿足分配需求的接收標準；分配需求是制定軟體開發計劃的根據，是整個軟體生命週期中估算、計劃、執行和跟蹤軟體專案活動的基礎。

d) 軟體開發計劃、軟體工作產品和軟體過程活動與軟體需求保持一致。

業界常見的測試過程中存在的問題：

軟體測試本身的需求文件不全，有些需求待定；

產品質量維度事先沒有全面明確，要包括的測試型別不全；

測試計劃和編寫測試案例沒有規範；

沒有系統的測試需求分析方法、流程或指導；

測試中經常會出現需求和缺陷遺漏、測試設計遺漏的問題。

3) 軟體測試需求管理意義

（1）失敗經驗教訓說明必須要有軟體測試需求管理

（2）業界專家建議必須實施軟體測試需求管理

（3）缺乏成熟的理論和統一標準而需要需求管理

2.2軟體測試需求分析

1， 分析的目標和任務：

1） 軟體測試需求分析的目標：軟體需求分析的目的就是要對軟體測試要解決的問題進行詳細的分析，弄清楚參與軟體測試活動的干係人對軟體測試活動和交付物要求，包括需要輸入什麼資料，要得到什麼結果，最後應輸出什麼。

2） 測試需求分析主要有兩個任務：

（1）通過對測試活動需要解決問題及其環境的理解、分析和綜合，建立分析模型。

（2）在完全弄清所有測試活動干係人對測試的確切要求的基礎上，用 “軟體測試需求規格說明書”把測試需求以正式書面形式確定下來。（Software Test Requirement Specification，SRS，簡稱測試需求書）

2，分析的方法

1）軟體測試需求分析的意義：

如果把測試活動比作軟體生命週期，測試需求就相當於軟體的需求規格，測試用例相當於軟體的詳細設計，測試用例的開發過程相當於軟體的編碼過程。但是軟體測試不是簡單把“軟體”兩個字全部替換成了“測試”這樣簡單，就測試需求分析的方法而言，即可以參考軟體需求分析方法，又有其獨特性。

2） 軟體測試需求分析的方法:

（1） 通過軟體的需求推導軟體測試需求（最通用的方法）

3，分析的過程

1） 軟體測試需求分析的過程

（1） 軟體測試需求分析干係人分析

（2） 需求收集和整理

（3） 測試需求的優先順序排序

（4） 評審測試需求

4， 分析結果和評審

評審內容:評審的內容包括完整性檢查和準確性檢查。

評審的方法:相互評審、交叉評審；輪查；走查；小組評審；評審人員

正式評審小組中，一般存在多種角色，包括協調人、作者、評審員等。

評審員需要精心挑選，保證不同型別的人員都要參與進行來，通常包括開發經理、專案經理、測試經理、系統分析人員、相關開發人員和測試人員等。

2.3軟體測試需求管理內容

1，變更管理

從關注幾個方面的問題來分析軟體測試需求管理的內容：

（1）定義測試需求

（2）測試需求確認

（3）建立測試需求狀態

（4）測試需求評審

（5）測試需求責任制

（6）測試需求跟蹤

1） 軟體測試需求的變更的原因：

a)客戶的需求變更

b)市場需求變更

c)技術或非技術的其他原因

2）軟體測試需求變更管理:

a)測試需求變更管理的必要性

b)測試需求變更管理的意義

c)軟體測試需求變更的主要任務:分析變更的必要性和合理性，確定是否實施變更；記錄變更資訊，提交變更申請；做出更改；修改相應的軟體測試工作，如更新測試用例等；評審後，正式釋出新版本的軟體測試需求說明書。

d) 建立測試需求管理模型

2， 狀態管理

在測試工作進展的過程中，可能存在若干種狀態：

（1）只知道大致需求，具體細節還有待細化；

（2）已經初步確定，等待評審；

（3） 已經確定的，並經過團隊評審，在可預期未來不會發生變更；

（4） 已經評審完畢正在進行設計、實現測試用例的測試需求；

（5） 完成設計、實現測試用例的測試需求。

1)[軟體測試需求的狀態

Open：對於原始需求或接收到的正式需求，但未正式進行需求分析之前的需求狀態統一定義為：“Open”狀態

Analyzed：對需求狀態為“Open”的需求，若已完成需求分析過程，但還未正式通過需求評審前，其狀態統一定義為“Analyzed”狀態

Reviewed：對需求狀態為“Analyzed”的需求，若已正式通過需求評審，但還未完成測試，或測試結果為不合格之前，其狀態統一定義為“Reviewed”狀態

Resolved：對需求狀態為“Analyzed”或“Reviewed”的需求，若已完成需求設計和編碼，且已通過單元測試，其狀態統一定義為“Resolved”狀態

Passed：對需求狀態為“Resolved”的需求，如果已通過正式測試，其狀態統一定義為“Passed”狀態

Unresolved：對需求狀態為“Resolved”的需求，如果未通過正式測試，其狀態統一定義為“Unresolved”狀態。

Closed：對需求狀態為“Resolved”的需求，若需求已正式上線商用，且得到客戶和專案團隊的共同認可後，其狀態統一定義為“Closed”狀態。

Cancel：當原定義的某些需求被取消時（包括上線前取消和上線後取消），其需求狀態統一定義為“Cancel”狀態。

Failed：對需求狀態為“Closed”的需求，若需求在上線商用後發現問題或存在缺陷，需要對其進行修正時，其需求狀態統一定義為“Failed”狀態

測試需求狀態轉換

3， 文件版本管理

定義：軟體測試需求文件的版本管理是軟體測試需求管理的基礎，籍此可以使得同一軟體測試需求文件可以被測試團隊中不同的人員編輯，並且記錄下每次編輯的增量，必要的情況下還可以回滾到某個版本。

HP Application Lifecycle Management文件版本管理的功能：

• 許可權管理

• 每次文件升級後的版本管理和恢復

• 團隊協作時同時操作

• 文件版本比較

4， 跟蹤管理:指跟蹤一個軟體測試需求使用期限的全過程。

1)軟體測試需求跟蹤有兩種方式，正向跟蹤與逆向跟蹤:

正向跟蹤：以軟體測試需求為切入點，檢查軟體測試需求說明書中的每個需求是否都能在測試用例設計和實現中有相應的測試用例對應。

逆向跟蹤：測試用例設計和實現等測試交付物是否都能在軟體測試需求說明書中找到測試需求與之對應。

2) 軟體測試需求跟蹤的作用

• 為測試團隊提供了軟體測試需求跟蹤能力。

• 通過跟蹤軟體測試需求的後續測試用例資訊可以幫助確保所有軟體測試需求被實現，沒有遺漏。

• 在對軟體測試需求進行增、刪、改等變更時可以確保與之對應的測試用例也進行必要的更新，而不被不忽略。

• 及時可靠的對軟體測試需求進行跟蹤，使得維護時能正確、完整地實施變更，從而提高生產效率

2.4惠普測試需求管理解決方案

用於現代應用測試的軟體解決方案有惠普應用生命週期管理(ALM)是一款應用測試軟體，可為您提供統一的儲存庫、一致的使用者體驗,可定製的儀表板，支援從單一儲存庫管理整個應用生命週期，包括從需求開始到準備交付為止的整個過程。

惠普應用程式生命週期管理流程圖:

（1）指定版本

（2）指定需求

（3）計劃測試

（4）執行測試

（5）追蹤缺陷

惠普應用程式生命週期管理系統模組有11個模組，如圖：