【正文】 工程領(lǐng)域認(rèn)可： （ 1） 測試是為了發(fā)現(xiàn)程序中的錯(cuò)誤而執(zhí)行程序的過程； （ 2） 好的測試方案極有可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯(cuò)誤； （ 3） 成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯(cuò)誤 。 盡管人們采取了多種保證軟件質(zhì)量的措施 ，由于軟件系統(tǒng)的客觀復(fù)雜性 ， 人們的主觀認(rèn)識不可能完全符合客觀實(shí)際 ， 完美無缺 ， 每個(gè)階段的技術(shù)審查也不可能毫無遺漏地查出和糾正所有的設(shè)計(jì)和分析上的錯(cuò)誤 ， 在軟件生命周期的各個(gè)階段 ， 都不可避免地會(huì)產(chǎn)生差錯(cuò) ， 這些差錯(cuò)遲早會(huì)在軟件的生產(chǎn)和使用過程中暴露出來 。 是根據(jù)軟件開發(fā)的各個(gè)階段的說明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計(jì)的一批測試用例 （ 有輸入數(shù)據(jù)及預(yù)期的結(jié)果 ） ， 并利用這些測試用例執(zhí)行程序及發(fā)現(xiàn)錯(cuò)誤的過程 。 軟件工程中所有其它階段都是 “ 建設(shè)性 ” 的 ， 軟件工程師力圖從抽象概念出發(fā) ， 逐步設(shè)計(jì)出具體的軟件系統(tǒng) ， 而測試人員的工作表面上看卻是 “ 破壞性 ” 的 ， 竭力證明軟件中含有錯(cuò)誤 ， 不能按預(yù)定要求正確工作 。 設(shè)程序段為 S， 其前斷言為 P， 后斷言為 R。修正過的文檔一般需經(jīng)過再次測試，直到通過測試為止。 測試信息流 23 （ 3） 從測試結(jié)果的表現(xiàn)上分類： 1） 功能錯(cuò)誤：由系統(tǒng)需求分析不完整引起的； 2） 結(jié)構(gòu)錯(cuò)誤：由總體設(shè)計(jì)的錯(cuò)誤引起的； 3） 過程錯(cuò)誤：由詳細(xì)設(shè)計(jì)的錯(cuò)誤引起的； 4） 數(shù)據(jù)錯(cuò)誤：由軟件編碼或詳細(xì)設(shè)計(jì)的錯(cuò)誤引起的； 5） 編碼錯(cuò)誤：由軟件編碼引起的錯(cuò)誤； 6） 其它錯(cuò)誤：由文檔和其它系統(tǒng)元素引起的錯(cuò)誤； 測試信息流 24 軟件測試步驟與軟件開發(fā)各階段的關(guān)系 軟件測試一般分為四個(gè)步驟： （ 1） 單元測試 （ 也稱模塊測試 ） ：針對軟件設(shè)計(jì)的基本單元 —— 程序模塊 ， 進(jìn)行正確性檢驗(yàn)的測試工作 。 在一個(gè)程序段中 ， 還存在著尚未發(fā)現(xiàn)的錯(cuò)誤概率與已發(fā)現(xiàn)的錯(cuò)誤數(shù)正相關(guān) 。 41 軟件測試的方法 包含所有可能情況的測試稱為窮盡測試 ， 實(shí)際上 ， 通常不可能做到窮盡測試 。 44 測試方案與測試用例 設(shè)計(jì)測試方案是軟件測試中的關(guān)鍵問題。具有語句覆蓋 、 判定覆蓋 （ 分支覆蓋 ） 、 條件覆蓋 、判定 /條件覆蓋 、 路徑覆蓋 、 條件組合覆蓋 、 點(diǎn)覆蓋 、 邊覆蓋 ， 下面以一個(gè)經(jīng)典例子分別介紹： 設(shè)有某個(gè)算法片段的程序流程圖如下： 47 白盒法（邏輯覆蓋） 圖 65程序段程序框圖 (A1)AND (B=0) (A=2)OR (X1) X=X/A X=X+1 a b c d e T T 48 白盒法（邏輯覆蓋） 該程序片段有四條路徑： abd,acd,ace,aed。 選擇測試用例： A=2,B=1,X=0,預(yù)期結(jié)果為：A=2,B=1,X=1。 X1,X≤ 1。 滿足了條件覆蓋 ， 卻不滿足判定覆蓋 ， 第二個(gè)判定表達(dá)式的值總為真 。 2) A1,B≠ 0。滿足點(diǎn)覆蓋的要求是選取足夠多的測試用例 ， 測試執(zhí)行程序時(shí)的路徑 ， 至少經(jīng)過程序圖的每個(gè)節(jié)點(diǎn)一次 。 63 黑盒法（邏輯覆蓋） 黑盒測試法把程序看成是一個(gè)黑盒子 ， 不考慮程序內(nèi)部的執(zhí)行過程 ， 著眼于外部特性 ， 在接口上進(jìn)行測試 ， 僅考慮輸入與輸出能否與需求規(guī)格說明書對應(yīng)起來 ， 輸入能否正確的接收 ， 輸出能否得到正確的結(jié)果 。 66 等價(jià)類劃分 等價(jià)類劃分的原則： （ 1） 如果規(guī)定了輸入值的取值范圍 ， 則可劃分出一個(gè)有效的等價(jià)類 （ 輸入值在此范圍內(nèi) ） ，兩個(gè)無效的等價(jià)類 （ 輸入值小于最小值 、 或大于最大值 ） ； （ 2） 如果規(guī)定了輸入數(shù)據(jù)的個(gè)數(shù) ， 則類似地也可以劃分出一個(gè)有效等價(jià)類和兩個(gè)無效等價(jià)類 。 因果圖的使用可以分為如下步驟： （ 1） 列出模塊的原因 —— 和效果 （ 動(dòng)作 ） ， 給每個(gè)原因和效果一個(gè)標(biāo)示符； （ 2） 把原因 、 效果用邏輯符號連接起來 ， 畫出原因效果圖 ， 標(biāo)出約束條件； 73 因果圖法 （ 3） 原因相對于判定表中的條件 ， 效果相對于判定表中的動(dòng)作 ， 把原因效果圖轉(zhuǎn)換為判定表； （ 4） 把判定表中右邊部分的每一列表示的情況轉(zhuǎn)換為測試用例 。 77 綜合測試策略 對于集成測試可以使用模塊的自頂向下的結(jié)合方式 ， 也可以使用自底向上的結(jié)合方式進(jìn)行測試 ，還可用輔助測試工具協(xié)助測試 。 調(diào)試的策略有：試探法 ， 回溯法 ， 對分查找法 、歸納法 、 演繹法 。 83 .1軟件質(zhì)量評價(jià) 開發(fā)人員常把產(chǎn)品外部特性用軟件內(nèi)部質(zhì)量結(jié)構(gòu)來對應(yīng) 。 除了定性評價(jià)外 ， 人們逐漸重視軟件的質(zhì)量度量 ，它是在系統(tǒng)運(yùn)行過程中進(jìn)行動(dòng)態(tài)檢測 ， 不斷收集軟件性能方面的數(shù)據(jù) ， 利用軟件質(zhì)量模型 （ 如軟件可靠性模型 、 軟件復(fù)雜度模型等 ） 進(jìn)行分析和評價(jià) 。 96 .2軟件質(zhì)量保證 ISO 90003標(biāo)準(zhǔn)不適用于面向多數(shù)用戶的程序軟件包 ， 僅適用于依照合同進(jìn)行單獨(dú)定貨的開發(fā)軟件 ，對供需方的責(zé)任都作了明確的規(guī)定 ， 最重要的是質(zhì)量保證體系 ， 也是企業(yè)建立質(zhì)量保證體系的指南 ， 要求證實(shí)企業(yè)具有持續(xù)提供符合要求產(chǎn)品的能力 ， 主要強(qiáng)調(diào)將質(zhì)量作入產(chǎn)品之中： （ 1） 軟件質(zhì)量保證體系是貫穿于整個(gè)生存期的集成化過程體系 ， 而不僅僅體現(xiàn)在最后的產(chǎn)品交付驗(yàn)收時(shí)； 97 .2軟件質(zhì)量保證 ? （ 2） 強(qiáng)調(diào)防患于未然而不是事后糾正； ? （ 3） 更強(qiáng)調(diào)質(zhì)量體系的文件化 ， 實(shí)施內(nèi)部質(zhì)量審核制度； ? （ 4） 強(qiáng)調(diào)對每一項(xiàng)軟件開發(fā)都按計(jì)劃開展質(zhì)量活動(dòng)并且確保相關(guān)組織機(jī)構(gòu)的了解和監(jiān)督； ? （ 5） 進(jìn)行合同審查 ， 需求規(guī)格說明可用于產(chǎn)品交付驗(yàn)證時(shí)的認(rèn)證； 98 .2軟件質(zhì)量保證 ? （ 6） 實(shí)施開發(fā)計(jì)劃管理 ， 質(zhì)量計(jì)劃管理 ， 進(jìn)行產(chǎn)品的設(shè)計(jì)和實(shí)現(xiàn)； ? （ 7） 進(jìn)行多層次的測試和驗(yàn)證 ， 交付安裝時(shí)提供義務(wù)期限； ? （ 8） 提供維護(hù)支持 、 配置管理 、 文檔控制 、 質(zhì)量記錄 、 培訓(xùn)人員和其它支持活動(dòng)等； 99 .2軟件質(zhì)量保證 總之 ， 加強(qiáng)質(zhì)量管理 ， 針對所有可能影響軟件質(zhì)量的各個(gè)因素都要采取有力措施 ， 作出加強(qiáng)質(zhì)量管理和控制的決定 。 盡管修改和變更總是有理由的 ， 但在修改過程中常常會(huì)引進(jìn)一些潛伏的錯(cuò)誤 。 85 .1軟件質(zhì)量評價(jià) 國際標(biāo)準(zhǔn)化機(jī)構(gòu)建議 ， 軟件質(zhì)量模型由三層組成： 高層：軟件質(zhì)量需求評價(jià)準(zhǔn)則 （ SQRC） ； 中層：軟件質(zhì)量設(shè)計(jì)評價(jià)準(zhǔn)則 （ SQDC） ； 低層：軟件質(zhì)量度量評價(jià)準(zhǔn)則 （ SQMC） ； 86 .1軟件質(zhì)量評價(jià) 多數(shù)軟件同行公認(rèn)的一般質(zhì)量按如下特性進(jìn)行評價(jià)： ? 正確性： （ 功能度 ） 在預(yù)定的環(huán)境下 ， 軟件實(shí)現(xiàn)的功能達(dá)到設(shè)計(jì)規(guī)范和滿足用戶要求的程度； ? 可靠性：軟件在給定的條件下和規(guī)定的時(shí)間內(nèi)完成預(yù)定職能的概率；即保持其性能的能力相關(guān)的屬性； ? 易用性：用戶學(xué)習(xí)軟件 、 運(yùn)行操作軟件 、 準(zhǔn)備輸入 、理解輸出所做的努力程度 ， 根據(jù)用戶評估使用軟件所需進(jìn)行努力的程度相關(guān)的屬性； 87 .1軟件質(zhì)量評價(jià) ? 效率：在規(guī)定的條件下 ， 軟件表現(xiàn)的性能級別與所使用資源總量 （ 包括人員 、 時(shí)間 、 財(cái)力 ） 關(guān)系的屬性； ? 可維護(hù)性：軟件修改難易程度的一組屬性； ? 可移植性； （ 可轉(zhuǎn)換性 ） 指一個(gè)軟件從一個(gè)環(huán)境轉(zhuǎn)換到另一個(gè)環(huán)境運(yùn)行的能力的相關(guān)屬性 。 隨著技術(shù)的發(fā)展 ，軟件規(guī)模的擴(kuò)大 ， 軟件復(fù)雜性的增加 ， 人們對軟件質(zhì)量的觀點(diǎn)早已發(fā)生了很大變化 ， 更強(qiáng)調(diào)軟件的全面質(zhì)量評價(jià) 。 調(diào)試必須由程序員自己來進(jìn)行 。 75 綜合測試策略 對軟件系統(tǒng)的實(shí)際測試 ， 往往利用多種測試方法進(jìn)行 ，