測試管理之從需求到跟蹤的操作實務_軟體測試

本文連結： http://www.51testing.com/html/09/n-3724909.html

需求跟蹤是一個高階的管理活動，目標是為了更好地管理需求的狀態，更好地分析需求變更產生的影響。雖然執行需求跟蹤會帶來不錯的效益，但其所需付出的工作量也是巨大的。因此在需求定義，需求開發和需求管理還沒有非常順暢時，不太建議引入需求跟蹤活動。 1.1 需求跟蹤的基本概念

需求跟蹤是將單個需求和其他系統元素之間的依賴關係和邏輯聯絡建立跟蹤。這些元素包括：各種類型的需求，商務規則，系統架構，設計組件，源碼，測試案例，以及協助文檔等。具體來說需求跟蹤涉及5中類型的跟蹤鏈：

通常需求跟蹤的收益體現在以下幾個方面，都屬於比較高階的管理收益：

》審核：跟蹤資訊可以協助審核確保所有需求都被應用。

》變更影響分析：跟蹤資訊在增刪改需求時，可以確保不忽略每個受到影響的系統元素。

》維護：可靠的跟蹤資訊使得維護時能正確，完整地實施變更，從而提高生產率。

》項目跟蹤：認真記錄跟蹤資料，可以使得計劃當前的實現狀態。

》再設計：可以列出傳統系統中將要替換的功能，記錄他們在新系統的需求和軟體組件中的位置。

需求跟蹤是比較高階的管理活動，所需的工作量非常大，特別是軟體需求到設計項目的跟蹤，因此一定要考慮投入與收益是否成正比。

1.1.1 使用者需求到軟體需求的跟蹤

跟蹤鏈第一類是使用者需求到軟體需求的跟蹤，工作量中等，對與專案管理好處很明顯，建議有時間盡量實現此類跟蹤。

1.1.1.1 目的：保證所有的使用者原始需求都得到滿足。

1.1.1.2 好處：

》開發人員在實現時能精確地定位到相關的原始需求。

》可以為軟體需求是否必要提供第一手證據。

》容易找到需求之間的矛盾和歧義。

1.1.1.2 具體手段：在第六章 需求分析與建模最佳實務中介紹到一種方法，就是將一句話標識的使用者原始需求直接歸併到軟體需求的用例中。

1.1.2 軟體需求到軟體需求的跟蹤

跟蹤鏈中的第二類是軟體需求到軟體需求的跟蹤，這類跟蹤工作量規模較小，對於需求管理的好處十分明顯，此類跟蹤最應該建立。

1.1.2.1 主要內容：

》項目目標，stakeholder關注點到軟體需求的跟蹤。

》相關軟體需求之間的跟蹤。

1.1.2.2 目的：確保項目目標，stakeholder關注點被實現。

1.1.2.3 好處：

》更好地理解軟體需求的實現意義。

》更好地處理軟體需求之間的邏輯相關性。

1.1.2.4 具體手段：為項目目標，stakeholder關注點，建立唯一編號，通過表格或連結法實現跟蹤。

1.1.3 軟體需求到下遊工作產品的跟蹤

跟蹤鏈中第三類是軟體需求到下遊工作產品(系統架構，設計組件，源碼，測試案例，協助檔案等)的跟蹤。這類跟蹤對於變更管理的好處十分明顯，但工作量巨大，因此此類跟蹤應該謹慎使用。

1.1.3.1 目的：維護軟體需求與設計項目，測試元素之間的關聯關係。

1.1.3.2 好處：

》在針對變更的技術影響分析時，能夠得到更加精確的評估結果。

》可以更好地隔離變更影響。

1.1.3.3 具體手段：手動更新或通過組態管理軟體來實現更新。 1.2 需求跟蹤的操作方法

要對需求進行跟蹤，就必須對每個需求定義唯一標識。在實際操作過程中，主要有表格法和鏈表法兩種跟蹤策略。

1.2.1 表格法

在使用需求跟蹤矩陣時，只是制定了計劃而沒做具體工作時還不能填寫這些資訊，必須完成了工作並且通過驗證後才能填入這些資訊。

1.2.2 鏈表法

鏈表法主要是用於特定軟體上，比如需求管理工具Telelogic DOORS。 1.3 小結

每當談起需求跟蹤活動，總是有一句話作為核心：需求開發活動都是必須的，需求管理活動都是可選的。因為任何管理活動都是有成本的，因此我們必須做好成本效益分析，而不是將所有管理活動都做到位了就是最好的。

我們可以根據項目，人員，團隊的特點，選擇部分意義重大，價值較高的項目做需求跟蹤，甚至可以在一個項目內，選擇部分需求進行跟蹤；另外還應該選擇合適的需求管理工具，以降低需求跟蹤的工作量。