【正文】 這組測試用例覆蓋了路徑 acd和 aed ,滿足了判定覆蓋要求 。 如圖 65中 ， 有四個條件： A1,B=0,A=2,X1,每個條件可能出現(xiàn)的各種結(jié)果為： a點出現(xiàn)：A1,A≤ 1。 53 白盒法（邏輯覆蓋） 例如 ， 選擇測試用例： A=2,B=0,X=4,預期結(jié)果為：A=2,B=0,X=3。 54 白盒法（邏輯覆蓋） 但也有相反的情況 ， 每個條件雖然取得兩個不同的結(jié)果 ， 判定表達式卻始終只取一個值 ， 例如：取數(shù)據(jù)： ? A=2,B=0,X=1。 55 白盒法（邏輯覆蓋） ? (4) 判定 /條件覆蓋：選擇足夠的測試用例 ， 使得程序判定中的每個條件都能獲得各種可能的結(jié)果 ， 并且使得每個判定都取得各種可能的結(jié)果 。但它也并不比條件覆蓋更強。 3) A≤ 1,B=0。 開銷大 ， 應注意權(quán)衡 。顯然 ， 點覆蓋的要求和語句覆蓋的要求是相同的 。 62 白盒法（邏輯覆蓋） (8)路徑覆蓋：選擇足夠的測試用例 ， 使得程序中的每條可能組合路徑都至少執(zhí)行一次 。 也稱為數(shù)據(jù)驅(qū)動或輸入 /輸出驅(qū)動測試 ， 或功能測試 。 65 等價類劃分 假設我們可以把輸入的數(shù)據(jù)域劃分成有限的等價類 ， 用每個等價類的代表值作為測試用例的輸入數(shù)據(jù)進行測試 ， 等價于該類的任何其它值作為設計用例的輸入數(shù)據(jù)進行的測試 。 67 等價類劃分 （ 3） 如果規(guī)定了輸入數(shù)據(jù)的一組值 ， 而且程序?qū)Σ煌斎胫底霾煌靥幚?， 則每個允許的值是一個有效的等價類 ， 還有一個無效的等價類（ 任何一個不允許的輸入值 ） ； （ 4） 如果規(guī)定了輸入數(shù)據(jù)必須遵循的規(guī)則 ，則可以劃分出一個有效的等價類 （ 符合規(guī)則的輸入數(shù)據(jù) ） 和若干個無效的等價類 （ 從各種不同角度違反規(guī)則 ） ； 68 等價類劃分 （ 5） 如果輸入數(shù)據(jù)為整型 ， 則可以劃分出正整數(shù) 、零和負整數(shù)三個有效類； （ 6） 如果程序處理的對象是表格 ， 則應該使用空表 、 以及含有一項或多項的表進行測試 。 所以選取稍微高于或低于邊界值的數(shù)據(jù)進行測試 。 74 錯誤推測法 錯誤推測法 在很大程度上依靠人的直覺和經(jīng)驗進行。 通常是用黑盒法設計一些基本的測試用例 ， 再用白盒法補充設計一些必要的測試用例 ， 黑盒 、 白盒法相結(jié)合 —— 灰盒法進行測試 。 軟件系統(tǒng)測試完后 ， 應對軟件配置進行復查 ，確保軟件的有關文檔資料的完整齊全 ， 分類編目 ，便于軟件的維護和修改 。 79 軟件調(diào)試 調(diào)試技術有以下類別： 輸出存儲器內(nèi)容：發(fā)現(xiàn)問題時 ， 設法保留現(xiàn)場信息 ， 把所有寄存器和主存中相關部分的內(nèi)容打印出來進行分析研究 。 可根據(jù)個人經(jīng)驗和具體情況靈活應用 。 82 .1軟件質(zhì)量評價 不同的人員對軟件質(zhì)量關心的著重點不同 ， 反映了對軟件質(zhì)量的不同要求 。 維護人員要求軟件系統(tǒng) 、 軟件文檔清晰 、 軟件文檔與源代碼一致 ， 軟件易于修改 、 易于維護 。 以上六條是常見的評價方面 。 90 .2軟件質(zhì)量控制 做好軟件質(zhì)量的控制 ， 就要加強軟件生命期各個階段的軟件質(zhì)量保證 ， 需要做好如下幾方面的軟件管理工作： （ 1） 采用技術手段保證軟件質(zhì)量：在軟件開發(fā)過程中 ， 注意采用科學的軟件工程方法和工具來保證所開發(fā)軟件的質(zhì)量； 91 .2軟件質(zhì)量控制 （ 2） 組織技術評審：在軟件開發(fā)的每個階段結(jié)束后 ， 都要組織評審 ， 對質(zhì)量進行評價 ， 可以及早地發(fā)現(xiàn)軟件開發(fā)過程中的可能引起軟件質(zhì)量問題的潛在錯誤； （ 3） 加強軟件測試：軟件測試是軟件質(zhì)量保證的重要手段 。 因此嚴格控制軟件的修改和變更是十分必要的； （ 6） 對軟件質(zhì)量進行度量：軟件質(zhì)量管理要求對軟件質(zhì)量進行跟蹤 ， 就必須進行軟件質(zhì)量度量 ，并對軟件質(zhì)量情況及時記錄和報告 。 與質(zhì)量有關的人員都要規(guī)定其職責和權(quán)限 ， 使責任落實到人 ， 保證產(chǎn)品質(zhì)量真正得到控制 。 ? 管理復審：向開發(fā)組織或使用部門的管理人員 ， 提供有關項目的總體狀況 、 成本和進度等方面的情況 ，以便他們從管理角度對開發(fā)工作進行審查 。 一旦確認 ， 就應在軟件開發(fā)中得到遵循 ， 軟件規(guī)范則成為軟件技術評審的一項重要內(nèi)容； 93 .2軟件質(zhì)量控制 （ 5） 對軟件的修改 、 變更進行嚴格控制：影響軟件的一個不可忽視的危險因素來自軟件的修改和變更 。 如： ? 健壯性：在硬件發(fā)生故障 、 輸入數(shù)據(jù)無效或操作失誤等意外情況下 ， 系統(tǒng)不至于崩潰 ， 能作出適當響應的程度； ? 完整性： （ 安全性 ） 對未經(jīng)授權(quán)的人使用軟件或數(shù)據(jù)的企圖 ， 系統(tǒng)能夠控制 （ 禁止 ） 的程度； 89 .1軟件質(zhì)量評價 ? 可測試性：系統(tǒng)容易測試的程度； ? 可再用性：在其他應用中該軟件可以被再次使用的程度 （ 或范圍 ） ； ? 可互連性：把軟件系統(tǒng)與其他系統(tǒng)連接起來的能力 。 一般要求軟件具有良好的結(jié)構(gòu) ， 齊全的文檔資料 ， 易于閱讀和理解 ， 便于修改和維護 ， 內(nèi)部層次結(jié)構(gòu)清晰 、 人機界面友好 ， 用戶樂于使用 。 軟件開發(fā)人員既要開發(fā)滿足質(zhì)量要求的最終產(chǎn)品 ， 又要注意軟件開發(fā)過程中的每個階段的質(zhì)量 。 在軟件工程誕生之前 ， 由于計算機設備條件的限制 ， 計算機發(fā)展的早期 ， 內(nèi)存容量有限 ， 執(zhí)行速度不高 ，當時的軟件設計特別強調(diào)效率 。 80 軟件調(diào)試 利用調(diào)試工具跟蹤程序的動態(tài)變化 ， 單步跟蹤 ，檢查主存和寄存器內(nèi)容 ， 檢查重要變量內(nèi)容 ， 檢查是否進入預定的程序分支 ， 設置斷點 ， 當程序運行到檢查的重點位置 ， 暫停程序運行 ， 觀察主要的變化信息 ，分析程序狀態(tài) ， 決定繼續(xù)跟蹤還是停止執(zhí)行 ， 為程序的調(diào)試提供了有力的手段 。 78 軟件調(diào)試 程序測試只是發(fā)現(xiàn)錯誤的跡象 ， 并不清楚具體錯誤的位置和產(chǎn)生的原因 ， 應該立即進行調(diào)試 ， 即糾正錯誤的工作 ， 它包含兩方面工作： （ 1） 確定程序中錯誤的具體位置和性質(zhì)； （ 2） 修改錯誤 。經(jīng)驗表明這種方法設計出的測試用例 ， 暴露程序錯誤的能力最強 ， 應該包括輸入和輸出數(shù)據(jù)的邊界情況； 76 綜合測試策略 ? （ 2） 必要時用等價類劃分法補充測試用例； ? （ 3） 必要時用錯誤推測法補充測試用例； ? （ 4） 對照程序邏輯 ， 檢查設計測試用例 ， 可根據(jù)對程序的可靠性要求采用不同的邏輯覆蓋標準 ， 補充測試用例 ， 達到邏輯覆蓋標準； ? （ 5） 如果有輸入條件的組合 ， 就應從輸入條件及其組合開始測試 。也可利用程序錯誤清單作為推測測試的依據(jù)。 72 因果圖法 因果圖可以提供邏輯條件和相應動作之間的簡潔邏輯關系表示 。 上面是針對輸入數(shù)據(jù)而言 ， 對輸出數(shù)據(jù)也可類似劃分 。 相反 ， 若測不出錯誤 ， 則該等價類的其他測試用例 ， 也測不出錯誤 。 64 等價類劃分 一個理想的測試用例能夠獨自發(fā)現(xiàn)某一類錯誤 。 ） 它是相當強的邏輯覆蓋標準 ， 選擇的測試用例更具有代表性 ， 暴露錯誤的能力也更強 。 為了滿足邊覆蓋的測試要求 ，使得程序的執(zhí)行路徑經(jīng)過程序圖中的每一條邊 。 如果把程序流程圖的每個處理框 （ 含一個或多個語句 ） 作為一個節(jié)點 ， 就畫出了程序圖 。 5) A=2,X1 6) A=2,X=1 7) A≠ 2,X1 8) A≠ 2,X≤ 1 58 白盒法（邏輯覆蓋） ? 用 A=2,B=0,X=4, 預期結(jié)果： A=2,B=0,X=3, 覆蓋情況 1） 、 5） ； ? 用 A=2,B=1,X=1, 預期結(jié)果： A=2,B=1,X=2, 覆蓋情況 2） 、 6）