軟件測試需求分析與定義方法

如何確定測試工作的范圍？
　　對于一個存在生命周期的軟件產品來說，它的開發和測試往往都不是一次性的，因為隨著新的需求的出現，以及對原有版本的改進，新的版本會不斷的發布（即使對于一些以客戶定制方式運作的項目，在開發過程中以及發布后的維護期內，也會產生眾多的內部版本）。隨著版本的迭代，我們的測試工作也會一直繼續下去。而在每一次迭代時，可能在整個工作階段的開始就受到一些因素的影響，比如市場需求、既定的發布時間、并發的工作導致的資源緊張等等，使我們不得不考慮對軟件質量要求的適度，最終使得我們在每個階段的測試工作的要求或者說所涉及到的內容有可能是不同的。這種變化，最終將會影響到測試需求的確定。
　　那么到底該如何確定每次迭代是測試工作的范圍呢？在筆者的實踐中，通常把測試工作范圍的確定，等價的認為是軟件需求的確定。
　　不過現在有一個很實際的問題是這樣：軟件需求在開發過程中不斷發生變化，有時候到了后期還會有新的需求添加進來，還有些需求在交付內部測試版本之后又發現原來的需求本身就存在缺陷，之后再次返工，在軟件最終發布之前，怎么可能確定的下來呢。啊，這些都是讓我們的開發人員和測試人員極其頭痛的事情。到底應該怎樣在頻繁變更的需求中確定哪些部分是我們在某個階段要測試的內容呢？或者說通過什么樣的方法可以改善我們上面提到的那些問題呢？一個實際的做法就是實現軟件需求的版本化控制。既然說到了這里，就不免要說些題外話。筆者一直都認為軟件需求是開發工作和測試工作在制定計劃、開展工作時所共同參照的源頭和依據，而我們只有在源頭上控制好，才能保證下面工作的平穩開展。如果希望某個階段工作的進度和內容可以明確的定義下來，就必須要考慮軟件需求的版本化控制。這里所提到的“軟件需求的版本化控制”，是指在一個軟件產品的生命周期中，當要進行一個新版本的迭代時，要盡早的確定這個版本中將要實現的需求，并同上個版本做出比較，哪些內容是新增的，哪些內容是被調整過的。在該階段工作開始之初的工作會議上，明確的向所有需要了解軟件需求的涉眾傳達這部分信息。而如果在該版本的開發過程中不斷的出現需求變更的情況，則應該根據市場策略、已公布的發布時間、客戶需求、實現的代價、難易程度以及對現有工作的影響等方面，對需求進行適度劃分，嚴格定義當前版本中需要實現的需求，而其他部分，則作為未來版本的軟件需求進行考慮。如果有的朋友認為上面的內容還是太理論化，需要一個更實際的、可操作的方法。那么只能說，對于需求的變更，以及因為需求變更而引起的設計的變更，必須要早發現，早討論，早決定，早調整。這可能更多的要依靠一個團隊中相關負責人員的主動工作來保證，而不是依靠一個明確的方法。注意，這里的一個關鍵是，對于軟件需求，同樣需要嚴格按照版本進行管理，或者說使用“基線”進行管理。如何整理測試需求？
　　一旦當前階段測試工作的范圍確定下來，我們就可以開始考慮測試需求的整理——也就是明確的定義現階段要“測什么”。測試需求的確定將為我們制定進度時間表、分配資源以及如何確定某個階段測試工作是否完成提供一個可供衡量的標準。當然，還有更重要的一點，已被確定的測試需求是我們進行測試用例設計和考慮測試覆蓋的依據。整理測試需求的第一步，就是要“測試需求”。測試需求？對，不知道您是否想到，這里的“測試需求”中的“測試”是一個動詞，指的是對軟件需求本身的檢查。
　　??？這不是已經超出了測試工作的范圍了嗎？測試人員不是應該只關心軟件的實現同需求是否相符嗎？這樣對測試人員要求未免太高了?！@是筆者過去同一些朋友談到測試人員必須對需求進行檢查時聽到的一些不同的聲音?！　≡谶@里，首先要明確一個問題，就是軟件測試的工作到底做什么？
　　在《軟件測試》（ Ron Patton〔美〕，中文版由機械工業出版社出版，這本書是測試新手入門的經典教材）一書的第10頁，有一個明確而簡潔的定義：軟件測試員的目標是找到軟件缺陷，盡可能早一些，并確保其得以修復。
　　瞧！這里說要“盡可能早”的“找到軟件缺陷”。那這“盡可能早”要早到什么時候呢？
　　不知道大家對《軟件工程》這本書還有什么印象。至少在筆者看過的多個不同版本的軟件工程方面的書中，對于軟件缺陷都會有一段類似的描述：缺陷發現的越早，則修復這個缺陷的代價就越小，在需求、設計、編碼、測試、發布等不同的階段，發現缺陷后修復的代價都會比在前一個階段修復的代價提高10倍（參見下圖）。這樣看來，上面問題的答案自然就變成了“禿子頭上的虱子”：從需求階段開始！從“測試需求”開始！
　　注意，筆者這里的觀點并不是說可以取消團隊中的“需求評審會議”，這里并不存在沖突。筆者所希望講述的，是測試人員應該如何看待軟件需求，而并不是把“需求評審會議”所承擔的責任攬到自己身上。?在論壇上也偶爾看到有的朋友問：如何測試需求呢？每次看到這樣的提問，筆者內心就禁不住的一陣激動，因為一直以來，討論這方面問題的朋友的確少之又少。

在筆者的實際工作中，對軟件需求的檢查包括兩個方面的內容。

一是對軟件需求正確性的檢查，也就是要保證需求文檔中所描述的內容是真實可靠的。在進行這部分工作時，不要迷信所謂的“都是用戶提出的真實的需求”，因為我們必須考慮，提出這些需求的涉眾，是否真的可以正確的描述自己的需求？我們的需求人員是否真的可以正確的理解用戶的需求？有沒有一些被用戶認為在業務處理上是理所當然、極其平常的事情，而沒有作為需求提出來？有沒有一些被用戶認為他們過去使用的軟件已經提供了相應的功能，所以認為我們也應當提供，而沒有提出來的？關于這個問題，也曾經有朋友提過不同的看法，認為這樣對測試人員的要求太高了——既要熟悉需求人員的工作，又要熟悉軟件所涉及的行業的業務。但筆者還是固執的認為，作為測試人員，還是需要對軟件產品所涉及的行業的業務有一個全面的、深入的了解——當然，這不是對一個剛剛入門的測試者的要求，但是如果想稱為一個優秀的測試者，是難免要付出這部分努力的。
　　二是要保證軟件需求的可測試性。對于“可測試性”，筆者的概念是：對于一條軟件需求或者一個需要實現的特性，必須存在一個可以明確預知的結果，并且可以通過設計一個可以重復的過程來對這個明確的結果進行驗證。說的具體一點，就是要保證所有的需要實現的需求都是可以用某種方法來明確的判斷是否符合需求文檔中的描述。如果對于某條需求或某個特性，無法通過一個明確的方法來進行驗證，或者無法預知它的結果，那么就意味著這條需求的描述存在缺陷，應該請需求人員對需求文檔進行修改或補充——我們有理由相信，如果作為測試人員對需求無法產生準確的理解，那么開發人員也同樣無法對同一條需求產生準確的理解。對于一條確定的軟件需求理解的二義性，是在不規范的開發過程中導致返工的一個主要原因。如果認為有必要，那應該在“需求評審會議”上確認所有涉眾對需求的理解是一致的。當然，對于如何提高軟件需求的質量，在網絡上或者已經出版的書刊中都已經有了很多更加具體、實用的方法，如果有興趣，大家也可以找來參考。不過，如果您是一位測試者，那么上面這部分內容對您仍然是非常有用的。相信您只要在工作中進行嘗試，慢慢的體會，一定會發現這種方法給您帶來的好處。?現在當前的測試工作范圍已經確定，相應版本的軟件需求也通過了評審，我們就可以在這個已經確定的范圍內進行測試需求的整理。我們手頭上可以參考的東西，通常會有軟件需求規約（以下簡稱SRS）和用例（以下簡稱UC）——當然，也可能是一份包含UC的SRS。通過對SRS和UC的閱讀，我們可以從文檔對特性和業務流程的描述中獲得對軟件所涉及的業務的一個基本的認識。比如用戶在處理實際業務時都要作些什么，多個業務之間的先后順序是怎樣的，用戶在處理業務是對于哪些地方有特別的要求，等等。這部分規則，將成為我們的測試需求中最基本的一部分。
　　至于測試需求的表現形式，筆者認為大家都可以根據自己的需要進行設計，而沒有必要把思路限制在到底使用表格方式還是使用文本方式，只要把握一個原則就行了：在一條測試需求中，用容易理解的自然語言，明確的描述一項需要測試的內容。對于多項測試內容，應盡可能的剝離開來，保證一條測試需求只包含一項測試內容。
　　另外，大家也可能注意到了，在軟件開發過程的這個階段，通常是沒有用戶界面（以下簡稱UI）可供參考的——雖然RUP中對于需求階段的工作描述包括了UI設計的部分，但很多時候在這個階段還是無法提供一個確定的UI的——也就是說我們這時獲得的測試需求，將是完全基于業務的，而并不包括基于UI的那部分規則，是同軟件的最終具體實現相獨立的。
　　隨著開發工作的繼續，開發部門的架構設計文檔和詳細設計文檔也將陸續提交，這時候，我們可以根據設計文檔來對已有的測試需求進行增補。注意，這里我們對于設計文檔中提到的內容要有選擇的采用，只有同SRS或UC中已經定義的部分相符的內容，才可以用來調整我們的測試需求。而同軟件需求不相符的部分，則需要同設計人員和需求人員一起討論，確定下以哪一方作為基準，決定是否需要調整軟件需求，然后對測試需求進行相應的增補或者調整。比如對于一些算法，需要考慮設計文檔中定義的，同系統實現相關的那些計算公式，是否同軟件需求中描述的算法表達的是否是同一個意思？而對于一些約束或者業務規則，設計文檔中描述的是否同需求中的相應部分一致？呵呵，看完上面這部分內容，恐怕又有一部分朋友暈倒在地了，而沒有暈倒的那部分朋友也要提出異議：??？！你這不是又包含了對開發人員所作的設計工作的檢查嗎？！剛剛讓我們檢查需求，現在又讓我們檢查設計，真的把我們當成全才了！沒辦法，為了讓軟件交到我們手上的時候只包含盡量少的缺陷，大家只能再辛苦一下了。我們的工作不應當僅僅限制在軟件交付后盡力找到存在的缺陷，而更應該努力及早發現軟件缺陷出現的苗頭，盡量預防缺陷的出現。雖然并不是說在所有的團隊中都應該由測試人員承擔“測試需求”和“測試設計”的工作，但是測試人員對這些工作起到的作用，是其他團隊中的其他角色所無法替代的。開發部門完成編碼實現工作，提交供內部測試的應用程序時，測試人員手頭上應該已經準備好了絕大部分測試用例和測試數據，測試部門將開始執行測試。通常在我們執行測試的過程中，即使我們已經從“通過測試”和“失敗測試”兩個不同的角度準備了非常充分的測試用例和測試數據，但總是有些缺陷的出現是出乎我們意料的，或者說是已有的測試需求和測試用例未能覆蓋的。那么，對于這部分缺陷，也應當添加到測試需求中，并設計相應的測試用例，以便于下次版本迭代時進行參考。OK，相信說到這里，各位看客也應該可以理解我的觀點了：對于一個長期發展的團隊或者持續開發的產品，它的所有東西都是要不斷積累的、不斷迭代的。無論對于軟件需求還是測試需求，不僅僅是在一個版本的開發過程中，在不同的階段進行迭代，在產品的整個生命周期中的不同版本間，也是不斷迭代和積累的。

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