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

軟件測試及軟件質(zhì)量控制第1頁，課件共100頁，創(chuàng)作于2023年2月軟件系統(tǒng)的開發(fā)過程中，軟件測試占據(jù)著重要地位。盡管人們采取了多種保證軟件質(zhì)量的措施，由于軟件系統(tǒng)的客觀復雜性，人們的主觀認識不可能完全符合客觀實際，完美無缺，每個階段的技術審查也不可能毫無遺漏地查出和糾正所有的設計和分析上的錯誤，在軟件生命周期的各個階段，都不可避免地會產(chǎn)生差錯，這些差錯遲早會在軟件的生產(chǎn)和使用過程中暴露出來。第2頁，課件共100頁，創(chuàng)作于2023年2月軟件工程實踐的經(jīng)驗表明，發(fā)現(xiàn)軟件的時刻越晚，改正這些錯誤所花費的代價也越高，如果在軟件投入使用之前沒有發(fā)現(xiàn)和糾正軟件的大部分錯誤，人們付出的代價會更高，往往會造成惡劣的后果。從廣義上來說，軟件測試工作散布在軟件生命周期的各個開發(fā)階段，人們認識到，軟件測試是保證軟件質(zhì)量的主要手段，各階段的評審工作和驗證工作，均是廣義概念上的測試工作。而主要的測試是在編碼和測試這兩個階段進行的。因此，狹義的軟件測試就是程序測試。第3頁，課件共100頁，創(chuàng)作于2023年2月6.1軟件測試基本概念

G.J.Myers給出了關于測試的一些規(guī)則，被軟件工程領域認可：（1）測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程；（2）好的測試方案極有可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤；（3）成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤。第4頁，課件共100頁，創(chuàng)作于2023年2月6.1軟件測試基本概念這些規(guī)則，實際上是軟件測試的狹義概念——程序測試。狹義的軟件測試：測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。是根據(jù)軟件開發(fā)的各個階段的說明和程序的內(nèi)部結構而精心設計的一批測試用例（有輸入數(shù)據(jù)及預期的結果），并利用這些測試用例執(zhí)行程序及發(fā)現(xiàn)錯誤的過程。第5頁，課件共100頁，創(chuàng)作于2023年2月6.1軟件測試基本概念廣義的軟件測試是對軟件計劃、軟件系統(tǒng)分析、軟件設計、軟件編碼進行的查錯活動，包括代碼執(zhí)行和人工審查活動，測試的目的是找出軟件生命周期的各個階段的錯誤，有利于以后進行修改和糾正。但測試本身不修正錯誤，調(diào)試才會修正錯誤。即找錯的活動是測試；分析錯誤的性質(zhì)與位置，進行糾錯的活動是調(diào)試，保證算法的正確實現(xiàn)。軟件測試與程序測試都是查找錯誤的活動，差別在于查找錯誤的范圍不同。第6頁，課件共100頁，創(chuàng)作于2023年2月6.1軟件測試基本概念由于測試的目標是暴露程序的錯誤，從心理學角度看，由設計者自己進行測試是不恰當?shù)?，設計小組和測試小組應該分別設立，有利于進行客觀和公正的軟件測試。測試是有限的，由于通常的測試過程不可能窮盡一切情況，即使經(jīng)過了嚴格的測試之后，仍然可能存在沒有被發(fā)現(xiàn)的錯誤隱藏在程序中，不能證明程序中沒有錯誤。第7頁，課件共100頁，創(chuàng)作于2023年2月6.1軟件測試基本概念因此，測試僅僅有可能找出程序的錯誤，測試不能證明程序是正確的。軟件工程中所有其它階段都是“建設性”的，軟件工程師力圖從抽象概念出發(fā)，逐步設計出具體的軟件系統(tǒng)，而測試人員的工作表面上看卻是“破壞性”的，竭力證明軟件中含有錯誤，不能按預定要求正確工作。凡是進行對比的方式均可理解為測試驗證。第8頁，課件共100頁，創(chuàng)作于2023年2月6.1.2軟件測試的對象軟件測試應該貫穿于軟件生命期的各個階段，各階段的工作是相互銜接、相互影響的，前一階段發(fā)生的問題自然要影響到下一階段的工作。為了把握各個環(huán)節(jié)的正確性，人們需要進行各種確認和驗證工作。軟件確認是廣義上的軟件測試，它是企圖證明軟件在一個給定的外部環(huán)境中軟件的邏輯正確性的一系列活動和過程，如需求說明書的確認、程序的確認等。第9頁，課件共100頁，創(chuàng)作于2023年2月6.1.2軟件測試的對象程序的確認又分為靜態(tài)確認與動態(tài)確認。靜態(tài)確認一般不在計算機上執(zhí)行程序，而是通過程序正確性證明、靜態(tài)分析或人工分析來確認程序的正確性；動態(tài)確認主要通過動態(tài)分析和動態(tài)測試，用執(zhí)行程序的過程來檢查執(zhí)行的狀態(tài)，確認程序是否有問題；第10頁，課件共100頁，創(chuàng)作于2023年2月6.1.2軟件測試的對象正確性證明主要是企圖繞過復雜的測試，直接證明程序的正確性。如程序的輸入輸出斷言法。設程序段為S，其前斷言為P，后斷言為R。如果執(zhí)行S以前P為真，則執(zhí)行S后R也為真，則證明S是正確的，記為{P}S{R}。第11頁，課件共100頁，創(chuàng)作于2023年2月6.1.2軟件測試的對象任何程序總可以分成S1、S2、…Sn個結點，對應的斷言為R1、R2、…、Rn，起初R1為輸入斷言，R2為輸出斷言，也是下一個輸入斷言，…

Rn為最后的輸出斷言，我們總可以，將S1、S2、…Sn逐個證明，自頂向下或自底向上都可證明程序的正確性，該分支已發(fā)展為計算機代數(shù)學；第12頁，課件共100頁，創(chuàng)作于2023年2月6.1.2軟件測試的對象軟件驗證也屬于廣義上的軟件測試，它試圖證明在軟件生命期的各個階段、各階段的邏輯協(xié)調(diào)性、完備性和正確性。包括系統(tǒng)分析員理解用戶要求的正確性、表達的正確性、設計人員對需求規(guī)格說明理解的正確性、設計與設計表達的正確性、程序編碼的正確性和運行軟件程序時輸入的正確性、運行結果的正確性等，運行結果與用戶預期的結果是否一致等，這說明任何一個環(huán)節(jié)上發(fā)生了問題都可能在軟件測試中表現(xiàn)出來。第13頁，課件共100頁，創(chuàng)作于2023年2月6.1.3測試信息流將測試的過程用數(shù)據(jù)流圖表示，可得測試信息流如圖6-1所示。（至軟件配置）軟件配置1測試結果2錯誤3修正的軟件測試配置測試結果測試工具測試評價調(diào)試正確

預測結果出錯率4數(shù)據(jù)可靠性分析圖6-1測試信息流

第14頁，課件共100頁，創(chuàng)作于2023年2月6.1.3測試信息流1.測試過程需要三類輸入：（1）軟件配置：包括軟件開發(fā)文檔（用戶文檔、需求規(guī)格說明、軟件設計說明、源程序代碼）、目標執(zhí)行程序、數(shù)據(jù)結構；（2）測試配置：包括測試計劃、測試用例、測試驅(qū)動程序等；實際上在整個軟件開發(fā)過程中，測試配置只是軟件配置的一個子集；第15頁，課件共100頁，創(chuàng)作于2023年2月（3）測試工具：為提高軟件測試效率，使用測試工具為測試工作服務；如：測試數(shù)據(jù)自動生成程序，靜態(tài)分析程序、動態(tài)分析程序、測試結果分析程序及標準例程測試數(shù)據(jù)庫等。6.1.3測試信息流第16頁，課件共100頁，創(chuàng)作于2023年2月測試之后，對所有測試結果進行分析，將實際測試的結果與預期的結果進行比較。如果發(fā)現(xiàn)出錯的數(shù)據(jù)，則意味著軟件有錯誤，需要糾錯，應進行調(diào)試，確定錯誤的位置和出錯的性質(zhì)，改正這些錯誤，同時修正相關文檔。修正過的文檔一般需經(jīng)過再次測試，直到通過測試為止。6.1.3測試信息流第17頁，課件共100頁，創(chuàng)作于2023年2月通過收集和分析測試結果的有關數(shù)據(jù)，可以建立軟件評估的可靠性模型。如果經(jīng)常出現(xiàn)需要修改設計的嚴重錯誤，那么軟件的質(zhì)量和可靠性就值得懷疑，同時也表明需要進一步測試。相反，如果軟件功能能夠正確完成，出現(xiàn)的錯誤易于修改，那么就可能有兩種評價：6.1.3測試信息流第18頁，課件共100頁，創(chuàng)作于2023年2月一種是軟件的質(zhì)量和可靠性達到可以接受的程度。另一種是所做的測試還不足以發(fā)現(xiàn)軟件的嚴重錯誤。如果得到的評價是沒有發(fā)現(xiàn)錯誤，很有可能測試的配置考慮得不夠充分和細致，軟件仍有潛伏的錯誤，以后改正錯誤需要付出高昂的代價。6.1.3測試信息流第19頁，課件共100頁，創(chuàng)作于2023年2月

2.軟件錯誤可以從不同角度進行分類：（1）從錯誤對程序的影響程度來分：

<1>嚴重性錯誤：嚴重影響程序的運行，甚至不能運行；

<2>一般性錯誤：經(jīng)常影響程序的運行，特殊情況下表現(xiàn)正常；6.1.3測試信息流第20頁，課件共100頁，創(chuàng)作于2023年2月

<3>微小錯誤：一般情況下程序能運行，特殊情況下表現(xiàn)異常；

<4>無影響性錯誤：不影響程序的運行。6.1.3測試信息流第21頁，課件共100頁，創(chuàng)作于2023年2月（2）從開發(fā)過程的轉換環(huán)節(jié)上分：

<1>構造錯誤：編碼實現(xiàn)與設計不一致；

<2>設計錯誤：設計邏輯與說明不一致；

<3>說明書錯誤：說明書與用戶要求不一致；

<4>需求錯誤：不滿足用戶的實際要求；

<5>配置錯誤：軟件配置不滿足實際環(huán)境。6.1.3測試信息流第22頁，課件共100頁，創(chuàng)作于2023年2月（3）從測試結果的表現(xiàn)上分類：

1）功能錯誤：由系統(tǒng)需求分析不完整引起的；

2）結構錯誤：由總體設計的錯誤引起的；

3）過程錯誤：由詳細設計的錯誤引起的；

4）數(shù)據(jù)錯誤：由軟件編碼或詳細設計的錯誤引起的；

5）編碼錯誤：由軟件編碼引起的錯誤；

6）其它錯誤：由文檔和其它系統(tǒng)元素引起的錯誤；6.1.3測試信息流第23頁，課件共100頁，創(chuàng)作于2023年2月6.1.4軟件測試步驟與軟件開發(fā)各階段的關系軟件測試一般分為四個步驟：（1）單元測試（也稱模塊測試）：針對軟件設計的基本單元——程序模塊，進行正確性檢驗的測試工作。目的在于發(fā)現(xiàn)各個模塊內(nèi)部可能存在的各種差錯。單元測試需要從程序內(nèi)部結構出發(fā)設計測試用例，多個模塊可以平行、獨立地進行測試；第24頁，課件共100頁，創(chuàng)作于2023年2月6.1.4軟件測試步驟與軟件開發(fā)各階段的關系（2）集成測試（也稱組裝測試，聯(lián)合測試）：在單元測試的基礎上，將所有模塊按設計要求集成在一起進行測試，以檢驗總體設計中各模塊間的接口設計問題、模塊之間的相互影響、上層模塊存在的各種差錯及全局數(shù)據(jù)結構對系統(tǒng)的影響等方面。第25頁，課件共100頁，創(chuàng)作于2023年2月6.1.4軟件測試步驟與軟件開發(fā)各階段的關系（3）確認測試（也稱驗收測試，有效性測試）：主要檢驗軟件的功能和性能是否與需求說明書中的規(guī)定一致。（4）系統(tǒng)測試：將軟件系統(tǒng)作為一個元素，放入整個實際的計算機系統(tǒng)中，與計算機硬件、其他軟件、使用人員等系統(tǒng)元素結合在一起，在實際使用環(huán)境下進行綜合全面的測試。第26頁，課件共100頁，創(chuàng)作于2023年2月6.1.4軟件測試步驟與軟件開發(fā)各階段的關系前面多次強調(diào)，使用軟件生命期（瀑布模型）模型，軟件開發(fā)過程是一個自頂向下，逐步細化的過程，而軟件測試過程則是與開發(fā)過程相反的次序進行的，是一個自底向上，逐步集成的過程，低一層測試為上一層測試準備測試條件和數(shù)據(jù)驅(qū)動環(huán)境，也包含兩者平行進行測試。第27頁，課件共100頁，創(chuàng)作于2023年2月6.1.4軟件測試步驟與軟件開發(fā)各階段的關系因此，發(fā)現(xiàn)引起錯誤的原因順序也與開發(fā)過程的相次序反，首先對每一個模塊進行單元測試，消除程序模塊內(nèi)部邏輯上和功能上的錯誤和缺陷，再對照軟件設計進行集成測試（有時也叫整體測試），檢測和排除子系統(tǒng)或系統(tǒng)結構上的錯誤，再對照需求進行確認測試（也稱為有效性測試），最后進行系統(tǒng)測試，運行系統(tǒng)，看軟件系統(tǒng)是否滿足功能和性能及其它要求。第28頁，課件共100頁，創(chuàng)作于2023年2月6.1.4軟件測試步驟與軟件開發(fā)各階段的關系需求分析軟件設計軟件編碼確認測試集成測試單元測試系統(tǒng)測試圖6-2軟件測試與軟件開發(fā)過程間的關系第29頁，課件共100頁，創(chuàng)作于2023年2月6.1.4軟件測試步驟與軟件開發(fā)各階段的關系需求分析說明書概要設計說明書詳細設計說明書源程序代碼確認測試集成測試單元測試系統(tǒng)測試圖6-3軟件測試與開發(fā)文檔之間的關系第30頁，課件共100頁，創(chuàng)作于2023年2月6.1.5軟件測試原則（1）將軟件測試貫穿于軟件開發(fā)的各個階段中，在開發(fā)過程中盡早地發(fā)現(xiàn)和預防錯誤，杜絕隱患，提高軟件質(zhì)量；（2）測試用例必須包含輸入數(shù)據(jù)和與之對應的預期輸出結果，精心設計測試用例；（3）測試時應避免設計者檢查自己設計的程序；（4）設計測試用例時，應包括合理的與不合理的輸入條件；第31頁，課件共100頁，創(chuàng)作于2023年2月6.1.5軟件測試原則（5）充分注意測試中出現(xiàn)的錯誤群集現(xiàn)象，若發(fā)現(xiàn)錯誤數(shù)目較多，則可能殘存的錯誤數(shù)目也較多，這種錯誤出現(xiàn)的群集現(xiàn)象，已為許多程序測試實踐所證實；（6）嚴格執(zhí)行測試計劃，以軟件需求說明書為基準設計測試用例，排除測試的隨意性；第32頁，課件共100頁，創(chuàng)作于2023年2月6.1.5軟件測試原則（7）對每一個測試結果做全面檢查，不能遺漏錯誤出現(xiàn)的征兆，軟件修改后要進行回歸測試，即用修改前測試過的測試用例進行測試，再用新的測試用例測試；（8）妥善保存測試計劃、測試用例、出錯統(tǒng)計數(shù)據(jù)和最終分析報告，為維護提供方便。在一個程序段中，還存在著尚未發(fā)現(xiàn)的錯誤概率與已發(fā)現(xiàn)的錯誤數(shù)正相關。第33頁，課件共100頁，創(chuàng)作于2023年2月6.1.5軟件測試原則殘存錯誤的可能性已發(fā)現(xiàn)的錯誤數(shù)圖6-4軟件錯誤的群集現(xiàn)象示意圖第34頁，課件共100頁，創(chuàng)作于2023年2月6.2軟件測試的方法軟件的測試方法很多，不同的出發(fā)點得到不同的測試方法。有：從測試過程來分：靜態(tài)分析法、動態(tài)測試法；從觀察結構的透明性方式來分：白盒法、黑盒法、灰盒法；從獲得測試數(shù)據(jù)形式上分：窮盡法；等價類劃分法；邊界值分析法；第35頁，課件共100頁，創(chuàng)作于2023年2月6.2軟件測試的方法從邏輯分析上分：因果圖法；錯誤推測法；從測試步驟上分：單元測試、集成測試、確認測試、系統(tǒng)測試等；從考察形式上分：功能測試，邏輯測試；第36頁，課件共100頁，創(chuàng)作于2023年2月6.2軟件測試的方法如何測試得更完全、怎樣進行測試用例的設計，是軟件測試中的關鍵技術。無論用哪種方法進行測試，都是設法用較少的測試用例集合測試出程序中較多的潛在錯誤。靜態(tài)分析時，不執(zhí)行程序，可對需求分析說明書、軟件設計說明書、源程序做結構檢查、流圖分析、符號執(zhí)行來分析軟件可能導致的異常情況，找出軟件錯誤。從測試過程來分：靜態(tài)分析法、動態(tài)測試法；第37頁，課件共100頁，創(chuàng)作于2023年2月6.2軟件測試的方法結構檢查是手工分析技術，對需求說明、程序設計、編碼、測試工作進行評議，虛擬地（模擬）執(zhí)行程序，在評議中發(fā)現(xiàn)和檢查錯誤；流圖分析是通過分析流程圖、代碼結構來檢查程序錯誤，便于進行編碼分析和測試結果分析；第38頁，課件共100頁，創(chuàng)作于2023年2月6.2軟件測試的方法符號執(zhí)行是定義符號化數(shù)據(jù)，為程序的每條路徑給出符號表達式，對特定路徑輸入符號，經(jīng)處理輸出符號，判斷程序的行為是否錯誤，這種方法復雜，易出錯，較少使用?；液蟹ㄊ前缀蟹ê秃诤蟹ㄏ嘟Y合使用的方法，僅對重點路徑和程序段用白盒法測試，大部分用黑盒法進行測試。第39頁，課件共100頁，創(chuàng)作于2023年2月6.2軟件測試的方法動態(tài)測試是直接執(zhí)行程序進行測試，包括功能測試、接口測試和結構測試，觀察程序的行為，記錄執(zhí)行的結果，從執(zhí)行結果來分析程序可能出現(xiàn)的錯誤；有些人設想，不管使用那種測試方法，只要對每一種可能發(fā)生的情況都進行測試，能正確通過，就可以得到完全正確的程序。第40頁，課件共100頁，創(chuàng)作于2023年2月6.2軟件測試的方法包含所有可能情況的測試稱為窮盡測試，實際上，通常不可能做到窮盡測試。因為各種輸入數(shù)據(jù)的排列組合情況往往多到無法實際測試完成的程度。如用黑盒法測試三個整數(shù)型的輸入數(shù)據(jù)，如果每個整數(shù)是16位二進制數(shù)，則輸入數(shù)據(jù)有

216×216×216=248≈2.8×1014種排列組合。第41頁，課件共100頁，創(chuàng)作于2023年2月6.2軟件測試的方法

如果每測試一次需要1毫秒，測試完畢這些排列組合的各種情況需要一萬年，另外還需測試不合法的輸入情況，實際上不可能窮盡所有組合情況。因此，一般的軟件測試是有限測試。

Alpha(α)測試：通用軟件產(chǎn)品為了征集用戶的意見，在開發(fā)者的場所，由用戶進行的測試，記錄用戶發(fā)現(xiàn)的錯誤和問題。第42頁，課件共100頁，創(chuàng)作于2023年2月6.2軟件測試的方法Beta(β)測試：在一個或多個用戶自己的場所，由最終用戶進行，并記錄在測試中遇到的所有問題和想法。重要的通用軟件產(chǎn)品，大多經(jīng)過α和β測試。第43頁，課件共100頁，創(chuàng)作于2023年2月6.3測試方案與測試用例設計測試方案是軟件測試中的關鍵問題。測試方案包括預定要測試的功能、結構，應該要輸入的測試數(shù)據(jù)和輸入這些數(shù)據(jù)后預期的結果——測試用例。測試用例的設計是其中較困難的問題，不同的測試數(shù)據(jù)發(fā)現(xiàn)程序錯誤的能力差別很大，為了提高測試效率，降低測試成本，應該選用高效的測試數(shù)據(jù)。因為不可能進行窮盡測試，選用少量高效的測試數(shù)據(jù)，進行盡可能完備的測試就顯得更重要了。第44頁，課件共100頁，創(chuàng)作于2023年2月6.3測試方案與測試用例設計測試方案的基本目標是，確定一組最有可能發(fā)現(xiàn)某個或某類錯誤的測試用例。有多種測試技術，同一種測試技術在不同的應用場合效果可能相差很大，因此，通常需要聯(lián)合使用多種測試技術來設計測試用例。通常的做法是用黑盒法設計基本測試方案，再用白盒法補充一些方案。第45頁，課件共100頁，創(chuàng)作于2023年2月

6.4白盒法（邏輯覆蓋）白盒法也稱邏輯驅(qū)動法（邏輯覆蓋法），從軟件的具體邏輯結構和執(zhí)行路徑出發(fā)，設計測試用例。具有語句覆蓋、判定覆蓋（分支覆蓋）、條件覆蓋、判定/條件覆蓋、路徑覆蓋、條件組合覆蓋、點覆蓋、邊覆蓋，下面以一個經(jīng)典例子分別介紹：設有某個算法片段的程序流程圖如下：第46頁，課件共100頁，創(chuàng)作于2023年2月

6.4白盒法（邏輯覆蓋）圖6-5程序段程序框圖

(A>1)AND(B=0)(A=2)OR(X>1)X=X/AX=X+1abcdeTT第47頁，課件共100頁，創(chuàng)作于2023年2月

6.4白盒法（邏輯覆蓋）該程序片段有四條路徑：abd,acd,ace,aed。(1)語句覆蓋：選擇足夠的測試用例使程序中每條語句至少執(zhí)行一次。為了使每個語句都執(zhí)行一次，程序的執(zhí)行路徑只需經(jīng)過a、b、c、d、e各點即可。如果選擇路徑ace，則能保證程序中的語句都執(zhí)行一次。第48頁，課件共100頁，創(chuàng)作于2023年2月

6.4白盒法（邏輯覆蓋）

例如，選擇測試用例：A=2,B=0,X=3,預期的結果為：A=2,B=0,X=2.5；但是，許多路徑得不到測試，這種測試很不充分。圖6-5程序段程序框圖

(A>1)AND(B=0)(A=2)OR(X>1)X=X/AX=X+1abcdeTT第49頁，課件共100頁，創(chuàng)作于2023年2月

6.4白盒法（邏輯覆蓋）(2)判定覆蓋（也稱分支覆蓋）：判定是一個邏輯表達式的結果。選擇足夠的測試用例，使程序中每個判定至少都能獲得一次“真”值和一次“假”值，從而使程序的每個判定的每個分支至少都執(zhí)行一次。例如，選擇測試用例：A=3,B=0,X=3,預期結果為：A=3,B=0,X=1;

選擇測試用例：A=2,B=1,X=0,預期結果為：A=2,B=1,X=1;第50頁，課件共100頁，創(chuàng)作于2023年2月

6.4白盒法（邏輯覆蓋）

這組測試用例覆蓋了路徑acd和aed,滿足了判定覆蓋要求。判定覆蓋比語句覆蓋強，但是判定覆蓋只關心整個判定表達式的值，對程序邏輯的覆蓋程度仍然不高，如上面的測試，只覆蓋了全部路徑的一半路徑。第51頁，課件共100頁，創(chuàng)作于2023年2月

6.4白盒法（邏輯覆蓋）(3)條件覆蓋：條件為邏輯表達式中的各個邏輯分量。選擇足夠的測試用例，使得程序判定中的每個條件都能獲得各種可能的結果。如圖6-5中，有四個條件：A>1,B=0,A=2,X>1,每個條件可能出現(xiàn)的各種結果為：a點出現(xiàn)：A>1,A≤1;B=0,B≠0;b點出現(xiàn)：A=2,A≠2;X>1,X≤1;第52頁，課件共100頁，創(chuàng)作于2023年2月

6.4白盒法（邏輯覆蓋）

例如，選擇測試用例：A=2,B=0,X=4,預期結果為：A=2,B=0,X=3;

選擇測試用例：A=1,B=1,X=1,預期結果為：A=1,B=1,X=1;

這組測試用例覆蓋了路徑acd，aed和abd,滿足了條件覆蓋要求。條件覆蓋比判定覆蓋強，它使判定表達式中的每個條件都取得了兩個不同的結果。第53頁，課件共100頁，創(chuàng)作于2023年2月

6.4白盒法（邏輯覆蓋）

但也有相反的情況，每個條件雖然取得兩個不同的結果，判定表達式卻始終只取一個值，例如：取數(shù)據(jù)：A=2,B=0,X=1;滿足A>1,B=0,A=2,X≤1的條件，執(zhí)行路徑ace；A=1,B=1,X=2;滿足A≤1,B≠0,A≠2,X>1的條件，執(zhí)行路徑abd;

滿足了條件覆蓋，卻不滿足判定覆蓋，第二個判定表達式的值總為真。第54頁，課件共100頁，創(chuàng)作于2023年2月

6.4白盒法（邏輯覆蓋）(4)判定/條件覆蓋：選擇足夠的測試用例，使得程序判定中的每個條件都能獲得各種可能的結果，并且使得每個判定都取得各種可能的結果。例如，選擇測試用例：A=2,B=0,X=4,預期結果為：A=2,B=0,X=3;

選擇測試用例：A=1,B=1,X=1,預期結果為：A=1,B=1,X=1;第55頁，課件共100頁，創(chuàng)作于2023年2月

6.4白盒法（邏輯覆蓋）

這組測試用例覆蓋了路徑acd，aed和abd,滿足了判定/條件覆蓋要求。但它也并不比條件覆蓋更強。第56頁，課件共100頁，創(chuàng)作于2023年2月

6.4白盒法（邏輯覆蓋）（5）條件組合覆蓋：選擇足夠的測試用例，使得程序判定中的條件的各種可能組合都至少出現(xiàn)一次。如圖6-5中，需要測試覆蓋條件組合的下述八種情況：

1)A>1,B=0;2)A>1,B≠0;3)A≤1,B=0;4）A≤1,B≠0;5)A=2,X>16)A=2,X<=17)A≠2,X>18)A≠2,X≤1第57頁，課件共100頁，創(chuàng)作于2023年2月

6.4白盒法（邏輯覆蓋）用A=2,B=0,X=4,預期結果：A=2,B=0,X=3,覆蓋情況1）、5）；用A=2,B=1,X=1,預期結果：A=2,B=1,X=2,覆蓋情況2）、6）用A=1,B=0,X=2,預期結果：A=1,B=0,X=3,覆蓋情況3)、7)用A=1,B=1,C=1,預期結果：A=1,B=1,X=1,覆蓋情況4)、8)第58頁，課件共100頁，創(chuàng)作于2023年2月

6.4白盒法（邏輯覆蓋）

條件組合覆蓋是最強的覆蓋，雖然這四個測試實現(xiàn)了條件組合覆蓋，但并沒有覆蓋每一條路徑，如：路徑acd遺漏了。以上各種技術基本上是依次增強的順序，但測試用例的數(shù)量也急劇增加。開銷大，應注意權衡。第59頁，課件共100頁，創(chuàng)作于2023年2月

6.4白盒法（邏輯覆蓋）(6)點覆蓋：圖論中的點覆蓋定義為：如果連通圖G的子圖G’是連通的，而且包含G的所有節(jié)點，則稱G’是G的點覆蓋。如果把程序流程圖的每個處理框（含一個或多個語句）作為一個節(jié)點，就畫出了程序圖。滿足點覆蓋的要求是選取足夠多的測試用例，測試執(zhí)行程序時的路徑，至少經(jīng)過程序圖的每個節(jié)點一次。顯然，點覆蓋的要求和語句覆蓋的要求是相同的。第60頁，課件共100頁，創(chuàng)作于2023年2月

6.4白盒法（邏輯覆蓋）(7)邊覆蓋：圖論中的邊覆蓋定義為：如果連通圖G的子圖G’是連通的，而且包含G的所有邊，則稱G’是G的邊覆蓋。為了滿足邊覆蓋的測試要求，使得程序的執(zhí)行路徑經(jīng)過程序圖中的每一條邊。通常邊覆蓋和判定覆蓋是一致的。

第61頁，課件共100頁，創(chuàng)作于2023年2月

6.4白盒法（邏輯覆蓋）

(8)路徑覆蓋：選擇足夠的測試用例，使得程序中的每條可能組合路徑都至少執(zhí)行一次。（如果程序圖中有環(huán)，則每個環(huán)至少經(jīng)過一次。）它是相當強的邏輯覆蓋標準，選擇的測試用例更具有代表性，暴露錯誤的能力也更強。第62頁，課件共100頁，創(chuàng)作于2023年2月

6.4黑盒法（邏輯覆蓋）黑盒測試法把程序看成是一個黑盒子，不考慮程序內(nèi)部的執(zhí)行過程，著眼于外部特性，在接口上進行測試，僅考慮輸入與輸出能否與需求規(guī)格說明書對應起來，輸入能否正確的接收，輸出能否得到正確的結果。也稱為數(shù)據(jù)驅(qū)動或輸入/輸出驅(qū)動測試，或功能測試。黑盒法包括等價類劃分、邊界值分析、因果圖法。第63頁，課件共100頁，創(chuàng)作于2023年2月6.5.1等價類劃分一個理想的測試用例能夠獨自發(fā)現(xiàn)某一類錯誤。一般的測試是以輸入數(shù)據(jù)為基礎進行的，我們著眼于劃分輸入數(shù)據(jù)值的情況，以便找出有代表性的測試數(shù)據(jù)，減少測試工作量。第64頁，課件共100頁，創(chuàng)作于2023年2月6.5.1等價類劃分假設我們可以把輸入的數(shù)據(jù)域劃分成有限的等價類，用每個等價類的代表值作為測試用例的輸入數(shù)據(jù)進行測試，等價于該類的任何其它值作為設計用例的輸入數(shù)據(jù)進行的測試。即：如果等價類中的一個測試用例檢測出程序的一個錯誤，那么這一等價類的其余測試用例也能發(fā)現(xiàn)同樣的錯誤。相反，若測不出錯誤，則該等價類的其他測試用例，也測不出錯誤。第65頁，課件共100頁，創(chuàng)作于2023年2月6.5.1等價類劃分等價類劃分的原則：（1）如果規(guī)定了輸入值的取值范圍，則可劃分出一個有效的等價類（輸入值在此范圍內(nèi)），兩個無效的等價類（輸入值小于最小值、或大于最大值）；（2）如果規(guī)定了輸入數(shù)據(jù)的個數(shù)，則類似地也可以劃分出一個有效等價類和兩個無效等價類。第66頁，課件共100頁，創(chuàng)作于2023年2月6.5.1等價類劃分

（3）如果規(guī)定了輸入數(shù)據(jù)的一組值，而且程序?qū)Σ煌斎胫底霾煌靥幚?，則每個允許的值是一個有效的等價類，還有一個無效的等價類（任何一個不允許的輸入值）；（4）如果規(guī)定了輸入數(shù)據(jù)必須遵循的規(guī)則，則可以劃分出一個有效的等價類（符合規(guī)則的輸入數(shù)據(jù)）和若干個無效的等價類（從各種不同角度違反規(guī)則）；第67頁，課件共100頁，創(chuàng)作于2023年2月6.5.1等價類劃分

（5）如果輸入數(shù)據(jù)為整型，則可以劃分出正整數(shù)、零和負整數(shù)三個有效類；（6）如果程序處理的對象是表格，則應該使用空表、以及含有一項或多項的表進行測試。以上列舉了可能情況的一部分，還可以根據(jù)經(jīng)驗進行劃分。上面是針對輸入數(shù)據(jù)而言，對輸出數(shù)據(jù)也可類似劃分。第68頁，課件共100頁，創(chuàng)作于2023年2月6.5.1等價類劃分根據(jù)等價類劃分來設計測試方案時主要使用下面的兩個步驟（先劃分好等價類）：1）設計一個新的測試方案，盡可能多的覆蓋尚未被覆蓋的有效等價類；重復這一步驟直到所有有效等價類都被覆蓋為止；2）設計一個新的測試方案，使它覆蓋一個，而且只覆蓋一個尚未被覆蓋的無效等價類，重復這一步驟直到所有無效等價類都被覆蓋為止；第69頁，課件共100頁，創(chuàng)作于2023年2月6.5.2邊界值分析經(jīng)驗表明，程序在處理邊界情況時最容易發(fā)生錯誤——忽略邊界數(shù)據(jù)域問題。所以選取稍微高于或低于邊界值的數(shù)據(jù)進行測試。啟發(fā)規(guī)則如下：（1）輸入條件規(guī)定取值范圍或輸入個數(shù)時，取邊界值的上下值或個數(shù)的上下界設計測試用例；（2）如果輸出條件規(guī)定取值范圍，取邊界上下浮動值作為測試數(shù)據(jù)；第70頁，課件共100頁，創(chuàng)作于2023年2月6.5.2邊界值分析（3）規(guī)格說明中提出輸入輸出有序集，取有序集的第一個和最后一個元素作為測試數(shù)據(jù)；（4）分析規(guī)格說明，找出其他可能存在的邊界條件，取其上下浮動值作為測試數(shù)據(jù)。第71頁，課件共100頁，創(chuàng)作于2023年2月6.5.3因果圖法因果圖可以提供邏輯條件和相應動作之間的簡潔邏輯關系表示。因果圖的使用可以分為如下步驟：（1）列出模塊的原因——和效果（動作），給每個原因和效果一個標示符；（2）把原因、效果用邏輯符號連接起來，畫出原因效果圖，標出約束條件；第72頁，課件共100頁，創(chuàng)作于2023年2月6.5.3因果圖法（3）原因相對于判定表中的條件，效果相對于判定表中的動作，把原因效果圖轉換為判定表；（4）把判定表中右邊部分的每一列表示的情況轉換為測試用例。

第73頁，課件共100頁，創(chuàng)作于2023年2月6.5.3錯誤推測法

錯誤推測法在很大程度上依靠人的直覺和經(jīng)驗進行。有時利用其他測試方法測試后的程序表現(xiàn)，推測應該如何進行下一步的測試。也可利用程序錯誤清單作為推測測試的依據(jù)。第74頁，課件共100頁，創(chuàng)作于2023年2月6.5.3綜合測試策略對軟件系統(tǒng)的實際測試，往往利用多種測試方法進行，形成綜合測試策略。通常是用黑盒法設計一些基本的測試用例，再用白盒法補充設計一些必要的測試用例，黑盒、白盒法相結合——灰盒法進行測試。具體策略為：(1)在任何情況下都應該使用邊界值分析法進行測試。經(jīng)驗表明這種方法設計出的測試用例，暴露程序錯誤的能力最強，應該包括輸入和輸出數(shù)據(jù)的邊界情況；第75頁，課件共100頁，創(chuàng)作于2023年2月6.5.3綜合測試策略（2）必要時用等價類劃分法補充測試用例；（3）必要時用錯誤推測法補充測試用例；（4）對照程序邏輯，檢查設計測試用例，可根據(jù)對程序的可靠性要求采用不同的邏輯覆蓋標準，補充測試用例，達到邏輯覆蓋標準；（5）如果有輸入條件的組合，就應從輸入條件及其組合開始測試。第76頁，課件共100頁，創(chuàng)作于2023年2月6.5.3綜合測試策略對于集成測試可以使用模塊的自頂向下的結合方式，也可以使用自底向上的結合方式進行測試，還可用輔助測試工具協(xié)助測試。軟件系統(tǒng)測試完后，應對軟件配置進行復查，確保軟件的有關文檔資料的完整齊全，分類編目，便于軟件的維護和修改。審查的資料包括：用戶所需的文檔（用戶手冊、操作手冊）；設計文檔；源程序；測試文檔（測試說明書，測試報告）及其它說明等。第77頁，課件共100頁，創(chuàng)作于2023年2月6.6軟件調(diào)試程序測試只是發(fā)現(xiàn)錯誤的跡象，并不清楚具體錯誤的位置和產(chǎn)生的原因，應該立即進行調(diào)試，即糾正錯誤的工作，它包含兩方面工作：（1）確定程序中錯誤的具體位置和性質(zhì)；（2）修改錯誤。

調(diào)試必須由程序員自己來進行。第78頁，課件共100頁，創(chuàng)作于2023年2月6.6軟件調(diào)試調(diào)試技術有以下類別：輸出存儲器內(nèi)容：發(fā)現(xiàn)問題時，設法保留現(xiàn)場信息，把所有寄存器和主存中相關部分的內(nèi)容打印出來進行分析研究。打印關鍵變量的動態(tài)內(nèi)容：為取得關鍵變量的動態(tài)值，在程序中插入標準的打印語句，檢驗在某個事件發(fā)生后變量是否按預期的要求進行變化。第79頁，課件共100頁，創(chuàng)作于2023年2月6.6軟件調(diào)試利用調(diào)試工具跟蹤程序的動態(tài)變化，單步跟蹤，檢查主存和寄存器內(nèi)容，檢查重要變量內(nèi)容，檢查是否進入預定的程序分支，設置斷點，當程序運行到檢查的重點位置，暫停程序運行，觀察主要的變化信息，分析程序狀態(tài)，決定繼續(xù)跟蹤還是停止執(zhí)行，為程序的調(diào)試提供了有力的手段。調(diào)試的策略有：試探法，回溯法，對分查找法、歸納法、演繹法?？筛鶕?jù)個人經(jīng)驗和具體情況靈活應用。第80頁，課件共100頁，創(chuàng)作于2023年2月6.7軟件質(zhì)量控制高質(zhì)量是產(chǎn)品得以存在和生長的前提，軟件工程的主要目標之一就是要獲得高質(zhì)量的軟件。在軟件工程誕生之前，由于計算機設備條件的限制，計算機發(fā)展的早期，內(nèi)存容量有限，執(zhí)行速度不高，當時的軟件設計特別強調(diào)效率。隨著技術的發(fā)展，軟件規(guī)模的擴大，軟件復雜性的增加，人們對軟件質(zhì)量的觀點早已發(fā)生了很大變化，更強調(diào)軟件的全面質(zhì)量評價。第81頁，課件共100頁，創(chuàng)作于2023年2月6.7.1軟件質(zhì)量評價不同的人員對軟件質(zhì)量關心的著重點不同，反映了對軟件質(zhì)量的不同要求。用戶關心軟件產(chǎn)品是否滿足規(guī)定的功能和性能要求，軟件運行是否可靠，是否易于學習掌握，易于使用，是否有較高的運行效率，是否可以從一個環(huán)境移植到另一個環(huán)境等問題。軟件開發(fā)人員既要開發(fā)滿足質(zhì)量要求的最終產(chǎn)品，又要注意軟件開發(fā)過程中的每個階段的質(zhì)量。第82頁，課件共100頁，創(chuàng)作于2023年2月6.7.1軟件質(zhì)量評價開發(fā)人員常把產(chǎn)品外部特性用軟件內(nèi)部質(zhì)量結構來對應。維護人員要求軟件系統(tǒng)、軟件文檔清晰、軟件文檔與源代碼一致，軟件易于修改、易于維護。管理人員關心的是軟件的總體質(zhì)量特性，在軟件質(zhì)量與開發(fā)工期之間進行折中選擇；第83頁，課件共100頁，創(chuàng)作于2023年2月6.7.1軟件質(zhì)量評價但影響軟件質(zhì)量的各因素之間是相互聯(lián)系、甚至是相互矛盾的，如追求可靠性要犧牲一定的時間和空間效率為代價，要求軟件不但能在合法的輸入情況下正確地運行，而且還應該能夠安全地排除非法的入侵和處理意外的事件。一般要求軟件具有良好的結構，齊全的文檔資料，易于閱讀和理解，便于修改和維護，內(nèi)部層次結構清晰、人機界面友好，用戶樂于使用。第84頁，課件共100頁，創(chuàng)作于2023年2月6.7.1軟件質(zhì)量評價

國際標準化機構建議，軟件質(zhì)量模型由三層組成：高層：軟件質(zhì)量需求評價準則（SQRC）；中層：軟件質(zhì)量設計評價準則（SQDC）；低層：軟件質(zhì)量度量評價準則（SQMC）；第85頁，課件共100頁，創(chuàng)作于2023年2月6.7.1軟件質(zhì)量評價多數(shù)軟件同行公認的一般質(zhì)量按如下特性進行評價：正確性：（功能度）在預定的環(huán)境下，軟件實現(xiàn)的功能達到設計規(guī)范和滿足用戶要求的程度；可靠性：軟件在給定的條件下和規(guī)定的時間內(nèi)完成預定職能的概率；即保持其性能的能力相關的屬性；易用性：用戶學習軟件、運行操作軟件、準備輸入、理解輸出所做的努力程度，根據(jù)用戶評估使用軟件所需進行努力的程度相關的屬性；第86頁，課件共100頁，創(chuàng)作于2023年2月6.7.1軟件質(zhì)量評價效率：在規(guī)定的條件下，軟件表現(xiàn)的性能級別與所使用資源總量（包括人員、時間、財力）關系的屬性；可維護性：軟件修改難易程度的一組屬性；可移植性；（可轉換性）指一個軟件從一個環(huán)境轉換到另一個環(huán)境運行的能力的相關屬性。以上六條是常見的評價方面。第87頁，課件共100頁，創(chuàng)作于2023年2月6.7.1軟件質(zhì)量評價還有其它方面的特性來評價軟件質(zhì)量，衡量總體質(zhì)量的優(yōu)劣程度。如：健壯性：在硬件發(fā)生故障、輸入數(shù)據(jù)無效或操作失誤等意外情況下，系統(tǒng)不至于崩潰，能作出適當響應的程度；完整性：（安全性）對未經(jīng)授權的人使用軟件或數(shù)據(jù)的企圖，系統(tǒng)能夠控制（禁止）的程度；第88頁，課件共100頁，創(chuàng)作于2023年2月6.7.1軟件質(zhì)量評價可測試性：系統(tǒng)容易測試的程度；可再用性：在其他應用中該軟件可以被再次使用的程度（或范圍）；可互連性：把軟件系統(tǒng)與其他系統(tǒng)連接起來的能力。除了定性評價外，人們逐漸重視軟件的質(zhì)量度量，它是在系統(tǒng)運行過程中進行動態(tài)檢測，不斷收集軟件性能方面的數(shù)據(jù)，利用軟件質(zhì)量模型（如軟件可靠性模型、軟件復雜度模型等）進行分析和評價。第89頁，課件共100頁，創(chuàng)作于2023年2月6.7.2軟件質(zhì)量控制做好軟件質(zhì)量的控制，就要加強軟件生命