實現數據庫原理

第一頁，共一百三十二頁，2022年，8月28日軟件測試基礎本章內容7.2單元測試7.3集成測試7.4確認測試7.5白盒測試技術7.67.1編碼7.7黑盒測試技術7.8調試第二頁，共一百三十二頁，2022年，8月28日編碼通常把編碼和測試統(tǒng)稱為實現?編碼就是把軟件設計結果翻譯成用某種程序設計語言書寫的程序編碼是對設計的進一步具體化程序的質量主要取決于軟件設計的質量程序設計語言的特點及編碼風格將影響程序的可靠性、可讀性、可測試性和可維護性編碼過程中還不可避免地會引入新的錯誤測試主要是準對編碼進行的，測試和編碼反復進行，而且單元測試和編碼還是同一個人完成的第三頁，共一百三十二頁，2022年，8月28日測試測試是在軟件投入生產性運行之前，盡可能多地發(fā)現軟件中的錯誤，調試的目：診斷并改正測試發(fā)現的錯誤是保證軟件質量的關鍵步驟對軟件規(guī)格說明、設計和編碼的最后復審軟件測試包括單元測試和整體測試兩個階段測試的工作量占軟件開發(fā)總工作量的40%以上第四頁，共一百三十二頁，2022年，8月28日7.1.1選擇程序設計語言編碼之前第一步要做的事情就是選擇程序設計語言通常用高級語言寫的程序容易閱讀，容易測試，容易調試，容易維護。（效率高）第五頁，共一百三十二頁，2022年，8月28日7.1.1選擇程序設計語言選擇程序設計語言的標準:1、系統(tǒng)用戶的要求：由用戶負責維護的時候2、可以使用的編譯程序3、可以得到的軟件工具（開發(fā)工具和數據庫）4、工程規(guī)模5、程序員的知識6、軟件可移植性要求7、軟件的應用領域Fortran合適科學計算，cobol合適商業(yè)領域，lisp合適組合問題，prolog合適人工智能第六頁，共一百三十二頁，2022年，8月28日7.1.2編碼風格源代碼質量標準：邏輯簡明清晰、易讀易懂，為了做到這點應該遵循的規(guī)則：程序內部的文檔：數據說明：次序應該標準化、字母順序語句構造規(guī)則不要為了節(jié)省空間而把多個語句寫在同一行；盡量避免復雜的條件判斷；盡量減少對“非”條件的判斷；避免大量使用循環(huán)嵌套和條件嵌套；利用括號使邏輯表達式或算術表達式的運算次序清晰直觀。標識符、注解、程序視角組織第七頁，共一百三十二頁，2022年，8月28日編碼風格4.

輸入輸出風格的規(guī)則對所有輸入數據都進行檢驗；檢查輸入項重要組合的合法性；保持輸入格式簡單；使用數據結束標記，不要要求用戶指定數據的數目；明確提示交互式輸入的請求，詳細說明可用的選擇或邊界數值；當程序設計語言對格式有嚴格要求時，應保持輸入格式一致；設計良好的輸出報表；給所有輸出數據加標志。如果有多個輸入組合的話第八頁，共一百三十二頁，2022年，8月28日編碼風格5.效率：處理機時間和存儲器容量和輸入輸出效率是性能要求，在需求分析階段確定效率是靠好設計來提高的不要犧牲程序的清晰性和可讀性來提高效率(1)程序運行時間1、算法的復雜度2、寫程序的規(guī)則：第九頁，共一百三十二頁，2022年，8月28日編碼風格(2)存儲器效率使用結構化控制結構、適當的編譯程序和語言(3)輸入輸出的效率1、使用緩沖減少通信開銷；2、二級存儲器（硬盤）選用最簡單的訪問方法3、二級存儲器（硬盤）數據傳送以組為單位4、如果高效率輸入輸出不好被理解，則放棄第十頁，共一百三十二頁，2022年，8月28日7.2軟件測試基礎

7.2.1軟件測試的目標軟件測試和其他階段的思路區(qū)別：“建設性”和“破壞性”。測試階段的根本目標：是盡可能多地發(fā)現并排除軟件中潛藏的錯誤，最終把一個高質量的軟件系統(tǒng)交給用戶使用。(1)測試是為了發(fā)現程序中的錯誤而執(zhí)行程序的過程；(2)好的測試方案是極可能發(fā)現迄今為止尚未發(fā)現的錯誤的測試方案；(3)成功的測試是發(fā)現了至今為止尚未發(fā)現的錯誤的測試。通常由第三方或測試機構來完成測試工作測試決不能證明程序是正確的第十一頁，共一百三十二頁，2022年，8月28日7.2.2軟件測試準則（1）所有測試都應該能追溯到用戶需求。 對需求進行確認（p56）（2）應該遠在測試開始之前就制定出測試計劃。 設計階段制定詳細的測試方案（p93）（3）Pareto錯誤集聚現象：測試發(fā)現的錯誤中的80%很可能是由程序中20%的模塊造成的。（4）先進行“小規(guī)模”測試，并逐步進行“大規(guī)模”測試。（5）窮舉測試是不可能的。（6）由獨立的第三方從事測試工作。對所有的執(zhí)行路徑都檢查一遍的測試第十二頁，共一百三十二頁，2022年，8月28日例:Windows95有1000萬行代碼

Windows2000有5000萬行代碼Exchange2000和Windows2000開發(fā)人員結構Exchange2000Windows2000項目經理25人約250人開發(fā)人員140人約1700人測試人員350人約3200人第十三頁，共一百三十二頁，2022年，8月28日7.2.3測試方法黑盒測試法（功能測試）：完全不考慮程序的內部結構和處理過程。只在程序接口進行的測試，只檢查程序功能是否能按照規(guī)格說明書的規(guī)定正常使用，程序是否能適當地接收輸入數據并產生正確的輸出信息，程序運行過程中能否保持外部信息的完整性。白盒測試法（結構測試）：把程序看成裝在一個透明的白盒子里，程序的結構和處理算法完全可見。按照程序內部的邏輯測試程序，檢測程序中的主要執(zhí)行通路是否都能按預定要求正確工作。第十四頁，共一百三十二頁，2022年，8月28日7.2.4測試步驟大型軟件系統(tǒng)的測試過程由以下步驟組成：1.模塊測試模塊測試的目的是保證每個模塊作為一個單元能正確運行，所以模塊測試通常又稱為單元測試該步驟中通常發(fā)現編碼和詳細設計的錯誤2.子系統(tǒng)測試子系統(tǒng)測試是把經過單元測試的模塊放在一起形成一個子系統(tǒng)來測試著重測試模塊接口間的協(xié)調和通信第十五頁，共一百三十二頁，2022年，8月28日測試步驟3.系統(tǒng)測試系統(tǒng)測試是把經過測試的子系統(tǒng)裝配成一個完整的系統(tǒng)來測試應該驗證系統(tǒng)確實能提供需求說明書中指定的功能、性能、可靠性等要求往往發(fā)現軟件設計或需求說明中的錯誤集成測試：子系統(tǒng)測試與系統(tǒng)測試第十六頁，共一百三十二頁，2022年，8月28日測試步驟4.驗收測試（確認測試）把軟件系統(tǒng)作為單一的實體進行測試，測試內容與系統(tǒng)測試基本類似在用戶積極參與下，使用實際數據(系統(tǒng)將來要處理的信息)進行測試驗收測試的目的是驗證系統(tǒng)確實能夠滿足用戶的需要往往發(fā)現系統(tǒng)需求說明書中的錯誤第十七頁，共一百三十二頁，2022年，8月28日測試步驟5.平行運行同時運行新開發(fā)出來的系統(tǒng)和將被它取代的舊系統(tǒng)，以便比較新舊兩個系統(tǒng)的處理結果。具體目的有如下幾點：(1)可以在準生產環(huán)境中運行新系統(tǒng)而又不冒風險；(2)用戶能有一段熟悉新系統(tǒng)的時間；(3)可以驗證用戶指南和使用手冊之類的文檔；(4)能夠以準生產模式對新系統(tǒng)進行全負荷測試，可以用測試結果驗證性能指標。第十八頁，共一百三十二頁，2022年，8月28日測試步驟第十九頁，共一百三十二頁，2022年，8月28日測試步驟第二十頁，共一百三十二頁，2022年，8月28日7.2.5測試階段的信息流測試階段輸入信息的信息流有兩類：(1)軟件配置，包括需求說明書、設計說明書和源程序清單等；(2)測試配置，包括測試計劃和測試方案。測試方案包括測試時使用的輸入數據(稱為測試用例)、每組輸入數據預定要檢驗的功能以及每組輸入數據預期的正確輸出。最終提交的軟件配置應該包括測試配置、測試的實際結果和調試的記錄第二十一頁，共一百三十二頁，2022年，8月28日測試階段的信息流第二十二頁，共一百三十二頁，2022年，8月28日經驗如果測試經常出現要修改設計，那軟件質量和可靠性值得懷疑，不出現這樣的情況，則還有兩種可能：(1)軟件的可靠性是可以接受的；(2)所進行的測試尚不足以發(fā)現嚴重的錯誤。若測試沒有發(fā)現錯誤，則很可能是因為測試不充分，無法暴露潛藏的錯誤。隱藏的錯誤最終將被用戶發(fā)現，在維護階段改正它們，要付出高出許多倍的代價。第二十三頁，共一百三十二頁，2022年，8月28日7.3單元測試集中檢測軟件設計的最小單元——模塊單元測試和編碼屬于軟件過程的同一個階段可以應用人工測試和計算機測試這樣兩種不同類型的測試方法，完成單元測試工作單元測試主要使用白盒測試技術并行地進行第二十四頁，共一百三十二頁，2022年，8月28日7.3.1測試重點1.模塊接口檢查參數的數目、次序、屬性或單位系統(tǒng)與變元是否一致；是否修改了只作輸入用的變元；全局變量的定義和用法在各個模塊中是否一致。2.局部數據結構主要發(fā)現局部數據說明、初始化、默認值等方面的錯誤。3.重要的執(zhí)行通路選擇最有代表性、最可能發(fā)現錯誤的執(zhí)行通路進行測試，用來發(fā)現由于錯誤的計算、不正確的比較或不適當的控制流而造成的錯誤。數據庫中最小存儲和處理單位數據庫中最小存儲和處理單位第二十五頁，共一百三十二頁，2022年，8月28日測試重點4.出錯處理通路好的設計應該能預見出現錯誤的條件，設置適當的處理錯誤的通路。程序中應包含出錯處理通路，并認真測試這種通路。評價出錯處理通路時，著重測試下述可能發(fā)生的錯誤：(1)對錯誤的描述是難以理解的；(2)記下的錯誤與實際遇到的錯誤不同；(3)在對錯誤進行處理之前，錯誤條件已經引起系統(tǒng)干預；(4)對錯誤的處理不正確；(5)描述錯誤的信息不足以幫助確定造成錯誤的位置。第二十六頁，共一百三十二頁，2022年，8月28日測試重點5.邊界條件邊界測試是單元測試中最后的也可能是最重要的任務。什么是邊界？軟件常常在它的邊界上失效。如：數組的循環(huán)使用剛好小于、剛好等于和剛好大于最大值或最小值的數據結構、控制量和數據值的測試方案，容易發(fā)現錯誤。第二十七頁，共一百三十二頁，2022年，8月28日7.3.2代碼審查由審查小組正式進行人工測試源程序。是一種非常有效的程序驗證技術，通?？梢圆槌?0%～70%的邏輯設計錯誤和編碼錯誤。審查小組最好由下述4人組成：(1)組長，應該是一個很有能力的程序員，而且沒有直接參與這項工程；(2)程序的設計者；(3)程序的編寫者；(4)程序的測試者。第二十八頁，共一百三十二頁，2022年，8月28日審查會1、小組成員先研究設計說明書，力求理解這個設計。2、審查會上先由設計者扼要地介紹他的設計。3、由程序的編寫者逐句解釋他是怎樣用程序代碼實現這個設計的邏輯，小組其他成員仔細傾聽他的講解，并力圖發(fā)現其中的錯誤。4、對照程序設計常見錯誤清單，分析審查這個程序。5、當發(fā)現錯誤時由組長記錄下來，審查會繼續(xù)進行(審查小組的任務是發(fā)現錯誤而不是改正錯誤)。代碼審查可以發(fā)現許多錯誤，減少系統(tǒng)驗證的總工作量。應與計算機測試配合使用，提高查找錯誤的效率。第二十九頁，共一百三十二頁，2022年，8月28日7.3.3計算機測試輔助模塊：驅動軟件和(或)存根軟件。驅動程序就是一個“主程序”，它接收測試數據，把這些數據傳送給被測試的模塊，并且印出有關的結果。存根程序代替被測試的模塊所調用的模塊，也稱為“虛擬子程序”、“樁模塊”。做最少量的數據操作，印出對入口的檢驗或操作結果，并且把控制歸還給調用它的模塊。不作為軟件產品的一部分交給用戶第三十頁，共一百三十二頁，2022年，8月28日驅動模塊和樁模塊第三十一頁，共一百三十二頁，2022年，8月28日驅動模塊和樁模塊例如，要測試其中編號為3.0的關鍵模塊——正文編輯模塊。需要有一個測試驅動程序來調用它，說明必要的變量，接收測試數據——字符串，并且設置正文編輯模塊的編輯功能；正文編輯模塊3.0通過調用存根程序模擬下層模塊來完成簡化的編輯功能?？梢栽O置的編輯功能只有修改(CHANGE)和添加(APPEND)兩種，用控制變量CFUNCT標記要求的編輯功能。以下是用偽碼書寫的存根程序和驅動程序。第三十二頁，共一百三十二頁，2022年，8月28日圖7.2正文加工系統(tǒng)的層次圖第三十三頁，共一百三十二頁，2022年，8月28日存根程序TESTSTUB(*測試正文編輯模塊用的存根程序*) 初始化； 輸出信息“進入了正文編輯程序”； 輸出“輸入的控制信息是”CFUNCT； 輸出緩沖區(qū)中的字符串；

IFCFUNCT=CHANGE THEN 把緩沖區(qū)中第二個字改為***//測試修改

ELSE 在緩沖區(qū)的尾部加???//測試添加

END IF； 輸出緩沖區(qū)中的新字符串；ENDTESTSTUB第三十四頁，共一百三十二頁，2022年，8月28日驅動程序TESTDRIVER(*測試正文編輯模塊用的驅動程序*) 說明長度為2500個字符的一個緩沖區(qū)； 把CFUNCT置為希望測試的狀態(tài)； 輸入字符串； 調用正文編輯模塊； 停止或再次初啟；ENDTESTDRIVER第三十五頁，共一百三十二頁，2022年，8月28日7.4集成測試集成測試是測試和組裝軟件的系統(tǒng)化技術目標是發(fā)現與接口有關的問題發(fā)現問題：數據穿過接口時可能丟失；把子功能組合起來可能不產生預期的主功能；個別看來是可以接受的誤差可能積累到不能接受的程度；全程數據結構可能有問題。。。。。。第三十六頁，共一百三十二頁，2022年，8月28日組裝策略模塊組裝成程序有兩種方法：1、非漸增式測試：先分別測試每個模塊，再把所有模塊按設計要求放在一起結合成所要的程序；2、漸增式測試：把下一個要測試的模塊同已經測試好的那些模塊結合起來進行測試，測試完以后再把下一個應該測試的模塊結合進來測試。同時完成單元測試和集成測試。漸增方式下有自頂向下和自底向上兩種集成策略。第三十七頁，共一百三十二頁，2022年，8月28日非漸增式測試第三十八頁，共一百三十二頁，2022年，8月28日漸增式測試——自頂向下第三十九頁，共一百三十二頁，2022年，8月28日漸增式測試——自底向上第四十頁，共一百三十二頁，2022年，8月28日兩種集成策略優(yōu)缺點非漸增式測試一下子把所有模塊放在一起，并把龐大的程序作為一個整體來測試，難于診斷定位一個錯誤；一旦改正一個錯誤之后，馬上又會遇到新的錯誤。漸增式測試把程序劃分成小段來構造和測試，比較容易定位和改正錯誤；對接口可以進行更徹底的測試；可以使用系統(tǒng)化的測試方法。目前普遍采用漸增式測試方法。第四十一頁，共一百三十二頁，2022年，8月28日7.4.1自頂向下集成自頂向下集成方法：從主控制模塊開始，沿著程序的控制層次向下移動，逐漸把各個模塊結合起來。在把主控制模塊的附屬模塊組裝到程序結構中去時，它包括深度優(yōu)先和寬度優(yōu)先兩種組裝策略。深度優(yōu)先的結合方法先組裝在軟件結構的一條主控制通路上的所有模塊。寬度優(yōu)先的結合方法是沿軟件結構水平地移動，把處于同一個控制層次上的所有模塊組裝起來。第四十二頁，共一百三十二頁，2022年，8月28日自頂向下結合第四十三頁，共一百三十二頁，2022年，8月28日具體集成過程第一步，對主控制模塊進行測試，測試時用存根程序代替所有直接附屬于主控制模塊的模塊；第二步，根據選定的結合策略(深度優(yōu)先或寬度優(yōu)先)，每次用一個實際模塊代換一個存根程序(新結合進來的模塊往往又需要新的存根程序)；第三步，在結合進一個模塊的同時進行測試；第四步，為了保證加入模塊沒有引進新的錯誤，可能需要進行回歸測試(即，全部或部分地重復以前做過的測試)。從第二步開始不斷地重復進行上述過程，直到構造起完整的軟件結構為止。第四十四頁，共一百三十二頁，2022年，8月28日7.4.2自底向上集成這種組裝的方式是從程序模塊結構的最底層的模塊開始組裝和測試。因為模塊是自底向上進行組裝，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經組裝并測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。第四十五頁，共一百三十二頁，2022年，8月28日自底向上集成的過程第一步，把低層模塊組合成實現某個特定軟件子功能的族；第二步，寫一個驅動程序(用于測試的控制程序)，協(xié)調測試數據的輸入和輸出；第三步，對由模塊組成的子功能族進行測試；第四步，去掉驅動程序，沿軟件結構自下向上移動，把子功能族組合起來形成更大的子功能族。上述第二步到第四步實質上構成了一個循環(huán)。第四十六頁，共一百三十二頁，2022年，8月28日自底向上結合第四十七頁，共一百三十二頁，2022年，8月28日7.4.3不同集成測試策略的比較自頂向下測試方法的主要優(yōu)點是不需要測試驅動程序，能夠在測試階段的早期實現并驗證系統(tǒng)的主要功能，及早發(fā)現上層模塊的接口錯誤。自頂向下測試方法的主要缺點是需要存根程序，可能產生測試困難，低層關鍵模塊中的錯誤發(fā)現較晚，在早期不能充分展開人力。兩種方法的優(yōu)缺點剛好相反。第四十八頁，共一百三十二頁，2022年，8月28日混合集成策略改進的自頂向下測試方法。

基本上使用自頂向下的測試方法，但是在早期使用自底向上的方法測試軟件中的少數關鍵模塊。具有自頂向下方法的優(yōu)點，而且能在測試的早期發(fā)現關鍵模塊中的錯誤；它的缺點是測試關鍵模塊時需要驅動程序。（2）混合法。對軟件結構中較上層使用的自頂向下方法與對軟件結構中較下層使用的自底向上方法相結合。兼有兩種方法的優(yōu)點和缺點，當關鍵模塊比較多時是最好的折衷方法。第四十九頁，共一百三十二頁，2022年，8月28日回歸測試集回歸測試是指重新執(zhí)行已經做過的測試的某個子集，以保證最新變化沒有帶來非預期的副作用。為限制回歸測試用例的數量，應該把回歸測試集設計成只包括可以檢測程序每個主要功能中的一類或多類錯誤的那樣一些測試用例。第五十頁，共一百三十二頁，2022年，8月28日7.5確認測試確認測試（驗收測試），它的目標是驗證軟件的有效性。確認（validation）指的是為了保證軟件確實滿足了用戶需求而進行的一系列活動。驗證（verification）指的是保證軟件正確地實現了某個特定要求的一系列活動。第五十一頁，共一百三十二頁，2022年，8月28日軟件有效性軟件有效性的簡單定義：如果軟件的功能和性能如同用戶所合理期待的那樣，軟件就是有效的。需求分析階段產生的軟件需求規(guī)格說明書，準確地描述了用戶對軟件的合理期望，因此是軟件有效性的標準，也是進行確認測試的基礎。第五十二頁，共一百三十二頁，2022年，8月28日7.5.1確認測試的范圍確認測試必須有用戶積極參與，或者以用戶為主進行。用戶參與設計測試方案，使用用戶界面輸入測試數據并且分析評價測試的輸出結果。確認測試通常使用黑盒測試法。應該仔細設計測試計劃和測試過程通過測試和調試要確認軟件能滿足所有功能和性能要求，文檔資料是準確而完整的，還應該保證軟件能滿足其他預定的要求（例如，安全性、可移植性、兼容性和可維護性等）。第五十三頁，共一百三十二頁，2022年，8月28日7.5.2軟件配置復查是確認測試的一個重要內容目的是保證軟件配置的所有成分都齊全，質量符合要求，文檔與程序完全一致，具有完成軟件維護所必須的細節(jié)，而且已經編好目錄。還應該檢驗用戶指南及其他操作程序的完整性和正確性記錄發(fā)現的遺漏或錯誤，并且適當地補充和改正。第五十四頁，共一百三十二頁，2022年，8月28日7.5.3Alpha和Beta測試驗收測試是由最終用戶進行，能夠發(fā)現隨著時間流逝降低系統(tǒng)質量的累積錯誤。產品軟件通常使用Alpha測試和Beta測試。Alpha測試由用戶在開發(fā)現場，在開發(fā)者的“指導”下進行測試（受控環(huán)境）。開發(fā)者負責記錄發(fā)現的錯誤和使用中遇到的問題。Beta測試由軟件的用戶在實際使用環(huán)境中進行。開發(fā)者不在現場。用戶把遇到的一切問題記錄并定期報告。開發(fā)者根據報告的問題對軟件進行修改，發(fā)布最終的軟件產品。第五十五頁，共一百三十二頁，2022年，8月28日7.6白盒測試技術設計測試方案是測試階段的關鍵技術問題。測試方案包括具體的測試目的（要測試的具體功能），應該輸入的測試數據和預期的結果。通常又把測試數據和預期的輸出結果稱為測試用例。關鍵問題是設計測試用的輸入數據。選用少量“最有效的”測試數據，做到盡可能完備的測試。第五十六頁，共一百三十二頁，2022年，8月28日7.6.1邏輯覆蓋測試選擇執(zhí)行程序中最有代表性的通路替代窮盡測試。邏輯覆蓋是對一系列測試過程的總稱，根據測試數據執(zhí)行(覆蓋)程序邏輯的程度劃分等級，進行越來越完整的通路測試。根據流程圖，分析下不同的覆蓋標準。第五十七頁，共一百三十二頁，2022年，8月28日例(A>1)

and

(B=0)(A=2)

or

(X>1)X=X/AX=X+1TTFFabdce第五十八頁，共一百三十二頁，2022年，8月28日L1(ace)={(A>1)and(B=0)}and{(A=2)or(X/A>1)}=(A>1)and(B=0)and(A=2)or(A>1)and(B=0)and(X/A>1)=(A=2)and(B=0)

or

(A>1)and(B=0)and(X/A>1)

邏輯路徑第五十九頁，共一百三十二頁，2022年，8月28日L2(abd)=not{(A>1)and(B=0)}

andnot{(A=2)or(X>1)}={not(A>1)ornot(B=0)}and

{not(A=2)andnot(X>1)}=

not(A>1)andnot(A=2)andnot(X>1)

or

not(B=0)and

not(A=2)andnot(X>1)邏輯路徑第六十頁，共一百三十二頁，2022年，8月28日L3(abe)=not{(A>1)and(B=0)}and

{(A=2)or(X>1)}={not(A>1)ornot(B=0)}and

{(A=2)or(X>1)}=not(A>1)and(A=2)

or

not(A>1)and

(X>1)

or

not(B=0)and(A=2)

or

not(B=0)and(X>1)邏輯路徑第六十一頁，共一百三十二頁，2022年，8月28日L4(acd)={(A>1)and(B=0)}

andnot

{(A=2)or(X/A>1)}=(A>1)and(B=0)andnot(A=2)and

not(X/A>1)邏輯路徑第六十二頁，共一百三十二頁，2022年，8月28日1.語句覆蓋

語句覆蓋就是設計若干個測試用例，運行被測程序，使得每一可執(zhí)行語句至少執(zhí)行一次。在圖例中，選擇路徑L1設計測試用例，就可以覆蓋所有的可執(zhí)行語句。為圖例設計滿足語句覆蓋的測試用例是:

【(2,0,4)，(2,0,3)】覆蓋ace【L1】第六十三頁，共一百三十二頁，2022年，8月28日語句覆蓋的缺點語句覆蓋是很弱的邏輯覆蓋標準。例如：intfoo(inta,intb)

{

returna/b;

}假如我們的測試人員編寫如下測試案例：TeseCase:a=10,b=5測試人員的測試結果會告訴你，他的代碼覆蓋率達到了100％，并且所有測試案例都通過了。然而遺憾的是，我們的語句覆蓋率達到了所謂的100%，但是卻沒有發(fā)現最簡單的Bug，比如，當我讓b=0時，會拋出一個除零異常。第六十四頁，共一百三十二頁，2022年，8月28日判定覆蓋就是設計若干個測試用例，運行被測程序，使得程序中每個判斷的取真分支和取假分支至少經歷測試一次。對于圖例，如果選擇路徑L1和L2，就可得滿足要求的測試用例:2.判定覆蓋（分支覆蓋）【(2,0,4)，(2,0,3)】覆蓋ace【L1】

【(1,1,1)，(1,1,1)】覆蓋abd【L2】(A=2)and(B=0)

or

(A>1)and(B=0)and(X/A>1)

not(A>1)andnot(A=2)andnot(X>1)

ornot(B=0)and

not(A=2)andnot(X>1)第六十五頁，共一百三十二頁，2022年，8月28日如果選擇路徑L3和L4，還可得另一組可用的測試用例:

【(2,1,1)，(2,1,2)】覆蓋abe【L3】

【(3,0,3)，(3,0,1)】覆蓋acd【L4】not(A>1)and(X>1)

ornot(B=0)and

(A=2)

ornot(B=0)and(X>1)(A>1)and(B=0)andnot(A=2)and

not(X/A>1)判定覆蓋（分支覆蓋）沒有對每一個條件進行檢查，如果判定2中的條件X>1誤寫成X>2，不一定能被發(fā)現。第六十六頁，共一百三十二頁，2022年，8月28日3.條件覆蓋條件覆蓋就是設計若干個測試用例，運行被測程序，使得程序中每個判斷的每個條件的可能取值至少執(zhí)行一次。在圖例中，事先可對所有條件的取值加以標記。對于第一個判斷：條件A＞1取真，取假

條件B＝0取真，取假對于第二個判斷：條件A＝2取真，取假

條件X＞1取真，取假第六十七頁，共一百三十二頁，2022年，8月28日測試用例

覆蓋分支

條件取值【(2,0,4)，(2,0,3)】L1(c,e)

【(1,0,1)，(1,0,1)】L2(b,d)【(2,1,1)，(2,1,2)】L3(b,e)或【(1,0,3)，(1,0,4)】L3(b,e)

【(2,1,1)，(2,1,2)】L3(b,e)

滿足條件覆蓋，卻不一定滿足判定覆蓋。條件覆蓋第六十八頁，共一百三十二頁，2022年，8月28日判定－條件覆蓋就是設計足夠的測試用例，使得判斷中每個條件的所有可能取值至少執(zhí)行一次，每個判斷中的每個分支至少執(zhí)行一次。

測試用例

覆蓋分支

條件取值【(2,0,4)，(2,0,3)】L1(c,e)【(1,1,1)，(1,1,1)】L2(b,d)4、判定/條件覆蓋(A=2)and(B=0)

or

(A>1)and(B=0)and(X/A>1)

not(A>1)andnot(A=2)andnot(X>1)

ornot(B=0)and

not(A=2)andnot(X>1)第六十九頁，共一百三十二頁，2022年，8月28日5、條件組合覆蓋條件組合覆蓋就是設計足夠的測試用例，運行被測程序，使得每個判斷的所有可能的條件取值組合至少執(zhí)行一次。記①A＞1,B＝0作

②A＞1,B≠0作③A≯1,B＝0作④A≯1,B≠0作

⑤A＝2,X＞1作

⑥A＝2,X≯1作

⑦A≠2,X＞1作

⑧A≠2,X≯1作第七十頁，共一百三十二頁，2022年，8月28日

測試用例

路徑

覆蓋條件

覆蓋組合【(2,0,4),(2,0,3)】(L1) ①,⑤【(2,1,1),(2,1,2)】(L3) ②,⑥【(1,0,3),(1,0,4)】(L3) ③,⑦【(1,1,1),(1,1,1)】(L2) ④,⑧是前述幾種覆蓋標準中最強的。滿足條件組合覆蓋標準的測試數據并不一定能使程序中的每條路徑都執(zhí)行到。5、條件組合覆蓋第七十一頁，共一百三十二頁，2022年，8月28日6.點覆蓋點覆蓋定義：如果連通圖G的子圖G′是連通的，而且包含G的所有結點，則稱G′是G的點覆蓋。滿足點覆蓋標準要求選取足夠多的測試數據，使得程序執(zhí)行路徑至少經過流圖（連通的有向圖）的每個結點（若干條語句）一次，顯然，點覆蓋標準和語句覆蓋標準是相同的。第七十二頁，共一百三十二頁，2022年，8月28日7.邊覆蓋邊覆蓋定義：如果連通圖G的子圖G″是連通的，而且包含G的所有邊，則稱G″是G的邊覆蓋。為了滿足邊覆蓋的測試標準，要求選取足夠多測試數據，使得程序執(zhí)行路徑至少經過流圖中每條邊一次。通常邊覆蓋和判定覆蓋是一致的。第七十三頁，共一百三十二頁，2022年，8月28日8.路徑覆蓋路徑測試就是設計足夠的測試用例，覆蓋程序中所有可能的路徑。

測試用例

通過路徑

覆蓋條件【(2,0,4),(2,0,3)】ace(L1)

【(1,1,1),(1,1,1)】abd

(L2)

【(1,1,2),(1,1,3)】abe

(L3)

【(3,0,3),(3,0,1)】acd

(L4)

滿足路徑覆蓋，未必滿足條件組合覆蓋，通常把兩種覆蓋結合起來測試。 第七十四頁，共一百三十二頁，2022年，8月28日7.6.2控制結構測試1.基本路徑測試基本思想：在程序控制流圖的基礎上，首先計算程序的環(huán)形復雜度，并用該復雜度為指南定義基本可執(zhí)行路徑集合，從該基本集合導出的測試用例可以保證程序中的每條語句至少執(zhí)行一次，而且每個條件在執(zhí)行時都將分別取真、假兩種值。第七十五頁，共一百三十二頁，2022年，8月28日基本路徑測試的步驟設計測試用例的步驟如下：第一步，根據過程設計結果畫出相應的流圖。第二步，計算流圖的環(huán)形復雜度。環(huán)形復雜度定量度量程序的邏輯復雜性?？梢杂?種方法之一計算環(huán)形復雜度。圖7.6所示流圖的環(huán)形復雜度為6。第三步，確定線性獨立路徑的基本集合。第七十六頁，共一百三十二頁，2022年，8月28日第七十七頁，共一百三十二頁，2022年，8月28日獨立路徑是指至少引入程序的一個新處理語句集合或一個新條件的路徑，即獨立路徑至少包含一條在定義該路徑之前不曾用過的邊。程序的環(huán)形復雜度決定了程序中獨立路徑的數量，這個數是確保程序中所有語句至少被執(zhí)行一次所需的測試數量的上界。圖7.6所描述的求平均值過程共有6條獨立路徑。Path1:1-2-10-11-13Path2:1-2-10-12-13Path3:1-2-3-10-11-13Path4:1-2-3-4-5-8-9-2-…Path5:1-2-3-4-5-6-8-9-2-…Path6:1-2-3-4-5-6-7-8-9-2-…獨立路徑第七十八頁，共一百三十二頁，2022年，8月28日第四步，設計可強制執(zhí)行基本集合中每條路徑的測試用例。某些獨立路徑不能以獨立的方式測試(程序的正常流程不能形成獨立執(zhí)行該路徑所需要的數據組合)，這些路徑必須作為另一個路徑的一部分來測試。基本路徑測試的步驟第七十九頁，共一百三十二頁，2022年，8月28日為每一條獨立路徑設計測試用例。假設：n=5；minimum=0；maximum=100。路徑1：1-2-10-11-13測試數據：value=[90，-999，0，0，0]預期結果：Average=90，total.input=1，total.valid=1路徑2：1-2-10-12-13測試數據：value=[-999，0，0，0，0]預期結果：Average=-999，total.input=0，total.valid=0第八十頁，共一百三十二頁，2022年，8月28日路徑3：1-2-3-10-11-13測試數據：value=[-1，90，70，-1，80]預期結果：Average=80，total.input=5，total.valid=3路徑4：1-2-3-4-5-8-9-2-10-12-13測試數據：value=[-1，-2，-3，-4，-999]預期結果：Average=-999，total.input=4，total.valid=0第八十一頁，共一百三十二頁，2022年，8月28日路徑5：1-2-3-4-5-6-8-9-2-10-12-13測試數據：value=[120，110，101，-999，0]預期結果：Average=-999，total.input=3，total.valid=0路徑6：1-2-3-4-5-6-7-8-9-2-10-11-13測試數據：value=[95，90，70，65，-999]預期結果：Average=80，total.input=4，total.valid=4第八十二頁，共一百三十二頁，2022年，8月28日2.條件測試測試用例能夠檢查程序模塊中包含的邏輯條件。條件成分的類型包括布爾算符、布爾變量、布爾括弧（括住簡單條件或復合條件）、關系算符及算術表達式。如果條件不正確，則至少條件的一個成分不正確。1、布爾算符錯2、布爾變量錯3、布爾括弧錯4、關系算符錯5、算術表達式錯第八十三頁，共一百三十二頁，2022年，8月28日條件測試策略1、分支測試：復合條件C的真分支和假分支中的每個簡單條件都至少執(zhí)行一次；2、域測試：每個關系表達式執(zhí)行3或4個測試，如果E1<關系算符>E2要執(zhí)行大于、等于和小于；3、布爾變量測試：有n個變量的布爾表達式要測試2n

個測試；4、BRO測試：利用條件C的條件約束來設計測試用例,如果布爾運算符和關系運算符只出現一次而且沒有公共變的條件下，BRO測試可以發(fā)現布爾運算符和關系運算符錯誤。包括n個簡單條件的條件C的約束條件定義為（D1,D2,…DN）,其中Di表示第i個簡單條件的輸出約束第八十四頁，共一百三十二頁，2022年，8月28日BRO測試舉例：例1：C1：B1&B2B1,B2為布爾變量。C1的條件約束形如（D1，D2），其中D1和D2的值是t或f。BRO測試策略要求約束集{(t,t),(f,t),(t,f)}由C1的執(zhí)行所覆蓋，如果C1由于布爾運算符錯誤而不正確，該約束集中至少有一個約束強制C1失敗。例2：C2：B1&(E3=E4){(t,=),(f,=),(t,<),(t,>)}，此約束集的覆蓋率將保證檢測C2的布爾運算符和關系運算符錯誤。例3：C3:（E1>E2）&（E3=E4）{(>,=),(=,=),(<,=),(>,<),(>,>)}編程者經?；煜齼山M運算符：（&&，||，！）和（&，|，^）。第一組是邏輯運算符，它的操作數是布爾型，而第二組則是位運算符，其操作數是位序列。第八十五頁，共一百三十二頁，2022年，8月28日3.循環(huán)測試重點測試循環(huán)結構的有效性。在結構化的程序中通常只有3種循環(huán)，即簡單循環(huán)、串接循環(huán)和嵌套循環(huán)第八十六頁，共一百三十二頁，2022年，8月28日測試簡單循環(huán)（1）測試簡單循環(huán)：其中n是允許通過循環(huán)的最大次數。測試一下內容：跳過循環(huán)。只通過循環(huán)一次。通過循環(huán)兩次。通過循環(huán)m次，其中m<n-1。通過循環(huán)n-1,n,n+1次。第八十七頁，共一百三十二頁，2022年，8月28日測試嵌套循環(huán)（2）嵌套循環(huán)（直接應用簡單循環(huán)測試方法，測試數會隨嵌套層數的增加按幾何級數增長）從最內層循環(huán)開始測試，使用簡單循環(huán)測試方法，使外層循環(huán)的迭代參數（循環(huán)計數器）取最小值（為越界值或非法值進行額外的測試）。由內向外，對下一個循環(huán)進行測試，但保持所有其他外層循環(huán)為最小值，其他嵌套循環(huán)為“典型”值。繼續(xù)進行下去，直到測試完所有循環(huán)。第八十八頁，共一百三十二頁，2022年，8月28日測試串接循環(huán)（3）串接循環(huán)：如果串接循環(huán)的各個循環(huán)都彼此獨立，則可以使用前述的測試簡單循環(huán)的方法來測試串接循環(huán)。如果兩個循環(huán)串接，而且第一個循環(huán)的循環(huán)計數器值是第二個循環(huán)的初始值，則這兩個循環(huán)并不是獨立的。當循環(huán)不獨立時，建議使用測試嵌套循環(huán)的方法來測試串接循環(huán)。第八十九頁，共一百三十二頁，2022年，8月28日7.7黑盒測試技術黑盒測試著重測試軟件功能。白盒測試在測試過程的早期進行，而黑盒測試主要用于測試過程的后期。二者是互補的測試方法。力圖發(fā)現下述類型的錯誤：①功能不正確或遺漏了功能；②界面錯誤；③數據結構錯誤或外部數據庫訪問錯誤；④性能錯誤；⑤初始化和終止錯誤。白盒測試也稱結構測試或邏輯驅動測試，它是按照程序內部的結構測試程序，通過測試來檢測產品內部動作是否按照設計規(guī)格說明書的規(guī)定正常進行，檢驗程序中的每條通路是否都能按預定要求正確工作。第九十頁，共一百三十二頁，2022年，8月28日黑盒測試用見方法等價類劃分邊界值分析錯誤推測第九十一頁，共一百三十二頁，2022年，8月28日如何劃分等價類？有效等價類(合理等價類)無效等價類(不合理等價類)

劃分等價類的標準：覆蓋不相交代表性7.7.1等價劃分第九十二頁，共一百三十二頁，2022年，8月28日劃分等價類的規(guī)則

(1)如果輸入條件規(guī)定了一個范圍，可定義一個有效等價類和兩個無效等價類。例

輸入值是學生成績，范圍是0～100第九十三頁，共一百三十二頁，2022年，8月28日

劃分等價類的規(guī)則（2）如果輸入條件規(guī)定了輸入數據值的集合或必須遵循的規(guī)則，則可以確定出一個有效的等價類和若干個無效的等價類；例如：Pascal語言規(guī)定“一個語句必須以分號‘;’結束”。這時，可以確定一個有效等價類“以‘;’結束”，若干個無效等價類“以‘:’結束”、“以‘,’結束”、“以‘’結束”、“以LF結束”等。例如：在Pascal語言中對變量標識符規(guī)定為“以字母打頭的……串”。那么所有以字母打頭的構成有效等價類，而不在此集合內（不以字母打頭）的歸于無效等價類。（3）如果輸入條件是一個布爾量，則可以確定一個有效等價類和一個無效等價類。

第九十四頁，共一百三十二頁，2022年，8月28日劃分等價類的規(guī)則(4)如果規(guī)定了輸入數據的一組值，而且程序要對每個輸入值分別進行處理。這時可為每一個輸入值確立一個有效等價類，此外針對這組值確立一個無效等價類，它是所有不允許的輸入值的集合。例如，在教師上崗方案中規(guī)定對教授、副教授、講師和助教分別計算分數，做相應的處理。因此可以確定4個有效等價類為教授、副教授、講師和助教；一個無效等價類，它是所有不符合以上身分的人員的輸入值的集合，如工程師、技術員、科長等。第九十五頁，共一百三十二頁，2022年，8月28日確立測試用例的原則建立等價類表，列出所有劃分出的等價類。再從劃分出的等價類中按以下原則選擇測試用例：

(1)

設計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋的有效等價類，重復這一步，直到所有的有效等價類都被覆蓋為止；

(2)

設計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步，直到所有的無效等價類都被覆蓋為止。第九十六頁，共一百三十二頁，2022年，8月28日

例：用在某一PASCAL語言版本中規(guī)定：“標識符是由字母開頭，后跟字母或數字的任意組合構成。有效字符數為8個，最大字符數為80個。” 并且規(guī)定：“標識符必須先說明，再使用?！薄霸谕徽f明語句中，標識符至少必須有一個?！?/p>

等價類劃分法實例第九十七頁，共一百三十二頁，2022年，8月28日建立輸入等價類表第九十八頁，共一百三十二頁，2022年，8月28日下面選取了9個測試用例，它們覆蓋了所有的等價類。

①VARx，T1234567：REAL；

BEGINx:=3.414；

T1234567:=2.732；

...…(1),(2),(4),(8),(9),(12),(14)

②VAR：REAL；(3)

③VARx，：REAL;(5)

④VART12345678：REAL；(6)⑤VART12345......：REAL；(7)

多于80個字符⑥VART$：CHAR；(10)⑦VARGOTO：INTEGER；(11)⑧VAR2T：REAL；(13)⑨VARPAR：REAL；(15)

BEGIN......

PAP:=SIN(3.14*0.8)/6；等價類劃分法實例第九十九頁，共一百三十二頁，2022年，8月28日

例如：某一報表處理系統(tǒng)，要求用戶輸入處理報表的日期。假設日期限制在1990年1月至1999年12月，即系統(tǒng)只能對該段時期內的報表進行處理。如果用戶輸入的日期不在此范圍內，則顯示輸入錯誤信息。該系統(tǒng)規(guī)定日期由年、月的6位數字字符組成，前4位代表年，后兩位代表月?，F用等價類劃分法設計測試用例，來測試程序的“日期檢查功能”。等價類劃分法實例第一百頁，共一百三十二頁，2022年，8月28日①劃分等價類并編號:劃分成3個有效等價類，7個無效等價類，如表5-3所示。②為合理等價類設計測試用例，對于表中編號為1,5,8對應的3個合理等價類，用一個測試用例覆蓋。等價類劃分法實例第一百零一頁，共一百三十二頁，2022年，8月28日③為每一個不合理等價類至少設計一個測試用例:

測試數據期望結果覆蓋范圍

99MAY輸入無效219995輸入無效31999005輸入無效4198912輸入無效6200001輸入無效7199900輸入無效9199913輸入無效10等價類劃分法實例第一百零二頁，共一百三十二頁，2022年，8月28日7.7.2邊界值分析人們從長期的測試工作經驗得知，大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，而不是在輸入范圍的內部。如:下標、循環(huán)的邊界設計使程序運行在邊界情況附近的測試方案，暴露出程序錯誤的可能性更大一些。第一百零三頁，共一百三十二頁，2022年，8月28日三角形的邊長例如：在做三角形計算時，要輸入三角形的三個邊長：A、B和C。我們應注意到這三個數值應當滿足

A＞0、B＞0、C＞0、

A＋B＞C、A＋C＞B、B＋C＞A，才能構成三角形。但如果把六個不等式中的任何一個大于號“＞”錯寫成大于等于號“≥”，那就不能構成三角形。問題恰出現在容易被疏忽的邊界附近。第一百零四頁，共一百三十二頁，2022年，8月28日邊界值分析法測試方案首先確定邊界情況，通常輸入等價類和輸出等價類的邊界，就是應該著重測試的程序邊界情況。選取剛好等于、稍小于和稍大于等價類邊界值的數據作為測試數據。通常聯合使用等價劃分和邊界值分析兩種技術。第一百零五頁，共一百三十二頁，2022年，8月28日

例如：若輸入值的范圍是［1，100］，可取0，1，100，101等值作為測試數據。若一個輸入文件可包括1~255個記錄，則分別設計有1個記錄、255個記錄，以及0個記錄和256個記錄的輸入文件的測試用例。若只能查詢05~09級大學生的各科成績，測試用例應查詢范圍內的某一屆或五屆學生的學生成績，還需設計查詢04級、10級學生成績的測試用例（不合理輸出等價類）。

邊界值分析法測試方案第一百零六頁，共一百三十二頁，2022年，8月28日錯誤推測法主要靠直覺和經驗進行。依據常見錯誤的清單，列出可能有的錯誤和容易發(fā)生錯誤的特殊情況，選擇測試方案。輸入或輸出數據為零個時往往容易發(fā)生錯誤數據庫操作輸出結果為空時，容易出錯7.7.3錯誤推測第一百零七頁，共一百三十二頁，2022年，8月28日例如，測試一個排序子程序，可考慮如下情況：輸入表為空；輸入表只有一個元素；輸入表的所有元素都相同；輸入表已排序。又如，測試二分法檢索子程序，可考慮如下情況：表中只有一個元素；表長為2n；表長為2n-1；表長為2n+1第一百零八頁，共一百三十二頁，2022年，8月28日其它方法判定表或判定樹：適合多個輸入數據組合的情況，列出輸入數據各種組合與程序應作的動作(及相應的輸出結果)之間的對應關系，然后為判定表的每一列至少設計一個測試用例。因果圖：適合描述在測試時必須考慮對于多種輸入條件的組合，相應產生多個動作的形式來設計測試用例，最終生成判定表?？梢园延嬎銠C測試和人工檢查代碼結合起來選擇輸入組合。第一百零九頁，共一百三十二頁，2022年，8月28日第一百一十頁，共一百三十二頁，2022年，8月28日系統(tǒng)測試（SystemTesting）系統(tǒng)測試是對整個基于計算機的系統(tǒng)進行的一系列測試。系統(tǒng)測試的種類很多，每種測試都有不同的目的，它們從不同的角度測試計算機系統(tǒng)是否被正常地集成，并完成相應的功能。常用的系統(tǒng)測試包括：恢復測試（recoverytesting）安全測試（securitytesting）壓力測試（stresstesting）性能測試（performancetesting）第一百一十一頁，共一百三十二頁，2022年，8月28日恢復測試（recoverytesting）恢復測試是通過各種手段，強制軟件發(fā)生故障，然后來驗證系統(tǒng)能否在指定的時間間隔內恢復正常，包括修正錯誤并重新啟動系統(tǒng)。如果恢復是由系統(tǒng)自身來完成的，那么，需驗證重新初始化、檢查點機制、數據恢復和重啟動等的正確性。如果恢復需要人工干預，那么要估算平均修復時間MTTR（meantimetorepair）是否在用戶可以接受的范圍內。第一百一十二頁，共一百三十二頁，2022年，8月28日安全測試（securitytesting）安全測試用來驗證集成在系統(tǒng)中的保護機制能否實際保護系統(tǒng)不受非法侵入。在安全測試過程中，測試者扮演一個試圖攻擊系統(tǒng)的角色，采用各種方式攻擊系統(tǒng)。例如，截取或碼譯密碼；借助特殊軟件攻擊系統(tǒng)；“制服”系統(tǒng)，使他人無法訪問；故意導致系統(tǒng)失效，企圖在系統(tǒng)恢復之機侵入系統(tǒng)；通過瀏覽非保密數據，從中找出進入系統(tǒng)的鑰匙等等。一般來說，只要有足夠的時間和資源，好的完全測試一定能最終侵入系統(tǒng)。系統(tǒng)設計者的任務是把系統(tǒng)設計成：攻破系統(tǒng)所付出的代價大于攻破系統(tǒng)后得到信息的價值。第一百一十三頁，共一百三十二頁，2022年，8月28日壓力測試（stresstesting）壓力測試也稱強度測試，它是在一種需要非正常數量、頻率或容量的方式下執(zhí)行系統(tǒng)，其目的是檢查系統(tǒng)對非正常情況的承受程度。例如：當系統(tǒng)的中斷頻率是每秒1或2個時，執(zhí)行每秒10個中斷的測試用例將輸入數據的數量提高一個數量級來測試輸入功能如何響應執(zhí)行需要最大內存或其它資源的測試用例執(zhí)行可能導致大量磁盤駐留數據的測試用例第一百一十四頁，共一百三十二頁，2022年，8月28日性能測試（performancetesting）性能測試用來測試軟件在集成的系統(tǒng)中的運行性能。它對實時系統(tǒng)和嵌入式系統(tǒng)尤為重要。性能測試可以發(fā)生在測試過程的所有步驟中單元測試時，主要測試一個獨立模塊的性能，如算法的執(zhí)行速度。軟件集成后，進行軟件整體的性能測試。計算機系統(tǒng)集成后，進行整個計算機系統(tǒng)的性能測試。性能測試常常需要與壓力測試結合起來進行，而且常常需要一些硬件和軟件測試設備，以監(jiān)測系統(tǒng)的運行情況。第一百一十五頁，共一百三十二頁，2022年，8月28日7.8調試（糾錯）調試是在測試發(fā)現錯誤之后排除錯誤的過程。調試過程有兩種結果：①找到了問題的原因并改正和排除了問題；②沒找出問題的原因。猜想原因，設計測試用例來驗證假設，重復此過程直至找到原因并改正了錯誤。是把軟件錯誤的癥狀和內在原因聯系起來的智力過程，很大程度上依賴于軟件工程師的經驗和技巧。第一百一十六頁，共一百三十二頁，2022年，8月28日7.8.1調試過程第一百一十七頁，共一百三十二頁，2022年，8月28日軟件錯誤的特征（1）癥狀所在的模塊和產生癥狀的原因模塊可能在程序中相距甚遠。緊耦合時更加典型。（2）當改正了另一個錯誤之后，癥狀可能暫時消失。（3）癥狀可能實際上并不是由錯誤引起的（如誤差）。（4）癥狀可能是由不易跟蹤的人為錯誤引起的。（5）癥狀可能是由定時問題而不是由處理問題引起的。（6）可能很難重新產生完全一樣的輸入條件（例如，輸入順序不確定的實時應用系統(tǒng)）。（7）癥狀可能時有時無。在嵌入式系統(tǒng)中特別常見。（8）癥狀可能是由分布運行在不同的處理機上的任務中的原因引起的。第一百一十八頁，共一百三十二頁，2022年，8月28日調試的困難調試是軟件開發(fā)過程中最艱巨的腦力勞動。確定發(fā)生錯誤的內在原因和位置占整個調試工作量的90%左右。為什么調試這么困難？1、軟件錯誤本身的特征2、心理方面的原因多于技術方面的原因3、與測試比較，調試技術缺乏系統(tǒng)的理論研究,調試方法多是實踐中的經驗積累。4、錯誤的后果越嚴重，查找錯誤原因的壓力也越大。導致軟件開發(fā)人員在改正一個錯誤的同時引入兩個甚至更多個錯誤。第一百一十九頁，共一百三十二頁，2022年，8月28日7.8.2調試途徑經驗：在調試之前，首先進行周密的思考，明確目的，盡量減少無關信息的數量。1.蠻干法1)在程序中插入打印語句比較容易檢查源程序的有關信息，但低效率，有偶然性。2)運行部分程序把不需要執(zhí)行的語句段前和后加上注釋符，使這段程序不再執(zhí)行。調試過后，再將注釋符去掉。在不需要執(zhí)行的語句段前加判定值為“假”的IF語句或者加GOTO語句，使該程序不執(zhí)行。調試結束后，再撤銷這些語句，使程序復原。3)借助于調試工具追蹤子程序調用、循環(huán)與分支執(zhí)行路徑、特定變量的變化情況；利用“置斷點”可以執(zhí)行特定語句或改變特定變量值引起的程序中斷，以便檢查程序的當前狀態(tài)。第一百二十頁，共一百三十二頁，2022年，8月28日調試途徑2.回溯法是一種相當常用的調試方法，當調試小程序時這種方法是有效的。從發(fā)現癥狀的地