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