軟件工程(第3版)第5章人民郵電出版社.ppt

《軟件工程(第3版)第5章人民郵電出版社.ppt》由會員分享，可在線閱讀，更多相關(guān)《軟件工程(第3版)第5章人民郵電出版社.ppt（268頁珍藏版）》請在裝配圖網(wǎng)上搜索。

第5章結(jié)構(gòu)化實現(xiàn) 通常把編碼和測試統(tǒng)稱為實現(xiàn) 所謂編碼就是把軟件設(shè)計翻譯成計算機可以理解的形式 用某種程序設(shè)計語言書寫的程序 作為軟件工程過程的一個階段 編碼是設(shè)計的自然結(jié)果 因此 程序的質(zhì)量主要取決于軟件設(shè)計的質(zhì)量 但是 所選用的程序設(shè)計語言的特點和編碼風(fēng)格 也會對程序的可靠性 可讀性 可測試性和可維護性產(chǎn)生深遠的影響 無論怎樣強調(diào)軟件測試的重要性和它對軟件可靠性的影響都不過分 在開發(fā)大型軟件系統(tǒng)的漫長過程中 面對著極其錯綜復(fù)雜的問題 人的主觀認識不可能完全符合客觀現(xiàn)實 與工程密切相關(guān)的各類人員之間的通信和配合也不可能完美無缺 因此 在軟件生命周期的每個階段都不可避免地會產(chǎn)生差錯 我們力求在每個階段結(jié)束之前通過嚴格的技術(shù)審查 盡可能早地發(fā)現(xiàn)并糾正差錯 但是 經(jīng)驗表明審查并不能發(fā)現(xiàn)所有差錯 此外在編碼過程中還不可避免地會引入新的錯誤 如果在軟件投入生產(chǎn)性運行之前 沒有發(fā)現(xiàn)并糾正軟件中的大部分差錯 則這些差錯遲早會在生產(chǎn)過程中暴露出來 那時不僅改正這些錯誤的代價更高 而且往往會造成很惡劣的后果 測試的目的就是在軟件投入生產(chǎn)性運行之前 盡可能多地發(fā)現(xiàn)軟件中的錯誤 目前軟件測試仍然是保證軟件質(zhì)量的關(guān)鍵步驟 它是對軟件規(guī)格說明 設(shè)計和編碼的最后復(fù)審 軟件測試在軟件生命周期中橫跨兩個階段 通常在編寫出每個模塊之后就對它做必要的測試 稱為單元測試 模塊的編寫者和測試者是同一個人 編碼和單元測試屬于軟件生命周期的同一個階段 在這個階段結(jié)束之后 對軟件系統(tǒng)還應(yīng)該進行各種綜合測試 這是軟件生命周期中的另一個獨立的階段 通常由專門的測試人員承擔(dān)這項工作 大量統(tǒng)計資料表明 軟件測試的工作量往往占軟件開發(fā)總工作量的40 以上 在極端情況 測試那種關(guān)系人的生命安全的軟件所花費的成本 可能相當(dāng)于軟件工程其他步驟總成本的3 5倍 因此 必須高度重視軟件測試工作 絕不要以為寫出程序之后軟件開發(fā)工作就接近完成了 實際上 大約還有同樣多的開發(fā)工作量需要完成 僅就測試而言 它的目標(biāo)是發(fā)現(xiàn)軟件中的錯誤 但是 發(fā)現(xiàn)錯誤并不是我們的最終目的 軟件工程的根本目標(biāo)是開發(fā)出高質(zhì)量的完全符合用戶需要的軟件 因此 通過測試發(fā)現(xiàn)錯誤之后還必須診斷并改正錯誤 這就是調(diào)試的目的 調(diào)試是測試階段最困難的工作 在對測試結(jié)果進行收集和評價的時候 軟件所達到的可靠性也開始明朗了 軟件可靠性模型使用故障率數(shù)據(jù) 估計軟件將來出現(xiàn)故障的情況并預(yù)測軟件的可靠性 5 1編碼 5 1 1選擇程序設(shè)計語言 總的說來 高級語言明顯優(yōu)于匯編語言 因此 除了在很特殊的應(yīng)用領(lǐng)域 例如 對程度執(zhí)行時間和使用的空間都有很嚴格限制的情況 需要產(chǎn)生任意的甚至非法的指令序列 體系結(jié)構(gòu)特殊的微處理機 以致在這類機器上通常不能實現(xiàn)高級語言編譯程序 或者大型系統(tǒng)中執(zhí)行時間非常關(guān)鍵的 或直接依賴于硬件的 一小部分代碼需要用匯編語言書寫之外 其他程序應(yīng)該一律用高級語言書寫 為了使程序容易測試和維護以減少生命周期的總成本 選用的高級語言應(yīng)該有理想的模塊化機制 以及可讀性好的控制結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu) 為了便于調(diào)試和提高軟件可靠性 語言特點應(yīng)該使編譯程序能夠盡可能多地發(fā)現(xiàn)程序中的錯誤 為了降低軟件開發(fā)和維護的成本 選用的語言應(yīng)該有良好的獨立編譯機制 上述這些要求是選擇語言的理想標(biāo)準(zhǔn) 但是在實際選用語言時不能僅僅考慮理論上的標(biāo)準(zhǔn) 還必須同時考慮實用方面的各種限制 5 1 2編碼風(fēng)格 源程序代碼的邏輯簡明清晰 易讀易懂是好程序的一個重要標(biāo)準(zhǔn) 為了做到這一點 應(yīng)該遵循下述規(guī)則 1 程序內(nèi)部的文檔 所謂程序內(nèi)部的文檔包括恰當(dāng)?shù)臉?biāo)識符 適當(dāng)?shù)淖⒔夂统绦虻囊曈X組織等等 2 數(shù)據(jù)說明 雖然在設(shè)計期間已經(jīng)確定了數(shù)據(jù)結(jié)構(gòu)的組織和復(fù)雜程度 然而數(shù)據(jù)說明的風(fēng)格卻是在寫程序時確定的 為了使數(shù)據(jù)更容易理解和維護 有一些比較簡單的原則應(yīng)該遵循 3 語句構(gòu)造 構(gòu)造語句時應(yīng)該遵循的原則是 每個語句都應(yīng)該簡單而直接 不能為了提高效率而使程序變得過分復(fù)雜 4 輸入 輸出 在設(shè)計和編寫程序時應(yīng)該考慮下述有關(guān)輸入 輸出風(fēng)格的規(guī)則 對所有輸入數(shù)據(jù)都進行檢驗 檢查輸入項重要組合的合法性 保持輸入格式簡單 使用數(shù)據(jù)結(jié)束標(biāo)記 不要要求用戶指定數(shù)據(jù)的數(shù)目 明確提示交互式輸入的請求 詳細說明可用的選擇或邊界數(shù)值 當(dāng)程序設(shè)計語言對格式有嚴格要求時 應(yīng)保持輸入格式一致 設(shè)計良好的輸出報表 給所有輸出數(shù)據(jù)加標(biāo)志 5 效率 效率主要指處理機時間和存儲器容量兩個方面 雖然值得提出提高效率的要求 但是在進一步討論這個問題之前應(yīng)該記住三條原則 首先 效率是性能要求 因此應(yīng)該在需求分析階段確定效率方面的要求 軟件應(yīng)該像對它要求的那樣有效 而不應(yīng)該如同人類可能做到的那樣有效 其次 效率是靠好設(shè)計來提高的 第三 程序的效率和程序的簡單程度是一致的 不要犧牲程序的清晰性和可讀性來不必要地提高效率 5 2軟件測試基礎(chǔ) 5 2 1測試目標(biāo) G Myers給出了關(guān)于測試的一些規(guī)則 這些規(guī)則也可以看作是測試的目標(biāo)或定義 測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程 好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案 成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試 由于測試的目標(biāo)是暴露程序中的錯誤 從心理學(xué)角度看 由程序的編寫者自己進行測試是不恰當(dāng)?shù)?因此 在綜合測試階段通常由其他人員組成測試小組來完成測試工作 5 2 2黑盒測試和白盒測試對于軟件測試而言 黑盒測試法把程序看成一個黑盒子 完全不考慮程序的內(nèi)部結(jié)構(gòu)和處理過程 也就是說 黑盒測試是在程序接口進行的測試 它只檢查程序功能是否能按照規(guī)格說明書的規(guī)定正常使用 程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)產(chǎn)生正確的輸出信息 并且保持外部信息 如 數(shù)據(jù)庫或文件 的完整性 黑盒測試又稱為功能測試 與黑盒測試法相反 白盒測試法的前提是可以把程序看成裝在一個透明的白盒子里 也就是完全了解程序的結(jié)構(gòu)和處理過程 這種方法按照程序內(nèi)部的邏輯測試程序 檢驗程序中的每條通路是否都能按預(yù)定要求正確工作 白盒測試又稱為結(jié)構(gòu)測試 5 2 3測試準(zhǔn)則 為了能設(shè)計出有效的測試方案 軟件工程師必須充分理解并正確運用指導(dǎo)軟件測試的基本準(zhǔn)則 主要的測試準(zhǔn)則如下所述 所有的測試都應(yīng)該能追溯到用戶需求 應(yīng)該在測試開始之前的相當(dāng)長時間 就制定出測試計劃 把Pareto原理應(yīng)用于軟件測試 Pareto原理告訴我們 測試發(fā)現(xiàn)的錯誤中的80 很可能是由程序中20 的模塊造成的 測試應(yīng)該從 小規(guī)模 開始 并逐步進行 大規(guī)模 測試 窮舉測試是不可能的 為了達到最佳的測試效果 應(yīng)該由獨立的第三方來從事測試工作 5 2 4流圖 在設(shè)計測試方案時 往往需要仔細分析程序的控制流 為了突出表示程序的控制流 可以使用流圖 也稱為程序圖 流圖僅僅描繪程序的控制流程 它完全不表現(xiàn)對數(shù)據(jù)的具體操作以及分支或循環(huán)的具體條件 在流圖中用圓表示節(jié)點 一個圓代表一條或多條語句 程序流程圖中的一個處理框序列和一個菱形判定框 可以映射成流圖中的一個節(jié)點 流圖中的箭頭線稱為邊 它和程序流程圖中的箭頭線類似 代表控制流 在流圖中一條邊必須終止于一個節(jié)點 即使這個節(jié)點并不代表任何語句 實際上相當(dāng)于一個空語句 由邊和節(jié)點圍成的面積稱為區(qū)域 當(dāng)計算區(qū)域數(shù)時應(yīng)該包括圖外部未被圍起來的那個區(qū)域 圖5 1舉例說明把程序流程圖映射成流圖的方法 圖5 1把程序流程圖映射成流圖 a 程序流程圖 b 流圖 PDL procedure sort 1 dowhilerecordsremain readrecord 2 ifrecordfield1 0 3 thenprocessrecord storeinbuffer incremertcounter 4 elseifrecardfield2 0 5 thenresetcounter 6 elseprocessrecord storeinfile 7a endif endif 7b enddo 8 end 圖5 2由PDL翻譯成的流圖 圖5 3由包含復(fù)合條件的PDL映射成的流圖 5 3邏輯覆蓋 邏輯覆蓋是設(shè)計白盒測試方案的一種技術(shù) 設(shè)計測試方案是測試階段的關(guān)鍵技術(shù)問題 所謂測試方案包括具體的測試目的 例如 要測試的具體功能 應(yīng)該輸入的測試數(shù)據(jù)和預(yù)期的輸出結(jié)果 通常又把測試數(shù)據(jù)和預(yù)期的輸出結(jié)果稱為測試用例 不同的測試數(shù)據(jù)發(fā)現(xiàn)程序錯誤的能力差別很大 為了提高測試效率降低測試成本 應(yīng)該選用高效的測試數(shù)據(jù) 因為不可能進行窮盡的測試 選用少量 最有效的 測試數(shù)據(jù) 做到盡可能完備的測試就更重要了 有選擇地執(zhí)行程序中某些最有代表性的通路是對窮盡測試的唯一可行的替代辦法 所謂邏輯覆蓋是對一系列測試過程的總稱 這組測試過程逐漸進行越來越完整的通路測試 測試數(shù)據(jù)執(zhí)行 或叫覆蓋 程序邏輯的程度可以劃分成哪些不同的等級 從覆蓋源程序語句的詳盡程度分析 大致有以下一些不同的覆蓋標(biāo)準(zhǔn) 1 語句覆蓋 為了暴露程序中的錯誤 至少每個語句應(yīng)該執(zhí)行一次 語句覆蓋的含義是 選擇足夠多的測試數(shù)據(jù) 使被測程序中每個語句至少執(zhí)行一次 圖5 4被測試模塊的流程圖 2 判定覆蓋 判定覆蓋又叫分支覆蓋 它的含義是 不僅每個語句必須至少執(zhí)行一次 而且每個判定的每種可能的結(jié)果都應(yīng)該至少執(zhí)行一次 也就是每個判定的每個分支都至少執(zhí)行一次 3 條件覆蓋 條件覆蓋的含義是 不僅每個語句至少執(zhí)行一次 而且使判定表達式中的每個條件都取到各種可能的結(jié)果 4 判定 條件覆蓋 既然判定覆蓋不一定包含條件覆蓋 條件覆蓋也不一定包含判定覆蓋 自然會提出一種能同時滿足這兩種覆蓋標(biāo)準(zhǔn)的邏輯覆蓋 這就是判定 條件覆蓋 它的含義是 選取足夠多的測試數(shù)據(jù) 使得判定表達式中的每個條件都取到各種可能的值 而且每個判定表達式也都取到各種可能的結(jié)果 5 條件組合覆蓋 條件組合覆蓋是更強的邏輯覆蓋標(biāo)準(zhǔn) 它要求選取足夠多的測試數(shù)據(jù) 使得每個判定表達式中條件的各種可能組合都至少出現(xiàn)一次 5 4控制結(jié)構(gòu)測試 5 4 1基本路徑測試 基本路徑測試是TomMcCabe提出的一種白盒測試技術(shù) 使用這種技術(shù)設(shè)計測試用例時 首先計算過程設(shè)計結(jié)果的邏輯復(fù)雜度 并以該復(fù)雜度為指南定義執(zhí)行路徑的基本集合 從該基本集合導(dǎo)出的測試用例可以保證程序中的每條語句至少執(zhí)行一次 而且每個條件在執(zhí)行時都將分別取true 真 和false 假 值 使用基本路徑測試技術(shù)設(shè)計測試用例的步驟如下 1 根據(jù)過程設(shè)計結(jié)果畫出相應(yīng)的流圖 圖5 5求平均值過程的流圖 PROCEDUREaverage 這個過程計算不超過100個在規(guī)定值域內(nèi)的有效數(shù)字的平均值 同時計算有效數(shù)字的總和及個數(shù) INTERFACERETURNSaverage total input total valid INTERFACECCEPTSvalue minimum maximum TYPEvalue 1 100 ISSCALARARRAY TYPEaverage total input total valid minimum maximum sumISSCALAR TYPEiISINTEGER 1 i 1 total input total valid 0 sum 0 2 DOWHILEvalue i 999 3 ANDtotal input 100 4 incrementtotal inputby1 5 IFvalue i minimum 6 ANDvalue i maximum 7 THENincrementtotal validby1 sum sum value i 8 ENDIF incrementiby1 9 ENDDO 10 IFtotal valid 0 11 THENaverage sum total valid 12 ELSEaverage 999 13 ENDIF ENDaverage 2 計算流圖的環(huán)形復(fù)雜度 用環(huán)形復(fù)雜度來定量度量程序的邏輯復(fù)雜性 有了描繪程序控制流的流圖之后 可以用下述三種方法之一來計算環(huán)形復(fù)雜度 流圖中的區(qū)域數(shù)等于環(huán)形復(fù)雜度 流圖G的環(huán)形復(fù)雜度V G E N 2 其中E是流圖中邊的條數(shù) N是流圖中節(jié)點數(shù) 流圖G的環(huán)形復(fù)雜度V G P 1 其中P是流圖中判定節(jié)點的數(shù)目 使用上述任何一種方法 都可以計算出圖5 5所示流圖的環(huán)形復(fù)雜度為6 3 確定線性獨立路徑的基本集合所謂獨立路徑 是指至少引入程序的一個新處理語句集合或一個新條件的路徑 用流圖術(shù)語描述 獨立路徑至少包含一條在定義該路徑之前不曾用過的邊 使用基本路徑測試法設(shè)計測試用例時 程序的環(huán)形復(fù)雜度決定了程序中獨立路徑的數(shù)量 而且這個數(shù)是確保程序中所有語句至少被執(zhí)行一次所需的測試數(shù)量的上界 對于圖5 5所描述的求平均值過程來說 由于環(huán)形復(fù)雜度為6 因此共有6條獨立路徑 例如 下面列出了6條獨立路徑 路徑1 1 2 10 11 13 路徑2 1 2 10 12 13 路徑3 1 2 3 10 11 13 路徑4 1 2 3 4 5 8 9 2 路徑5 1 2 3 4 5 6 8 9 2 路徑6 1 2 3 4 5 6 7 8 9 2 路徑4 5 6后面的省略號 表示可以后接通過控制結(jié)構(gòu)其余部分的任意路徑 例如 10 11 13 通常在導(dǎo)出測試用例時 識別出判定節(jié)點是很有必要的 本例中節(jié)點2 3 5 6和10是判定節(jié)點 4 設(shè)計可強制執(zhí)行基本集合中每條路徑的測試用例 應(yīng)該選取數(shù)據(jù) 使得在測試每條路徑時都適當(dāng)?shù)卦O(shè)置好了各個判定節(jié)點的條件 可以測試上述基本集合的測試用例如下 路徑1的測試用例 Value k 有效輸入值 其中k i i的定義在下面 value i 999 其中2 i 100 預(yù)期結(jié)果 基于k的正確平均值和總數(shù)注意 路徑1無法獨立測試 必須作為路徑4 5和6的一部分來測試 路徑2的測試用例 value 1 999 預(yù)期結(jié)果 average 999 其他都保持初始值 路徑5的測試用例 value i 有效輸入值 其中i 100 value k maximum 其中k I預(yù)期結(jié)果 其于k的正確平均值和總數(shù) 路徑6的測試用例 value i 有效輸入值 其中i 100預(yù)期結(jié)果 正確的平均值和總數(shù) 5 4 2條件測試 盡管基本路徑測試技術(shù)簡單而且高效 但是僅有這種技術(shù)還不夠 還需要使用其他控制結(jié)構(gòu)測試技術(shù) 才能進一步提高白盒測試的質(zhì)量 用條件測試技術(shù)設(shè)計出的測試用例 能夠檢查程序模塊中包含的邏輯條件 一個簡單條件是一個布爾變量或一個關(guān)系表達式 在布爾變量或關(guān)系表達式之前還可能有一個NOT 算符 關(guān)系表達式的形式如下 E1 關(guān)系算符 E2 其中 E1和E2是算術(shù)表達式 而 關(guān)系算符 是下列算符之一 或 復(fù)合條件由兩個或多個簡單條件 布爾算符和括弧組成 布爾算符有OR AND 和NOT 不包含關(guān)系表達式的條件稱為布爾表達式 在上述種種條件測試技術(shù)的基礎(chǔ)上 K C Tai提出了一種被稱為BRO BranchandRelationalOperalor 測試的條件測試策略 如果在條件中所有布爾變量和關(guān)系算符都只出現(xiàn)一次而且沒有公共變量 則BRO測試保證能發(fā)現(xiàn)該條件中的分支錯和關(guān)系算符錯 BRO測試利用條件C的條件約束來設(shè)計測試用例 包含n個簡單條件的條件C的條件約束定義為 D1 D2 Dn 其中D i 0 i n 表示條件C中第i個簡單條件的輸出約束 如果在條件C的一次執(zhí)行過程中 C中每個簡單條件的輸出都滿足D中對應(yīng)的約束 則稱C的這次執(zhí)行覆蓋了C的條件約束D 對于布爾變量B來說 B的輸出約束指出 B必須是真 t 或假 f 類似地 對于關(guān)系表達式來說 用符號 和 指定表達式的輸出約束 作為一個例子 考慮下列條件 C1 B1 B2 其中 B1和B2是布爾變量 C1的條件約束形式為 D1 D2 其中D1和D2中的每一個都是 t 或 f 值 t f 是C1的一個條件約束 并由使B1值為真B2值為假的測試所覆蓋 BRO測試策略要求 約束集 t t f t t f 被C1的執(zhí)行所覆蓋 如果C1因布爾算符錯誤而不正確 則至少上述約束集中的一個約束將迫使C1失敗 5 4 3數(shù)據(jù)流測試 數(shù)據(jù)流測試方法根據(jù)程序中變量定義和使用的位置 選擇程序的測試路徑 為了說明數(shù)據(jù)流測試方法 假設(shè)已賦予程序每條語句一個唯一的語句號 而且每個函數(shù)都不修改它的參數(shù)或全局變量 對于語句號為S的語句 DEF S X 語句S包含變量X的定義 USE S X 語句S使用變量X 如果S是if或循環(huán)語句 則它的DEF集為空 而它的USE集取決于S的條件 如果存在從語句S到語句S 的路徑 而且在該路徑中不包含X的任何其他定義 則稱變量X在語句S中的定義在語句S 仍然有效 變量X的定義 使用鏈 或稱為DU鏈 的形式為 X S S 其中S和S 是語句號 X在集合DEF S 和USE S 中 而且在語句S中對X的定義在語句S 仍然有效 一種簡單的數(shù)據(jù)流測試策略要求 每個DU鏈至少被覆蓋一次 這種策略稱為DU測試策略 5 4 4循環(huán)測試 循環(huán)測試是一種白盒測試技術(shù) 它專注于測試循環(huán)結(jié)構(gòu)的有效性 在結(jié)構(gòu)化的程序中通常只有三種循環(huán) 分別是簡單循環(huán) 串接循環(huán)和嵌套循環(huán) 如圖5 6所示 下面分別討論不同類型循環(huán)的測試方法 1 簡單循環(huán) 應(yīng)該使用下列測試集來測試簡單循環(huán) 其中n是允許通過循環(huán)的最大次數(shù) 跳過循環(huán) 只通過循環(huán)一次 通過循環(huán)兩次 通過循環(huán)m次 其中m n 1 通過循環(huán)n 1 n n 1次 2 嵌套循環(huán) 如果把簡單循環(huán)的測試方法直接應(yīng)用到嵌套循環(huán) 可能的測試數(shù)就會隨嵌套層數(shù)的增加按幾何級數(shù)增長 這會導(dǎo)致不切實際的測試數(shù)目 B Beizer提出了一種能減少測試數(shù)的方法 從最內(nèi)層循環(huán)開始測試 把所有其他循環(huán)都設(shè)置為最小值 對最內(nèi)層循環(huán)使用簡單循環(huán)測試方法 而使外層循環(huán)的迭代參數(shù) 例如 循環(huán)計數(shù)器 取最小值 并為越界值或非法值增加一些額外的測試 由內(nèi)向外 對下一個循環(huán)進行測試 但保持所有其他外層循環(huán)為最小值 其他嵌套循環(huán)為 典型 值 繼續(xù)進行下去 直到測試完所有循環(huán) 3 串接循環(huán) 如果串接循環(huán)的各個循環(huán)都彼此獨立 則可以使用前述的測試簡單循環(huán)的方法來測試串接循環(huán) 但是 如果兩個循環(huán)串接 而且第一個循環(huán)的循環(huán)計數(shù)器值是第二個循環(huán)的初始值 則這兩個循環(huán)并不是獨立的 當(dāng)循環(huán)不獨立時 建議使用測試嵌套循環(huán)的方法來測試串接循環(huán) 圖5 6三種循環(huán) 5 5黑盒測試技術(shù) 黑盒測試著重測試軟件的功能需求 也就是說 黑盒測試讓軟件工程師設(shè)計出能充分檢查程序所有功能需求的輸入條件集 黑盒測試并不能取代白盒測試技術(shù) 它是與白盒測試互補的方法 它很可能發(fā)現(xiàn)白盒測試不易發(fā)現(xiàn)的其他不同類型的錯誤 黑盒測試力圖發(fā)現(xiàn)下述類型的錯誤 功能不正確或遺漏了功能 界面錯誤 數(shù)據(jù)結(jié)構(gòu)錯誤或外部數(shù)據(jù)庫訪問錯誤 性能錯誤 初始化和終止錯誤 白盒測試在測試過程的早期階段進行 而黑盒測試主要用于測試過程的后期 黑盒測試故意不考慮程序的控制結(jié)構(gòu) 而把注意力集中于信息域 5 5 1等價劃分 等價劃分是一種黑盒測試方法 這種方法把程序的輸入域劃分成數(shù)據(jù)類 據(jù)此可以導(dǎo)出測試用例 一個理想的測試用例能獨自發(fā)現(xiàn)一類錯誤 例如 對所有字符數(shù)據(jù)的處理都不正確 如果把所有可能的輸入數(shù)據(jù) 有效的和無效的 劃分成若干個等價類 則可以合理地做出下述假定 每類中的一個典型值在測試中的作用與這一類中所有其他值的作用相同 因此 可以從每個等價類中只取一組數(shù)據(jù)作為測試數(shù)據(jù) 這樣選取的測試數(shù)據(jù)最有代表性 最可能發(fā)現(xiàn)程序中的錯誤 使用等價劃分法設(shè)計測試方案首先需要劃分輸入數(shù)據(jù)的等價類 為此需要研究程序的功能說明 從而確定輸入數(shù)據(jù)的有效等價類和無效等價類 在確定輸入數(shù)據(jù)的等價類時常常還需要分析輸出數(shù)據(jù)的等價類 以便根據(jù)輸出數(shù)據(jù)的等價類導(dǎo)出對應(yīng)的輸入數(shù)據(jù)等價類 劃分等價類需要經(jīng)驗 下述幾條啟發(fā)式規(guī)則可能有助于等價類的劃分 如果規(guī)定了輸入值的范圍 則可劃分出一個有效的等價類 輸入值在此范圍內(nèi) 兩個無效的等價類 輸入值小于最小值或大于最大值 如果規(guī)定了輸入數(shù)據(jù)的個數(shù) 則類似地也可以劃分出一個有效的等價類和兩個無效的等價類 如果規(guī)定了輸入數(shù)據(jù)的一組值 而且程序?qū)Σ煌斎胫底霾煌幚?則每個允許的輸入值是一個有效的等價類 此外還有一個無效的等價類 任一個不允許的輸入值 如果規(guī)定了輸入數(shù)據(jù)必須遵循的規(guī)則 則可以劃分出一個有效的等價類 符合規(guī)則 和若干個無效的等價類 從各種不同角度違反規(guī)則 如果規(guī)定了輸入數(shù)據(jù)為整型 則可以劃分出正整數(shù) 零和負整數(shù)等三個有效類 如果程序的處理對象是表格 則應(yīng)該使用空表 以及含一項或多項的表 劃分出等價類以后 等價類設(shè)計測試方案時主要使用下面兩個步驟 設(shè)計一個新的測試方案以盡可能多地覆蓋尚未被覆蓋的有效等價類 復(fù)重這一步驟直到所有有效等價類都被覆蓋為止 設(shè)計一個新的測試方案 使它覆蓋一個而且只覆蓋一個尚未被覆蓋的無效等價類 重復(fù)這一步驟直到所有無效等價類都被覆蓋為止 下面用等價劃分法設(shè)計一個簡單程序的測試方案 假設(shè)有一個把數(shù)字串轉(zhuǎn)變成整數(shù)的函數(shù) 運行程序的計算機字長16位 用二進制補碼表示整數(shù) 這個函數(shù)是用PASCAL語言編寫的 它的說明如下 functionstrtoint dstr shortstr integer 函數(shù)的參數(shù)類型是shortstr 它的說明是 typeshortstr array 1 6 ofchar 被處理的數(shù)字串是右對齊的 也就是說 如果數(shù)字串比六個字符短 則在它的左邊補空格 如果數(shù)字串是負的 則負號和最高位數(shù)字緊相鄰 負號在最高位數(shù)字左邊一位 考慮到PASCAL編譯程序固有的檢錯功能 測試時不需要使用長度不等于6的數(shù)組做實在參數(shù) 更不需要使用任何非字符數(shù)組類型的實在參數(shù) 分析這個程序的規(guī)格說明 可以劃分出如下等價類 1 有效輸入的等價類有 1 6個數(shù)字字符組成的數(shù)字串 最高位數(shù)字不是零 最高位數(shù)字是零的數(shù)字串 最高位數(shù)字左鄰是負號的數(shù)字串 2 無效輸入的等價類有 空字符串 全是空格 左部填充的字符既不是零也不是空格 最高位數(shù)字右面由數(shù)字和空格混合組成 最高位數(shù)字右面由數(shù)字和其他字符混合組成 負號與最高位數(shù)字之間有空格 3 合法輸出的等價類有 在計算機能表示的最小負整數(shù)和零之間的負整數(shù) 零 在零和計算機能表示的最大正整數(shù)之間的正整數(shù) 4 非法輸出的等價類有 比計算機能表示的最小負整數(shù)還小的負整數(shù) 比計算機能表示的最大正整數(shù)還大的正整數(shù) 因為所用的計算機字長16位 用二進制補碼表示整數(shù) 所以能表示的最小負整數(shù)是 32768 能表示的最大正整數(shù)是32767 根據(jù)上面劃分出的等價類 可以設(shè)計出下述測試方案 注意 每個測試方案由三部分內(nèi)容組成 1 6個數(shù)字組成的數(shù)字串 輸出是合法的正整數(shù) 輸入 1 預(yù)期的輸出 1 最高位數(shù)字是零的數(shù)字串 輸出是合法的正整數(shù) 輸入 000001 預(yù)期的輸出 1 負號與最高位數(shù)字緊相鄰 輸出合法的負整數(shù) 輸入 00001 預(yù)期的輸出 1 最高位數(shù)字是零 輸出也是零 輸入 000000 預(yù)期的輸出 0 太小的負整數(shù) 輸入 47561 預(yù)期的輸出 錯誤 無效輸入 太大的正整數(shù) 輸入 132767 預(yù)期的輸出 錯誤 無效輸入 空字符串 輸入 預(yù)期的輸出 錯誤 沒有數(shù)字 字符串左部字符既不是零也不是空格 輸入 1 預(yù)期的輸出 錯誤 填充錯 最高位數(shù)字后面有空格 輸入 12 預(yù)期的輸出 錯誤 無效輸入 最高位數(shù)字后面有其他字符 輸入 1 2 預(yù)期的輸出 錯誤 無效輸入 負號和最高位數(shù)字之間有空格 輸入 12 預(yù)期的輸出 錯誤 負號位置錯 5 5 2邊界值分析 經(jīng)驗表明 處理邊界情況時程序最容易發(fā)生錯誤 例如 許多程序錯誤出現(xiàn)在下標(biāo) 純量 數(shù)據(jù)結(jié)構(gòu)和循環(huán)等的邊界附近 因此 設(shè)計使程序運行在邊界情況附近的測試方案 暴露出程序錯誤的可能性更大一些 使用邊界值分析方法設(shè)計測試方案首先應(yīng)該確定邊界情況 這需要經(jīng)驗和創(chuàng)造性 通常輸入等價類和輸出等價類的邊界 就是應(yīng)該著重測試的程序邊界情況 選取的 測試數(shù)據(jù)應(yīng)該剛好等于 剛剛小于和剛剛大于邊界值 也就是說 按照邊界值分析法 應(yīng)該選取剛好等于 稍小于和稍大于等價類邊界值的數(shù)據(jù)作為測試數(shù)據(jù) 而不是選取每個等價類內(nèi)的典型值或任意值作為測試數(shù)據(jù) 5 5 3錯誤推測錯誤推測法在很大程度上靠直覺和經(jīng)驗進行 它的基本想法是列舉出程序中可能有的錯誤和容易發(fā)生錯誤的特殊情況 并且根據(jù)它們選擇測試方案 5 6測試策略 5 6 1測試步驟 從過程的觀點考慮測試 在軟件工程環(huán)境中的測試過程 實際上是順序進行的四個步驟的序列 最開始 著重測試每個單獨的模塊 以確保它作為一個單元來說功能是正確的 因些 這種測試稱為單元測試 單元測試大量使用白盒測試技術(shù) 檢查模塊控制結(jié)構(gòu)中的特定路徑 以確保做到完全覆蓋并發(fā)現(xiàn)最大數(shù)量的錯誤 接下來 必須把模塊裝配 即集成 在一起形成完整的軟件包 在裝配的同時進行測試 因此稱為集成測試 集成測試同時解決程序驗證和程序構(gòu)造這兩個問題 在集成過程中最常用的是黑盒測試用例設(shè)計技術(shù) 當(dāng)然 為了保證覆蓋主要的控制路徑 也可能使用一定數(shù)量的白盒測試 在軟件集成完成之后 還需要進行一系列高級測試 必須測試在需求分析階段確定下來的確認標(biāo)準(zhǔn) 確認測試是對軟件滿足所有功能的 行為的和性能的需求的最終保證 在確認測試過程中僅使用黑盒測試技術(shù) 5 6 2單元測試 通常 單元測試和編碼屬于軟件工程過程的同一個階段 在編寫出源程序代碼并通過了編譯程序的語法檢查之后 可以應(yīng)用人工測試和計算機測試這樣兩種類型的測試 完成單元測試工作 這兩種類型的測試各有所長 互相補充 下面分別討論人工測試和計算機測試的問題 1 代碼審查 人工測試源程序可以由編寫者本人非正式地進行 也可以由審查小組正式進行 后者稱為代碼審查 它是一種非常有效的程序驗證技術(shù) 對于典型的程序來說 可以查出30 70 的邏輯設(shè)計錯誤和編碼錯誤 審查小組最好由下述四人組成 組長 他應(yīng)該是一個很有能力的程序員 而且沒有直接參與這項工程 程序的設(shè)計者 程序的編寫者 程序的測試者 實踐表明 對于查找某些類型的錯誤來說 人工測試比計算機測試更有效 對于其他類型的錯誤來說則剛好相反 因此 人工測試和計算機測試是互相補充 相輔相成的 缺少其中任何一種方法都會使查找錯誤的效率降低 2 測試軟件 模塊并不是一個獨立的程序 因此必須為每個單元測試開發(fā)驅(qū)動軟件和 或 存根軟件 通常驅(qū)動程序也就是一個 主程序 它接收測試數(shù)據(jù) 把這些數(shù)據(jù)傳送給被測試的模塊 并且印出有關(guān)的結(jié)果 存根程序代替被測試的模塊所調(diào)用的模塊 因此存根程序也可以稱為 虛擬子程序 它使用被它代替的模塊的接口 可能做最少量的數(shù)據(jù)操作 印出對入口的檢驗或操作結(jié)果 并且把控制歸還給調(diào)用它的模塊 圖5 7正文加工系統(tǒng)的層次圖 I TESTSTUB 測試正文編輯模塊用的存根程序 初始化 輸出信息 進入了正文編輯程序 輸出 輸入的控制信息是 CFUNCT 輸出緩沖區(qū)中的字符串 IFCFUNCT CHANGE THEN 把緩沖區(qū)中第二個字改為 ELSE 在緩沖區(qū)的尾部加 ENDIF 輸出緩沖區(qū)中的新字符串 ENDTESTSTUB TESTDRIVER 測試正文編輯模塊用的驅(qū)動程序 說明長度為2500個字符的一個緩沖區(qū) 把CFUNCT置為希望測試的狀態(tài) 輸入字符串 調(diào)用正文編輯模塊 停止或再次初啟 ENDTESTDRIVER 5 6 3集成測試 集成測試是測試和組裝軟件的系統(tǒng)化技術(shù) 在把模塊按照設(shè)計要求組裝起來的同時進行測試 主要目標(biāo)是發(fā)現(xiàn)與接口有關(guān)的問題 由模塊組裝成程序時有兩種方法 一種方法是先分別測試每個模塊 再把所有模塊按設(shè)計要求放在一起結(jié)合成所要的程序 這種方法稱為非漸增式測試方法 另一種方法是把下一個要測試的模塊同已經(jīng)測試好的那些模塊結(jié)合起來進行測試 測試完以后再把下一個應(yīng)該測試的模塊結(jié)合進來測試 這種每次增加一個模塊的方法稱為漸增式測試 1 自頂向下集成 自頂向下的集成 結(jié)合 方法是一個日益為人們廣泛采用的組裝軟件的途徑 從主控制模塊 主程序 開始 沿著軟件的控制層次向下移動 從而逐漸把各個模塊結(jié)合起來 在把附屬于 以及最終附屬于 主控制模塊的那些模塊組裝到軟件結(jié)構(gòu)中去時 或者使用深度優(yōu)先的策略 或者使用寬度優(yōu)先的策略 把模塊結(jié)合進軟件結(jié)構(gòu)的具體過程由下述四個步驟完成 對主控制模塊進行測試 測試時用存根程序代替所有直接附屬于主控制模塊的模塊 根據(jù)選定的結(jié)合策略 深度優(yōu)先或?qū)挾葍?yōu)先 每次用一個實際模塊代換一個存根程序 新結(jié)合進來的模塊往往又需要新的存根程序 在結(jié)合進一個模塊的同時進行測試 為了保證加入模塊沒有引進新的錯誤 可能需要進行回歸測試 即 全部或部分地重復(fù)以前做過的測試 從第二步開始不斷地重復(fù)進行上述過程 直到構(gòu)造起完整的軟件結(jié)構(gòu)為止 圖5 8自頂向下結(jié)合 2 自底向上集成 自底向上測試從 原子 模塊 即在軟件結(jié)構(gòu)最低層的模塊 開始組裝和測試 因為是從底部向上結(jié)合模塊 總能得到需要的下層模塊處理功能 所以不需要存根程序 用下述步驟可以實現(xiàn)自底向上的結(jié)合策略 把低層模塊組合成實現(xiàn)某個特定的軟件子功能的簇 寫一個驅(qū)動程序 用于測試的控制程序 協(xié)調(diào)測試數(shù)據(jù)的輸入和輸出 對由模塊組成的子功能簇進行測試 去掉驅(qū)動程序 沿軟件結(jié)構(gòu)自下向上移動 把子功能簇組合起來形成更大的子功能簇 上述第2步到第4步實質(zhì)上構(gòu)成了一個循環(huán) 圖5 9自底向上結(jié)合 3 回歸測試 每當(dāng)一個新模塊作為集成測試的一部分加進來的時候 軟件就發(fā)生了變化 建立了新的數(shù)據(jù)流路徑 可能出現(xiàn)了新的I O操作 激活了新的控制邏輯 這些變化可能使原來工作正常的功能出現(xiàn)問題 在集成測試的范疇中 所謂回歸測試是指重新執(zhí)行已經(jīng)做過的測試的某個子集 以保證上述這些變化沒有帶來非預(yù)期的副作用 回歸測試集 已執(zhí)行過的測試用例的子集 包括下述三種不同的測試用例 檢測軟件全部功能的代表性測試用例 專門針對可能受修改影響的軟件功能的附加測試 針對被修改過的軟件成分的測試 4 不同集成測試策略的比較 自頂向下測試方法的主要優(yōu)點是不需要測試驅(qū)動程序 能夠在測試階段的早期實現(xiàn)并驗證系統(tǒng)的主要功能 而且能在早期發(fā)現(xiàn)上層模塊的接口錯誤 自頂向下測試方法的主要缺點是需要存根程序 可能遇到與此相聯(lián)系的測試困難 低層關(guān)鍵模塊中的錯誤發(fā)現(xiàn)較晚 而且用這種方法在早期不能充分展開人力 可以看出 自底向上測試方法的優(yōu)缺點與上述自頂向下測試方法的優(yōu)缺點剛好相反 在測試實際的軟件系統(tǒng)時 應(yīng)該根據(jù)軟件的特點以及工程進度安排 選用適當(dāng)?shù)臏y試策略 一般說來 純粹自頂向下或純粹自底向上的策略可能都不實用 人們在實踐中創(chuàng)造出許多混合策略 5 6 4確認測試 確認測試也稱為驗收測試 它的目標(biāo)是驗證軟件的有效性 上面我們使用了確認 Validation 和驗證 Verification 這樣兩個不同的術(shù)語 為了避免混淆 首先扼要地解釋一下這兩個術(shù)語的含義 通常 驗證指的是保證軟件正確地實現(xiàn)了某一特定要求的一系列活動 而確認指的是保證軟件的實現(xiàn)滿足了用戶需求的一系列活動 1 確認測試的范圍 確認測試必須有用戶積極參與 或者以用戶為主進行 2 軟件配置復(fù)查 確認測試的一個重要內(nèi)容是復(fù)查軟件配置 3 Alpha和Beta測試 如果一個軟件是為許多客戶開發(fā)的 例如 向大眾出售的盒裝軟件產(chǎn)品 那么讓每個客戶都進行正式的驗收測試是不現(xiàn)實的 在這種情況下 絕大多數(shù)軟件開發(fā)商都使用被稱為Alpha測試和Beta測試的過程 來發(fā)現(xiàn)那些看起來只有最終用戶才能發(fā)現(xiàn)的錯誤 Alpha測試由用戶在開發(fā)者的場所進行 并且在開發(fā)者對用戶的 指導(dǎo) 下進行測試 開發(fā)者負責(zé)記錄錯誤和使用中遇到的問題 總之 Alpha測試是在受控的環(huán)境中進行的 Beta測試由軟件的最終用戶們在一個或多個客戶場所進行 與Alpha測試不同 開發(fā)者通常不在Beta測試的現(xiàn)場 因此 Beta測試是軟件在開發(fā)者不能控制的環(huán)境中的 真實 應(yīng)用 用戶記錄下在Beta測試過程中遇到的一切問題 真實的或想像的 并且定期把這些問題報告給開發(fā)者 接收到Beta測試期間報告的問題之后 軟件開發(fā)者對產(chǎn)品進行修改 并準(zhǔn)備向全體客戶發(fā)布最終的軟件產(chǎn)品 5 7調(diào)試 調(diào)試 也稱為糾錯 作為成功的測試的后果而出現(xiàn) 也就是說 調(diào)試是在測試發(fā)現(xiàn)錯誤之后排除錯誤的過程 5 7 1調(diào)試過程 調(diào)試不是測試 但是它總是發(fā)生在測試之后 如圖5 10所示 調(diào)試過程從執(zhí)行一個測試用例開始 評估測試結(jié)果 如果發(fā)現(xiàn)實際結(jié)果與預(yù)期結(jié)果不一致 則這種不一致就是一個癥狀 它表明在軟件中存在著隱藏的問題 調(diào)試過程試圖找出產(chǎn)生癥狀的原因 以便改正錯誤 圖5 10調(diào)試過程 5 7 2調(diào)試途徑 無論采用什么方法 調(diào)試的根本目標(biāo)都是尋找軟件錯誤的原因并改正之 這個目標(biāo)是通過把系統(tǒng)地評估 直覺和運氣組合起來實現(xiàn)的 一般來說 有下列三種調(diào)試途徑可以采用 蠻干法 回溯法 原因排除法 5 8軟件可靠性 5 8 1基本概念 1 軟件可靠性的定義 對于軟件可靠性有許多不同的定義 其中多數(shù)人承認的一個定義是 軟件可靠性是程序在給定的時間間隔內(nèi) 按照規(guī)格說明書的規(guī)定成功地運行的概率 2 軟件的可用性 通常用戶也很關(guān)注軟件系統(tǒng)可以使用的程度 一般來說 對于任何其故障是可以修復(fù)的系統(tǒng) 都應(yīng)該同時使用可靠性和可用性衡量它的優(yōu)劣程度 軟件可用性的一個定義是 軟件可用性是程序在給定的時間點 按照規(guī)格說明書的規(guī)定 成功地運行的概率 如果在一段時間內(nèi) 軟件系統(tǒng)故障停機時間分別為td1 td2 正常運行時間分別為tu1 tu2 則系統(tǒng)的穩(wěn)態(tài)可用性為 其中Tup tui Tdown tdi 如果引入系統(tǒng)平均無故障時間MTTF和平均維修時間MTTR的概念 則 5 1 式可以變成 平均維修時間MTTR是修復(fù)一個故障平均需要用的時間 它取決于維護人員的技術(shù)水平和對系統(tǒng)的熟悉程度 也和系統(tǒng)的可維護性有重要關(guān)系 平均無故障時間MTTF是系統(tǒng)按規(guī)格說明書規(guī)定成功地運行的平均時間 它主要取決于系統(tǒng)中潛伏的錯誤的數(shù)目 因此和測試的關(guān)系十分密切 5 8 2估算平均無故障時間的方法 軟件的平均無故障時間MTTF是一個重要的質(zhì)量指標(biāo) 往往作為對軟件的一項要求 由用戶提出來 為了估算MTTF 首先引入一些有關(guān)的量 1 符號 在估算MTTF的過程中使用下述符號表示有關(guān)的數(shù)量 ET 測試之前程序中錯誤總數(shù) IT 程序長度 機器指令總數(shù) 測試 包括調(diào)試 時間 Ed 在0至 期間發(fā)現(xiàn)的錯誤數(shù) Ec 在0至 期間改正的錯誤數(shù) 2 基本假定 根據(jù)經(jīng)驗數(shù)據(jù) 可以作出下述假定 在類似的程序中 單位長度里的錯誤數(shù)ET IT近似為常數(shù) 美國的一些統(tǒng)計數(shù)字表明 通常 0 5 10 2 ET IT 2 10 2 也就是說 在測試之前每1000條指令中大約有5 20個錯誤 失效率正比于軟件中剩余的 潛藏的 錯誤數(shù) 而平均無故障時間MTTF與剩余的錯誤數(shù)成反比 此外 為了簡化討論 假設(shè)發(fā)現(xiàn)的每一個錯誤都立即正確地改正了 即 調(diào)試過程沒有引入新的錯誤 因此 Ec Ed 剩余的錯誤數(shù)為 Er ET Ec 單位長度程序中剩余的錯誤數(shù)為 r ET Ir Ec IT 3 估算平均無故障時間 經(jīng)驗表明 平均無故障時間與單位長度程序中剩余的錯誤數(shù)成反比 即 其中K為常數(shù) 它的值應(yīng)該根據(jù)經(jīng)驗選取 美國的一些統(tǒng)計數(shù)字表明 K的典型值是200 估算平均無故障時間的公式 可以評價軟件測試的進展情況 此外 由 5 5 式可得 因此 也可以根據(jù)對軟件平均無故障時間的要求 估計需要改正多少個錯誤之后 測試工作才能結(jié)束 4 估計錯誤總數(shù)的方法 1 植入錯誤法 使用這種估計方法 在測試之前由專人在程序中隨機地植入一些錯誤 測試之后 根據(jù)測試小組發(fā)現(xiàn)的錯誤中原有的和植入的兩種錯誤的比例 來估計程序中原有錯誤的總數(shù)ET 假設(shè)人為地植入的錯誤數(shù)為Ns 經(jīng)過一段時間的測試之后發(fā)現(xiàn)ns個植入的錯誤 此外還發(fā)現(xiàn)了n個原有的錯誤 如果可以認為測試方案發(fā)現(xiàn)植入錯誤和發(fā)現(xiàn)原有錯誤的能力相同 則能夠估計出程序中原有錯誤的總數(shù)為 其中即是錯誤總數(shù)E T的估計值 2 分別測試法 為了隨機地給一部分錯誤加標(biāo)記 分別測試法使用兩個測試員 或測試小組 彼此獨立地測試同一個程序的兩個副本 把其中一個測試員發(fā)現(xiàn)的錯誤作為有標(biāo)記的錯誤 具體做法是 在測試過程的早期階段 由測試員甲和測試員乙分別測試同一個程序的兩個副本 由另一名分析員分析他們的測試結(jié)果 用 表示測試時間 假設(shè) 0時錯誤總數(shù)為B0 1時測試員甲發(fā)現(xiàn)的錯誤數(shù)為B1 1時測試員乙發(fā)現(xiàn)的錯誤數(shù)為B2 1時兩個測試員發(fā)現(xiàn)的相同錯誤數(shù)為bc 如果認為測試員甲發(fā)現(xiàn)的錯誤是有標(biāo)記的 即程序中有標(biāo)記的錯誤總數(shù)為B1 則測試員乙發(fā)現(xiàn)的B2個錯誤中有bc個是有標(biāo)記的 假定測試員乙發(fā)現(xiàn)有標(biāo)記錯誤和發(fā)現(xiàn)無標(biāo)記錯誤的概率相同 則可以估計出測試前程序中的錯誤總數(shù)為 使用分別測試法 在測試階段的早期 每隔一段時間分析員分析兩名測試員的測試結(jié)果 并且用 5 8 式計算B0 如果幾次估算的結(jié)果相差不多 則可用B0的平均值作為ET的估計值 此后一名測試員可以改做其他工作 由余下的一名測試員繼續(xù)完成測試工作 因為他可以繼承另一名測試員的測試結(jié)果 所以分別測試法增加的測試成本并不太多 5 9小結(jié) 實現(xiàn)包括編碼和測試兩個階段 按照傳統(tǒng)的軟件工程方法學(xué) 編碼是在對軟件進行了概要設(shè)計和詳細設(shè)計之后進行的 編碼不過是把軟件設(shè)計的結(jié)果翻譯成用某種程序設(shè)計語言書寫的程序 因此 程序的質(zhì)量基本上由設(shè)計的質(zhì)量決定 但是 編碼使用的語言 特別是寫程序的風(fēng)格 也對程序質(zhì)量有相當(dāng)大的影響 大量實踐結(jié)果表明 高級程序設(shè)計語言較匯編語言有很多優(yōu)點 因此 除非在非常必要的場合 一般不要使用匯編語言寫程序 至于具體選用哪種高級程序設(shè)計語言 則不僅要考慮語言本身的特點 還應(yīng)該考慮使用環(huán)境等一系列實際因素 程序內(nèi)部的良好文檔資料 有規(guī)律的數(shù)據(jù)說明格式 簡單清晰的語句構(gòu)造和輸入 輸出格式等 都對提高程序的可讀性有很大作用 也在相當(dāng)大的程度上改進了程序的可維護性 目前 軟件測試仍然是保證軟件可靠性的主要手段 測試階段的根本任務(wù)是發(fā)現(xiàn)并改正軟件中的錯誤 設(shè)計測試方案是測試階段的關(guān)鍵技術(shù)問題 其基本目標(biāo)是選用盡可能少的高效測試數(shù)據(jù) 做到盡可能完善的測試 從而盡可能多地發(fā)現(xiàn)軟件中的錯誤 白盒測試和黑盒測試是軟件測試的兩類不同方法 這兩類方法各有所長 相互補充 在測試過程中應(yīng)該聯(lián)合使用這兩類方法 通常 在測試過程的早期階段主要使用白盒測試技術(shù) 而在測試的后期主要使用黑盒測試技術(shù) 為了設(shè)計出有效的測試方案 軟件工程師必須深入理解并應(yīng)用指導(dǎo)軟件測試的基本準(zhǔn)則 設(shè)計白盒測試方案的技術(shù)主要有邏輯覆蓋和控制結(jié)構(gòu)測試 設(shè)計黑盒測試方案的技術(shù)主要有等價劃分 邊界值分析和錯誤推測 大型軟件的測試應(yīng)該分階段進行 通常分為單元測試 集成測試 確認測試和系統(tǒng)測試 如果軟件是新開發(fā)的計算機系統(tǒng)的一部分 第四個階段 在測試過程中發(fā)現(xiàn)的軟件錯誤必須及時改正 這就是調(diào)試的任務(wù) 為了改正錯誤 首先必須確定錯誤的準(zhǔn)確位置 這是調(diào)試過程中最困難的任務(wù) 需要審慎周密的思考和推理 改正錯誤往往需要修正原來的設(shè)計 必須通盤考慮而不能 頭疼醫(yī)頭腳疼醫(yī)腳 應(yīng)該盡量避免在調(diào)試過程中引進新的錯誤 測試和調(diào)試是軟件測試階段中的兩個關(guān)系極端密切的過程 它們常常交替進行 程序中潛藏的錯誤的數(shù)目 直接決定了軟件的可靠性 通過測試可以估計出程序中剩余的錯誤數(shù) 根據(jù)測試和調(diào)試過程中已經(jīng)發(fā)現(xiàn)和改正的錯誤數(shù) 可以估計軟件的平均無故障時間 反之 根據(jù)要求達到的軟件平均無故障時間 可以估計應(yīng)該發(fā)現(xiàn)和改正的錯誤數(shù) 從而能夠判斷測試階段何時可以結(jié)束