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