論進的V測試模型綜述

1、本文格式為Word版，下載可任意編輯 論進的V測試模型綜述 簡介： 馬俊，男， 24歲，西南大學(xué)碩士研究生，主要研究方向：計算機軟件與理論；丁曉明，男，40歲，西南大學(xué)計算機科學(xué)與信息學(xué)院副教授，碩士生導(dǎo)師。 隨著計算機技術(shù)的飛速發(fā)展，軟件行業(yè)的競爭日益強烈，在開發(fā)軟件的過程中，人們使用了大量保證軟件質(zhì)量的方法來分析、設(shè)計和實現(xiàn)軟件，以保證自己生產(chǎn)的軟件在競爭中的不敗。但開發(fā)人員難免會在工作中犯錯誤，特別是對于規(guī)模大，繁雜性高的軟件更是如此。這樣，在軟件產(chǎn)品中就會隱蔽大量錯誤和缺陷。這些錯誤和缺陷假如遺留到軟件投入運行之時，終將會暴露出來。1996年，由于阿里亞納（Ariane）5號火箭上的軟

2、件系統(tǒng)失敗，損失了多個衛(wèi)星，造成的間接經(jīng)濟損失達到數(shù)十億美元1。象這種要求極高的系統(tǒng)的驗證工作比其他類型的系統(tǒng)更為重要，而且成本也高得多。但若不進行足夠的驗證而出現(xiàn)Ariane 5號火箭這種狀況，則造成的損失比驗證的成本要高得多。大量類型的軟件所使用的領(lǐng)域還涉及到人類的生命安全。譬如醫(yī)用領(lǐng)域的胰島素注射系統(tǒng)，若因軟件的缺陷而造成系統(tǒng)故障，向病人注射過量的胰島素，會導(dǎo)致腦功能障礙甚至死亡。以上提到這些風(fēng)險及大的軟件系統(tǒng)，在開發(fā)過程中必需經(jīng)過嚴格的測試，以驗證軟件系統(tǒng)的可靠性。就算一般的系統(tǒng)，雖然不會對人的生命造成危害，但是在經(jīng)濟方面的損失是不可估量的。譬如銀行的管理系統(tǒng)，若出現(xiàn)系統(tǒng)崩潰的狀況，經(jīng)

3、濟損失巨大。所以不管什么系統(tǒng)，都必需在經(jīng)濟允許的狀況下，進行足夠的測試，已保證軟件的質(zhì)量。 軟件測試有以下幾項原則： （）在軟件開發(fā)生命周期中盡早地和不斷地進行測試2。 質(zhì)量保證協(xié)會的調(diào)查說明，應(yīng)用系統(tǒng)每1000個源語句中存在大約60個缺陷，這些缺陷中有2/3是出現(xiàn)在系統(tǒng)的需求和設(shè)計階段的。假如拖到后面的階段解決這些缺陷，將增加大量費用。 （）測試用例應(yīng)由測試輸入數(shù)據(jù)和與之對應(yīng)的預(yù)期輸出結(jié)果這兩部分組成。 （）程序員應(yīng)避免測試自己的程序。假如程序員測試自己的程序，他會按自己開發(fā)時的思維方式來對待自己的程序，總認為自己的程序是正確的，不利于找到缺陷。 （）要合理保存測試計劃、測試用例、出錯統(tǒng)計和

4、最終分析報告，這些文檔會為維護人員維護階段的工作提供便利。維護階段是軟件交付后的階段，有可能維護人員是用戶方的人而不是開發(fā)人員，保存這些文檔就尤為重要。 其左邊每個開發(fā)活動都與右邊的測試活動相對應(yīng),它描繪了軟件開發(fā)過程中,需求、總體設(shè)計、詳細設(shè)計和編碼逐步實現(xiàn)，針對這些開發(fā)階段的測試，其開展的次序正好相反。也就是說，代碼最終被開發(fā)出來，而相應(yīng)的單元測試首先被執(zhí)行；需求最早開發(fā)，但相應(yīng)的驗收測試是最終才進行的。這個傳統(tǒng)的模型是早期開發(fā)出來的，和現(xiàn)代軟件工程中測試的原則不相適合。 V模型的缺點： （）V模型是等到編碼終止才開始進行單元測試，和前面提到的要在軟件開發(fā)生命周期中盡早地和不斷地進行測試這

5、個最重要的測試原則相矛盾。 （）應(yīng)當(dāng)開發(fā)和測試并行，開發(fā)小組和測試小組通力合作，而傳統(tǒng)的V模型的這種方式很可能出現(xiàn)這種狀況，開發(fā)人員編碼完成，就等著測試小組提交缺陷報告，然后修改程序。這種就對比空閑，不利于人力資源的利用，也不利于小組間的合作。 （）這個模型測試過程和開發(fā)過程在時間上嚴格的劃分開，這樣不利于測試計劃、測試用例、出錯統(tǒng)計和最終分析報告等文檔的保存。 基于以上原因以及傳統(tǒng)V測試模型的缺點，提出了改進的測試模型，如下圖。 這個模型左邊是開發(fā)階段，右邊是與各個開發(fā)階段對應(yīng)的測試。他們的執(zhí)行順序都是從上到下，測試與開發(fā)并行進行。如需求分析階段就有制定測試計劃和測試需求這兩個測試步驟；軟件

6、設(shè)計階段就設(shè)計此階段的測試用例并測試設(shè)計階段得出的結(jié)果。每個階段都要設(shè)計相應(yīng)的測試用例，一旦得出了可測試的結(jié)果，就對其進行測試。這也符合盡早地和不斷地進行測試這個原則。而且這樣的話測試小組和開發(fā)小組就可以更好地合作，有利于資源利用。 該模型從一開始的需求階段就制定測試計劃，在需求分析的過程中，對可測試的需求文檔進行需求測試。測試計劃的目標(biāo)是描述所有要完成的測試，包括完成所需的資源和進度。測試計劃應(yīng)給出被測試軟件的背景信息、測試的目標(biāo)和風(fēng)險，以及所要執(zhí)行的特定測試。測得太多不行，浪費人力財力；測得太少也不行，軟件的質(zhì)量得不到保證。有效的測試方法就是明確和評價計算機系統(tǒng)的各種風(fēng)險。能把這些風(fēng)險縮小

7、到測試范圍內(nèi)是很重要的。要確定能接受多少風(fēng)險，然后制定測試計劃實現(xiàn)這個目標(biāo)。風(fēng)險的概念確定了從經(jīng)濟學(xué)的角度考慮需要完成多少測試或測試類型，而不是進行不可能完成的窮舉測試或者憑直覺胡亂地測試。所以有經(jīng)驗的測試人員會基于風(fēng)險找到一個平衡點，逐步完成測試計劃。需求測試的目的是要確保需求得到了正確的記錄，保證信息服務(wù)工程小組正確解釋了需求。由于需求階段應(yīng)當(dāng)是用戶占主導(dǎo)地位的階段，所以測試必需要確定需求很好地代表了用戶的需要，確定已經(jīng)文檔化了需要。 接下來是對總體設(shè)計和詳細設(shè)計的測試。這個階段執(zhí)行設(shè)計評審以及審查可交付的設(shè)計結(jié)果。此階段的測試和需求階段的測試都是靜態(tài)測試，沒有可執(zhí)行的代碼，只有文檔和可交

8、付結(jié)果用于審查。假如將缺陷遺留到后面的階段解決，會增加大量花費。這也不符合及早地不斷地進行測試的原則?？山桓督Y(jié)果包括：輸入規(guī)格說明、處理規(guī)格說明、輸出規(guī)格說明、操縱規(guī)格說明、系統(tǒng)流程圖等等，基本上就是對這些文檔進行測試。這個階段有幾個任務(wù)需要完成：分析設(shè)計因素、進行設(shè)計評審、審查設(shè)計階段可交付的結(jié)果。 編碼階段進行的測試，主要是針對代碼進行測試，已白盒測試技術(shù)為主，已黑盒測試為輔。白盒測試技術(shù)中的語句覆蓋、條件覆蓋、路徑覆蓋等技術(shù)都可用于代碼的測試階段。從這個階段開始，就有了可執(zhí)行的代碼，所以此階段和之后的階段都是進行動態(tài)測試。 編碼階段終止后就進入了傳統(tǒng)的測試階段，這個階段要進行單元測試，然后在軟件模塊的集成過程中要進行集成測試，在進行系統(tǒng)測試和用戶的驗收測試。系統(tǒng)測試和驗收測試里面也包括了對系統(tǒng)功能的測試。這個階段基本上就按傳統(tǒng)的測試階段進行，但是由于此前做了大量測試工作，這個階段的大量步驟比傳統(tǒng)測試階段的步驟更簡單，返工的工作也更少，花費也更小。開發(fā)階段的測試就到此為止，形成了成品軟件，交付給用戶方。