版本更新時軟件測試工作內容

 對于一個存在生命周期的軟件來說，它的開發和測試往往是循環的多次的，因為隨著新的需求的出現，以及對原有版本的改進，新的版本會不斷的發布（即使對于一些以客戶定制方式運作的項目，在開發過程中以及發布后的維護期內，也會產生眾多的內部版本）。隨著版本的迭代更新，我們的軟件測試工作也會一直繼續下去。而在每一次迭代時，可能在整個工作階段的開始就受到一些因素的影響，比如市場需求、既定的發布時間、并發的工作導致的資源緊張等等，使我們不得不考慮對軟件質量要求的適度，最終使得我們在每個階段的測試工作的要求或者說所涉及到的內容有可能是不同的。這種變化，最終將會影響到測試需求的確定。

        那么到底該如何確定每次迭代是測試工作的范圍呢？通常把測試工作范圍的確定，等價的認為是軟件需求的確定。

        不過現在有一個很實際的問題是這樣：軟件需求在開發過程中不斷發生變化，有時候到了后期還會有新的需求添加進來，還有些需求在交付內部測試版本之后又發現原來的需求本身就存在缺陷，之后再次返工，在軟件最終發布之前，怎么可能確定的下來呢。

        啊，這些都是讓我們的開發人員和測試人員極其頭痛的事情。到底應該怎樣在頻繁變更的需求中確定哪些部分是我們在某個階段要測試的內容呢？或者說通過什么樣的方法可以改善我們上面提到的那些問題呢？一個實際的做法就是實現軟件需求的版本化控制。既然說到了這里，就不免要說些題外話。

        筆者一直都認為軟件需求是開發工作和測試工作在制定計劃、開展工作時所共同參照的源頭和依據，而我們只有在源頭上控制好，才能保證下面工作的平穩開展。如果希望某個階段工作的進度和內容可以明確的定義下來，就必須要考慮軟件需求的版本化控制。這里所提到的“軟件需求的版本化控制”，是指在一個軟件產品的生命周期中，當要進行一個新版本的迭代時，要盡早的確定這個版本中將要實現的需求，并同上個版本做出比較，哪些內容是新增的，哪些內容是被調整過的。

        在該階段工作開始之初的工作會議上，明確的向所有需要了解軟件需求的涉眾傳達這部分信息。而如果在該版本的開發過程中不斷的出現需求變更的情況，則應該根據市場策略、已公布的發布時間、客戶需求、實現的代價、難易程度以及對現有工作的影響等方面，對需求進行適度劃分，嚴格定義當前版本中需要實現的需求，而其他部分，則作為未來版本的軟件需求進行考慮。如果有的朋友認為上面的內容還是太理論化，需要一個更實際的、可操作的方法。那么只能說，對于需求的變更，以及因為需求變更而引起的設計的變更，必須要早發現，早討論，早決定，早調整。

        這可能更多的要依靠一個團隊中相關負責人員的主動工作來保證，而不是依靠一個明確的方法。注意，這里的一個關鍵是，對于軟件需求，同樣需要嚴格按照版本進行管理，或者說使用“基線”進行管理。

 

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