需求測試怎么做？

需求測試怎么做？　

　需求測試  軟件測試

　　軟件測試V模型要求我們在需求階段就開始制定系統測試的計劃，開始考慮系統測試的方法。但這還不是足夠的。全面的質量管理要求我們在每個階段都要進行驗證和確認的過程。因此在需求階段我們還需要對需求本身進行測試。這個測試是必要的，因為在許多失敗的項目中，7 0 %～8 5 %的返工是由于需求方面的錯誤所導致的。并且因為需求的緣故而導致大量的返工，造成進度延遲、缺陷的發散，這是一件及其痛苦的事情。因此我們要求在項目的源頭(需求)就開始測試。這類測試更多的還只是靜態手工方面的測試，當然也有一些自動化的工具，但這些工具會要求我們按照某個固定的格式進行需求的表述(例如形式化的方法)，因此在適用性上會受到限制。通過靜態手工方法進行需求測試中最常使用的手段是同行評審。

　　通過評審來測試需求

　　同行評審是業界公認的最有效的排錯手段之一。我們在需求測試過程當中，使用最多的也是同行評審(Peer Review)，尤其是正規檢視(Inspection)。正規檢視是由Michael Fagan 在I B M 制定出來的一種非常嚴格的評審過程。

　　需求評審的參與者當中，必須要有用戶或用戶代表參與，同時還需要包括項目的管理者，系統工程師和相關開發人員、測試人員、市場人員、維護人員等。在項目開始之初就應當確定不同級別、不同類型的評審必須要有哪些人員的參與，否則，評審可能會遺漏掉某些人員的意見，導致今后不同程度的返工。

　　好的需求應當具有的特點

　　一個良好的需求應當具有一下特點：

　　完整性：每一項需求都必須將所要實現的功能描述清楚，以使開發人員獲得設計和實現這些功能所需的所有必要信息。

　　正確性：每一項需求都必須準確地陳述其要開發的功能。

　　一致性：一致性是指與其它軟件需求或高層(系統，業務)需求不相矛盾。

　　可行性：每一項需求都必須是在已知系統和環境的權能和限制范圍內可以實施的。

　　無二義性：對所有需求說明的讀者都只能有一個明確統一的解釋，由于自然語言極易導致二義性，所以盡量把每項需求用簡潔明了的用戶性的語言表達出來。

　　健壯性：需求的說明中是否對可能出現的異常進行了分析，并且對這些異常進行了容錯處理。

　　必要性：“必要性”可以理解為每項需求都是用來授權你編寫文檔的“根源”。要使每項需求都能回溯至某項客戶的輸入，如Use Case或別的來源。

　　可測試性：每項需求都能通過設計測試用例或其它的驗證方法來進行測試。

　　可修改性：每項需求只應在S R S 中出現一次。這樣更改時易于保持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規格說明書更容易修改。

　　可跟蹤性：應能在每項軟件需求與它的根源和設計元素、源代碼、測試用例之間建立起鏈接鏈，這種可跟蹤性要求每項需求以一種結構化的，粒度好(f i n e - g r a i n e d )的方式編寫并單獨標明，而不是大段大段的敘述。

　　另外應當對所有的需求分配優先級。如果把所有的需求都看作同樣的重要，那么項目管理者在開發或節省預算或調度中就喪失控制自由度

原文轉自：http://www.anti-gravitydesign.com