軟件測試及軟件質(zhì)量控制ppt課件

1、軟件測試及軟件質(zhì)量控制 第六章. 軟件系統(tǒng)的開發(fā)過程中，軟件測試占據(jù)著重要位置。雖然人們采取了多種保證軟件質(zhì)量的措施，由于軟件系統(tǒng)的客觀復(fù)雜性，人們的客觀認識不能夠完全符合客觀實踐，完美無缺，每個階段的技術(shù)審查也不能夠毫無脫漏地查出和糾正一切的設(shè)計和分析上的錯誤，在軟件生命周期的各個階段，都不可防止地會產(chǎn)生過失，這些過失遲早會在軟件的消費和運用過程中暴顯露來。. 軟件工程實際的閱歷闡明，發(fā)現(xiàn)軟件的時辰越晚，矯正這些錯誤所破費的代價也越高，假設(shè)在軟件投入運用之前沒有發(fā)現(xiàn)和糾正軟件的大部分錯誤，人們付出的代價會更高，往往會呵斥惡劣的后果。 從廣義上來說，軟件測試任務(wù)分布在軟件生命周期的各個開發(fā)階段

2、，人們認識到，軟件測試是保證軟件質(zhì)量的主要手段，各階段的評審任務(wù)和驗證任務(wù)，均是廣義概念上的測試任務(wù)。而主要的測試是在編碼和測試這兩個階段進展的。因此，狹義的軟件測試就是程序測試。 .6.1 軟件測試根本概念 G.J.Myers給出了關(guān)于測試的一些規(guī)那么，被軟件工程領(lǐng)域認可： 1測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程； 2好的測試方案極有能夠發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤； 3勝利的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤。.6.1 軟件測試根本概念 這些規(guī)那么，實踐上是軟件測試的狹義概念程序測試。 狹義的軟件測試：測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。是根據(jù)軟件開發(fā)的各個階段的闡明和程序的內(nèi)部構(gòu)造而

3、精心設(shè)計的一批測試用例有輸入數(shù)據(jù)及預(yù)期的結(jié)果，并利用這些測試用例執(zhí)行程序及發(fā)現(xiàn)錯誤的過程。 .6.1 軟件測試根本概念 廣義的軟件測試是對軟件方案、軟件系統(tǒng)分析、軟件設(shè)計、軟件編碼進展的查錯活動，包括代碼執(zhí)行和人工審查活動，測試的目的是找出軟件生命周期的各個階段的錯誤，有利于以后進展修正和糾正。但測試本身不修正錯誤，調(diào)試才會修正錯誤。即找錯的活動是測試；分析錯誤的性質(zhì)與位置，進展糾錯的活動是調(diào)試，保證算法的正確實現(xiàn)。軟件測試與程序測試都是查找錯誤的活動，差別在于查找錯誤的范圍不同。.6.1 軟件測試根本概念 由于測試的目的是暴露程序的錯誤，從心思學角度看，由設(shè)計者本人進展測試是不恰當?shù)模O(shè)計小

4、組和測試小組應(yīng)該分別設(shè)立，有利于進展客觀和公正的軟件測試。測試是有限的，由于通常的測試過程不能夠窮盡一切情況，即使經(jīng)過了嚴厲的測試之后，依然能夠存在沒有被發(fā)現(xiàn)的錯誤隱藏在程序中，不能證明程序中沒有錯誤。.6.1 軟件測試根本概念 因此，測試僅僅有能夠找出程序的錯誤，測試不能證明程序是正確的。軟件工程中一切其它階段都是“建立性的，軟件工程師力圖從籠統(tǒng)概念出發(fā)，逐漸設(shè)計出詳細的軟件系統(tǒng)，而測試人員的任務(wù)外表上看卻是“破壞性的，竭力證明軟件中含有錯誤，不能按預(yù)定要求正確任務(wù)。凡是進展對比的方式均可了解為測實驗證。 .6.1.2 軟件測試的對象 軟件測試應(yīng)該貫穿于軟件生命期的各個階段，各階段的任務(wù)是相

5、互銜接、相互影響的，前一階段發(fā)生的問題自然要影響到下一階段的任務(wù)。為了把握各個環(huán)節(jié)的正確性，人們需求進展各種確認和驗證任務(wù)。軟件確認是廣義上的軟件測試，它是企圖證明軟件在一個給定的外部環(huán)境中軟件的邏輯正確性的一系列活動和過程，如需求闡明書確實認、程序確實認等。.6.1.2 軟件測試的對象 程序確實認又分為靜態(tài)確認與動態(tài)確認。 靜態(tài)確認普通不在計算機上執(zhí)行程序，而是經(jīng)過程序正確性證明、靜態(tài)分析或人工分析來確認程序的正確性； 動態(tài)確認主要經(jīng)過動態(tài)分析和動態(tài)測試，用執(zhí)行程序的過程來檢查執(zhí)行的形狀，確認程序能否有問題； .6.1.2 軟件測試的對象 正確性證明主要是企圖繞過復(fù)雜的測試，直接證明程序的正

6、確性。 如程序的輸入輸出斷言法。 設(shè)程序段為S，其前斷言為P，后斷言為R。假設(shè)執(zhí)行S以前P為真，那么執(zhí)行S后R也為真，那么證明S是正確的，記為PSR。.6.1.2 軟件測試的對象 任何程序總可以分成S1、S2、 Sn個結(jié)點，對應(yīng)的斷言為R1、R2、Rn，起初R1為輸入斷言，R2為輸出斷言，也是下一個輸入斷言， Rn為最后的輸出斷言，我們總可以，將S1、S2、 Sn逐個證明，自頂向下或自底向上都可證明程序的正確性，該分支已開展為計算機代數(shù)學； .6.1.2 軟件測試的對象 軟件驗證也屬于廣義上的軟件測試，它試圖證明在軟件生命期的各個階段、各階段的邏輯協(xié)調(diào)性、完備性和正確性。 包括系統(tǒng)分析員了解用

7、戶要求的正確性、表達的正確性、設(shè)計人員對需求規(guī)格闡明了解的正確性、設(shè)計與設(shè)計表達的正確性、程序編碼的正確性和運轉(zhuǎn)軟件程序時輸入的正確性、運轉(zhuǎn)結(jié)果的正確性等，運轉(zhuǎn)結(jié)果與用戶預(yù)期的結(jié)果能否一致等，這闡明任何一個環(huán)節(jié)上發(fā)生了問題都能夠在軟件測試中表現(xiàn)出來。 .6.1.3 測試信息流 將測試的過程用數(shù)據(jù)流圖表示，可得測試信息流如圖6-1所示。 至軟件配置軟件配置 1 測試結(jié)果 2 錯誤 3 修正的軟件測試配置 測試結(jié)果測試工具 測試 評價 調(diào)試 正確 預(yù)測結(jié)果 出錯率 4 數(shù)據(jù) 可靠性 分析圖6-1 測試信息流 .6.1.3 測試信息流 1.測試過程需求三類輸入： 1軟件配置：包括軟件開發(fā)文檔用戶文檔

8、、需求規(guī)格闡明、軟件設(shè)計闡明、源程序代碼、目的執(zhí)行程序、數(shù)據(jù)構(gòu)造； 2測試配置：包括測試方案、測試用例、測試驅(qū)動程序等；實踐上在整個軟件開發(fā)過程中，測試配置只是軟件配置的一個子集；. 3測試工具：為提高軟件測試效率，運用測試工具為測試任務(wù)效力；如：測試數(shù)據(jù)自動生成程序，靜態(tài)分析程序、動態(tài)分析程序、測試結(jié)果分析程序及規(guī)范例程測試數(shù)據(jù)庫等。 6.1.3 測試信息流. 測試之后，對一切測試結(jié)果進展分析，將實踐測試的結(jié)果與預(yù)期的結(jié)果進展比較。假設(shè)發(fā)現(xiàn)出錯的數(shù)據(jù)，那么意味著軟件有錯誤，需求糾錯，應(yīng)進展調(diào)試，確定錯誤的位置和出錯的性質(zhì)，矯正這些錯誤，同時修正相關(guān)文檔。修正過的文檔普通需經(jīng)過再次測試，直到經(jīng)

9、過測試為止。6.1.3 測試信息流. 經(jīng)過搜集和分析測試結(jié)果的有關(guān)數(shù)據(jù)，可以建立軟件評價的可靠性模型。 假設(shè)經(jīng)常出現(xiàn)需求修正設(shè)計的嚴重錯誤，那么軟件的質(zhì)量和可靠性就值得疑心，同時也闡明需求進一步測試。 相反，假設(shè)軟件功能可以正確完成，出現(xiàn)的錯誤易于修正，那么就能夠有兩種評價：6.1.3 測試信息流.一種是軟件的質(zhì)量和可靠性到達可以接受的程度。另一種是所做的測試還缺乏以發(fā)現(xiàn)軟件的嚴重錯誤。 假設(shè)得到的評價是沒有發(fā)現(xiàn)錯誤，很有能夠測試的配置思索得不夠充分和細致，軟件仍有埋伏的錯誤，以后矯正錯誤需求付出高昂的代價。 6.1.3 測試信息流. 2.軟件錯誤可以從不同角度進展分類： 1從錯誤對程序的影響

10、程度來分： 嚴重性錯誤：嚴重影響程序的運轉(zhuǎn)，甚至不能運轉(zhuǎn)； 普通性錯誤：經(jīng)常影響程序的運轉(zhuǎn)，特殊情況下表現(xiàn)正常；6.1.3 測試信息流. 微小錯誤：普通情況下程序能運轉(zhuǎn)，特殊情況下表現(xiàn)異常； 無影響性錯誤：不影響程序的運轉(zhuǎn)。6.1.3 測試信息流. 2從開發(fā)過程的轉(zhuǎn)換環(huán)節(jié)上分： 構(gòu)造錯誤：編碼實現(xiàn)與設(shè)計不一致； 設(shè)計錯誤：設(shè)計邏輯與闡明不一致； 闡明書錯誤：闡明書與用戶要求不一致； 需求錯誤：不滿足用戶的實踐要求； 配置錯誤：軟件配置不滿足實踐環(huán)境。6.1.3 測試信息流.3從測試結(jié)果的表現(xiàn)上分類： 1功能錯誤：由系統(tǒng)需求分析不完好引起的； 2構(gòu)造錯誤：由總體設(shè)計的錯誤引起的； 3過程錯誤：由

11、詳細設(shè)計的錯誤引起的； 4數(shù)據(jù)錯誤：由軟件編碼或詳細設(shè)計的錯誤引起的； 5編碼錯誤：由軟件編碼引起的錯誤； 6其它錯誤：由文檔和其它系統(tǒng)元素引起的錯誤；6.1.3 測試信息流.6.1.4 軟件測試步驟與軟件開發(fā)各階段的關(guān)系軟件測試普通分為四個步驟： 1單元測試也稱模塊測試：針對軟件設(shè)計的根本單元程序模塊，進展正確性檢驗的測試任務(wù)。目的在于發(fā)現(xiàn)各個模塊內(nèi)部能夠存在的各種過失。單元測試需求從程序內(nèi)部構(gòu)造出發(fā)設(shè)計測試用例，多個模塊可以平行、獨立地進展測試；.6.1.4 軟件測試步驟與軟件開發(fā)各階段的關(guān)系 2集成測試也稱組裝測試，結(jié)合測試：在單元測試的根底上，將一切模塊按設(shè)計要求集成在一同進展測試，以

12、檢驗總體設(shè)計中各模塊間的接口設(shè)計問題、模塊之間的相互影響、上層模塊存在的各種過失及全局數(shù)據(jù)構(gòu)造對系統(tǒng)的影響等方面。.6.1.4 軟件測試步驟與軟件開發(fā)各階段的關(guān)系 3確認測試也稱驗收測試，有效性測試：主要檢驗軟件的功能和性能能否與需求闡明書中的規(guī)定一致。 4系統(tǒng)測試：將軟件系統(tǒng)作為一個元素，放入整個實踐的計算機系統(tǒng)中，與計算機硬件、其他軟件、運用人員等系統(tǒng)元素結(jié)合在一同，在實踐運用環(huán)境下進展綜合全面的測試。.6.1.4 軟件測試步驟與軟件開發(fā)各階段的關(guān)系 前面多次強調(diào)，運用軟件生命期瀑布模型模型，軟件開發(fā)過程是一個自頂向下，逐漸細化的過程，而軟件測試過程那么是與開發(fā)過程相反的次序進展的，是一個

13、自底向上，逐漸集成的過程，低一層測試為上一層測試預(yù)備測試條件和數(shù)據(jù)驅(qū)動環(huán)境，也包含兩者平行進展測試。.6.1.4 軟件測試步驟與軟件開發(fā)各階段的關(guān)系 因此，發(fā)現(xiàn)引起錯誤的緣由順序也與開發(fā)過程的相次序反，首先對每一個模塊進展單元測試，消除程序模塊內(nèi)部邏輯上和功能上的錯誤和缺陷，再對照軟件設(shè)計進展集成測試有時也叫整體測試，檢測和排除子系統(tǒng)或系統(tǒng)構(gòu)造上的錯誤，再對照需求進展確認測試也稱為有效性測試，最后進展系統(tǒng)測試，運轉(zhuǎn)系統(tǒng)，看軟件系統(tǒng)能否滿足功能和性能及其它要求。 .6.1.4 軟件測試步驟與軟件開發(fā)各階段的關(guān)系需求分析軟件設(shè)計軟件編碼確認測試集成測試單元測試系統(tǒng)測試圖6-2 軟件測試與軟件開發(fā)過

14、程間的關(guān)系.6.1.4 軟件測試步驟與軟件開發(fā)各階段的關(guān)系需求分析 闡明書概要設(shè)計 闡明書詳細設(shè)計 闡明書源程序 代碼確認測試集成測試單元測試系統(tǒng)測試圖6-3 軟件測試與開發(fā)文檔之間的關(guān)系.6.1.5 軟件測試原那么1將軟件測試貫穿于軟件開發(fā)的各個階段中，在開發(fā)過程中盡早地發(fā)現(xiàn)和預(yù)防錯誤，杜絕隱患，提高軟件質(zhì)量；2測試用例必需包含輸入數(shù)據(jù)和與之對應(yīng)的預(yù)期輸出結(jié)果，精心設(shè)計測試用例；3測試時應(yīng)防止設(shè)計者檢查本人設(shè)計的程序；4設(shè)計測試用例時，應(yīng)包括合理的與不合理的輸入條件；.6.1.5 軟件測試原那么5充分留意測試中出現(xiàn)的錯誤群集景象，假設(shè)發(fā)現(xiàn)錯誤數(shù)目較多，那么能夠殘存的錯誤數(shù)目也較多，這種錯誤出

15、現(xiàn)的群集景象，已為許多程序測試實際所證明；6嚴厲執(zhí)行測試方案，以軟件需求闡明書為基準設(shè)計測試用例，排除測試的隨意性；.6.1.5 軟件測試原那么7對每一個測試結(jié)果做全面檢查，不能脫漏錯誤出現(xiàn)的征兆，軟件修正后要進展回歸測試，即用修正前測試過的測試用例進展測試，再用新的測試用例測試；8妥善保管測試方案、測試用例、出錯統(tǒng)計數(shù)據(jù)和最終分析報告，為維護提供方便。 在一個程序段中，還存在著尚未發(fā)現(xiàn)的錯誤概率與已發(fā)現(xiàn)的錯誤數(shù)正相關(guān)。 .6.1.5 軟件測試原那么殘存錯誤的能夠性已發(fā)現(xiàn)的錯誤數(shù)圖6-4 軟件錯誤的群集景象表示圖.6.2 軟件測試的方法 軟件的測試方法很多，不同的出發(fā)點得到不同的測試方法。有：

16、從測試過程來分：靜態(tài)分析法、動態(tài)測試法；從察看構(gòu)造的透明性方式來分：白盒法、黑盒法、灰盒法；從獲得測試數(shù)據(jù)方式上分：窮盡法；等價類劃分法；邊境值分析法；.6.2 軟件測試的方法從邏輯分析上分：因果圖法；錯誤推測法；從測試步驟上分：單元測試、集成測試、確認測試、系統(tǒng)測試等；從調(diào)查方式上分：功能測試，邏輯測試；.6.2 軟件測試的方法 如何測試得更完全、怎樣進展測試用例的設(shè)計，是軟件測試中的關(guān)鍵技術(shù)。無論用哪種方法進展測試，都是設(shè)法用較少的測試用例集合測試出程序中較多的潛在錯誤。 靜態(tài)分析時，不執(zhí)行程序，可對需求分析闡明書、軟件設(shè)計闡明書、源程序做構(gòu)造檢查、流圖分析、符號執(zhí)行來分析軟件能夠?qū)е碌漠?/p>

17、常情況，找出軟件錯誤。從測試過程來分：靜態(tài)分析法、動態(tài)測試法；.6.2 軟件測試的方法 構(gòu)造檢查是手工分析技術(shù)，對需求闡明、程序設(shè)計、編碼、測試任務(wù)進展評議，虛擬地模擬執(zhí)行程序，在評議中發(fā)現(xiàn)和檢查錯誤； 流圖分析是經(jīng)過分析流程圖、代碼構(gòu)造來檢查程序錯誤，便于進展編碼分析和測試結(jié)果分析；.6.2 軟件測試的方法 符號執(zhí)行是定義符號化數(shù)據(jù)，為程序的每條途徑給出符號表達式，對特定途徑輸入符號，經(jīng)處置輸出符號，判別程序的行為能否錯誤，這種方法復(fù)雜，易出錯，較少運用。 灰盒法是白盒法和黑盒法相結(jié)合運用的方法，僅對重點途徑和程序段用白盒法測試，大部分用黑盒法進展測試。.6.2 軟件測試的方法 動態(tài)測試是直

18、接執(zhí)行程序進展測試，包括功能測試、接口測試和構(gòu)造測試，察看程序的行為，記錄執(zhí)行的結(jié)果，從執(zhí)行結(jié)果來分析程序能夠出現(xiàn)的錯誤； 有些人想象，不論運用那種測試方法，只需對每一種能夠發(fā)生的情況都進展測試，能正確經(jīng)過，就可以得到完全正確的程序。.6.2 軟件測試的方法 包含一切能夠情況的測試稱為窮盡測試，實踐上，通常不能夠做到窮盡測試。由于各種輸入數(shù)據(jù)的陳列組合情況往往多到無法實踐測試完成的程度。如用黑盒法測試三個整數(shù)型的輸入數(shù)據(jù)，假設(shè)每個整數(shù)是16位二進制數(shù)，那么輸入數(shù)據(jù)有 216216216=2482.81014種陳列組合。.6.2 軟件測試的方法 假設(shè)每測試一次需求1毫秒，測試終了這些陳列組合的各

19、種情況需求一萬年，另外還需測試不合法的輸入情況，實踐上不能夠窮盡一切組合情況。因此，普通的軟件測試是有限測試。 Alpha()測試：通用軟件產(chǎn)品為了征集用戶的意見，在開發(fā)者的場所，由用戶進展的測試，記錄用戶發(fā)現(xiàn)的錯誤和問題。.6.2 軟件測試的方法 Beta()測試：在一個或多個用戶本人的場所，由最終用戶進展，并記錄在測試中遇到的一切問題和想法。 重要的通用軟件產(chǎn)品，大多經(jīng)過和測試。.6.3 測試方案與測試用例 設(shè)計測試方案是軟件測試中的關(guān)鍵問題。測試方案包括預(yù)定要測試的功能、構(gòu)造，應(yīng)該要輸入的測試數(shù)據(jù)和輸入這些數(shù)據(jù)后預(yù)期的結(jié)果測試用例。測試用例的設(shè)計是其中較困難的問題，不同的測試數(shù)據(jù)發(fā)現(xiàn)程序

20、錯誤的才干差別很大，為了提高測試效率，降低測試本錢，應(yīng)該選用高效的測試數(shù)據(jù)。由于不能夠進展窮盡測試，選用少量高效的測試數(shù)據(jù)，進展盡能夠完備的測試就顯得更重要了。.6.3 測試方案與測試用例 設(shè)計測試方案的根本目的是，確定一組最有能夠發(fā)現(xiàn)某個或某類錯誤的測試用例。有多種測試技術(shù)，同一種測試技術(shù)在不同的運用場所效果能夠相差很大，因此，通常需求結(jié)合運用多種測試技術(shù)來設(shè)計測試用例。 通常的做法是用黑盒法設(shè)計根本測試方案，再用白盒法補充一些方案。. 6.4 白盒法邏輯覆蓋 白盒法也稱邏輯驅(qū)動法邏輯覆蓋法，從軟件的詳細邏輯構(gòu)造和執(zhí)行途徑出發(fā)，設(shè)計測試用例。具有語句覆蓋、斷定覆蓋分支覆蓋、條件覆蓋、斷定/條

21、件覆蓋、途徑覆蓋、條件組合覆蓋、點覆蓋、邊覆蓋，下面以一個經(jīng)典例子分別引見： 設(shè)有某個算法片段的程序流程圖如下：. 6.4 白盒法邏輯覆蓋圖6-5程序段程序框圖 (A1)AND(B=0) (A=2)OR(X1) X=X/AX=X+1abcdeTT. 6.4 白盒法邏輯覆蓋該程序片段有四條途徑：abd,acd,ace,aed。(1) 語句覆蓋：選擇足夠的測試用例使程序中每條語句至少執(zhí)行一次。 為了使每個語句都執(zhí)行一次，程序的執(zhí)行途徑只需經(jīng)過a、b、c、d、e各點即可。假設(shè)選擇途徑ace，那么能保證程序中的語句都執(zhí)行一次。. 6.4 白盒法邏輯覆蓋 例如，選擇測試用例：A=2,B=0,X=3,預(yù)期

22、的結(jié)果為：A=2,B=0,X=2.5； 但是，許多途徑得不到測試，這種測試很不充分。 圖6-5程序段程序框圖 (A1)AND(B=0) (A=2)OR(X1) X=X/AX=X+1abcdeTT. 6.4 白盒法邏輯覆蓋(2) 斷定覆蓋也稱分支覆蓋：斷定是一個邏輯表達式的結(jié)果。選擇足夠的測試用例，使程序中每個斷定至少都能獲得一次“真值和一次“假值，從而使程序的每個斷定的每個分支至少都執(zhí)行一次。 例如，選擇測試用例：A=3,B=0,X=3,預(yù)期結(jié)果為：A=3,B=0,X=1; 選擇測試用例：A=2,B=1,X=0,預(yù)期結(jié)果為：A=2,B=1,X=1;. 6.4 白盒法邏輯覆蓋 這組測試用例覆蓋了

23、途徑acd和aed ,滿足了斷定覆蓋要求。斷定覆蓋比語句覆蓋強，但是斷定覆蓋只關(guān)懷整個斷定表達式的值，對程序邏輯的覆蓋程度依然不高，如上面的測試，只覆蓋了全部途徑的一半途徑。 . 6.4 白盒法邏輯覆蓋(3) 條件覆蓋：條件為邏輯表達式中的各個邏輯分量。選擇足夠的測試用例，使得程序斷定中的每個條件都能獲得各種能夠的結(jié)果。 如圖6-5中，有四個條件：A1,B=0,A=2,X1,每個條件能夠出現(xiàn)的各種結(jié)果為：a點出現(xiàn)：A1,A1; B=0,B0; b點出現(xiàn)：A=2,A2; X1,X1;. 6.4 白盒法邏輯覆蓋 例如，選擇測試用例：A=2,B=0,X=4,預(yù)期結(jié)果為：A=2,B=0,X=3; 選擇

24、測試用例：A=1,B=1,X=1,預(yù)期結(jié)果為：A=1,B=1,X=1; 這組測試用例覆蓋了途徑acd，aed 和abd ,滿足了條件覆蓋要求。條件覆蓋比斷定覆蓋強，它使斷定表達式中的每個條件都獲得了兩個不同的結(jié)果。. 6.4 白盒法邏輯覆蓋 但也有相反的情況，每個條件雖然獲得兩個不同的結(jié)果，斷定表達式卻一直只取一個值，例如：取數(shù)據(jù)：A=2,B=0,X=1; 滿足A1,B=0,A=2,X1的條件，執(zhí)行途徑ace；A=1,B=1,X=2; 滿足A1,B0,A2,X1的條件，執(zhí)行途徑abd; 滿足了條件覆蓋，卻不滿足斷定覆蓋，第二個斷定表達式的值總為真。 . 6.4 白盒法邏輯覆蓋(4) 斷定/條件

25、覆蓋：選擇足夠的測試用例，使得程序斷定中的每個條件都能獲得各種能夠的結(jié)果，并且使得每個斷定都獲得各種能夠的結(jié)果。 例如，選擇測試用例：A=2,B=0,X=4,預(yù)期結(jié)果為：A=2,B=0,X=3; 選擇測試用例：A=1,B=1,X=1,預(yù)期結(jié)果為：A=1,B=1,X=1;. 6.4 白盒法邏輯覆蓋 這組測試用例覆蓋了途徑acd，aed 和abd ,滿足了斷定/條件覆蓋要求。但它也并不比條件覆蓋更強。. 6.4 白盒法邏輯覆蓋5條件組合覆蓋：選擇足夠的測試用例，使得程序斷定中的條件的各種能夠組合都至少出現(xiàn)一次。 如圖6-5中，需求測試覆蓋條件組合的下述八種情況： 1) A1,B=0 ; 2) A1

26、,B0; 3) A1,B=0; 4A1,B0; 5) A=2,X1 6) A=2,X1 8) A2,X1. 6.4 白盒法邏輯覆蓋用A=2,B=0,X=4, 預(yù)期結(jié)果：A=2,B=0,X=3, 覆蓋情況1、5；用A=2,B=1,X=1, 預(yù)期結(jié)果：A=2,B=1,X=2, 覆蓋情況2、6用A=1,B=0,X=2, 預(yù)期結(jié)果：A=1,B=0,X=3, 覆蓋情況 3)、7)用A=1,B=1,C=1, 預(yù)期結(jié)果：A=1,B=1,X=1, 覆蓋情況 4)、8) . 6.4 白盒法邏輯覆蓋 條件組合覆蓋是最強的覆蓋，雖然這四個測試實現(xiàn)了條件組合覆蓋，但并沒有覆蓋每一條途徑，如：途徑acd脫漏了。 以上各

27、種技術(shù)根本上是依次加強的順序，但測試用例的數(shù)量也急劇添加。開銷大，應(yīng)留意權(quán)衡。. 6.4 白盒法邏輯覆蓋(6)點覆蓋：圖論中的點覆蓋定義為：假設(shè)連通圖G的子圖G是連通的，而且包含G的一切節(jié)點，那么稱G是G的點覆蓋。假設(shè)把程序流程圖的每個處置框含一個或多個語句作為一個節(jié)點，就畫出了程序圖。滿足點覆蓋的要求是選取足夠多的測試用例，測試執(zhí)行程序時的途徑，至少經(jīng)過程序圖的每個節(jié)點一次。顯然，點覆蓋的要求和語句覆蓋的要求是一樣的。. 6.4 白盒法邏輯覆蓋 (7)邊覆蓋：圖論中的邊覆蓋定義為：假設(shè)連通圖G的子圖G是連通的，而且包含G的一切邊，那么稱G是G的邊覆蓋。為了滿足邊覆蓋的測試要求，使得程序的執(zhí)行

28、途徑經(jīng)過程序圖中的每一條邊。通常邊覆蓋和斷定覆蓋是一致的。 . 6.4 白盒法邏輯覆蓋 (8)途徑覆蓋：選擇足夠的測試用例，使得程序中的每條能夠組合途徑都至少執(zhí)行一次。假設(shè)程序圖中有環(huán)，那么每個環(huán)至少經(jīng)過一次。它是相當強的邏輯覆蓋規(guī)范，選擇的測試用例更具有代表性，暴露錯誤的才干也更強。 . 6.4 黑盒法邏輯覆蓋 黑盒測試法把程序看成是一個黑盒子，不思索程序內(nèi)部的執(zhí)行過程，著眼于外部特性，在接口上進展測試，僅思索輸入與輸出能否與需求規(guī)格闡明書對應(yīng)起來，輸入能否正確的接納，輸出能否得到正確的結(jié)果。也稱為數(shù)據(jù)驅(qū)動或輸入/輸出驅(qū)動測試，或功能測試。 黑盒法包括等價類劃分、邊境值分析、因果圖法。.6.

29、5.1 等價類劃分 一個理想的測試用例可以單獨發(fā)現(xiàn)某一類錯誤。普通的測試是以輸入數(shù)據(jù)為根底進展的，我們著眼于劃分輸入數(shù)據(jù)值的情況，以便找出有代表性的測試數(shù)據(jù)，減少測試任務(wù)量。.6.5.1 等價類劃分 假設(shè)我們可以把輸入的數(shù)據(jù)域劃分成有限的等價類，用每個等價類的代表值作為測試用例的輸入數(shù)據(jù)進展測試，等價于該類的任何其它值作為設(shè)計用例的輸入數(shù)據(jù)進展的測試。即：假設(shè)等價類中的一個測試用例檢測出程序的一個錯誤，那么這一等價類的其他測試用例也能發(fā)現(xiàn)同樣的錯誤。相反，假設(shè)測不出錯誤，那么該等價類的其他測試用例，也測不出錯誤。 .6.5.1 等價類劃分等價類劃分的原那么： 1假設(shè)規(guī)定了輸入值的取值范圍，那么

30、可劃分出一個有效的等價類輸入值在此范圍內(nèi)，兩個無效的等價類輸入值小于最小值、或大于最大值； 2假設(shè)規(guī)定了輸入數(shù)據(jù)的個數(shù)，那么類似地也可以劃分出一個有效等價類和兩個無效等價類。.6.5.1 等價類劃分 3假設(shè)規(guī)定了輸入數(shù)據(jù)的一組值，而且程序?qū)Σ煌斎胫底霾煌靥幹?，那么每個允許的值是一個有效的等價類，還有一個無效的等價類任何一個不允許的輸入值； 4假設(shè)規(guī)定了輸入數(shù)據(jù)必需遵照的規(guī)那么，那么可以劃分出一個有效的等價類符合規(guī)那么的輸入數(shù)據(jù)和假設(shè)干個無效的等價類從各種不同角度違反規(guī)那么；.6.5.1 等價類劃分 5假設(shè)輸入數(shù)據(jù)為整型，那么可以劃分出正整數(shù)、零和負整數(shù)三個有效類； 6假設(shè)程序處置的對象是表

31、格，那么應(yīng)該運用空表、以及含有一項或多項的表進展測試。 以上列舉了能夠情況的一部分，還可以根據(jù)閱歷進展劃分。上面是針對輸入數(shù)據(jù)而言，對輸出數(shù)據(jù)也可類似劃分。.6.5.1 等價類劃分 根據(jù)等價類劃分來設(shè)計測試方案時主要運用下面的兩個步驟先劃分好等價類：1設(shè)計一個新的測試方案，盡能夠多的覆蓋尚未被覆蓋的有效等價類；反復(fù)這一步驟直到一切有效等價類都被覆蓋為止；2設(shè)計一個新的測試方案，使它覆蓋一個，而且只覆蓋一個尚未被覆蓋的無效等價類，反復(fù)這一步驟直到一切無效等價類都被覆蓋為止；.6.5.2 邊境值分析 閱歷闡明，程序在處置邊境情況時最容易發(fā)生錯誤忽略邊境數(shù)據(jù)域問題。所以選取略微高于或低于邊境值的數(shù)據(jù)

32、進展測試。啟發(fā)規(guī)那么如下：1輸入條件規(guī)定取值范圍或輸入個數(shù)時，取邊境值的上下值或個數(shù)的上下界設(shè)計測試用例；2假設(shè)輸出條件規(guī)定取值范圍，取邊境上下浮動值作為測試數(shù)據(jù)；.6.5.2 邊境值分析3規(guī)格闡明中提出輸入輸出有序集，取有序集的第一個和最后一個元素作為測試數(shù)據(jù)；4分析規(guī)格闡明，找出其他能夠存在的邊境條件，取其上下浮動值作為測試數(shù)據(jù)。.6.5.3 因果圖法 因果圖可以提供邏輯條件和相應(yīng)動作之間的簡約邏輯關(guān)系表示。 因果圖的運用可以分為如下步驟： 1列出模塊的緣由和效果動作，給每個緣由和效果一個標示符； 2把緣由、效果用邏輯符號銜接起來，畫出緣由效果圖，標出約束條件；.6.5.3 因果圖法 3緣

33、由相對于斷定表中的條件，效果相對于斷定表中的動作，把緣由效果圖轉(zhuǎn)換為斷定表； 4把斷定表中右邊部分的每一列表示的情況轉(zhuǎn)換為測試用例。 .6.5.3 錯誤推測法 錯誤推測法在很大程度上依托人的直覺和閱歷進展。有時利用其他測試方法測試后的程序表現(xiàn)，推測應(yīng)該如何進展下一步的測試。也可利用程序錯誤清單作為推測測試的根據(jù)。.6.5.3 綜合測試戰(zhàn)略 對軟件系統(tǒng)的實踐測試，往往利用多種測試方法進展，構(gòu)成綜合測試戰(zhàn)略。通常是用黑盒法設(shè)計一些根本的測試用例，再用白盒法補充設(shè)計一些必要的測試用例，黑盒、白盒法相結(jié)合灰盒法進展測試。詳細戰(zhàn)略為：(1)在任何情況下 都應(yīng)該運用邊境值分析法進展測試。閱歷闡明這種方法設(shè)

34、計出的測試用例，暴露程序錯誤的才干最強，應(yīng)該包括輸入和輸出數(shù)據(jù)的邊境情況；.6.5.3 綜合測試戰(zhàn)略2必要時用等價類劃分法補充測試用例；3必要時用錯誤推測法補充測試用例；4對照程序邏輯，檢查設(shè)計測試用例，可根據(jù)對程序的可靠性要求采用不同的邏輯覆蓋規(guī)范，補充測試用例，到達邏輯覆蓋規(guī)范；5假設(shè)有輸入條件的組合，就應(yīng)從輸入條件及其組合開場測試。.6.5.3 綜合測試戰(zhàn)略 對于集成測試可以運用模塊的自頂向下的結(jié)合方式，也可以運用自底向上的結(jié)合方式進展測試，還可用輔助測試工具協(xié)助測試。 軟件系統(tǒng)測試完后，應(yīng)對軟件配置進展復(fù)查，確保軟件的有關(guān)文檔資料的完好齊全，分類編目，便于軟件的維護和修正。審查的資料包

35、括：用戶所需的文檔用戶手冊、操作手冊；設(shè)計文檔；源程序；測試文檔測試闡明書，測試報告及其它闡明等。.6.6 軟件調(diào)試 程序測試只是發(fā)現(xiàn)錯誤的跡象，并不清楚詳細錯誤的位置和產(chǎn)生的緣由，應(yīng)該立刻進展調(diào)試，即糾正錯誤的任務(wù)，它包含兩方面任務(wù)： 1確定程序中錯誤的詳細位置和性質(zhì)； 2修正錯誤。 調(diào)試必需由程序員本人來進展。.6.6 軟件調(diào)試 調(diào)試技術(shù)有以下類別： 輸出存儲器內(nèi)容：發(fā)現(xiàn)問題時，設(shè)法保管現(xiàn)場信息，把一切存放器和主存中相關(guān)部分的內(nèi)容打印出來進展分析研討。 打印關(guān)鍵變量的動態(tài)內(nèi)容：為獲得關(guān)鍵變量的動態(tài)值，在程序中插入規(guī)范的打印語句，檢驗在某個事件發(fā)生后變量能否按預(yù)期的要求進展變化。.6.6 軟

36、件調(diào)試 利用調(diào)試工具跟蹤程序的動態(tài)變化，單步跟蹤，檢查主存和存放器內(nèi)容，檢查重要變量內(nèi)容，檢查能否進入預(yù)定的程序分支，設(shè)置斷點，當程序運轉(zhuǎn)到檢查的重點位置，暫停程序運轉(zhuǎn)，察看主要的變化信息，分析程序形狀，決議繼續(xù)跟蹤還是停頓執(zhí)行，為程序的調(diào)試提供了有力的手段。 調(diào)試的戰(zhàn)略有：試探法，回溯法，對分查找法、歸納法、演繹法?？筛鶕?jù)個人閱歷和詳細情況靈敏運用。.6.7 軟件質(zhì)量控制 高質(zhì)量是產(chǎn)品得以存在和生長的前提，軟件工程的主要目的之一就是要獲得高質(zhì)量的軟件。在軟件工程誕生之前，由于計算機設(shè)備條件的限制，計算機開展的早期，內(nèi)存容量有限，執(zhí)行速度不高，當時的軟件設(shè)計特別強調(diào)效率。隨著技術(shù)的開展，軟件規(guī)

37、模的擴展，軟件復(fù)雜性的添加，人們對軟件質(zhì)量的觀念早已發(fā)生了很大變化，更強調(diào)軟件的全面質(zhì)量評價。 .6.7 .1軟件質(zhì)量評價 不同的人員對軟件質(zhì)量關(guān)懷的著重點不同，反映了對軟件質(zhì)量的不同要求。 用戶關(guān)懷軟件產(chǎn)品能否滿足規(guī)定的功能和性能要求，軟件運轉(zhuǎn)能否可靠，能否易于學習掌握，易于運用，能否有較高的運轉(zhuǎn)效率，能否可以從一個環(huán)境移植到另一個環(huán)境等問題。 軟件開發(fā)人員既要開發(fā)滿足質(zhì)量要求的最終產(chǎn)品，又要留意軟件開發(fā)過程中的每個階段的質(zhì)量。.6.7 .1軟件質(zhì)量評價 開發(fā)人員常把產(chǎn)品外部特性用軟件內(nèi)部質(zhì)量構(gòu)造來對應(yīng)。 維護人員要求軟件系統(tǒng)、軟件文檔明晰、軟件文檔與源代碼一致，軟件易于修正、易于維護。 管

38、理人員關(guān)懷的是軟件的總體質(zhì)量特性，在軟件質(zhì)量與開發(fā)工期之間進展折中選擇；.6.7 .1軟件質(zhì)量評價 但影響軟件質(zhì)量的各要素之間是相互聯(lián)絡(luò)、甚至是相互矛盾的，如追求可靠性要犧牲一定的時間和空間效率為代價，要求軟件不但能在合法的輸入情況下正確地運轉(zhuǎn)，而且還應(yīng)該可以平安地排除非法的入侵和處置不測的事件。 普通要求軟件具有良好的構(gòu)造，齊全的文檔資料，易于閱讀和了解，便于修正和維護，內(nèi)部層次構(gòu)造明晰、人機界面友好，用戶樂于運用。.6.7 .1軟件質(zhì)量評價 國際規(guī)范化機構(gòu)建議，軟件質(zhì)量模型由三層組成： 高層：軟件質(zhì)量需求評價準那么SQRC； 中層：軟件質(zhì)量設(shè)計評價準那么SQDC； 低層：軟件質(zhì)量度量評價準

39、那么SQMC；.6.7 .1軟件質(zhì)量評價多數(shù)軟件同行公認的普通質(zhì)量按如下特性進展評價：正確性：功能度在預(yù)定的環(huán)境下，軟件實現(xiàn)的功能到達設(shè)計規(guī)范和滿足用戶要求的程度；可靠性：軟件在給定的條件下和規(guī)定的時間內(nèi)完成預(yù)定職能的概率；即堅持其性能的才干相關(guān)的屬性；易用性：用戶學習軟件、運轉(zhuǎn)操作軟件、預(yù)備輸入、了解輸出所做的努力程度，根據(jù)用戶評價運用軟件所需進展努力的程度相關(guān)的屬性；.6.7 .1軟件質(zhì)量評價效率：在規(guī)定的條件下，軟件表現(xiàn)的性能級別與所運用資源總量包括人員、時間、財力關(guān)系的屬性；可維護性：軟件修正難易程度的一組屬性；可移植性；可轉(zhuǎn)換性指一個軟件從一個環(huán)境轉(zhuǎn)換到另一個環(huán)境運轉(zhuǎn)的才干的相關(guān)屬性

40、。 以上六條是常見的評價方面。.6.7 .1軟件質(zhì)量評價 還有其它方面的特性來評價軟件質(zhì)量，衡量總體質(zhì)量的優(yōu)劣程度。如：強壯性：在硬件發(fā)生缺點、輸入數(shù)據(jù)無效或操作失誤等不測情況下，系統(tǒng)不至于解體，能作出適當呼應(yīng)的程度；完好性：平安性對未經(jīng)授權(quán)的人運用軟件或數(shù)據(jù)的企圖，系統(tǒng)可以控制制止的程度；.6.7 .1軟件質(zhì)量評價可測試性：系統(tǒng)容易測試的程度；可再用性：在其他運用中該軟件可以被再次運用的程度或范圍；可互連性：把軟件系統(tǒng)與其他系統(tǒng)銜接起來的才干。 除了定性評價外，人們逐漸注重軟件的質(zhì)量度量，它是在系統(tǒng)運轉(zhuǎn)過程中進展動態(tài)檢測，不斷搜集軟件性能方面的數(shù)據(jù)，利用軟件質(zhì)量模型如軟件可靠性模型、軟件復(fù)雜度模型等進展分析和評價。.6.7 .2軟件質(zhì)量控制 做好軟件質(zhì)量的控制，就要加強軟件生命期各個階段的軟件質(zhì)量保證，需求做好如下幾方面的軟件管理任務(wù)： 1