由于軟件系統的復雜性，在需求分析階段可能存在著開發方對委托方業務需求理解不全面、不準確的情況。在這種情況下，如果不進行相關的質量控制，往往會造成開發結果與用戶需求不一致的后果。需求測試的目的就在于保證軟件設計最大可能地滿足有關用戶的所有需求，降低額外風險和未預料的成本。

通過開展需求測試，測試人員應能及時發現需求定義中存在的問題，使相關單位在認知上達成一致，采取有效的預防措施，降低變更的成本；更好地理解產品的功能性和非功能性需求，為制定測試計劃和用例打下基礎。

人工的靜態分析是需求測試中最常使用的手段，測試人員可以通過需求評審和設計測試用例的方式來測試需求。

一、需求評審

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

對需求的評審應從以下幾個方面進行：

完整性：每一項需求都必須將所要實現的功能描述清楚，以使開發人員獲得設計和實現這些功能所需的所有必要信息。
正確性：每一項需求都必須準確地陳述其要開發的功能。
一致性：一致性是指與其它軟件需求或相關標準規定不相矛盾。
可行性：每一項需求都必須是在已知系統和環境的限制范圍內可以實施的。
無二義性：對所有需求說明都只能有一個明確統一的解釋，由于自然語言極易導致二義性，所以盡量把每項需求用簡潔明了的語言表達出來。
健壯性：需求的說明中是否對可能出現的異常進行了分析，并且對這些異常進行了容錯處理。
必要性：每項需求的制定都是必要的且能夠追溯的。
可測試性：每項需求都能通過設計測試用例或其它的驗證方法來進行測試。
可修改性：每項需求只應在軟件需求說明書中出現一次，這樣更改時易于保持一致性。
可跟蹤性：應能在每項軟件需求與它的根源和設計元素、源代碼、測試用例之間建立起鏈接，這種可跟蹤性要求每項需求以一種結構化的方式編寫并單獨標明。

二、設計測試用例

設計概念性測試用例可以發現需求的錯誤、二義性、不可測性、缺失等方面問題，為了獲得最大的效果，要求測試人員能夠獨立的去對需求進行思維，從一個不同于開發的角度上進行分析，這可能會是一個逆向的思維過程，在這個過程中，測試人員可以采取需求建模的方式對需求進行分析。

需求的建模包括把需求轉換成圖形模型或形式化語言模型。需求的圖形化分析模型包括數據流圖、實體關系圖、狀態轉化圖、對話圖和類圖。這些圖形化模型可以借助于自動化分析工具本身提供的檢測手段來對需求進行測試，而這類檢測主要可以提供描述上的完整性檢查，需求項之間的不一致性檢查等方面的功能。同時，使用這類自動分析工具有助于獲得需求的質量特性，包括：有效性、一致性、可靠性、可用性、正確性、可維護性、可測試性、可擴展性、可交互性、可重用性等。

需求測試不等同于后面階段集成測試或者系統測試，后面的測試都是軟件已經編寫完成的條件下，判斷軟件是否會出錯。而需求測試，只是驗證需求是否真正是用戶所期望的。對于需求的功能測試，可以用快速開發工具建立界面原型，用戶通過原型的操作來確定是否需求跟他的期望相同。對于用戶不合理的需求，測試人員應能夠分辨，并跟用戶進行核對，確定用戶的真實需求。可以說需求測試是需求測試人員和用戶共同來執行的。

------

關于需求評審，首先我覺得應該解決的是可用的評審可用資源問題，只有把這個問題解決了，其評審結果才可以采信，否則不過形式爾耳。

關于需求評審的一些必備資源，我這里選列了相關角色，如下列：

* 業務專家或是熟悉該業務的人員（通常也叫業務方代表）

* 文檔審查人員

* 架構師

* 需求分析師

* 需求評審組織人員及記錄人員

當然，除了人員意外，必要的時間、場地和上層決策者的支持也是不可或缺的。

這些資源一旦準備停當，接下來就是如何安排評審事宜的問題了。我這里簡單列下以往曾做過的一輪需求評審的過程：

* 準備階段（P）

o 爭取上層決策者的支持與諒解

o 籌備相關的資源，包括人力、時間計劃，評審場地

o 在正式評審之前，將相關的需求記錄（文檔或其他形式）發布給每個參與評審的人員手中，并確保其有足夠的時間可以通閱需求并做好評審前的相關質疑與確認記錄

o 在正式評審之前，會議組織者應先收集相關評審人員的各項需求評審建議和意見，對存在爭議和疑惑的需求說明必須做好討論的安排

o 發布經確認后的評審計劃或時間表

* 實施階段（D）

o 由評審組織者召集各評審人員集中評議，可以以正式的會議等形式組織，此處以會議為形式做說明

o 與會人就某具體的問題進行討論，討論的優先級如下所列

* 最重要的業務內容，一般是按流程、功能、細節來排定

* 爭議或疑問較多的地方

* 部分有爭議的地方

* 對于沒有提出疑義的地方，可以快速流過

o 最后，要注意一定要回顧已提出問題和有結論的地方

o 由會議記錄人員整理會議的綱要，記錄各與會人員的相關意見，并在會后遞交紀要

* 檢查再實施階段（C）

o 對評審得出結論的問題進行再次確認和修正補充

o 確定下次評審的時間

o 按照第一階段的流程再次進行組織，并確認結果

o 對大多數組織，兩次評審可以解決大部分的問題，對于懸而未決的問題，如影響范圍有限，則可以延后討論解決

* 總結階段（A）

o 就以上內容做最后的確認，需求定稿，各方簽字確認。

o 今后的變更轉入需求變更流程，其后產生的評審為小范圍內評審。

給出了一項檢查清單，作為文檔審查人員審查需求的參考檢查表使用，大家可以在進行需求評審時參考使用。

建議一：分層次評審

我們知道用戶的需求是可以分層次的，一般而言可以分成如下的層次：

* 目標性需求：定義了整個系統需要達到的目標；

* 功能性需求：定義了整個系統必須完成的任務；

* 操作性需求：定義了完成每個任務的具體的人機交互；

目標性需求是企業的高層管理人員所關注的，功能性需求是企業的中層管理人員所關注的，

操作性需求是企業的具體操作人員所關注的。對不同層次的需求，其描述形式是有區別的，參與評審的人員也是不同的。如果讓具體的操作人員去評審目標性需求，可能會很容易地導致“撿了芝麻，丟了西瓜”的現象，如果讓高層的管理人員也去評審那些操作性需求，無疑是一種資源的浪費或者就會出現案例三的情形。

建議二：正式評審與非正式評審結合（郵件等得方式）

正式評審是指通過開評審會的形式，組織多個專家，將需求涉及到的人員集合在一起，并定義好參與評審人員的角色和職責，對需求進行正規的會議評審。而非正式的評審并沒有這種嚴格的組織形式，一般也不需要將人員集合在一起評審，而是通過電子郵件、文件匯簽甚至是網絡聊天等多種形式對需求進行評審。2種形式各有利弊，但往往非正式的評審比正式的評審效率更高，更容易發現問題。因此在評審時，應該更靈活地利用這2種方式。

建議三：分階段評審

應該在需求形成的過程中進行分階段的評審，而不是在需求最終形成后再進行評審。分階段評審可以將原本需要進行的大規模評審拆分成各個小規模的評審，降低了需求返工的風險，提高了評審的質量。比如可以在形成目標性需求后進行一次評審，在形成系統的初次概要需求后進行一次評審，當對概要需求細分成幾個部分，對每個部分進行各個評審，最終再對整體的需求進行評審。

建議四：精心挑選評審員

需求評審可能涉及的人員包括：需方的高層管理人員、中層管理人員、具體操作人員、IT主管、采購主管；供方的市場人員、需求分析人員、設計人員、測試人員、質量保證人員、實施人員、項目經理以及第三方的領域專家等等。在這些人員中由于大家所處的立場不同，對同一個問題的看法是不相同的，有些觀點是和系統的目標有關系的，有些是關系不大的，不同的觀點可能形成互補的關系。為了保證評審的質量和效率，需要精心挑選評審員。首先要保證使不同類型的人員的都要參與進來，否則很可能會漏掉了很重要的需求。其次在不同類型的人員中要選擇那些真正和系統相關的，對系統有足夠了解的人員參與進來，否則很可能使評審的效率降低或者最終不切實際的修改了系統的范圍。

建議五：對評審員進行培訓

在很多情況下，評審員是領域專家而不是進行評審活動的專家，他們沒有掌握進行評審的方法、技巧、過程等，因此需要對評審員進行，同樣對于主持評審的管理者也需要進行培訓，以便于參與評審的人員能夠緊緊圍繞評審的目標來進行，能夠控制評審活動的節奏，提高評審效率，避免發生案例一和案例二中出現的現象。對評審員的培訓也可以區分為簡單培訓與詳細培訓2種。簡單培訓可能需要十幾分鐘或者幾十分鐘，需要將在評審過程中的需要把握的基本原則，需要注意的常見問題說清楚。詳細培訓則可能要需要對評審的方法、技巧、過程進行正式的培訓，需要花費較長的時間，是一個獨立的活動。需要注意的是被評審人員也要被培訓。

建議六：充分利用需求評審檢查單

需求檢查單是很好的評審工具，需求檢查單可以分成2類：

需求形式的檢查單和需求內容的檢查單。需求形式的檢查可以由QA人員負責，主要是針對需求文擋的格式是否符合質量標準來提出的，需求內容的檢查是由評審員負責的，主要是檢查需求內容是否達到了系統目標、是否有遺漏、是否有錯誤等等，這是需求評審的重點。檢查單可以幫助評審員系統全面地發現需求中的問題，檢查單也是隨著工程財富的積累逐漸豐富和優化的。

建議七：建立標準的評審流程

對正規的需求評審會需要建立正規的需求評審流程，按照流程中定義的活動進行規范的評審過程。比如在評審流程定義中可能規定評審的進入條件，評審需要提交的資料，每次評審會議的人員職責分配，評審的具體步驟，評審通過的條件等等。通過評審流程執行可能會避免出現案例五之類的問題。

建議八：做好評審后的跟蹤工作

在需求評審后，需要根據評審人員提出的問題進行評價，以確定哪些問題是必須糾正的，哪些可以不糾正，并給出充分的客觀的理由與證據。當確定需要糾正的問題后，要形成書面的需求變更的申請，進入需求變更的管理流程，并確保變更的執行，在變更完成后，要進行復審。切忌評審完畢后，沒有對問題進行跟蹤，而無法保證評審結果的落實，使前期的評審努力付之東流。

建議九：充分準備評審

評審質量的好壞很大程度上取決于在評審會議前的準備活動。常出現的問題是，需求文檔在評審會議前并沒有提前下發給參與評審會議的人員，沒有留出更多更充分的時間讓參與評審的人員閱讀需求文檔。

更有甚者，沒有執行需求評審的進入條件，在評審文檔中存在大量的低級的錯誤或者沒有在評審前進行溝通，文檔中存在方向性的錯誤，從而導致評審的效率很低，質量很差。對評審的準備工作，也應當定義一個檢查單，在評審之前對照檢查單落實每項準備工作。

總結

以上是生活随笔為你收集整理的如何进行需求测试/需求评审的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。