測試需求的意義 無論對于開發還是測試，一個全面精準有預見性的設計是保證項目順利進行的前提。實際項目操作中，常常感受到測試過程有著各種問題：
1、產品質量維度關注的不全面，測試類型不完整；
2、測試規格設計較為隨意，測試分解分配比較隨意；
導致測試過程中，經常會出現需求遺漏、測試設計遺漏的問題；
因此一份詳細精準的測試需求分析有利于這些問題的解決。
測試需求的定義
軟件需求定義的是要產品要實現的功能是什么，而測試需求這個名詞業界并沒有權威的定義，多數的意見認為測試需求定義測試的范圍（即主要解決測什么、及測 到什么程度的問題），這樣說還是太過泛泛，換個說法，測試人員依據初期功能需求，評估需要測試的功能點都有什么，每個功能點需要什么類型的測試，每個功能 點測試到什么程度算是通過，這樣初步評估出了測試的規模、復雜程度和風險，同時可以初步預估出哪個環節需要研發同事提供測試接口。
測試需求設計的愈加詳細精準，代表對待測試的軟件了解的愈深，對各種測試手段了解的愈深，但是這往往要求測試需求的設計者擁有一定的測試經驗。
測試需求的流程
測試需求的采集
測試需求最直接的來源是：
1、軟件需求規格；
2、業界協議規范；
3、測試經驗庫；
4、對于已有舊版本的軟件測試，還需要考慮繼承性的測試需求。
對以上內容進行梳理，形成原始測試需求表，列表的內容包括需求標識、原始測試需求描述、信息來源，如下：
來源編號 | 測試原始需求編號 | 測試原始需求描述 | 開發特性 | 需求標識 | 需求描述 | 需求優先級 | 測試規格分析的工程方法 |
DR001 | EMAIL-001 | 能夠支持電子郵件的收發 | Email | OR_MKT.00010 | 能夠支持電子郵件的收發 | | |
測試人員需要對開發需求進行整理，首先需要確認軟件需求的正確性、其次保證軟件需求的可測試性。所謂的可測試指的是“存在一個可明確預知的結果，可用某 種方法對這個明確的結果進行判斷、驗證。”原則上，所有的軟件需求都應該是可測試的，因為如果作為測試人員對需求無法產生準確的理解（即無法得出明確的結 果），那么開發人員也同樣無法對同一條需求產生準確的理解。每一個測試需求需要保證一條需求只包含一項測試內容，因此一條軟件需求通常可能對應多條測試需 求。
這個階段的測試需求整理，最重要的一點就是要注意廣泛性和全面性，要盡可能的收集更多的原始需求，不存在遺漏，并且可以對需求進行適當的擴充，這些需求應該不僅僅局限于上述的五種來源類型，也不僅僅局限于各種文檔、資料。
測試需求的分析 測試需求采集之后得到的是一張沒有優化的需求表，需要對這份原始需求表進行初步的規劃：
1、刪除冗余重復的需求，各個需求間沒有過多的交集；
2、需求需覆蓋業務流程、功能、非功能方面的需求；
業務流程：任何一套軟件都會有一定的業務流，也就是用戶用該軟件來實現自己實際業務的一個流程。簡單的來說，在做測試需求分析時需要列出以下類別：
1）常用的或規定的業務流程
2）各業務流程分支的遍歷
3）明確規定不可使用的業務流程
4）沒有明確規定但是應該不可以執行的業務流程
5）其他異常或不符合規定的操作
1、需求需考慮了各功能模塊之間交互關系分析；
2、確定測試特性（即測試功能點）；
3、確定需求的測試類型；
1、確定需求的質量屬性；
2、確定本版本測試所屬的階段；
測試階段：產品的不同階段，對于測試階段的要求也不一樣。對于初期版本的產品，更側重于關注：功能是否實現（這個功 能正常場景下是否順利）、較為成熟階段之后，會關注：功能是否實現的夠完善（異常場景下，是否正常處理），更加成熟之后會關注，是否通得過各種壓力測試場 景。
測試需求跟蹤矩陣
建立測試需求跟蹤矩陣，對測試需求進行管理。將上述步驟分析、確定的開發需求、測試需求、測試類型填入測試跟蹤需求矩陣。
建立測試需求跟蹤矩陣，對測試需求進行管理。將上述步驟分析、確定的開發需求、測試需求、測試類型填入測試跟蹤需求矩陣。
通過測試需求跟蹤矩陣的方式對需求變更實施管理。軟件需求一旦發生變化，就要對需求跟蹤表進行維護，啟動配置管理過程，將與軟件需求變更相關的內容進行同步變更。
測試需求評審
評審的內容：
完整性審查：應保證測試需求能充分覆蓋軟件需求的各種特征，重點關注功能要求、數據定義、接口定義、性能要求、安全性要求、可靠性要求、系統約束等方面，同時還應關注是否覆蓋開發人員遺漏的、系統隱含的需求；
準確性審查：應保證所描述的內容能夠得到相關各方的一致理解，各項測試需求之間沒有矛盾和沖突，各項測試需求在詳盡程度上保持一致，每一項測試需求都可以作為測試用例設計的依據。