一旦當前階段測試工作的范圍確定下來,，我們就可以開始考慮測試需求的整理——也就是明確的定義現(xiàn)階段要“測什么”。測試需求的確定將為我們制定進度時間表、分配資源以及如何確定某個階段測試工作是否完成提供一個可供衡量的標準,。當然,，還有更重要的一點，已被確定的測試需求是我們進行測試用例設計和考慮測試覆蓋的依據(jù),。整理測試需求的第一步,，就是要“測試需求”。測試需求,？對,，不知道您是否想到，這里的“測試需求”中的“測試”是一個動詞,，指的是對軟件需求本身的檢查,。

　　對于軟件缺陷都會有一段定義：缺陷發(fā)現(xiàn)的越早，則修復這個缺陷的代價就越小,，在需求,、設計、編碼,、測試,、發(fā)布等不同的階段，發(fā)現(xiàn)缺陷后修復的代價都會比在前一個階段修復的代價提高10倍,。

　　注意,，筆者這里的觀點并不是說可以取消團隊中的“需求評審會議”，這里并不存在沖突,。筆者所希望講述的,，是測試人員應該如何看待軟件需求，而并不是把“需求評審會議”所承擔的責任攬到自己身上,。?在論壇上也偶爾看到有的朋友問：如何測試需求呢,？每次看到這樣的提問，筆者內(nèi)心就禁不住的一陣激動,，因為一直以來,，討論這方面問題的朋友的確少之又少。在筆者的實際工作中,，對軟件需求的檢查包括兩個方面的內(nèi)容,。一是對軟件需求正確性的檢查，也就是要保證需求文檔中所描述的內(nèi)容是真實可靠的,。在進行這部分工作時,，不要迷信所謂的“都是用戶提出的真實的需求”，因為我們必須考慮,，提出這些需求的涉眾,，是否真的可以正確的描述自己的需求,？我們的需求人員是否真的可以正確的理解用戶的需求？有沒有一些被用戶認為在業(yè)務處理上是理所當然,、極其平常的事情,，而沒有作為需求提出來？有沒有一些被用戶認為他們過去使用的軟件已經(jīng)提供了相應的功能,，所以認為我們也應當提供,，而沒有提出來的？關于這個問題,，也曾經(jīng)有朋友提過不同的看法,，認為這樣對測試人員的要求太高了——既要熟悉需求人員的工作，又要熟悉軟件所涉及的行業(yè)的業(yè)務,。但筆者還是固執(zhí)的認為,，作為測試人員，還是需要對軟件產(chǎn)品所涉及的行業(yè)的業(yè)務有一個全面的,、深入的了解——當然,，這不是對一個剛剛?cè)腴T的測試者的要求，但是如果想稱為一個優(yōu)秀的測試者,，是難免要付出這部分努力的,。

　　要保證軟件需求的可測試性。對于“可測試性”,，筆者的概念是：對于一條軟件需求或者一個需要實現(xiàn)的特性,，必須存在一個可以明確預知的結(jié)果，并且可以通過設計一個可以重復的過程來對這個明確的結(jié)果進行驗證,。說的具體一點，就是要保證所有的需要實現(xiàn)的需求都是可以用某種方法來明確的判斷是否符合需求文檔中的描述,。如果對于某條需求或某個特性,，無法通過一個明確的方法來進行驗證，或者無法預知它的結(jié)果,，那么就意味著這條需求的描述存在缺陷,，應該請需求人員對需求文檔進行修改或補充——我們有理由相信，如果作為測試人員對需求無法產(chǎn)生準確的理解,，那么開發(fā)人員也同樣無法對同一條需求產(chǎn)生準確的理解,。對于一條確定的軟件需求理解的二義性，是在不規(guī)范的開發(fā)過程中導致返工的一個主要原因,。如果認為有必要,，那應該在“需求評審會議”上確認所有涉眾對需求的理解是一致的。當然,，對于如何提高軟件需求的質(zhì)量,，在網(wǎng)絡上或者已經(jīng)出版的書刊中都已經(jīng)有了很多更加具體,、實用的方法，如果有興趣,，大家也可以找來參考,。不過，如果您是一位測試者,，那么上面這部分內(nèi)容對您仍然是非常有用的,。相信您只要在工作中進行嘗試，慢慢的體會,，一定會發(fā)現(xiàn)這種方法給您帶來的好處,。?現(xiàn)在當前的測試工作范圍已經(jīng)確定，相應版本的軟件需求也通過了評審,，我們就可以在這個已經(jīng)確定的范圍內(nèi)進行測試需求的整理,。我們手頭上可以參考的東西，通常會有軟件需求規(guī)約（以下簡稱SRS）和用例（以下簡稱UC）——當然,，也可能是一份包含UC的SRS,。通過對SRS和UC的閱讀，我們可以從文檔對特性和業(yè)務流程的描述中獲得對軟件所涉及的業(yè)務的一個基本的認識,。比如用戶在處理實際業(yè)務時都要作些什么,，多個業(yè)務之間的先后順序是怎樣的，用戶在處理業(yè)務是對于哪些地方有特別的要求,，等等,。這部分規(guī)則，將成為我們的測試需求中最基本的一部分,。

　　至于測試需求的表現(xiàn)形式,，筆者認為大家都可以根據(jù)自己的需要進行設計，而沒有必要把思路限制在到底使用表格方式還是使用文本方式,，只要把握一個原則就行了：在一條測試需求中,，用容易理解的自然語言，明確的描述一項需要測試的內(nèi)容,。對于多項測試內(nèi)容,，應盡可能的剝離開來，保證一條測試需求只包含一項測試內(nèi)容,。

　　另外,，大家也可能注意到了，在軟件開發(fā)過程的這個階段,，通常是沒有用戶界面（以下簡稱UI）可供參考的——雖然RUP中對于需求階段的工作描述包括了UI設計的部分,，但很多時候在這個階段還是無法提供一個確定的UI的——也就是說我們這時獲得的測試需求，將是完全基于業(yè)務的,，而并不包括基于UI的那部分規(guī)則,，是同軟件的最終具體實現(xiàn)相獨立的,。

　　隨著開發(fā)工作的繼續(xù)，開發(fā)部門的架構設計文檔和詳細設計文檔也將陸續(xù)提交,，這時候,，我們可以根據(jù)設計文檔來對已有的測試需求進行增補。注意,，這里我們對于設計文檔中提到的內(nèi)容要有選擇的采用,，只有同SRS或UC中已經(jīng)定義的部分相符的內(nèi)容，才可以用來調(diào)整我們的測試需求,。而同軟件需求不相符的部分,，則需要同設計人員和需求人員一起討論，確定下以哪一方作為基準,，決定是否需要調(diào)整軟件需求,，然后對測試需求進行相應的增補或者調(diào)整。比如對于一些算法,，需要考慮設計文檔中定義的,，同系統(tǒng)實現(xiàn)相關的那些計算公式，是否同軟件需求中描述的算法表達的是否是同一個意思,？而對于一些約束或者業(yè)務規(guī)則,，設計文檔中描述的是否同需求中的相應部分一致？呵呵,，看完上面這部分內(nèi)容,，恐怕又有一部分朋友暈倒在地了，而沒有暈倒的那部分朋友也要提出異議：??？！你這不是又包含了對開發(fā)人員所作的設計工作的檢查嗎,？,！剛剛讓我們檢查需求，現(xiàn)在又讓我們檢查設計,，真的把我們當成全才了！沒辦法,，為了讓軟件交到我們手上的時候只包含盡量少的缺陷,，大家只能再辛苦一下了。我們的工作不應當僅僅限制在軟件交付后盡力找到存在的缺陷,，而更應該努力及早發(fā)現(xiàn)軟件缺陷出現(xiàn)的苗頭,，盡量預防缺陷的出現(xiàn)。雖然并不是說在所有的團隊中都應該由測試人員承擔“測試需求”和“測試設計”的工作,，但是測試人員對這些工作起到的作用,，是其他團隊中的其他角色所無法替代的,。開發(fā)部門完成編碼實現(xiàn)工作，提交供內(nèi)部測試的應用程序時,，測試人員手頭上應該已經(jīng)準備好了絕大部分測試用例和測試數(shù)據(jù),，測試部門將開始執(zhí)行測試。通常在我們執(zhí)行測試的過程中,，即使我們已經(jīng)從“通過測試”和“失敗測試”兩個不同的角度準備了非常充分的測試用例和測試數(shù)據(jù),，但總是有些缺陷的出現(xiàn)是出乎我們意料的，或者說是已有的測試需求和測試用例未能覆蓋的,。那么,，對于這部分缺陷，也應當添加到測試需求中,，并設計相應的測試用例,，以便于下次版本迭代時進行參考。OK,，相信說到這里,，各位看客也應該可以理解我的觀點了：對于一個長期發(fā)展的團隊或者持續(xù)開發(fā)的產(chǎn)品，它的所有東西都是要不斷積累的,、不斷迭代的,。無論對于軟件需求還是測試需求，不僅僅是在一個版本的開發(fā)過程中,，在不同的階段進行迭代,，在產(chǎn)品的整個生命周期中的不同版本間，也是不斷迭代和積累的,。