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