【正文】 徑出發(fā) ， 設(shè)計測試用例 。 例如 ， 選擇測試用例： A=3,B=0,X=3,預(yù)期結(jié)果為：A=3,B=0,X=1。 b點(diǎn)出現(xiàn)： A=2,A≠ 2。 滿足 A≤ 1,B≠ 0,A≠ 2,X1的條件 ， 執(zhí)行路徑 abd。 如圖 65中 ， 需要測試覆蓋條件組合的下述八種情況： 1) A1,B=0 。 如果把程序流程圖的每個處理框 （ 含一個或多個語句 ） 作為一個節(jié)點(diǎn) ， 就畫出了程序圖 。 ） 它是相當(dāng)強(qiáng)的邏輯覆蓋標(biāo)準(zhǔn) ， 選擇的測試用例更具有代表性 ， 暴露錯誤的能力也更強(qiáng) 。 相反 ， 若測不出錯誤 ， 則該等價類的其他測試用例 ， 也測不出錯誤 。 72 因果圖法 因果圖可以提供邏輯條件和相應(yīng)動作之間的簡潔邏輯關(guān)系表示 。經(jīng)驗(yàn)表明這種方法設(shè)計出的測試用例 ， 暴露程序錯誤的能力最強(qiáng) ， 應(yīng)該包括輸入和輸出數(shù)據(jù)的邊界情況； 76 綜合測試策略 ? （ 2） 必要時用等價類劃分法補(bǔ)充測試用例； ? （ 3） 必要時用錯誤推測法補(bǔ)充測試用例； ? （ 4） 對照程序邏輯 ， 檢查設(shè)計測試用例 ， 可根據(jù)對程序的可靠性要求采用不同的邏輯覆蓋標(biāo)準(zhǔn) ， 補(bǔ)充測試用例 ， 達(dá)到邏輯覆蓋標(biāo)準(zhǔn)； ? （ 5） 如果有輸入條件的組合 ， 就應(yīng)從輸入條件及其組合開始測試 。 80 軟件調(diào)試 利用調(diào)試工具跟蹤程序的動態(tài)變化 ， 單步跟蹤 ，檢查主存和寄存器內(nèi)容 ， 檢查重要變量內(nèi)容 ， 檢查是否進(jìn)入預(yù)定的程序分支 ， 設(shè)置斷點(diǎn) ， 當(dāng)程序運(yùn)行到檢查的重點(diǎn)位置 ， 暫停程序運(yùn)行 ， 觀察主要的變化信息 ，分析程序狀態(tài) ， 決定繼續(xù)跟蹤還是停止執(zhí)行 ， 為程序的調(diào)試提供了有力的手段 。 軟件開發(fā)人員既要開發(fā)滿足質(zhì)量要求的最終產(chǎn)品 ， 又要注意軟件開發(fā)過程中的每個階段的質(zhì)量 。 如： ? 健壯性：在硬件發(fā)生故障 、 輸入數(shù)據(jù)無效或操作失誤等意外情況下 ， 系統(tǒng)不至于崩潰 ， 能作出適當(dāng)響應(yīng)的程度； ? 完整性： （ 安全性 ） 對未經(jīng)授權(quán)的人使用軟件或數(shù)據(jù)的企圖 ， 系統(tǒng)能夠控制 （ 禁止 ） 的程度； 89 .1軟件質(zhì)量評價 ? 可測試性：系統(tǒng)容易測試的程度； ? 可再用性：在其他應(yīng)用中該軟件可以被再次使用的程度 （ 或范圍 ） ； ? 可互連性：把軟件系統(tǒng)與其他系統(tǒng)連接起來的能力 。 ? 管理復(fù)審：向開發(fā)組織或使用部門的管理人員 ， 提供有關(guān)項(xiàng)目的總體狀況 、 成本和進(jìn)度等方面的情況 ，以便他們從管理角度對開發(fā)工作進(jìn)行審查 。 因此嚴(yán)格控制軟件的修改和變更是十分必要的； （ 6） 對軟件質(zhì)量進(jìn)行度量：軟件質(zhì)量管理要求對軟件質(zhì)量進(jìn)行跟蹤 ， 就必須進(jìn)行軟件質(zhì)量度量 ，并對軟件質(zhì)量情況及時記錄和報告 。 以上六條是常見的評價方面 。 82 .1軟件質(zhì)量評價 不同的人員對軟件質(zhì)量關(guān)心的著重點(diǎn)不同 ， 反映了對軟件質(zhì)量的不同要求 。 79 軟件調(diào)試 調(diào)試技術(shù)有以下類別： 輸出存儲器內(nèi)容：發(fā)現(xiàn)問題時 ， 設(shè)法保留現(xiàn)場信息 ， 把所有寄存器和主存中相關(guān)部分的內(nèi)容打印出來進(jìn)行分析研究 。 通常是用黑盒法設(shè)計一些基本的測試用例 ， 再用白盒法補(bǔ)充設(shè)計一些必要的測試用例 ， 黑盒 、 白盒法相結(jié)合 —— 灰盒法進(jìn)行測試 。 所以選取稍微高于或低于邊界值的數(shù)據(jù)進(jìn)行測試 。 65 等價類劃分 假設(shè)我們可以把輸入的數(shù)據(jù)域劃分成有限的等價類 ， 用每個等價類的代表值作為測試用例的輸入數(shù)據(jù)進(jìn)行測試 ， 等價于該類的任何其它值作為設(shè)計用例的輸入數(shù)據(jù)進(jìn)行的測試 。 62 白盒法（邏輯覆蓋） (8)路徑覆蓋：選擇足夠的測試用例 ， 使得程序中的每條可能組合路徑都至少執(zhí)行一次 。 開銷大 ， 應(yīng)注意權(quán)衡 。但它也并不比條件覆蓋更強(qiáng)。 54 白盒法（邏輯覆蓋） 但也有相反的情況 ， 每個條件雖然取得兩個不同的結(jié)果 ， 判定表達(dá)式卻始終只取一個值 ， 例如：取數(shù)據(jù)： ? A=2,B=0,X=1。 如圖 65中 ， 有四個條件： A1,B=0,A=2,X1,每個條件可能出現(xiàn)的各種結(jié)果為： a點(diǎn)出現(xiàn)：A1,A≤ 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) 判定覆蓋 （ 也稱分支覆蓋 ） ：判定是一個邏輯表達(dá)式的結(jié)果 。 有多種測試技術(shù) ，同一種測試技術(shù)在不同的應(yīng)用場合效果可能相差很大 ， 因此 ， 通常需要聯(lián)合使用多種測試技術(shù)來設(shè)計測試用例 。 Alpha(α) 測試：通用軟件產(chǎn)品為了征集用戶的意見 ， 在開發(fā)者的場所 ， 由用戶進(jìn)行的測試 ， 記錄用戶發(fā)現(xiàn)的錯誤和問題 。 從測試過程來分：靜態(tài)分析法 、 動態(tài)測試法； 38 軟件測試的方法 結(jié)構(gòu)檢查是手工分析技術(shù) ， 對需求說明 、 程序設(shè)計 、 編碼 、 測試工作進(jìn)行評議 ， 虛擬地 （ 模擬 ）執(zhí)行程序 ， 在評議中發(fā)現(xiàn)和檢查錯誤； 流圖分析是通過分析流程圖 、 代碼結(jié)構(gòu)來檢查程序錯誤 ， 便于進(jìn)行編碼分析和測試結(jié)果分析； 39 軟件測試的方法 符號執(zhí)行是定義符號化數(shù)據(jù) ， 為程序的每條路徑給出符號表達(dá)式 ， 對特定路徑輸入符號 ， 經(jīng)處理輸出符號 ， 判斷程序的行為是否錯誤 ， 這種方法復(fù)雜 ， 易出錯 ， 較少使用 。 27 軟件測試步驟與軟件開發(fā)各階段的關(guān)系 前面多次強(qiáng)調(diào)，使用軟件生命期（瀑布模型）模型，軟件開發(fā)過程是一個自頂向下，逐步細(xì)化的過程，而軟件測試過程則是與開發(fā)過程相反的次序進(jìn)行的，是一個自底向上，逐步集成的過程，低一層測試為上一層測試準(zhǔn)備測試條件和數(shù)據(jù)驅(qū)動環(huán)境，也包含兩者平行進(jìn)行測試。 如果得到的評價是沒有發(fā)現(xiàn)錯誤 ， 很有可能測試的配置考慮得不夠充分和細(xì)致 ， 軟件仍有潛伏的錯誤 ， 以后改正錯誤需要付出高昂的代價 。 （ 至軟件配置 ） 軟件配置 1 測試結(jié)果 2 錯誤 3 修正的軟件 測試配置 測試結(jié)果 測試工具 測試 評價 調(diào)試 正確 預(yù)測結(jié)果 出錯率 4 數(shù)據(jù) 可靠性 分析 圖 61 測試信息流 15 測試信息流 ： （ 1） 軟件配置：包括軟件開發(fā)文檔 （ 用戶文檔 、需求規(guī)格說明 、 軟件設(shè)計說明 、 源程序代碼 ） 、 目標(biāo)執(zhí)行程序 、 數(shù)據(jù)結(jié)構(gòu)； （ 2） 測試配置：包括測試計劃 、 測試用例 、 測試驅(qū)動程序等；實(shí)際上在整個軟件開發(fā)過程中 ， 測試配置只是軟件配置的一個子集； 16 （ 3） 測試工具：為提高軟件測試效率 ， 使用測試工具為測試工作服務(wù)；如：測試數(shù)據(jù)自動生成程序 ， 靜態(tài)分析程序 、 動態(tài)分析程序 、 測試結(jié)果分析程序及標(biāo)準(zhǔn)例程測試數(shù)據(jù)庫等 。 10 軟件測試的對象 ? 程序的確認(rèn)又分為靜態(tài)確認(rèn)與動態(tài)確認(rèn) 。 7 軟件測試基本概念 由于測試的目標(biāo)是暴露程序的錯誤 ， 從心理學(xué)角度看 ， 由設(shè)計者自己進(jìn)行測試是不恰當(dāng)?shù)?， 設(shè)計小組和測試小