軟件工程基礎(chǔ)：第7章 軟件測試

第7章軟件測試軟件驗證軟件驗證是通過檢查和提供客觀證據(jù)表明軟件已經(jīng)滿足規(guī)定的需求，是確保軟件質(zhì)量和降低軟件成本的重要手段，涉及軟件的整個生存周期。進行軟件驗證的方式大體有兩種：測試和證明。

測試又分靜態(tài)測試和動態(tài)測試兩種。

靜態(tài)測試，又稱評審，是對軟件進行的一種分析和檢查活動。

動態(tài)測試是通過運行軟件來檢驗其動態(tài)行為和運行結(jié)果的正確性。

證明是一種通過形式化的數(shù)學(xué)方法來確保軟件正確性的活動。

軟件測試軟件測試是在軟件投入運行前，對軟件需求分析、設(shè)計規(guī)格說明和編碼的復(fù)審，是為了發(fā)現(xiàn)錯誤，通過檢查和提供客觀證據(jù)表明軟件已經(jīng)滿足規(guī)定的需求。軟件測試是確保軟件質(zhì)量和降低軟件成本的重要手段，涉及軟件的整個生存周期。一般的軟件開發(fā)組織要將30%~40%的項目精力投入到測試之中，一些人命悠關(guān)的軟件（如航空器的飛行控制軟件）其測試費用往往更高。軟件錯誤的來源用戶/客戶/開發(fā)人員之間信息交流不暢開發(fā)人員/管理人員經(jīng)驗與素質(zhì)缺陷軟件需求不確定（需求模糊或不斷變化）軟件及系統(tǒng)復(fù)雜（規(guī)模大、技術(shù)性強）測試復(fù)雜性與經(jīng)濟性誤解：開發(fā)一個程序是困難的，測試一個程序則比較容易。由于測試情況數(shù)量巨大，都不可能進行徹底的測試，即窮舉測試。為了降低測試成本，選擇測試用例時應(yīng)注意遵守“經(jīng)濟性”的原則。測試的主要影響因素：

系統(tǒng)的類型、潛在的用戶數(shù)量、信息的價值、開發(fā)機構(gòu)、測試的時機測試存在的疑問測試應(yīng)該什么時候開始？誰應(yīng)該執(zhí)行測試？測試技術(shù)如何能夠有助于防止錯誤？測試活動如何被集成到軟件過程的模型中？測試如何有利于復(fù)用？測試需要多大的工作量？7.1軟件測試基礎(chǔ)

軟件測試≠程序測試軟件測試對象：軟件生存周期各階段文檔和代碼據(jù)美國一家公司統(tǒng)計：64%的錯誤屬于分析和設(shè)計的錯誤，編碼錯誤只占36%。軟件測試不是打消軟件工程師積極性的過程，而是同軟件分析與設(shè)計一樣，是為了建成高質(zhì)量的軟件，只不過是從不同的側(cè)面進行罷了。7.1.1測試觀點

G.J.Myers在他有關(guān)軟件測試的著作《軟件測試技巧》中陳述了一系列關(guān)于測試的觀點：測試是為了尋找錯誤而運行程序的過程。一個好的測試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤。一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。軟件測試就是試圖以最少的代價發(fā)現(xiàn)軟件分析、設(shè)計和編碼中存在的各種不同類型的錯誤，從而提高軟件質(zhì)量，降低軟件成本。7.1.2測試原則

測試應(yīng)“盡早地和不斷地進行”。較早確定測試計劃，嚴格執(zhí)行測試計劃。注意錯誤的群集現(xiàn)象和應(yīng)用Pareto原則。測試規(guī)模應(yīng)從小到大。測試應(yīng)一般由獨立的第三方進行。應(yīng)保證測試用例的完整性和有效性。應(yīng)保存所有測試用例和出錯統(tǒng)計等，直至軟件不用為止。7.1.3測試工具

軟件測試工具是一種測試軟件，開發(fā)人員借助它可以提高軟件測試工作的效率。

按工作方式可分為：靜態(tài)分析工具和動態(tài)測試工具。按功能分有：測試計劃工具——支持制訂測試計劃；測試設(shè)計與開發(fā)工具——支持測試數(shù)據(jù)生成等；測試執(zhí)行工具——支持特定的測試方法，支持回歸測試等；測試評價工具——報告測試覆蓋情況；測試管理工具——協(xié)助進行測試組織工作；以及其它輔助測試工具等。

靜態(tài)分析測試軟件

通過掃描被測程序的正文，對其數(shù)據(jù)流和控制流進行分析，然后送出測試報告。主要功能包括：變量檢查、邏輯結(jié)構(gòu)檢查、接口檢查、編程風(fēng)格檢查和靜態(tài)特性統(tǒng)計等，通過建立交叉引用表的方式等實現(xiàn)。

動態(tài)分析測試軟件

通過對被測程序有控制地運行，自動地監(jiān)視、記錄和統(tǒng)計被測程序的運行情況。主要功能包括：語句執(zhí)行次數(shù)統(tǒng)計、執(zhí)行開銷估算、CPU執(zhí)行時間分析和軟硬件資源利用分析等。

測試數(shù)據(jù)自動生成程序

用來為被測程序自動產(chǎn)生測試輸入數(shù)據(jù)。這樣，一方面可以減輕生成大量測試數(shù)據(jù)的負擔(dān)，另一方面可以避免人為的偏見。對于預(yù)期結(jié)果，可以利用手工計算等得到。按生成測試數(shù)據(jù)的方式來分有：路徑測試數(shù)據(jù)生成程序、隨機測試數(shù)據(jù)生成程序、根據(jù)數(shù)據(jù)規(guī)格說明生成測試數(shù)據(jù)等。

文件比較程序

用來自動檢查測試結(jié)果。其檢查過程一般主要由三步組成；首先建立一個存放預(yù)期結(jié)果的文件；然后執(zhí)行測試，并把測試結(jié)果存進另一文件；最后，使用文件比較程序比較上述兩個文件，打印出有差異者的情況。

MercuryInteractive公司測試產(chǎn)品

TestDirector是基于Web的測試管理系統(tǒng)，它可以在公司組織內(nèi)進行全球范圍內(nèi)測試的協(xié)調(diào)。WinRunner是一種企業(yè)級的用于檢驗應(yīng)用程序是否如期運行的功能性測試工具。LoadRunner是一種較高規(guī)模適應(yīng)性的自動負載測試工具，它能預(yù)測系統(tǒng)行為，優(yōu)化性能。其他測試工具工具名支持語言簡介BoundsCheckerC++,DelphiAPI和OLE錯誤檢查、指針和泄露錯誤檢查、內(nèi)存錯誤檢查TrueTimeC++,Java,VisualBasic代碼運行效率檢查、組件性能的分析FailSafeVisualBasic自動錯誤處理和恢復(fù)系統(tǒng)JcheckMSVisualJ++圖形化的事件分析工具TrueCoverageC++,Java,VisualBasic函數(shù)調(diào)用次數(shù)、所占比率統(tǒng)計以及穩(wěn)定性跟蹤SmartCheckVisualBasic函數(shù)調(diào)用次數(shù)、所占比率統(tǒng)計以及穩(wěn)定性跟蹤CodeReviewVisualBasic自動源代碼分析工具JtestJava代碼分析和動態(tài)類、組件測試JcontractJava實時性能監(jiān)控以及分析優(yōu)化C++TestC,C++代碼分析和動態(tài)測試CodeWizardC,C++代碼靜態(tài)分析Insure++C,C++實時性能監(jiān)控以及分析優(yōu)化.test.Net代碼分析和動態(tài)測試7.1.4測試組織

一般來講，獨立測試之前，軟件開發(fā)者應(yīng)負責(zé)對程序單個模塊測試，以保證每個模塊能完成詳細設(shè)計的功能等。在很多情況下，軟件開發(fā)者也進行集成測試，以保證每個模塊能按總體設(shè)計的要求形成整個軟件系統(tǒng)。在系統(tǒng)形成之后，獨立測試小組才開始介入，同時為了保證測試順利進行，在測試過程中，開發(fā)人員必須協(xié)助。獨立測試應(yīng)確保系統(tǒng)滿足需求分析的要求和用戶意圖。

7.1.5測試與調(diào)試

測試是查找錯誤癥狀的過程，調(diào)試則是查找錯誤癥狀原因并改正錯誤的過程。

測試評價調(diào)試修改后的軟件配置出現(xiàn)錯誤的軟件

測試結(jié)果預(yù)期結(jié)果

錯誤率數(shù)據(jù)軟件配置

⊕

測試配置

測試工具未出現(xiàn)錯誤的軟件

⊕7.1.6動態(tài)測試步驟

用戶要求需求分析需求規(guī)格說明書概要設(shè)計概要設(shè)計說明書詳細設(shè)計詳細設(shè)計說明書編碼源代碼單元測試集成測試確認測試系統(tǒng)測試問題軟件7.2代碼復(fù)審

代碼復(fù)審一般在程序通過編譯（如查找語法等錯誤）及靜態(tài)分析工具檢查（如找出程序在結(jié)構(gòu)、編碼標準與風(fēng)格等方面的錯誤）之后，在動態(tài)測試之前進行。

代碼復(fù)審是一種人工進行的測試，可以由程序作者本人非正式地進行，也可以由審查小組以開會的方式進行。代碼復(fù)審的主要方法有：代碼會審、走查、辦公桌檢查。經(jīng)驗表明，代碼復(fù)審是一種非常有效的程序驗證技術(shù)，該方法能夠有效地發(fā)現(xiàn)30%到70%的邏輯設(shè)計和編碼錯誤。

7.2.1代碼復(fù)審內(nèi)容

對源程序代碼進行的復(fù)審主要著重于檢查編碼實現(xiàn)是否完備、正確等。

在復(fù)審過程中，可以對照有關(guān)條例或錯誤檢驗表，查找程序在結(jié)構(gòu)、功能、編碼標準和風(fēng)格等方面的錯誤或提出質(zhì)疑。

代碼復(fù)審內(nèi)容條例表舉例

錯誤檢驗表一般內(nèi)容

7.2.2代碼會審

會審小組一般由4人左右組成，包括組長1人，程序作者1人，其他程序員（或測試員）1~2人。會審小組通過對評審材料閱讀、討論和爭議，對程序代碼進行檢查。

會前，小組負責(zé)人將待評審的材料及有關(guān)附件發(fā)放給與會者，以熟悉有關(guān)內(nèi)容。

會上，程序作者逐句朗讀并講解程序代碼，其他人則集中精力對照有關(guān)條例或檢查表，捕捉程序可能存在的問題，也可以展開討論。

會后，應(yīng)把查出的問題清單交給程序作者處理，作者處理完后交回組長。如果問題很多，或者程序改動較大，則在改正后應(yīng)再次組織會審。

會審一方面可使得同行之間相互啟發(fā)從而更易于發(fā)現(xiàn)錯誤，另一方面有利于互相學(xué)習(xí)、交流經(jīng)驗、取長補短，以進一步提高軟件開發(fā)質(zhì)量和效率。

7.2.3走查

會前，發(fā)放有關(guān)材料給與會者進行熟悉，并至少指定一人設(shè)計測試用例。

會上，與會者扮演計算機角色，人工“執(zhí)行”被測程序。通過將測試用例“輸入”被測程序