測試需求?對，不知道您是否想到，這里的“測試需求”中的“測試”是一個動詞，指
的是對軟件需求本身的檢查。
啊?這不是已經超出了測試工作的范圍了嗎?測試人員不是應該只關心軟件的實現同需求是否相符嗎?這樣對測試人員要求未免太高了�！@是筆者過去同一些朋友談到測試人員必須對需求進行檢查時聽到的一些不同的聲音。
在這里，首先要明確一個問題，就是軟件測試的工作到底做什么?
在《軟件測試》( Ron Patton〔美〕，中文版由機械工業出版社出版，這本書是測試新手入門的經典教材)一書的第10頁，有一個明確而簡潔的定義：軟件測試員的目標是找到軟件缺陷，盡可能早一些，并確保其得以修復。
瞧!這里說要“盡可能早”的“找到軟件缺陷”。那這“盡可能早”要早到什么時候呢?
不知道大家對《軟件工程》這本書還有什么印象。至少在筆者看過的多個不同版本的軟件工程方面的書中，對于軟件缺陷都會有一段類似的描述：缺陷發現的越早，則修復這個缺陷的代價就越小，在需求、設計、編碼、測試、發布等不同的階段，發現缺陷后修復的代價都會比在前一個階段修復的代價提高10倍(參見下圖)。這樣看來，上面問題的答案自然就變成了“禿子頭上的虱子”：從需求階段開始!從“測試需求”開始!
注意，筆者這里的觀點并不是說可以取消團隊中的“需求評審會議”，這里并不存在沖突。筆者所希望講述的，是測試人員應該如何看待軟件需求，而并不是把“需求評審會議”所承擔的責任攬到自己身上。
在論壇上也偶爾看到有的朋友問：如何測試需求呢?每次看到這樣的提問，筆者內心就禁不住的一陣激動，因為一直以來，討論這方面問題的朋友的確少之又少。在筆者的實際工作中，對軟件需求的檢查包括兩個方面的內容。
一是對軟件需求正確性的檢查，也就是要保證需求文檔中所描述的內容是真實可靠的。在進行這部分工作時，不要迷信所謂的“都是用戶提出的真實的需求”，因為我們必須考慮，提出這些需求的涉眾，是否真的可以正確的描述自己的需求?我們的需求人員是否真的可以正確的理解用戶的需求?有沒有一些被用戶認為在業務處理上是理所當然、極其平常的事情，而沒有作為需求提出來?有沒有一些被用戶認為他們過去使用的軟件已經提供了相應的功能，所以認為我們也應當提供，而沒有提出來的?關于這個問題，也曾經有朋友提過不同的看法，認為這樣對測試人員的要求太高了——既要熟悉需求人員的工作，又要熟悉軟件所涉及的行業的業務。但筆者還是固執的認為，作為測試人員，還是需要對軟件產品所涉及的行業的業務有一個全面的、深入的了解——當然，這不是對一個剛剛入門的測試者的要求，但是如果想稱為一個優秀的測試者，是難免要付出這部分努力的。
二是要保證軟件需求的可測試性。對于“可測試性”，筆者的概念是：對于一條軟件需求或者一個需要實現的特性，必須存在一個可以明確預知的結果，并且可以通過設計一個可以重復的過程來對這個明確的結果進行驗證。說的具體一點，就是要保證所有的需要實現的需求都是可以用某種方法來明確的判斷是否符合需求文檔中的描述。如果對于某條需求或某個特性，無法通過一個明確的方法來進行驗證，或者無法預知它的結果，那么就意味著這條需求的描述存在缺陷，應該請需求人員對需求文檔進行修改或補充——我們有理由相信，如果作為測試人員對需求無法產生準確的理解，那么開發人員也同樣無法對同一條需求產生準確的理解。對于一條確定的軟件需求理解的二義性，是在不規范的開發過程中導致返工的一個主要原因。如果認為有必要，那應該在“需求評審會議”上確認所有涉眾對需求的理解是一致的。
當然，對于如何提高軟件需求的質量，在網絡上或者已經出版的書刊中都已經有了很多
更加具體、實用的方法，如果有興趣，大家也可以找來參考。不過，如果您是一位測試者，那么上面這部分內容對您仍然是非常有用的。相信您只要在工作中進行嘗試，慢慢的體會，一定會發現這種方法給您帶來的好處。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
