【正文】 試實(shí)現(xiàn)了條件組合覆蓋 ， 但并沒有覆蓋每一條路徑 ，如：路徑 acd遺漏了 。 3) A≤ 1,B=0。 如圖 65中 ， 需要測試覆蓋條件組合的下述八種情況： 1) A1,B=0 。但它也并不比條件覆蓋更強(qiáng)。 選擇測試用例： A=1,B=1,X=1,預(yù)期結(jié)果為：A=1,B=1,X=1。 55 白盒法（邏輯覆蓋） ? (4) 判定 /條件覆蓋：選擇足夠的測試用例 ， 使得程序判定中的每個(gè)條件都能獲得各種可能的結(jié)果 ， 并且使得每個(gè)判定都取得各種可能的結(jié)果 。 滿足 A≤ 1,B≠ 0,A≠ 2,X1的條件 ， 執(zhí)行路徑 abd。 54 白盒法（邏輯覆蓋） 但也有相反的情況 ， 每個(gè)條件雖然取得兩個(gè)不同的結(jié)果 ， 判定表達(dá)式卻始終只取一個(gè)值 ， 例如：取數(shù)據(jù)： ? A=2,B=0,X=1。 這組測試用例覆蓋了路徑 acd， aed 和 abd ,滿足了條件覆蓋要求 。 53 白盒法（邏輯覆蓋） 例如 ， 選擇測試用例： A=2,B=0,X=4,預(yù)期結(jié)果為：A=2,B=0,X=3。 b點(diǎn)出現(xiàn)： A=2,A≠ 2。 如圖 65中 ， 有四個(gè)條件： A1,B=0,A=2,X1,每個(gè)條件可能出現(xiàn)的各種結(jié)果為： a點(diǎn)出現(xiàn)：A1,A≤ 1。 52 白盒法（邏輯覆蓋） ? (3) 條件覆蓋：條件為邏輯表達(dá)式中的各個(gè)邏輯分量 。 51 白盒法（邏輯覆蓋） 這組測試用例覆蓋了路徑 acd和 aed ,滿足了判定覆蓋要求 。 例如 ， 選擇測試用例： A=3,B=0,X=3,預(yù)期結(jié)果為：A=3,B=0,X=1。 圖 65程序段程序框圖 (A1)AND (B=0) (A=2)OR (X1) X=X/A X=X+1 a b c d e T T 50 白盒法（邏輯覆蓋） ? (2) 判定覆蓋 （ 也稱分支覆蓋 ） ：判定是一個(gè)邏輯表達(dá)式的結(jié)果 。 如果選擇路徑ace， 則能保證程序中的語句都執(zhí)行一次 。 ? (1) 語句覆蓋：選擇足夠的測試用例使程序中每條語句至少執(zhí)行一次 。 46 白盒法（邏輯覆蓋） 白盒法也稱邏輯驅(qū)動(dòng)法 （ 邏輯覆蓋法 ） ， 從軟件的具體邏輯結(jié)構(gòu)和執(zhí)行路徑出發(fā) ， 設(shè)計(jì)測試用例 。 有多種測試技術(shù) ，同一種測試技術(shù)在不同的應(yīng)用場合效果可能相差很大 ， 因此 ， 通常需要聯(lián)合使用多種測試技術(shù)來設(shè)計(jì)測試用例 。因?yàn)椴豢赡苓M(jìn)行窮盡測試，選用少量高效的測試數(shù)據(jù)，進(jìn)行盡可能完備的測試就顯得更重要了。測試方案包括預(yù)定要測試的功能、結(jié)構(gòu)，應(yīng)該要輸入的測試數(shù)據(jù)和輸入這些數(shù)據(jù)后預(yù)期的結(jié)果 —— 測試用例。 重要的通用軟件產(chǎn)品 ， 大多經(jīng)過 α 和 β 測試 。 Alpha(α) 測試：通用軟件產(chǎn)品為了征集用戶的意見 ， 在開發(fā)者的場所 ， 由用戶進(jìn)行的測試 ， 記錄用戶發(fā)現(xiàn)的錯(cuò)誤和問題 。 42 軟件測試的方法 如果每測試一次需要 1毫秒 ， 測試完畢這些排列組合的各種情況需要一萬年 ， 另外還需測試不合法的輸入情況 ， 實(shí)際上不可能窮盡所有組合情況 。 因?yàn)楦鞣N輸入數(shù)據(jù)的排列組合情況往往多到無法實(shí)際測試完成的程度 。 40 軟件測試的方法 動(dòng)態(tài)測試是直接執(zhí)行程序進(jìn)行測試 ， 包括功能測試 、 接口測試和結(jié)構(gòu)測試 ， 觀察程序的行為 ， 記錄執(zhí)行的結(jié)果 ， 從執(zhí)行結(jié)果來分析程序可能出現(xiàn)的錯(cuò)誤； 有些人設(shè)想 ， 不管使用那種測試方法 ， 只要對每一種可能發(fā)生的情況都進(jìn)行測試 ， 能正確通過 ，就可以得到完全正確的程序 。 從測試過程來分：靜態(tài)分析法 、 動(dòng)態(tài)測試法； 38 軟件測試的方法 結(jié)構(gòu)檢查是手工分析技術(shù) ， 對需求說明 、 程序設(shè)計(jì) 、 編碼 、 測試工作進(jìn)行評(píng)議 ， 虛擬地 （ 模擬 ）執(zhí)行程序 ， 在評(píng)議中發(fā)現(xiàn)和檢查錯(cuò)誤； 流圖分析是通過分析流程圖 、 代碼結(jié)構(gòu)來檢查程序錯(cuò)誤 ， 便于進(jìn)行編碼分析和測試結(jié)果分析； 39 軟件測試的方法 符號(hào)執(zhí)行是定義符號(hào)化數(shù)據(jù) ， 為程序的每條路徑給出符號(hào)表達(dá)式 ， 對特定路徑輸入符號(hào) ， 經(jīng)處理輸出符號(hào) ， 判斷程序的行為是否錯(cuò)誤 ， 這種方法復(fù)雜 ， 易出錯(cuò) ， 較少使用 。 無論用哪種方法進(jìn)行測試 ，都是設(shè)法用較少的測試用例集合測試出程序中較多的潛在錯(cuò)誤 。 34 軟件測試原則 殘存錯(cuò)誤的可能性 已發(fā)現(xiàn)的錯(cuò)誤數(shù) 圖 64 軟件錯(cuò)誤的群集現(xiàn)象示意圖 35 軟件測試的方法 軟件的測試方法很多 ， 不同的出發(fā)點(diǎn)得到不同的測試方法 。 29 軟件測試步驟與軟件開發(fā)各階段的關(guān)系 需求分析 軟件設(shè)計(jì) 軟件編碼 確認(rèn)測試 集成測試 單元測試 系統(tǒng) 測試 圖 62 軟件測試與軟件開發(fā)過程間的關(guān)系 30 軟件測試步驟與軟件開發(fā)各階段的關(guān)系 需求分析 說明書 概要設(shè)計(jì) 說明書 詳細(xì)設(shè)計(jì) 說明書 源程序 代碼 確認(rèn)測試 集成測試 單元測試 系統(tǒng)測試 圖 63 軟件測試與開發(fā)文檔之間的關(guān)系 31 軟件測試原則 ? （ 1） 將軟件測試貫穿于軟件開發(fā)的各個(gè)階段中 ，在開發(fā)過程中盡早地發(fā)現(xiàn)和預(yù)防錯(cuò)誤 ， 杜絕隱患 ，提高軟件質(zhì)量； ? （ 2） 測試用例必須包含輸入數(shù)據(jù)和與之對應(yīng)的預(yù)期輸出結(jié)果 ， 精心設(shè)計(jì)測試用例； ? （ 3） 測試時(shí)應(yīng)避免設(shè)計(jì)者檢查自己設(shè)計(jì)的程序； ? （ 4） 設(shè)計(jì)測試用例時(shí) ， 應(yīng)包括合理的與不合理的輸入條件； 32 軟件測試原則 ? （ 5） 充分注意測試中出現(xiàn)的錯(cuò)誤群集現(xiàn)象 ， 若發(fā)現(xiàn)錯(cuò)誤數(shù)目較多 ， 則可能殘存的錯(cuò)誤數(shù)目也較多 ，這種錯(cuò)誤出現(xiàn)的群集現(xiàn)象 ， 已為許多程序測試實(shí)踐所證實(shí)； ? （ 6） 嚴(yán)格執(zhí)行測試計(jì)劃 ， 以軟件需求說明書為基準(zhǔn)設(shè)計(jì)測試用例 ， 排除測試的隨意性； 33 軟件測試原則 ? （ 7） 對每一個(gè)測試結(jié)果做全面檢查 ， 不能遺漏錯(cuò)誤出現(xiàn)的征兆 ， 軟件修改后要進(jìn)行回歸測試 ， 即用修改前測試過的測試用例進(jìn)行測試 ， 再用新的測試用例測試； ? （ 8） 妥善保存測試計(jì)劃 、 測試用例 、 出錯(cuò)統(tǒng)計(jì)數(shù)據(jù)和最終分析報(bào)告 ， 為維護(hù)提供方便 。 27 軟件測試步驟與軟件開發(fā)各階段的關(guān)系 前面多次強(qiáng)調(diào)，使用軟件生命期（瀑布模型）模型，軟件開發(fā)過程是一個(gè)自頂向下，逐步細(xì)化的過程，而軟件測試過程則是與開發(fā)過程相反的次序進(jìn)行的，是一個(gè)自底向上，逐步集成的過程，低一層測試為上一層測試準(zhǔn)備測試條件和數(shù)據(jù)驅(qū)動(dòng)環(huán)境，也包含兩者平行進(jìn)行測試。 26 軟件測試步驟與軟件開發(fā)各階段的關(guān)系 （ 3） 確認(rèn)測試 （ 也稱驗(yàn)收測試 ， 有效性測試 ） ：主要檢驗(yàn)軟件的功能和性能是否與需求說明書中的規(guī)定一致 。 目的在于發(fā)現(xiàn)各個(gè)模塊內(nèi)部可能存在的各種差錯(cuò) 。 測試信息流 22 （ 2） 從開發(fā)過程的轉(zhuǎn)換環(huán)節(jié)上分： 1 構(gòu)造錯(cuò)誤：編碼實(shí)現(xiàn)與設(shè)計(jì)不一致； 2 設(shè)計(jì)錯(cuò)誤：設(shè)計(jì)邏輯與說明不一致； 3 說明書錯(cuò)誤：說明書與用戶要求不一致； 4 需求錯(cuò)誤：不滿足用戶的實(shí)際要求； 5配置錯(cuò)誤：軟件配置不滿足實(shí)際環(huán)境 。 如果得到的評(píng)價(jià)是沒有發(fā)現(xiàn)錯(cuò)誤 ， 很有可能測試的配置考慮得不夠充分和細(xì)致 ， 軟件仍有潛伏的錯(cuò)誤 ， 以后改正錯(cuò)誤需要付出高昂的代價(jià) 。 相反 ， 如果軟件功能能夠正確完成 ， 出現(xiàn)的錯(cuò)誤易于修改 ， 那么就可能有兩種評(píng)價(jià)： 測試信息流 19 ? 一種是軟件的質(zhì)量和可靠性達(dá)到可以接受的程度 。 測試信息流 18 通過收集和分析測試結(jié)果的有關(guān)數(shù)據(jù) ， 可以建立軟件評(píng)估的可靠性模型 。如果發(fā)現(xiàn)出錯(cuò)的數(shù)據(jù)，則意味著軟件有錯(cuò)誤，需要糾錯(cuò)，應(yīng)進(jìn)行調(diào)試，確定錯(cuò)誤的位置和出錯(cuò)的性質(zhì)，改正這些錯(cuò)誤，同時(shí)修正相關(guān)文檔。