需求評審與需求測試

　　需求評審與需求測試 軟件測試

　　在軟件開發過程中，需求分析是最開始的工作，需求分析如果做得不夠詳細或者是偏離用戶需求的話，往往會給項目帶來滅絕性的災難。因此如何保證需求分析的正確性，不偏離用戶的需求就成了決定軟件項目成敗的關鍵。

　　需求工程師取得用戶的顯性需求后，要仔細的分析用戶到底要求軟件實現什么功能，用戶的表達和需求工程師的理解有時間并不會一致，這樣會導致用戶所想的和需求說明書上所描述的有偏差。并且需求工程師取得用戶的需求后必須做仔細透徹的分析，有時候用戶的需求并不一定正確，可能是用戶忽然的想法，并不可行。如果需求工程師不能對用戶提出的需求進行判斷的話，可能辛辛苦苦的實現了用戶需求，結果被用戶自己否決掉。用戶絕對不會將責任攬到自己身上，他們只會說“你們是專家，怎么能怪我呢?”。

　　網上有一幅漫畫形象地描述了信息在傳遞過程中產生的誤差。

　　需求分析師是項目中直接與客戶接觸的人，需求做的好不好決定項目成敗，因此對于需求規格說明書的正確性必須進行徹底的驗證，將錯誤在開工前就消滅。

　　通常有兩種手段來檢查需求的正確性，分別是需求評審和需求測試。

　　1、 需求評審

　　需求評審可以分為正式評審與非正式評審，在需求規格說明書完成后，需求組必須自己對需求做評審。如果需求組遞交的需求規格說明書在指導后面的工作的時候出現很明顯的錯誤，我想拿高工資的需求分析人員是無法向老板交差的。為了需求分析人員的名譽，他們自己會對自己提交的內容進行審核，直到他們認為自己的工作成果足夠好，才會將需求規格說明書提交給正式評審組。

　　正式評審組的成員一般由公司內經驗最豐富，技術最牛的人(技術總監)來擔任，當然參加評審的人中間還應該有項目經理、QA人員、測試人員、架構師，他們仔細閱讀需求規格說明書，并針對自己將要開展的工作內容進行檢查，并提出問題。

　　正式評審是最后一關，如果正式評審通過了，將進入系統設計階段，如果在系統設計階段再跨里程碑來修改需求的話，所花費的代價將大大增加。因此正式評審將是一個“雞蛋里挑骨頭”的過程，只有所有的人都認為需求已經沒有什么可挑剔評審才能通過。

　　2、 需求測試

　　可以認為需求評審也屬于需求測試范圍，但是這里提的需求測試和評審不同，它是測部門來測試需求是否符合用戶的要求。顯然這是有難度的，傳統的測試工作都是從單元測試開始，編碼之前全部做得都是計劃性工作。測試人員對需求分析進行測試?那么前提條件是測試人員必須熟悉需求分析，這對測試人員的要求提高了。將需求測試人員作為測試人員中的特殊種類來培養，能夠對需求是否正確進行檢查，這樣就能夠在需求階段就引入測試。當然需求測試人員可以是經過培訓的需求分析人員，但是他必須脫離需求組，加入測試部門，這樣才能保證測試不是自己人測自己，以保證測試的效果。

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

　　之所以將需求測試和需求評審并行進行，是因為需求評審是項目的各方干系人共同進行的檢查工作，評審工作關注的焦點是分散的，很難將偏離用戶的需求檢查出來，并且涉及的人很多，因此不可能耗費太長時間。而需求測試執行的時間可以比評審時間長，有專門的關注方面，能夠檢查出不合理的需求分析，在項目前期進行錯誤糾正，往往比實現后糾正要節約幾百甚至幾千倍的成本。

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