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