在軟件缺陷的8020原則中指出，軟件測試過程中，從需求分析開始到集成測試階段引入測試手段，能發現所有缺陷的80%;系統測試階段引入測試手段，能發現剩余缺陷中80%的缺陷;在運行維護階段經過長時間、大量運行軟件后，能夠發現最后剩余的20%缺陷。(來自于官方引用)也就是說明需求階段是軟件缺陷存在問題較多的地方。

　　在需求階段中，用戶一般是非計算機專業人員，軟件開發人員和用戶的溝通存在較大困難，對要開發的產品功能理解不一致。由于軟件產品還沒有設計、實現，完全靠想象去描述系統的實現結果，所以有些特性在當時不可能很清晰。需求變化的不一致性，用戶的需求總是在不斷地變化，這些變化應該在與需求相關的各類文檔中得到描述，但往往被忽略，并容易引起前后文、上下文的矛盾。沒有得到開發團隊或管理層的足夠重視，在需求分析和定義上投入的人力、時間不足。

　　在整個開發隊伍中沒有進行充分溝通，不同角色之間對需求的理解不一致。那么怎么能夠高效率獲取需求呢?咱們今天來分析一波。

　　測試需求分析過程包括需求采集、需求分析和需求評審三個環節。其中測試需求采集的輸入是需求規格說明書，測試需求分析的輸入是測試要點分析、功能交互分析、質量特性分析和測試類型分析，而需求評審的輸入是測試需求。測試需求分析的輸出包括：原始測試需求表、測試需求跟蹤矩陣和評審結論。

　　首先在收集測試需求階段，通過和軟件相關的文檔以及參考手冊，整理出原始的測試需求列表。

　　有了原始測試需求列表，接下來就可以進行測試需求分析，是測試人員將原始測試需求列表中的需求進行分析，分析軟件測試的測試類型、測試階段以及需求文檔本身未闡述清楚問題，形成測試需求跟蹤矩陣。

　　需求文檔不完善時，可通過上圖各方面去分析，并與用戶、業務人員、產品經理或產品設計人員、開發人員等溝通，逐步讓測試需求清晰起來。

　　經過可測性分析，整理出測試需求之后，進行需求評審，確認需求和軟件目標的一致性，識別出功能、非功能需求，為后續測試工作提供依據;確認需求規格說明書的正確性——經驗在豐富的需求人員也可能有需求遺漏或疏忽;使項目相關角色，對需求理解達成一致，降低修改和溝通成本;需求評審的主要對象是需求規格說明書。

　　需求評審會議結束后，如果沒有問題，那么測試人員在此階段結束后，明確了測試范圍。