1.1 什麼是測試需求？
確切地講，所謂的測試需求就是在專案中要測試什麼。我們在測試活動中，首先需要明確測試需求（What），才能決定怎麼測（How），測試時間（When），需要多少人（Who），測試的環境是什麼（Where），測試中需要的技能、工具以及相應的背景知識，測試中可能遇到的風險等等，以上所有的內容結合起來就構成了測試計劃的基本要素。而測試需求是測試計劃的基礎與重點。
就像軟體的需求一樣，測試需求根據不同的公司環境，不同的專業水平，不同的要求，詳細程度也是不同的。但是，對於一個全新的專案或者產品，測試需求力求詳細明確，以避免測試遺漏與誤解。
1.2 為什麼要做測試需求？
如果要成功的做一個測試專案，首先必須瞭解測試規模、複雜程度與可能存在的風險，這些都需要通過詳細的測試需求來了解。所謂知己知彼，百戰不殆。測試需求不明確，只會造成獲取的資訊不正確，無法對所測軟體有一個清晰全面的認識，測試計劃就毫無根據可言。活在自己世界裡的人是可悲的，只憑感覺不做詳細瞭解就下定論的專案是失敗的。
測試需求越詳細精準，表明對所測軟體的瞭解越深，對所要進行的任務內容就越清晰，就更有把握保證測試的質量與進度。
如果把測試活動比作軟體生命週期，測試需求就相當於軟體的需求規格，測試策略相當於軟體的架構設計，測試用例相當於軟體的詳細設計，測試執行相當於軟體的編碼過程。只是在測試過程中，我們把“軟體”兩個字全部替換成了“測試”。這樣，我們就明白了整個測試活動的依據來源於測試需求。
2.測試需求分析方法
2.1 測試需求分析依據
通常是以被測產品的需求為原型進行分析轉變而來，測試需求主要通過以下途徑來進行收集：
與待測軟體相關的各種文件資料。如軟體需求規格、Use case、介面設計、專案會議或與客戶溝通時有關於需求資訊的會議記錄、其他技術文件等。
與客戶或系統分析員的溝通。
業務背景資料。如待測軟體業務領域的知識等。
正式與非正式的培訓。
其他。如果以舊系統為原型，以全新的架構方式來設計或完善軟體，那麼舊系統的原有功能跟特性就成為了最有效的測試需求收集途徑。
2.2 測試需求架構劃分
測試需求分析應首先進行測試需求架構劃分並先進行評審，通過後才進行後續的測試需求展開分析，從產品整體上考慮有哪些功能、測試型別需要進行分析，列出測試特性列表，也方便下一步展開具體分析。
首先，這裡需要對功能進行一下定義以達成共識，功能是指能獨立實現一個基本業務處理要求，為了降低測試需求設計的複雜性及依賴性，測試需求架構羅列的功能是指最小功能點，即不可再繼續分解。
(1)應用程式：
A.一般是最底層的選單項為最小功能點，若最底層的選單項不能體現一個獨立的業務流程時，可採用上一層的選單項為最小功能點。 B. 還有某些比較特殊沒有體現在選單項的功能也需要作為最小功能點考慮，如POS應用程式中交易的衝正功能等。
(2)驅動：一般是以一個API為最小功能點。 然後，再考慮產品實際使用者使用的場合及使用者特點考慮哪些測試型別，如故障及恢復、功能整合、效能要求、安裝測試、軟硬體相容性等，此處需要從產品層面考慮，而不是從功能點層面考慮。
2.3 測試需求分析過程
2.3.1 測試需求收集
測試需求的收集主要通過對測試依據進行分析整理，最後生成一個以測試的觀點出發的checklist（檢查表），用來作為測試該軟體的主要工作內容。檢查表的檢查要點包括需求的正確性、必要性、優先順序、明確性、可測性、完整性、一致性、可修改性：
在整個資訊收集過程中，務必確保軟體的功能與特性被正確理解。因此，測試需求分析人員必須具備優秀的溝通能力與表達能力。
2.3.1.1 測試型別劃分
根據測試需求收集獲得的checklist(檢查表)，對每一條測試需求，從GB/T16260.1定義的軟體質量子特性角度出發，確定所對應的質量子特性。即，從適用性、準確性、互操作性、保密安全性、成熟性、容錯性、易恢復性、易理解性、易學性、以操作性、吸引性、時間特性、資源利用性、易分析性、易改變性、穩定性、易測試性、適應性、易安裝性、共存性、易替換性和依從性方面的定義出發，確定每一條測試需求所對應的質量子特性。從而對這些質量子特性進行測試型別劃分，如：功能測試、易用性測試（安裝測試、功能易用性測試、使用者介面測試、輔助系統測試）、相容性測試、可靠性測試、文件測試、效能測試，強度測試等。
2.3.1.2 測試型別細化
對劃分的每個測試型別進行細化。軟體測試需求是開發測試用例的依據，測試需求分解得越詳細精準，表明對軟體的瞭解越深，對所有要進行的任務就越清晰，對測試用例的設計質量的幫助也越大，詳細的測試需求還是衡量測試覆蓋度的重要指標，測試需求是計算測試覆蓋的分母，沒有詳細的測試需求就無法有效的進行軟體測試覆蓋計算。最好達到細化的結果是分支的最末端（測試項）針對的測試目的是單一的最小的功能點的測試，即每個測試項為一個測試功能點。
2.3.1.3 生成測試需求樹
已細化的測試需求中，由於在提取時，可能存在著重複或冗餘，需要進行刪除和合並需求。刪除測試需求中存在的重複的、冗餘的含有關係的測試項。如果有類似的測試項，則需要對其進行合併。最終生成測試需求樹。
2.3.2 測試風險分析
由於軟體的輸入、輸出、處理存在一定的限制和約束，另一方面由於測試樹中進行了必要的刪除和合並，這導致測試需求不可能是全面的覆蓋，從而形成了一定的測試風險。測試需求中必須對不分析或不測試部分給出相應的風險分析說明。
3.總結
以上主要描述了測試需求相關理論和獲得測試需求樹的一般過程。為具體專案實施測試中提供了一套獲取測試需求樹的參考方案。實際的測試型別劃分和測試需求樹生成的形式或粒度，因專案而不同，需靈活應用。