第八章軟件質量與質量保證8.1軟件質量的定義8.2影響軟件質量的因素8.3軟件質量保證策略8.4軟件質量保證活動8.5軟件評審 8.6軟件質量保證的標準8.7結構化程序的測試8.8面向對象的軟件測試8.9測試計劃與測試分析報告8.10軟件維護 8.1軟件質量的定義8.1軟件質量的定義軟件質量為“與軟件產品滿足規定的和隱含的需求的能力有關的特征或特性的全體”。

軟件質量是各種特性的復雜組合，隨著應用的不同而異，隨著用戶提出的質量要求不同而不同。

8.2影響軟件質量的因素8.2影響軟件質量的因素1．影響軟件質量的主要因素（1）正確性：系統滿足規格說明和用戶目標的程度，即在預定環境下能正確地完成預期功能的程度。（2）健壯性：在硬件發生故障、輸入的數據無效或操作錯誤等意外環境下，系統能做出適當響應的程度。（3）效率：為了完成預定的功能，系統需要的計算資源的多少。（4）安全性：對未經授權的人使用軟件或數據的企圖，系統能夠控制的程度。8.2影響軟件質量的因素1．影響軟件質量的主要因素（5）可用性：系統在完成預定應該完成的功能時令人滿意的程度。（6）風險：按預定的成本和進度把系統開發出來，并且受用戶所滿意的概率。（7）可理解性：理解和使用該系統的容易程度。（8）可維修性：診斷和改正在運行現場發現的錯誤所需要的工作量的大小。（9）適應性：修改或改進正在運行的系統需要的工作量的多少。8.2影響軟件質量的因素1．影響軟件質量的主要因素（10）可測試性：軟件容易測試的程度。（11）可移植性：把程序從一種硬件配置和軟件系統環境轉移到另一種配置和環境時，需要的工作量的多少。有一種定量度量的方法是：用原來程序設計和調試的成本除移植時需用的費用。（12）可再用性：在其他應用中該程序可以被再次使用的程度。（13）互運行性：把該系統和另一個系統結合起來的工作量的多少。8.2影響軟件質量的因素2．軟件質量評價應遵守的原則（1）應強調軟件總體質量（低成本高質量），而不應片面強調軟件正確性，忽略其可維護性與可靠性、可用性與效率等。（2）應在軟件工程化生產的整個周期的各個階段都注意軟件的質量，而不能只在軟件最終產品驗收時注意質量。（3）應制定軟件質量標準，定量地評價軟件質量，使軟件產品評價執行評測結合，以測為主的科學方法。

8.3軟件質量保證策略8.3軟件質量保證策略1．審查 審查就是在軟件生命周期每個階段結束之前，都正式使用結束標準對該階段生產出的軟件配置成分進行嚴格的技術審查。8.3軟件質量保證策略審查過程的步驟如下：（1）計劃：組織審查組，分發材料，安排日程等。（2）概貌介紹：當項目復雜龐大時，可由作者介紹概況。（3）準備：評審員閱讀材料取得有關項目的知識。（4）評審會：目的是發現和記錄錯誤。（5）返工：作者修正已經發現的問題。（6）復查：判斷返工是否真正解決了問題。8.3軟件質量保證策略2．復查和管理復審復查即是檢查已有的材料，以確定某階段的工作是否能夠開始或繼續。每個階段開始時的復查，是為了肯定前一個階段結束時的審查，已經具備了開始當前階段工作所必需的材料。管理復審通常指向開發組織或使用部門的管理人員，提供有關項目的總體狀況、成本和進度等方面的情況，以便從管理角度對開發工作進行審查。8.3軟件質量保證策略3．測試 測試就是用已知的輸入在已知環境中動態地運行系統或系統的部件。如果測試結果和預期的結果不一致，則表明系統中可能出現了錯誤。8.3軟件質量保證策略測試過程中產生的基本文檔如下：(1)測試計劃：通常包括單元測試和集成測試，確定測試范圍、方法和需要的資源等。(2)測試過程：詳細描述和每個測試方案有關的測試步驟和數據，包括測試數據及預期的結果。(3)測試結果：把每次測試運行的結果歸入文檔，如果運行出錯，則應產生問題報告，并且通過調試解決所發現的問題。8.4軟件質量保證活動8.4軟件質量保證活動1.驗證與確認 驗證是為了確定開發時期中某一階段的產品是否達到了階段對它的需求，確認則是在整個開發結束時對所開發的軟件能否滿足軟件需求的總評價。

8.4軟件質量保證活動2.開發時期的配置管理雖然維護時期堅持配置管理十分重要。但事實上，對配置的控制從計劃時期就開始了，一直延續到生存周期結束、軟件停止使用后才終止。軟件配置包括生存期中各個階段產生的文檔和程序。這些文檔或程序是隨著軟件的開發進程逐步產生的，所以也稱為階段產品

8.5軟件評審

8.5.1設計質量的評審內容

8.5.2程序質量的評審內容8.5軟件評審

8.5.1設計質量的評審內容 設計質量的評審對象是在需求分析階段產生的軟件需求規格說明、數據要求規格說明，在軟件概要設計階段產生的軟件概要設計說明等。8.5軟件評審

8.5.1設計質量的評審內容1．軟件的規格說明2．可靠性 可靠性措施應能失效發生

3保密措施實現4.操作特性實施5.性能實現6.可修改性7.可擴充性8.互換性 互換性是指當軟件功能擴充之后，其已有功能還能照原樣使用的特性。8.5軟件評審

8.5.1設計質量的評審內容9.可移植性 可移植性是指當把軟件移植到不同的運行環境時，不需改變其規格就能照原樣工作的特性。10.可測試性 可測試性是為保證軟件質量，有效地進行充分、全面的測試的特性。

11.復用性 復用性包含可移植性及功能上通用性等

12.互連性 與其他軟件有共同的接口及該接口部分是模塊化的，容易改變的。8.5軟件評審

8.5.2程序質量的評審內容1.軟件的結構(1)功能結構(2)功能的通用性(3)模塊的層次(4)模塊結構(5)處理過程的結構8.5軟件評審

8.5.2程序質量的評審內容2.與運行環境的接口(1)與其他軟件的接口(2)與硬件的接口(3)與用戶的接口(4)運行環境變更時的影響范圍8.6軟件質量保證的標準8.6軟件質量保證的標準1.ISO對質量保證系統的方法ISO9000質量保證模型將一個企業視為一個互聯過程的網絡。為了使質量系統符合ISO標準，這些過程必須與標準中給出的區域對應，并且必須按照描述進行文檔化和實現。ISO9000以一般術語描述了一個質量保證系統的要素。這些要素包括用于實現質量計劃、質量控制、質量保證和質量改進所需的組織結構、規程、過程和資源。8.6軟件質量保證的標準2.ISO9001標準（1）管理責任（2）質量系統（3）合同復審（4）設計控制（5）文檔和數據控制（6）采購（7）對客戶提供的產品的控制8.6軟件質量保證的標準2.ISO9001標準（8）產品標識和可跟蹤性（9）過程控制（10）審查和測試（11）審查、度量和測試設備的控制（12）審查和測試狀態（13）對不符合標準產品的控制（14）改正和預防行動8.6軟件質量保證的標準2.ISO9001標準（15）處理、存儲、包裝、保存和交付（16）質量記錄的控制（17）內部質量審計（18）培訓（19）服務（20）統計技術8.7結構化程序的測試

8.7.1軟件測試的目的

8.7.2軟件測試的原則

8.7.3軟件測試的對象

8.7.4軟件測試的基本過程8.7結構化程序的測試

8.7.1軟件測試的目的1．軟件測試的目的（1）軟件測試是確認軟件的質量，其一方面是確認軟件做了所期望的事情，另一方面是確認軟件以正確的方式來做了這個事件。（2）軟件測試是提供信息，比如提供給開發人員或項目經理的反饋信息，為風險評估所準備的信息。8.7結構化程序的測試

8.7.1軟件測試的目的1．軟件測試的目的（3）軟件測試不僅是在測試軟件產品本身，而且還包括軟件開發的過程。如果一個軟件產品開發完成之后發現了很多問題，則說明此軟件開發過程很可能是有缺陷的。因此這個目的是保證整個軟件開發過程的高質量。8.7結構化程序的測試

8.7.1軟件測試的目的2．軟件質量（1）在正確的時間用正確的的方法把一個工作做正確。（2）符合一些應用標準的要求，比如不同國家的用戶不同的操作習慣和要求，項目工程中的可維護性、可測試性等要求。（3）質量本身就是軟件達到了最開始所設定的要求，而代碼設計的技巧并不代表軟件的高質量。8.7結構化程序的測試

8.7.1軟件測試的目的2．軟件質量（4）質量也代表著它符合客戶的需要。作為軟件測試這個行業，最重要的一件事就是從客戶的需求出發，從客戶的角度去看產品，客戶如何使用這個產品，使用過程中將遇到什么樣的問題。只有這些問題都解決了，軟件產品的質量才可以說是上去了。8.7結構化程序的測試

8.7.2軟件測試的原則從用戶的角度出發，就是希望通過軟件測試能充分暴露軟件中存在的問題和缺陷，從而考慮是否可以接受該產品；從開發者的角度出發，就是希望測試能表明軟件產品不存在錯誤，已經正確地實現了用戶的需求。

8.7結構化程序的測試

8.7.2軟件測試的原則1．應當盡早測試和不斷的測試。2．程序員應該避免檢查自己的程序，測試工作應該由獨立的專業的軟件測試機構來完成。

3．設計測試用例時應該考慮到合法的輸入和不合法的輸入以及各種邊界條件，特殊情況要制造極端狀態和意外狀態，例如網絡異常中斷、電源斷電等情況。

4．一定要注意測試中的錯誤集中發生現象，這與程序員的編程水平和習慣有很大的關系。8.7結構化程序的測試

8.7.2軟件測試的原則

5．對測試錯誤結果一定要有一個確認的過程，一般有A測試出來的錯誤，一定要有一個B來確認，嚴重的錯誤可以召開評審會進行討論和分析。

6．制定嚴格的測試計劃，并把測試時間安排的盡量寬松，不要希望在極短的時間內完成一個高水平的測試。

7．回歸測試的關聯性一定要引起充分的注意，修改一個錯誤而引起更多的錯誤出現。

8．妥善保存測試過程文檔有重要意義，因為測試的重現性往往要靠測試文檔。8.7結構化程序的測試

8.7.3軟件測試的對象

軟件測試并不等同程序測試。軟件測試應該貫穿于軟件定義與開發的整個期間。因此需求分析、概要設計、詳細設計以及程序編碼等各階段所得到的文檔，包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程序，都應該是軟件測試的對象。

8.7結構化程序的測試

8.7.4軟件測試的基本過程軟件測試過程通常包括以下基本的測試活動

:1．擬定軟件測試計劃。2．編制軟件測試大綱。3．設計和生成測試用例。4．實施測試。5．生成軟件問題報告。8.7結構化程序的測試

8.7.5軟件測試技術

1．靜態分析技術 不執行被測軟件，可對需求分析說明書、軟件設計說明書、源程序做結構檢查、流程分析、符號執行來找出軟件錯誤。8.7結構化程序的測試

8.7.5軟件測試技術

1．靜態分析技術(1)結構檢查是手工分析技術，由一組人員對程序設計，需求分析，編碼，測試工作進行評議，虛擬執行程序，評議中作錯誤檢驗。8.7結構化程序的測試

8.7.5軟件測試技術

1．靜態分析技術(2)流圖分析是通過分析程序流程圖的代碼結構，來查程序的語法錯誤信息，語句中標識符引用狀況，予程序和函數調用狀況，變量是否賦初值，定義而未使用的變量，未說明或無用的標號，無法執行到的代碼段。8.7結構化程序的測試

8.7.5軟件測試技術

1．靜態分析技術(3)符號執行是一種符號化定義數據，并為程序每條路徑給出符號表達式，對特定路徑輸入符號，經處理輸出符號，從而判斷程序行為是否錯誤，達到分析錯誤的目的。8.7結構化程序的測試

8.7.5軟件測試技術2．動態測試技術 當把程序作為一個函數，輸入的全體稱為函數的定義域，輸出的全體稱為函數的值域，函數則描述了輸入的定義域與輸出值域的關系。

8.7結構化程序的測試

8.7.5軟件測試技術2．動態測試技術動態測試的過程為：

(1)選取定義域中的有效值，或定義域外無效值。(2)對已選取值決定預期的結果。(3)用選取值執行程序。(4)觀察程序行為，記錄執行結果。(5)將(4)的結果與(2)的結果相比較，不相同則表明程序有錯。8.7結構化程序的測試

8.7.5軟件測試技術

3．黑盒測試和白盒測試(1）黑盒測試法：又稱為功能測試。它把程序看成一個黑盒子，完全不考慮程序的內部結構和處理過程。(2）白盒測試法：它的前提是可以把程序看成裝在一個透明的白盒子里，也就是完全了解程序的結構和處理過程。8.7結構化程序的測試

8.7.6設計測試方案概述設計測試方案是測試階段的關鍵技術問題。測試方案包括預定要測試的功能、應該輸入的測試數據和預期的結果，其中最困難的問題是設計測試用的輸入數據，即測試用例。設計測試方案的基本目標是確定一組最可能發現某個錯誤或某類錯誤的測試數據。

8.7結構化程序的測試

8.7.6設計測試方案

1．白盒法(1)語句覆蓋(2)判定覆蓋(3)條件覆蓋(4)判定／條件覆蓋(5)條件組合覆蓋(6)路徑覆蓋8.7結構化程序的測試

8.7.6設計測試方案

2．黑盒法(1)等價劃分 使用等價劃分法設計測試方案首先需要劃分輸入數據的等價類，為此需要研究程序的功能說明，從而確定輸入數據的有效等價類和無效等價類。8.7結構化程序的測試

8.7.6設計測試方案

2．黑盒法(2)邊界值分析 使用邊界值分析方法設計測試方案首先應該確定邊界情況，這需要經驗和創造性，對于輸入等價類和輸出等價類的邊界確定，就是應該著重測試的程序邊界情況。

8.7結構化程序的測試

8.7.7測試的步驟

軟件測試的步驟:（1）單元測試（2）集成測試（3）確認測試（4）系統測試（5）驗收測試8.7結構化程序的測試

8.7.8軟件糾錯技術 根據測試出錯誤的外因分析找到內部原因并加以改正的代碼執行與人工活動稱為糾錯。

8.7結構化程序的測試

8.7.8軟件糾錯技術1.糾錯策略方法（1）強力法（2）跟蹤法（3）演繹法（4）歸納法 （5）測試糾錯法（6）試湊法（7）回歸測試（8）對分查找法8.8面向對象的軟件測試

8.8.1面向對象分析

和面向對象設計的模型測試

8.8.2面向對象的測試策略

8.8.3面向對象軟件測試集設計8.8面向對象的軟件測試

8.8.1面向對象分析和面向對象設計 的模型測試1.面向對象分析和設計模型的正確性 用于表示分析和設計模型的符號體系和語法將是與為項目選定的特定分析和設計方法聯系的。因此，不僅考慮語法正確性和符號體系是否合適使用，而且對每個模型復審以保證保持合適的建模約定。8.8面向對象的軟件測試

8.8.1面向對象分析和面向對象設計 的模型測試2．面向對象分析和設計模型的一致性 對OOA和OOD模型的一致性判斷可以通過考慮模型中實體間的關系，不一致的模型在某一部分有表示，但未在模型的其他部分正確地反映。8.8面向對象的軟件測試

8.8.2面向對象的測試策略1．面向對象的單元測試 對OO軟件的類測試等價于傳統軟件的單元測試。和傳統軟件的單元測試不一樣，OO軟件的類測試是由封裝在類中的操作和類的狀態行為所驅動的

8.8面向對象的軟件測試

8.8.2面向對象的測試策略2．面向對象的組裝測試 對OO軟件的集成測試有兩種不同策略，第一種稱為基于線程的測試，集成對回應系統的一個輸入或事件所需的一組類，每個線程被集成并分別測試，應用回歸測試以保證沒有產生副作用。8.8面向對象的軟件測試

8.8.2面向對象的測試策略2．面向對象的組裝測試 第二種稱為基于使用的測試，通過測試那些幾乎不使用服務器類的類（稱為獨立類）而開始構造系統，在獨立類測試完成后，下一層使用獨立類的類（稱為依賴類）被測試。這個依賴類層次的測試序列一直持續到構造完整系統。8.8面向對象的軟件測試

8.8.2面向對象的測試策略3．面向對象的確認測試傳統的黑盒測試方法可被用于有效性測試，此外，測試集可以從對象/行為模型和作為OOA的一部分的事件流圖中導出。傳統的黑盒測試方法可被用于有效性測試，此外，測試集可以從對象/行為模型和作為OOA的一部分的事件流圖中導出。8.8面向對象的軟件測試

8.8.3面向對象軟件測試集設計1．面向對象測試集設計的概念 OO測試集設計的方法如下：（1）每個測試集應該被惟一標識，并且和將被測試的類顯式地相關聯；（2）應該陳述測試的目的；（3）對每個測試應該開發一組測試步驟

8.8面向對象的軟件測試

8.8.3面向對象軟件測試集設計2．傳統測試集設計方法的適用性白盒測試方法可用于對為類定義的操作的測試，基本路徑、循環測試或數據流技術可以幫助保證已經測試了操作中的每一條語句，然而，很多類操作的簡潔結構導致把用白盒測試的工作量用于類級別的測試會更好。黑盒測試方法就像對傳統軟件工程方法開發的系統和對OO系統同樣適用的，測試集可以為黑盒及基于狀態的測試設計提供有用的輸入。8.8面向對象的軟件測試

8.8.3面向對象軟件測試集設計3.基于故障的測試 在OO系統中基于故障的測試的目標是設計最有可能發現似乎可能的故障的測試。由于產品或系統必須符合客戶需求，因此，完成基于故障的測試所需的初步計劃是從分析模型開始。測試員查找似乎可能的故障，為了確定是否存在這些故障，設計測試集以測試設計或代碼。8.8面向對象的軟件測試

8.8.3面向對象軟件測試集設計4．面向對象編程對測試的影響（1）某些類型的故障變得幾乎不可能（不值得去測試）（2）某些類型的故障變得更加可能（值得進行測試）（3）出現某些新的故障類型（4）當調用一個操作時，很難確切知道執行什么代碼，即可能屬于很多類之一。

8.8面向對象的軟件測試

8.8.3面向對象軟件測試集設計5．測試外部結構和內部結構（1）外部結構 外部結構指OO程序的外部可觀察的結構，即對終端用戶立即可見的結構。

（2）內部結構 內部結構指OO程序的內部技術細節，即通過檢查設計和/或代碼而理解的結構。

8.9測試計劃與測試分析報告8.9測試計劃與測試分析報告測試計劃可細化為測試計劃、測試設計說明、測試用例說明和測試規格說明；測試分析報告可細化為測試項傳遞報告、測試日志、測試事件報告和測試總結報告。8.10軟件維護

8.10.1軟件維護分類與特點

8.10.2軟件維護步驟

8.10.3軟件的可維護性

8.10.4軟件維護的副作用

8.10.5逆向工程和再生工程8.10軟件維護

8.10.1軟件維護分類與特點1.軟件維護的原因(1)改正在特定的使用條件下暴露出來的一些潛在程序錯誤或設計缺陷。(2)在軟件使用過程中因數據環境發生變化或處理環境發生變化，需要修改軟件以適應這種變化。(3)用戶和數據處理人員在使用時常提出改進現有功能、增加新的功能及改善總體性能的要求，為了滿足這些要求，就需要修改軟件并把這些要求納入到軟件之中。8.10軟件維護

8.10.1軟件維護分類與特點2.維護的分類按維護性質不同，軟件維護可分為：改正性維護、適應性維護、完善性維護和預防性維護等。8.10軟件維護

8.10.1軟件維護分類與特點3.維護的特點(1)結構化維護與非結構化維護(2)維護的代價(3)維護的問題 與軟件維護有關的絕大多數問題，都可歸因于軟件定義和軟件開發的方法的缺點。

8.10軟件維護

8.10.2軟件維護步驟1．維護步驟（1）分析和理解程序（2）修改程序（3）詳細地分析要修改的模塊和數據結 構的內部細節，設計修改計劃，標 明新邏輯及要改動的現有邏輯。（4）向用戶提供回避措施。

（5）修改代碼以適應變化

（6）重新驗證程序8.10軟件維護

8.10.2軟件維護步驟2．維護組織 每個維護申請通過維護管理員轉告給系統管理員，系統管理員一般都是對程序特別熟悉的技術人員，他們對維護申請及可能引起的軟件修改進行評估，并向修改控制決策機構（一個或一組管理者）報告，由它最后確定是否采取行動。

8.10軟件維護

8.10.3軟件的可維護性

1．影響可維護性的因素（1）是否擁有一組訓練有素的軟件人員；（2）系統結構是否可理解；（3）是否使用標準的程序設計語言；（4）是否使用標準的操作系統；（5）文檔的結構是否標準化；（6）測試用例是否合適；（7）是否已有嵌入系統的調試工具；（8）是否有一臺計算機可用于維護。8.10軟件維護

8.10.3軟件的可維護性

2．量化的測度（1）發現問題所用的時間；（2）收集維護工具使用的時間；（3）分析問題所需時間；（4）形成修改說明書所用時間；（5）糾錯（或修改）所用時間；（6）局部測試所用時間；（7）整體測試所用時間；（8）維護復審所用時間；（9）完全恢復所用時間。8.10軟件維護

8.10.3軟件的可維護性

3．保證可維護性的復審 在軟件工程每一階段的復審中，可維護性都是重要的指標。需求分析階段的復審設計階段的復審代碼復審配置復審8.10軟件維護

8.10.4軟