如何確定測試工作的范圍？
對于一個存在生命周期的軟件產(chǎn)品來說，它的開發(fā)和測試往往都不是一次性的，因為隨著新的需求的出現(xiàn)，以及對原有版本的改進，新的版本會不斷的發(fā)布（即使對于一些以客戶定制方式運作的項目，在開發(fā)過程中以及發(fā)布后的維護期內(nèi)，也會產(chǎn)生眾多的內(nèi)部版本）。隨著版本的迭代，我們的測試工作也會一直繼續(xù)下去。而在每一次迭代時，可能在整個工作階段的開始就受到一些因素的影響，比如市場需求、既定的發(fā)布時間、并發(fā)的工作導(dǎo)致的資源緊張等等，使我們不得不考慮對軟件質(zhì)量要求的適度，最終使得我們在每個階段的測試工作的要求或者說所涉及到的內(nèi)容有可能是不同的。這種變化，最終將會影響到測試需求的確定。
那么到底該如何確定每次迭代是測試工作的范圍呢？在筆者的實踐中，通常把測試工作范圍的確定，等價的認為是軟件需求的確定。
不過現(xiàn)在有一個很實際的問題是這樣：軟件需求在開發(fā)過程中不斷發(fā)生變化，有時候到了后期還會有新的需求添加進來，還有些需求在交付內(nèi)部測試版本之后又發(fā)現(xiàn)原來的需求本身就存在缺陷，之后再次返工，在軟件最終發(fā)布之前，怎么可能確定的下來呢。啊，這些都是讓我們的開發(fā)人員和測試人員極其頭痛的事情。到底應(yīng)該怎樣在頻繁變更的需求中確定哪些部分是我們在某個階段要測試的內(nèi)容呢？或者說通過什么樣的方法可以改善我們上面提到的那些問題呢？一個實際的做法就是實現(xiàn)軟件需求的版本化控制。既然說到了這里，就不免要說些題外話。筆者一直都認為軟件需求是開發(fā)工作和測試工作在制定計劃、開展工作時所共同參照的源頭和依據(jù)，而我們只有在源頭上控制好，才能保證下面工作的平穩(wěn)開展。如果希望某個階段工作的進度和內(nèi)容可以明確的定義下來，就必須要考慮軟件需求的版本化控制。這里所提到的“軟件需求的版本化控制”，是指在一個軟件產(chǎn)品的生命周期中，當要進行一個新版本的迭代時，要盡早的確定這個版本中將要實現(xiàn)的需求，并同上個版本做出比較，哪些內(nèi)容是新增的，哪些內(nèi)容是被調(diào)整過的。在該階段工作開始之初的工作會議上，明確的向所有需要了解軟件需求的涉眾傳達這部分信息。而如果在該版本的開發(fā)過程中不斷的出現(xiàn)需求變更的情況，則應(yīng)該根據(jù)市場策略、已公布的發(fā)布時間、客戶需求、實現(xiàn)的代價、難易程度以及對現(xiàn)有工作的影響等方面，對需求進行適度劃分，嚴格定義當前版本中需要實現(xiàn)的需求，而其他部分，則作為未來版本的軟件需求進行考慮。如果有的朋友認為上面的內(nèi)容還是太理論化，需要一個更實際的、可操作的方法。那么只能說，對于需求的變更，以及因為需求變更而引起的設(shè)計的變更，必須要早發(fā)現(xiàn)，早討論，早決定，早調(diào)整。這可能更多的要依靠一個團隊中相關(guān)負責(zé)人員的主動工作來保證，而不是依靠一個明確的方法。注意，這里的一個關(guān)鍵是，對于軟件需求，同樣需要嚴格按照版本進行管理，或者說使用“基線”進行管理。如何整理測試需求？
一旦當前階段測試工作的范圍確定下來，我們就可以開始考慮測試需求的整理——也就是明確的定義現(xiàn)階段要“測什么”。測試需求的確定將為我們制定進度時間表、分配資源以及如何確定某個階段測試工作是否完成提供一個可供衡量的標準。當然，還有更重要的一點，已被確定的測試需求是我們進行測試用例設(shè)計和考慮測試覆蓋的依據(jù)。整理測試需求的第一步，就是要“測試需求”。測試需求？對，不知道您是否想到，這里的“測試需求”中的“測試”是一個動詞，指的是對軟件需求本身的檢查。
??？這不是已經(jīng)超出了測試工作的范圍了嗎？測試人員不是應(yīng)該只關(guān)心軟件的實現(xiàn)同需求是否相符嗎？這樣對測試人員要求未免太高了?！@是筆者過去同一些朋友談到測試人員必須對需求進行檢查時聽到的一些不同的