如何對軟體需求進行測試

需求品質的把握首先可以從需求評審維度全面性來支撐評審活動的品質，參考國際通用方法有：
1：需求描述是否具備完整性；（沒有遺漏內容；或描述片面）
2：需求描述是否有二義性；（沒有讓不同的人有不同的理解結論）
3：需求描述是否是正確的；（需求之間沒有衝突等）
4：是否包含有非功能屬性的需求；（效能，安全性，可靠性，易用性等）
5：是否需求是可以驗證的；（需求描述具備可測試性）
6：需求是否可實現；   

更多細節，請見這個連結中的內容：
http://www.csis.pace.edu/~scharff/cs3892005/reqreview.doc
還有Delta公司的測試地圖，google搜尋吧。

其次，關於需求評審的效率。可以採用2個人單獨一個房間抽取專門的時間段100％投入進行結對評審的方式。事實證明，一大群能力高低不平的人集中在一個地方開評審會的方式，不但評審不會系統，而且溝通交流效率很低（太多意見不一致，人越多越難達成一致）。採用敏捷2個人結對程式設計的思想，結對評審能很好的在第一時間發現需求存在的二義性，而且2人還可以馬上進行討論，很快達成一致意見，能大大提高單位時間內需求評審的效率和需求評審品質。

最後，需求文字描述品質的把關。如果我們測試人員無法在需求的有無上進行判斷或需求的價值上進行建議，那麼測試人員至少可以在需求描述的品質上進行一定的把關。有一個很簡單的道理：如果開發人員在需求描述上都存在含混不清，或是描述不準確，不完整，那麼後續的程式員在閱讀需求時肯定會很吃力，一定會對需求理解產生偏差，在開發實現時與最初需求編寫者的要求產生偏差。測試人員在依據需求進行測試案例編寫時，也會出現需求理解困難，導致測試案例編寫的困難，最終測試未能覆蓋到需求編寫者的最初想法。

所以，當需求瞭解和分析被開發人員一家獨佔，測試人員只能進行輔助工作時，那就在開發人員提供已有的需求描述的材料上，儘可能的進行需求描述品質的測試。只要測試人員堅持做，敢做，儘力去做，需求品質的測試工作一定能開展下去。投入多少，就能得到產出多少，而測試人員的需求評審能力也能持續提升。

在需求階段，發現一個需求缺陷的價值是多大呢？業內有個缺陷修複成本比例，
需求階段：設計階段：測試階段：上市階段＝N:10N:100N:1000N；也就是說，如果需求的缺陷在測試階段才被發現，那麼用於修複需求缺陷的成本將是需求階段修複該缺陷成本的100倍，如果在上市後才發現，那麼成本將是1000倍。

事實上我一直認為：時間越短的項目，人員越少的項目，越要加強需求品質的測試，絕對投入產出是最大，也是解決時間不足，人員不足的好方法。根據經驗，需求中隱含的缺陷如果是在系統測試階段發現，大部分需求隱含的缺陷都是功能級缺陷，缺陷影響力是比較大的。

任何好的工程方法，好的思想，只是武器。有好的武器能提高好獵手的效率，但是如果獵手能力經驗不夠，好武器的效果會大打折扣。方法不用貪多，在用好用精手上的方法之前，用好自己的武器勝過再尋找更多的武器。需求評審的方法是“術”，而足夠的測試經驗、項目經驗和責任心則是“道”。同樣的需求測試方法，選取不同的人來實施，得到的效果和結果都是不一樣的。我的建議是：需求評審最好選取項目測試經驗最豐富的同事來實施。