第11章-軟件測試課件

1、內(nèi)容摘要內(nèi)容摘要一軟件測試基礎(chǔ)二白盒測試三黑盒測試四測試策略五面向?qū)ο鬁y試六測試完成標(biāo)準(zhǔn)七調(diào)試內(nèi)容摘要內(nèi)容摘要二白盒測試三黑盒測試四測試策略五面向?qū)ο鬁y試六測試完成標(biāo)準(zhǔn)七調(diào)試軟件測試基礎(chǔ)軟件測試基礎(chǔ)一一軟件測試的目的軟件測試的目的二二軟件測試的基本原則軟件測試的基本原則三三白盒測試和黑盒測試白盒測試和黑盒測試有關(guān)軟件測試的錯誤觀點有關(guān)軟件測試的錯誤觀點一 “軟件測試是為了證明程序是正確的，即測試能發(fā)現(xiàn)程序中所有的錯誤”。u事實上這是不可能的。要通過測試發(fā)現(xiàn)程序中的所有錯誤，就要窮舉所有可能的輸入數(shù)據(jù)。例如：(1) 對于一個輸入三個16位字長的整型數(shù)據(jù)的程序，輸入數(shù)據(jù)的所有組合情況有2*48 ，

2、如果測試一個數(shù)據(jù)需1ms，則即使一年365天一天24小時不停地測試，也需要約1萬年。(2) 對一個具有多重選擇和循環(huán)嵌套的程序，不同的路徑數(shù)目可能是天文數(shù)字。例如一個小程序的流程圖，它包括了一個執(zhí)行20次的循環(huán)，其循環(huán)體有五個分支。這個循環(huán)的不同執(zhí)行路徑數(shù)達(dá)5*20條，如果對每一條路徑進(jìn)行測試需要1毫秒，那么即使一年工作365 24小時，要想把所有路徑測試完，大約需3170年。一 “程序測試是證明程序正確地執(zhí)行了預(yù)期的功能”。實際上，一個程序不僅要完成它所需完成的功能，而且不應(yīng)完成它不該做的事。例：三條邊相等的三角形是等邊三角形。如不能把邊長為0、0、0的三條邊判斷為等邊三角形。有關(guān)軟件測試的

3、錯誤觀點有關(guān)軟件測試的錯誤觀點軟件測試的目的軟件測試的目的uGlen Myers給出的軟件測試目的：給出的軟件測試目的：測試是一個為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程測試是一個為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程一個好的測試用例是指很可能找到迄今為至尚未發(fā)現(xiàn)一個好的測試用例是指很可能找到迄今為至尚未發(fā)現(xiàn)的錯誤的測試用例的錯誤的測試用例一個成功的測試是指揭示了迄今為至尚未發(fā)現(xiàn)的錯誤一個成功的測試是指揭示了迄今為至尚未發(fā)現(xiàn)的錯誤的測試的測試 根據(jù)這個測試目的，我們應(yīng)該排除對測試的錯誤觀點，根據(jù)這個測試目的，我們應(yīng)該排除對測試的錯誤觀點，設(shè)計合適的測試用例，用盡可能少的測試用例，來發(fā)現(xiàn)設(shè)計合適的測試用例，用盡可能少

4、的測試用例，來發(fā)現(xiàn)盡可能多的軟件錯誤。盡可能多的軟件錯誤。軟件測試的原則軟件測試的原則Davis提出了一組指導(dǎo)軟件測試的基本原則：提出了一組指導(dǎo)軟件測試的基本原則：1. 所有的測試都應(yīng)可追溯到客戶需求所有的測試都應(yīng)可追溯到客戶需求2. 應(yīng)該在測試工作真正開始前的較長時間就進(jìn)行測試計劃應(yīng)該在測試工作真正開始前的較長時間就進(jìn)行測試計劃3. Pareto原則：測試中發(fā)現(xiàn)的原則：測試中發(fā)現(xiàn)的80%的錯誤可能來自于的錯誤可能來自于20%的程序代碼的程序代碼4. 測試應(yīng)從測試應(yīng)從“小規(guī)模小規(guī)?！遍_始，逐步轉(zhuǎn)向開始，逐步轉(zhuǎn)向“大規(guī)模大規(guī)?！?. 窮舉測試是不可能的窮舉測試是不可能的6. 為了達(dá)到最有效的測試

5、，應(yīng)由獨立的第三方來承擔(dān)測試為了達(dá)到最有效的測試，應(yīng)由獨立的第三方來承擔(dān)測試其他的測試原則：其他的測試原則：1.在設(shè)計測試用例時，應(yīng)包括合理的輸入條件和不合理的輸入條件在設(shè)計測試用例時，應(yīng)包括合理的輸入條件和不合理的輸入條件2.嚴(yán)格執(zhí)行測試計劃，排除測試的隨意性嚴(yán)格執(zhí)行測試計劃，排除測試的隨意性3.應(yīng)當(dāng)對每一個測試結(jié)果做全面檢查應(yīng)當(dāng)對每一個測試結(jié)果做全面檢查4.妥善保存測試計劃、測試用例、出錯統(tǒng)計和最終分析報告，為維妥善保存測試計劃、測試用例、出錯統(tǒng)計和最終分析報告，為維護(hù)提供方便護(hù)提供方便5.檢查程序是否做了應(yīng)做的事，僅僅是成功的一半，而成功的另一檢查程序是否做了應(yīng)做的事，僅僅是成功的一半，

6、而成功的另一半是檢查程序是否做了不該做的事半是檢查程序是否做了不該做的事6.在規(guī)劃測試時不要設(shè)想程序中不會查出錯誤在規(guī)劃測試時不要設(shè)想程序中不會查出錯誤軟件測試的原則軟件測試的原則u測試用例u測試用例的設(shè)計是軟件測試的關(guān)鍵所在u設(shè)計盡可能少的測試用例來發(fā)現(xiàn)盡可能多的錯誤u設(shè)計最有可能發(fā)現(xiàn)軟件錯誤的測試用例，同時避免使用發(fā)現(xiàn)錯誤效果相同的測試用例u測試用例的設(shè)計方法大體可分為兩類：白盒測試和黑盒測試，也稱白箱測試和黑箱測試軟件測試的原則軟件測試的原則u白盒測試白盒測試（又稱為結(jié)構(gòu)測試）（又稱為結(jié)構(gòu)測試）把測試對象看作一個透明的盒子，測把測試對象看作一個透明的盒子，測試人員根據(jù)程序內(nèi)部的邏輯結(jié)構(gòu)及

7、有關(guān)信息設(shè)計測試用例，檢查程試人員根據(jù)程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息設(shè)計測試用例，檢查程序中所有邏輯路徑是否都按預(yù)定的要求正確地工作。序中所有邏輯路徑是否都按預(yù)定的要求正確地工作。u白盒測試主要用于對模塊的測試，包括：白盒測試主要用于對模塊的測試，包括：程序模塊中的所有獨立路徑至少執(zhí)行一次程序模塊中的所有獨立路徑至少執(zhí)行一次對所有邏輯判定的取值（對所有邏輯判定的取值（“真真”與與“假假”）都至少測試一次）都至少測試一次在上下邊界及可操作范圍內(nèi)運(yùn)行所有循環(huán)在上下邊界及可操作范圍內(nèi)運(yùn)行所有循環(huán)測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性等測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性等白盒測試與黑盒測試白盒測試與黑盒測試u黑盒測試黑盒測試（

8、又稱行為測試）把測試對象看做一個黑盒子，（又稱行為測試）把測試對象看做一個黑盒子，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能需求。的功能需求。u黑盒測試可用于各種測試，它試圖發(fā)現(xiàn)以下類型的錯誤：黑盒測試可用于各種測試，它試圖發(fā)現(xiàn)以下類型的錯誤：不正確或遺漏的功能不正確或遺漏的功能接口錯誤，如輸入接口錯誤，如輸入/ /輸出參數(shù)的個數(shù)、類型等輸出參數(shù)的個數(shù)、類型等數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息( (如外部數(shù)據(jù)庫如外部數(shù)據(jù)庫

9、) )訪問錯誤訪問錯誤性能錯誤性能錯誤初始化和中止錯誤初始化和中止錯誤白盒測試與黑盒測試白盒測試與黑盒測試內(nèi)容摘要內(nèi)容摘要一軟件測試基礎(chǔ)三黑盒測試四測試策略五面向?qū)ο鬁y試六測試完成標(biāo)準(zhǔn)七調(diào)試白盒測試白盒測試常用的白盒測試方法有：常用的白盒測試方法有：邏輯覆蓋測試邏輯覆蓋測試基本路徑覆蓋測試基本路徑覆蓋測試數(shù)據(jù)流測試數(shù)據(jù)流測試循環(huán)測試循環(huán)測試邏輯覆蓋測試邏輯覆蓋測試 語句覆蓋語句覆蓋 判定覆蓋判定覆蓋 條件覆蓋條件覆蓋 判定條件覆蓋判定條件覆蓋 條件組合覆蓋條件組合覆蓋 路徑覆蓋路徑覆蓋邏輯表達(dá)式錯誤敏感的測試邏輯表達(dá)式錯誤敏感的測試u邏輯覆蓋測試依賴于程序中的邏輯條件，這些邏輯條件由邏輯表達(dá)式

10、組成。對于一個含有n個邏輯變量，或n個關(guān)系表達(dá)式的邏輯表達(dá)式，通常需要2n個測試用例來覆蓋其所有可能的條件組合。u當(dāng)n較大時，我們可以選擇對發(fā)現(xiàn)邏輯表達(dá)式錯誤比較敏感的組合條件進(jìn)行測試，以較少的測試用例來發(fā)現(xiàn)邏輯表達(dá)式中的絕大多數(shù)錯誤?；韭窂綔y試基本路徑測試u在實際問題中，一個不太復(fù)雜的程序，特別是包含循環(huán)的程序，其路徑數(shù)可能非常大。因此測試常常難以做到覆蓋程序中的所有路徑，為此，我們希望把測試的程序路徑數(shù)壓縮到一定的范圍內(nèi)。u基本路徑測試是Tom McCabe提出的一種白盒測試技術(shù)，這種方法首先根據(jù)程序或設(shè)計圖畫出控制流圖，并計算其區(qū)域數(shù)，然后確定一組獨立的程序執(zhí)行路徑（稱為基本路徑），最

11、后為每一條基本路徑設(shè)計一個測試用例。數(shù)據(jù)流測試數(shù)據(jù)流測試u數(shù)據(jù)流測試是根據(jù)程序中變量的定義（賦值）和引用位置來選擇測試用例u假定s為語句的標(biāo)號（每個語句有唯一的標(biāo)號），x為變量名。定義： DEF（s）= x | 語句s中含有對x的定義USE（s）= x | 語句s中含有對x的引用 當(dāng)s為分支或循環(huán)語句時， DEF（s）= 設(shè)變量x在語句s中被定義，如果存在一條從語句s到語句s 的路徑，并且在這條路徑上不存在對x的其它定義，則稱變量x在s處定義在s處仍有效。循環(huán)測試循環(huán)測試u循環(huán)分為4種不同類型：簡單循環(huán)、嵌套循環(huán)、串接循環(huán)和非結(jié)構(gòu)循環(huán)。 循環(huán)測試循環(huán)測試 (1) 簡單循環(huán)簡單循環(huán) 按照下列規(guī)則

12、設(shè)計測試用例：按照下列規(guī)則設(shè)計測試用例： 零次循環(huán)：從循環(huán)入口到出口零次循環(huán)：從循環(huán)入口到出口 一次循環(huán)：檢查循環(huán)初始值一次循環(huán)：檢查循環(huán)初始值 二次循環(huán)：檢查多次循環(huán)二次循環(huán)：檢查多次循環(huán) m次循環(huán)：次循環(huán)： 檢查多次循環(huán)檢查多次循環(huán) 最大次數(shù)循環(huán)最大次數(shù)循環(huán) 比最大次數(shù)多一次的循環(huán)比最大次數(shù)多一次的循環(huán) 比最大次數(shù)少一次的循環(huán)比最大次數(shù)少一次的循環(huán)按照下列規(guī)則設(shè)計測試用例： 先測試最內(nèi)層循環(huán)：所有外層的循環(huán)變量置為最小值，最內(nèi)層按簡單循環(huán)測試； 由里向外，測試上一層循環(huán)：測試時此層以外的所有外層循環(huán)的循環(huán)變量取最小值，此層以內(nèi)的所有嵌套內(nèi)層循環(huán)的循環(huán)變量取“典型”值，該層按簡單循環(huán)測試；

13、重復(fù)上一條規(guī)則，直到所有各層循環(huán)測試完畢；對全部各層循環(huán)同時取最小循環(huán)次數(shù)，同時取最大循環(huán)次數(shù)(2) 嵌套循環(huán)嵌套循環(huán)循環(huán)測試循環(huán)測試(3) 串接循環(huán)串接循環(huán)如果串接的各個循環(huán)互相獨立，則可以分別用簡單循環(huán)的方法進(jìn)行測試；但如果第一個循環(huán)的循環(huán)變量與第二個循環(huán)控制相關(guān)，則兩個循環(huán)不獨立，此時，把第一個循環(huán)看作外循環(huán)，第二個循環(huán)看作內(nèi)循環(huán)，然后用測試嵌套循環(huán)的辦法來處理。(4) 非結(jié)構(gòu)循環(huán)非結(jié)構(gòu)循環(huán)這一類循環(huán)應(yīng)該先將其結(jié)構(gòu)化，然后再測試。這一類循環(huán)應(yīng)該先將其結(jié)構(gòu)化，然后再測試。循環(huán)測試循環(huán)測試內(nèi)容摘要內(nèi)容摘要一軟件測試基礎(chǔ)二白盒測試四測試策略五面向?qū)ο鬁y試六測試完成標(biāo)準(zhǔn)七調(diào)試黑盒測試黑盒測試黑盒

14、測試是依據(jù)軟件的需求規(guī)約，檢查程序黑盒測試是依據(jù)軟件的需求規(guī)約，檢查程序的功能是否符合需求規(guī)約的要求。的功能是否符合需求規(guī)約的要求。主要的黑盒測試方法有：主要的黑盒測試方法有：等價類劃分等價類劃分邊界值分析邊界值分析比較測試比較測試錯誤猜測錯誤猜測因果圖因果圖等價類劃分等價類劃分u由于不能窮舉所有可能的輸入數(shù)據(jù)來進(jìn)行測試，由于不能窮舉所有可能的輸入數(shù)據(jù)來進(jìn)行測試，所以只能所以只能選擇少量有代表性選擇少量有代表性的輸入數(shù)據(jù)，來揭的輸入數(shù)據(jù)，來揭露盡可能多的程序錯誤露盡可能多的程序錯誤u等價類劃分方法等價類劃分方法將所有可能的輸入數(shù)據(jù)劃分成將所有可能的輸入數(shù)據(jù)劃分成若干個等價類，然后在每個等價類中

15、選取一個若干個等價類，然后在每個等價類中選取一個代表性的數(shù)據(jù)作為測試用例代表性的數(shù)據(jù)作為測試用例一 等價類劃分方法把輸入數(shù)據(jù)分為有效輸入數(shù)據(jù)和無效輸入數(shù)據(jù)二 有效輸入數(shù)據(jù)指符合規(guī)格說明要求的合理的輸入數(shù)據(jù)，主要用來檢驗程序是否實現(xiàn)了規(guī)格說明中的功能三 無效輸入數(shù)據(jù)指不符合規(guī)格說明要求的不合理或非法的輸入數(shù)據(jù)，主要用來檢驗程序是否做了規(guī)格說明以外的事四 在確定輸入數(shù)據(jù)等價類時，常常還要分析輸出數(shù)據(jù)的等價類，以便根據(jù)輸出數(shù)據(jù)等價類導(dǎo)出輸入數(shù)據(jù)等價類。等價類劃分等價類劃分等價類劃分設(shè)計測試用例的步驟等價類劃分設(shè)計測試用例的步驟一一確定等價類確定等價類根據(jù)軟件的規(guī)格說明，對每一個輸入條件（通常是規(guī)格根

16、據(jù)軟件的規(guī)格說明，對每一個輸入條件（通常是規(guī)格說明中的一句話或一個短語）確定若干個有效等價類和說明中的一句話或一個短語）確定若干個有效等價類和若干個無效等價類。若干個無效等價類?？墒褂萌缦卤砀窨墒褂萌缦卤砀褫斎霔l件輸入條件有效等價類有效等價類 無效等價類無效等價類一一確定等價類的規(guī)則：確定等價類的規(guī)則： 如果輸入條件規(guī)定了取值范圍，則可以確定一個有效等價如果輸入條件規(guī)定了取值范圍，則可以確定一個有效等價類（輸入值在此范圍內(nèi)）和兩個無效等價類（輸入值小于最類（輸入值在此范圍內(nèi)）和兩個無效等價類（輸入值小于最小值及大于最大值）小值及大于最大值）等價類劃分設(shè)計測試用例的步驟等價類劃分設(shè)計測試用例的步

17、驟一一設(shè)計測試用例設(shè)計測試用例在確定了等價類之后，建立等價類表，列出所有劃分出在確定了等價類之后，建立等價類表，列出所有劃分出的等價類。并為每個有效等價類和無效等價類編號。的等價類。并為每個有效等價類和無效等價類編號。 等價類劃分設(shè)計測試用例的步驟等價類劃分設(shè)計測試用例的步驟邊界值分析邊界值分析u邊界值分析也是一種黑盒測試方法，是對等價類劃分邊界值分析也是一種黑盒測試方法，是對等價類劃分方法的補(bǔ)充。方法的補(bǔ)充。u人們從長期的測試工作經(jīng)驗得知，人們從長期的測試工作經(jīng)驗得知，大量的錯誤是發(fā)生大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，在輸入或輸出范圍的邊界上，而不是在輸入范圍的內(nèi)而不是在輸入范圍的內(nèi)

18、部。因此針對各種邊界情況設(shè)計測試用例，其揭露程部。因此針對各種邊界情況設(shè)計測試用例，其揭露程序中錯誤的可能性就更大。序中錯誤的可能性就更大。u邊界值分析方法選擇測試用例的規(guī)則如下：1如果輸入條件規(guī)定了值的范圍，則選擇剛剛達(dá)到這個范圍的邊界的值以及剛剛超出這個范圍的邊界的值作為測試輸入數(shù)據(jù)。2如果輸入條件規(guī)定了值的個數(shù)，則分別選擇最大個數(shù)、最小個數(shù)、比最大個數(shù)多1、比最小個數(shù)少1的數(shù)據(jù)作為測試輸入數(shù)據(jù)。3對每個輸出條件使用第1條。4對每個輸出條件使用第2條。5如果程序的輸入或輸出是個有序集合，例如，順序文件、表格，則應(yīng)把注意力集中在有序集的第1個元素和最后一個元素上。6如果程序中定義的內(nèi)部數(shù)據(jù)結(jié)

19、構(gòu)有預(yù)定義的邊界，則應(yīng)選擇使得正好達(dá)到該數(shù)據(jù)結(jié)構(gòu)邊界以及剛好超出該數(shù)據(jù)結(jié)構(gòu)邊界的輸入數(shù)據(jù)作為測試數(shù)據(jù)。7發(fā)揮你的智慧，找出其他可能的邊界條件。 邊界值分析邊界值分析比較測試（比較測試（back to back）u在現(xiàn)實中，有些軟件有很高的可靠性要求，特別是那些可能危及人的生命安全的軟件系統(tǒng)，如航空航天控制軟件、核電廠控制軟件等，其軟件可靠性絕對重要。此時，需要冗余的硬件和軟件來減少錯誤發(fā)生的可能性。u通常，可由二支軟件開發(fā)隊伍，根據(jù)相同的需求規(guī)格說明分別開發(fā)二個軟件版本，然后，用相同的測試用例對二個版本的軟件分別進(jìn)行測試，比較二個版本軟件的測試結(jié)果，如果測試結(jié)果相同，則可認(rèn)為二個版本的軟件都是

20、正確的，如果測試結(jié)果不同，則要分析各個版本，以發(fā)現(xiàn)錯誤的所在。這種測試稱為比較測試或稱為背靠背測試（backtoback testing）。大多數(shù)情況下，可用自動化工具來進(jìn)行比較測試。u值得注意的是，比較測試并不能保證軟件沒有錯誤，如果規(guī)格說明本身有錯，那么所有的版本都可能反映這種錯誤。u另外，如果各個版本產(chǎn)生相同的，但都不正確的結(jié)果，那么比較測試也無法發(fā)現(xiàn)這種錯誤。比較測試（比較測試（back to back）錯誤推測法錯誤推測法u錯誤猜測是一種憑直覺和經(jīng)驗推測某些可能存在的錯誤，從而針對這些可能存在的錯誤設(shè)計測試用例的方法。u這種方法沒有機(jī)械的執(zhí)行步驟，主要依靠直覺和經(jīng)驗。u錯誤猜測法的基

21、本思想是：列舉出程序中所有可能的錯誤和容易發(fā)生錯誤的特殊情況，然后根據(jù)這些猜測設(shè)計測試用例。內(nèi)容摘要內(nèi)容摘要一軟件測試基礎(chǔ)二白盒測試三黑盒測試五面向?qū)ο鬁y試六測試完成標(biāo)準(zhǔn)七調(diào)試測試策略測試策略u一種測試策略就是將測試分為單元測試、集成測試、確認(rèn)測試和系統(tǒng)測試。u單元測試是針對程序中的模塊或構(gòu)件，主要揭露編碼階段產(chǎn)生的錯誤。u集成測試針對集成的軟件系統(tǒng)，主要揭露設(shè)計階段產(chǎn)生的錯誤。u確認(rèn)測試是根據(jù)軟件需求規(guī)約對集成的軟件進(jìn)行確認(rèn)，主要揭露不符合需求規(guī)約的錯誤。u對于基于計算機(jī)系統(tǒng)中的軟件，還需將它集成到基于計算機(jī)系統(tǒng)中，并進(jìn)行系統(tǒng)測試，以揭露不符合系統(tǒng)工程中對軟件要求的錯誤。uV模型：描述軟件開

22、發(fā)各階段與測試策略之間的對應(yīng)關(guān)模型：描述軟件開發(fā)各階段與測試策略之間的對應(yīng)關(guān)系系。系統(tǒng)工程系統(tǒng)工程需求分析需求分析設(shè)計設(shè)計編碼編碼系統(tǒng)測試系統(tǒng)測試確認(rèn)測試確認(rèn)測試集成測試集成測試單元測試單元測試測試策略測試策略uTom Gilb指出實現(xiàn)一個成功的軟件測試策略必須涉及的指出實現(xiàn)一個成功的軟件測試策略必須涉及的問題：問題：1.在著手開始測試之前的較長時間，就要以量化的形式確定產(chǎn)品的需求。在著手開始測試之前的較長時間，就要以量化的形式確定產(chǎn)品的需求。2.顯式地陳述測試目標(biāo)。顯式地陳述測試目標(biāo)。3.了解軟件的用戶并為每一類用戶建立剖面（了解軟件的用戶并為每一類用戶建立剖面（profile）圖）圖4.建

23、立一個強(qiáng)調(diào)建立一個強(qiáng)調(diào)“快速循環(huán)（快速循環(huán)（rapid cycle）測試）測試”的測試計劃。的測試計劃。5.構(gòu)造構(gòu)造“健壯健壯”的軟件，它被設(shè)計成可測試自身。的軟件，它被設(shè)計成可測試自身。6.使用有效的正式技術(shù)評審，作為測試之前的過濾器。使用有效的正式技術(shù)評審，作為測試之前的過濾器。7.使用正式技術(shù)評審，來評估測試策略和測試用例本身。使用正式技術(shù)評審，來評估測試策略和測試用例本身。8.為測試過程建立一種持續(xù)改進(jìn)的方法。為測試過程建立一種持續(xù)改進(jìn)的方法。測試策略測試策略單元測試單元測試 (Unit Testing)u單元測試又稱模塊測試，它著重對軟件設(shè)計的最小單元（軟件構(gòu)件或模塊）進(jìn)行驗證u單元

24、測試根據(jù)設(shè)計描述，對重要的控制路徑進(jìn)行測試，以發(fā)現(xiàn)構(gòu)件或模塊內(nèi)部的錯誤u單元測試通常采用白盒測試，并且多個構(gòu)件或模塊可以并行進(jìn)行測試u這里將構(gòu)件或模塊統(tǒng)一稱為模塊 單元測試的內(nèi)容u模塊接口：確保模塊的輸入/輸出參數(shù)信息是正確的。這些信息包括參數(shù)的個數(shù)、次序、類型等。u局部數(shù)據(jù)結(jié)構(gòu)：確保臨時存儲的數(shù)據(jù)在算法執(zhí)行的整個過程中都能維持其完整性。如不合適的類型說明、不同數(shù)據(jù)類型的比較或賦值、文件打開和關(guān)閉的遺漏、超越數(shù)據(jù)結(jié)構(gòu)的邊界等。u邊界條件：確保程序單元在極限或嚴(yán)格的情況下仍能正確地執(zhí)行。u所有獨立路徑：確保模塊中的所有語句都至少執(zhí)行一次。程序執(zhí)行的路徑實際上體現(xiàn)了計算的過程，計算中常見的錯誤有：

25、不正確的操作優(yōu)先級、不同類型數(shù)據(jù)間的操作、不正確的初始化、不精確的精度、不正確的循環(huán)中止、不適當(dāng)?shù)匦薷难h(huán)變量、發(fā)散的迭代等。u所有錯誤處理路徑：單元測試應(yīng)該對所有的錯誤處理路徑進(jìn)行測試。錯誤處理部分潛在的錯誤有：報錯信息沒有提供足夠的信息來幫助確定錯誤的性質(zhì)及其發(fā)生的位置、報錯信息與真正的錯誤不一致、錯誤條件在錯誤處理之前就已引起系統(tǒng)異常、異常條件處理不正確等。 單元測試的內(nèi)容集成測試（集成測試（Integrated Testing）u集成測試 也稱組裝測試、聯(lián)合測試u經(jīng)單元測試后，每個模塊都能獨立工作，但把它們放在一起往往不能正常工作。u主要問題在于：主要問題在于：數(shù)據(jù)可能在通過接口時丟失

26、；數(shù)據(jù)可能在通過接口時丟失；一個模塊可能對另一個模塊產(chǎn)生非故意的、有害的影響（即一個模塊可能對另一個模塊產(chǎn)生非故意的、有害的影響（即副作用）；副作用）；當(dāng)子功能被組合起來時，可能不能達(dá)到期望的主功能；當(dāng)子功能被組合起來時，可能不能達(dá)到期望的主功能；單個模塊可以接受的不精確性（如誤差），連接起來后可能單個模塊可以接受的不精確性（如誤差），連接起來后可能會擴(kuò)大到無法接受的程度；會擴(kuò)大到無法接受的程度；全局?jǐn)?shù)據(jù)結(jié)構(gòu)可能會存在問題。全局?jǐn)?shù)據(jù)結(jié)構(gòu)可能會存在問題。集成測試（集成測試（Integrated Testing）u集成的方式有兩種：非增量式集成：使用“一步到位”的方法來構(gòu)造程序。先將所有經(jīng)過單元測

27、試的模塊組合在一起，然后對整個程序（作為一個整體）進(jìn)行測試。這種測試在發(fā)現(xiàn)錯誤時，很難為錯誤定位。改正錯誤時容易引入新的錯誤，新舊錯誤混在一起，更難定位。增量式集成：根據(jù)程序結(jié)構(gòu)圖，按某種次序挑選一個（或一組）尚未測試過的模塊，把它集成到已測試好的模塊中一起進(jìn)行測試，每次增加一個（或一組）模塊，直至所有模塊全部集成到程序中。在增量集成測試過程中發(fā)現(xiàn)的錯誤，往往與新加入的模塊有關(guān)。集成測試（集成測試（Integrated Testing）u增量式集成又可分為自頂向下集成和增量式集成又可分為自頂向下集成和自底向上集成。自底向上集成。集成測試（集成測試（Integrated Testing）回歸測試

28、（回歸測試（Regression Testing）u在集成測試過程中，每當(dāng)增加一個（或一組）新模塊時，原先已集成的軟件就發(fā)生了改變。新的數(shù)據(jù)流路徑被建立，新的I/O操作可能出現(xiàn)，還可能激活新的控制邏輯，這些改變可能使原本正常的功能產(chǎn)生錯誤。u當(dāng)測試時發(fā)現(xiàn)錯誤后，需修改程序；或者在軟件維護(hù)時也需修改程序。這些對程序的修改也可能使原本正常的功能產(chǎn)生錯誤。u回歸測試就是對已經(jīng)進(jìn)行過的測試的子集的重新執(zhí)行，以確保對程序的改變和修改，沒有傳播非故意的副作用。u回歸測試集（已經(jīng)過測試的子集）包括三種不回歸測試集（已經(jīng)過測試的子集）包括三種不同類型的測試用例：同類型的測試用例：能測試軟件所有功能的代表性測試

29、用例能測試軟件所有功能的代表性測試用例專門針對可能會被修改影響的軟件功能的附加測試專門針對可能會被修改影響的軟件功能的附加測試注重于修改過的軟件模塊的測試注重于修改過的軟件模塊的測試回歸測試（回歸測試（Regression Testing）確認(rèn)測試（確認(rèn)測試（Validation Testing）u 確認(rèn)測試標(biāo)準(zhǔn)確認(rèn)測試標(biāo)準(zhǔn)u確認(rèn)測試以確認(rèn)測試以軟件需求規(guī)約為依據(jù)軟件需求規(guī)約為依據(jù)，以發(fā)現(xiàn)軟件與需求不一致的，以發(fā)現(xiàn)軟件與需求不一致的錯誤。錯誤。u主要檢查軟件是否實現(xiàn)了規(guī)約規(guī)定的全部功能要求，文檔資料主要檢查軟件是否實現(xiàn)了規(guī)約規(guī)定的全部功能要求，文檔資料是否完整、正確、合理，其他的需求，如可移植

30、性、可維護(hù)性、是否完整、正確、合理，其他的需求，如可移植性、可維護(hù)性、兼容性、錯誤恢復(fù)能力等是否滿足。兼容性、錯誤恢復(fù)能力等是否滿足。u 確認(rèn)測試的結(jié)果可分為兩類：確認(rèn)測試的結(jié)果可分為兩類：滿足需求規(guī)約要求的功能或性能特性，用戶可以接受。 發(fā)現(xiàn)與需求規(guī)約有偏差，此時需列出問題清單。確認(rèn)測試（確認(rèn)測試（Validation Testing）u 軟件配置評審軟件配置評審軟件配置評審也稱軟件審計（audit），其目的是保證軟件配置的所有成分都齊全，各方面的質(zhì)量都符合要求，具有維護(hù)階段必需的細(xì)節(jié)，而且已經(jīng)編排好分類目錄。軟件配置主要包括計算機(jī)程序（源代碼和可執(zhí)行程序），針對開發(fā)者和用戶的各類文檔，包含

31、在程序內(nèi)部或程序外部的數(shù)據(jù)。軟件配置評審u如果軟件是為一個客戶開發(fā)的，那么，最后由客戶進(jìn)行驗收測試（acceptance test），以使客戶確認(rèn)該軟件是他所需要的。u如果軟件是給許多客戶使用的（如市場上銷售的各種軟件），那么讓每個客戶做驗收測試是不現(xiàn)實的。大多數(shù)軟件廠商都使用一種稱為測試和測試的過程，來發(fā)現(xiàn)那些似乎只有最終用戶才能發(fā)現(xiàn)的錯誤。測試和測試u測試是由一個用戶在開發(fā)者的場所進(jìn)行的，軟件在開發(fā)者在用戶的“指導(dǎo)下”進(jìn)行測試。經(jīng)測試后的軟件稱為版軟件。u測試是由軟件的最終用戶在一個或多個用戶場所進(jìn)行的，與測試不同，開發(fā)者通常不在測試現(xiàn)場，因此，測試是軟件在一個開發(fā)者不能控制的環(huán)境中的“活

32、的”應(yīng)用，用戶記錄所有在測試中遇到的（真正的或想象的）問題，并定期把這些問題報告給開發(fā)者，在接到測試的問題報告后，開發(fā)者對軟件進(jìn)行最后的修改，然后著手準(zhǔn)備向所有的用戶發(fā)布最終的軟件產(chǎn)品。測試和測試系統(tǒng)測試（系統(tǒng)測試（System Testing）u系統(tǒng)測試是對整個基于計算機(jī)的系統(tǒng)進(jìn)行的一系列測試。u系統(tǒng)測試的種類很多，每種測試都有不同的目的，它們從不同的角度測試計算機(jī)系統(tǒng)是否被正常地集成，并完成相應(yīng)的功能。u常用的系統(tǒng)測試包括：恢復(fù)測試（recovery testing）安全測試（security testing）壓力測試（stress testing）性能測試（performance tes

33、ting）恢復(fù)測試（恢復(fù)測試（recovery testing）u恢復(fù)測試是通過各種手段，強(qiáng)制軟件發(fā)生故障，然后來驗證系統(tǒng)能否在指定的時間間隔內(nèi)恢復(fù)正常，包括修正錯誤并重新啟動系統(tǒng)。u如果恢復(fù)是由系統(tǒng)自身來完成的，那么，需驗證重新初始化、檢查點機(jī)制、數(shù)據(jù)恢復(fù)和重啟動等的正確性。u如果恢復(fù)需要人工干預(yù)，那么要估算平均修復(fù)時間MTTR（mean time to repair）是否在用戶可以接受的范圍內(nèi)。安全測試（安全測試（security testing）u安全測試用來驗證集成在系統(tǒng)中的保護(hù)機(jī)制能否實際保護(hù)系統(tǒng)不受非法侵入。u在安全測試過程中，測試者扮演一個試圖攻擊系統(tǒng)的角色，采用各種方式攻擊系統(tǒng)

34、。例如，截取或碼譯密碼；借助特殊軟件攻擊系統(tǒng)；“制服”系統(tǒng)，使他人無法訪問；故意導(dǎo)致系統(tǒng)失效，企圖在系統(tǒng)恢復(fù)之機(jī)侵入系統(tǒng)；通過瀏覽非保密數(shù)據(jù)，從中找出進(jìn)入系統(tǒng)的鑰匙等等。u一般來說，只要有足夠的時間和資源，好的完全測試一定能最終侵入系統(tǒng)。系統(tǒng)設(shè)計者的任務(wù)是把系統(tǒng)設(shè)計成：攻破系統(tǒng)所付出的代價大于攻破系統(tǒng)后得到信息的價值。攻破系統(tǒng)所付出的代價大于攻破系統(tǒng)后得到信息的價值。壓力測試（壓力測試（stress testing）u壓力測試也稱強(qiáng)度測試，它是在一種需要非正常數(shù)量、頻率或容量的方式下執(zhí)行系統(tǒng)，其目的是檢查系統(tǒng)對非正常情況的承受程度。u例如：當(dāng)系統(tǒng)的中斷頻率是每秒1或2個時，執(zhí)行每秒10個中斷的

35、測試用例將輸入數(shù)據(jù)的數(shù)量提高一個數(shù)量級來測試輸入功能如何響應(yīng)執(zhí)行需要最大內(nèi)存或其它資源的測試用例執(zhí)行可能導(dǎo)致大量磁盤駐留數(shù)據(jù)的測試用例性能測試（性能測試（performance testing）u性能測試用來測試軟件在集成的系統(tǒng)中的運(yùn)行性能。它對實時系統(tǒng)和嵌入式系統(tǒng)尤為重要。u性能測試可以發(fā)生在測試過程的所有步驟中單元測試時，主要測試一個獨立模塊的性能，如算法的執(zhí)行速度。軟件集成后，進(jìn)行軟件整體的性能測試。計算機(jī)系統(tǒng)集成后，進(jìn)行整個計算機(jī)系統(tǒng)的性能測試。u性能測試常常需要與壓力測試結(jié)合起來進(jìn)行，而且常常需要一些硬件和軟件測試設(shè)備，以監(jiān)測系統(tǒng)的運(yùn)行情況。內(nèi)容摘要內(nèi)容摘要一軟件測試基礎(chǔ)二白盒測試三

36、黑盒測試四測試策略六測試完成標(biāo)準(zhǔn)七調(diào)試面向?qū)ο鬁y試面向?qū)ο鬁y試u面向?qū)ο筌浖臏y試目標(biāo)仍然是用最少時間和工作量來發(fā)現(xiàn)盡可能多的錯誤u但面向?qū)ο筌浖男再|(zhì)改變了測試的策略和測試戰(zhàn)術(shù)。面向?qū)ο筌浖臏y試也給軟件工程師帶來新的挑戰(zhàn)。面向?qū)ο笳Z境對測試的影響面向?qū)ο笳Z境對測試的影響u繼承、封裝、多態(tài)性、基于消息的通信等概念都是面向繼承、封裝、多態(tài)性、基于消息的通信等概念都是面向?qū)ο筌浖闹匾卣?，它們對面向?qū)ο鬁y試有很大的影對象軟件的重要特征，它們對面向?qū)ο鬁y試有很大的影響。響。u單元單元適用于面向?qū)ο鬁y試的兩種單元定義適用于面向?qū)ο鬁y試的兩種單元定義單元是可以編譯和執(zhí)行的最小軟件部件單元是可以編譯和

37、執(zhí)行的最小軟件部件單元是決不會指派給多個設(shè)計人員開發(fā)的軟件部件單元是決不會指派給多個設(shè)計人員開發(fā)的軟件部件類是面向?qū)ο筌浖械膯卧愂敲嫦驅(qū)ο筌浖械膯卧庋b由于屬性和操作被封裝在類中，因此測試時很難獲得對象的某些具體信息（除非提供內(nèi)置操作來報告這些信息），從而給測試帶來困難。繼承測試了父類的操作后，并不表示其子類就不必對繼承的操作進(jìn)行測試。多態(tài)性在測試時，應(yīng)覆蓋反映多態(tài)的所有實現(xiàn)方法。基于消息的通信面向?qū)ο筌浖峭ㄟ^消息通信來實現(xiàn)類之間的協(xié)作，它們沒有明顯的層次控制結(jié)構(gòu)，因此，傳統(tǒng)的自頂向下和自底向上集成策略不適用于面向?qū)ο筌浖y試。面向?qū)ο鬁y試面向?qū)ο鬁y試面向?qū)ο蟮臏y試策略u把類作為面向?qū)?/p>

38、象軟件的單元，傳統(tǒng)的單元測試等價于面向?qū)ο笾械念悳y試，也稱類內(nèi)測試。它包括類內(nèi)的方法測試和類的行為測試。u面向?qū)ο笾械念愰g測試（interclass testing）相當(dāng)于面向?qū)ο蟮募蓽y試。它有兩種集成策略： 基于線程的測試（threadbased testing）：集成一組互相協(xié)作的類來響應(yīng)系統(tǒng)的一個輸入或事件，每個線程逐一被集成和測試，并通過回歸測試保證其沒有產(chǎn)生副作用。 基于使用的測試（usebased testing）：按使用層次來集成系統(tǒng)。把那些幾乎不使用其他類提供的服務(wù)的類稱為獨立類，把使用類的類稱為依賴類。集成從測試獨立類開始，然后集成直接依賴于獨立類的那些類，并對其測試。按照

39、依賴的層次關(guān)系，逐層集成并測試，直至所有的類被集成。內(nèi)容摘要內(nèi)容摘要一軟件測試基礎(chǔ)二白盒測試三黑盒測試四測試策略五面向?qū)ο鬁y試七調(diào)試測試完成的標(biāo)準(zhǔn)測試完成的標(biāo)準(zhǔn)u因為無法判定當(dāng)前查出的錯誤是否是最后一個錯誤，所以決定什么時候停止程序測試就成了最困難的問題，但是測試最后一定要停止的。u幾種實用的測試完成標(biāo)準(zhǔn)：Musa和Ackerman提出了一個基于統(tǒng)計標(biāo)準(zhǔn)的答復(fù)：“不，我們不能絕對地認(rèn)定軟件永遠(yuǎn)也不會再出錯，但是相對于一個理論上合理的和在試驗中有效的統(tǒng)計模型來說，如果一個在按照概率的方法定義的環(huán)境中，1000個CPU小時內(nèi)不出錯運(yùn)行的概率大于0995的話，那么我們就有95%的信心說，我們已經(jīng)進(jìn)行了足夠的測試”。1.使用指定的測試用例設(shè)計方法產(chǎn)生測試用例，運(yùn)行這些測試使用指定的測試用例設(shè)計方法產(chǎn)生測試用例，運(yùn)行這些測試用例均未發(fā)現(xiàn)錯誤（包括發(fā)現(xiàn)錯誤后已被糾正的情況），則用例均未發(fā)現(xiàn)錯誤（包括發(fā)現(xiàn)錯誤后已被糾正的情況），則測試可終止。測試可終止。2.觀察測試階段中單位時間內(nèi)發(fā)現(xiàn)錯誤數(shù)目的曲線：觀察測試階段中單位時間內(nèi)發(fā)現(xiàn)錯誤數(shù)目的曲線：單發(fā)單發(fā)位現(xiàn)位現(xiàn)時的時的間錯間錯內(nèi)誤內(nèi)誤數(shù)數(shù)周（或天）周（或天）可可以以停停止止單發(fā)單發(fā)位現(xiàn)位現(xiàn)時的時的間錯間錯內(nèi)誤內(nèi)誤數(shù)數(shù)周（或天）周（或天