第五章 軟體測試過程

大綱 5.1 軟體測試階段 5.2 單元測試 5.3 整合測試 5.4 系統測試 5.5 驗收測試 5.6 測試案例設計 5.7 結論

軟體測試階段 軟體測試階段 軟體測試V Model 軟體各階段測試 軟體測試類型

軟體測試階段1 軟體測試是有階段性。 軟體測試進程和軟體設計周期相互有關係。 而該什麼階段做什麼測試?以什麼策是為依據? 引用 V模型(V model) 說明

軟體測試階段2 V model 圖對於軟體的開發測試的管理提供一個簡單的框架 根據V model圖，管理人員可以安排對應的工作 也可以判斷測試工作是否更上進度

軟體測試V Model1 圖：軟體測試的V model

軟體測試V Model2 V model優勢 透過V圖左邊項目文件評審，發現不合理處可以馬上修正。 透過早期計畫，去做出測試風險預測。 透過各階層的測試準備工作，可以了解測試工作與人員配置是否完善。 透過各階層的回饋，使軟體品質不斷提升。

軟體各階段測試 軟體開發初期，都是由各個小單元去組成程式。 針對每個類別內的方法使用除錯器(Debugger)去測試各步驟與功能。 最後開發人員再系統的整體功能做整合測試。

軟體測試類型1 單元測試 針對類別中的細小個體去做測試。 整合測試 穩定度與功能性上的測試，整合了內外部與所支援的額外軟體。

軟體測試類型2 系統測試 對軟體的整體進行測試。 驗收測試 以專案客戶制定的驗收標準去測試產品。

單元測試 目錄 單元測試介紹 單元測試的內容 單元測試的環境 單元測試的實施步驟 單元測試結論

單元測試介紹1 單元測試是最早期的測試，保證該單元的功能與設計文件中的描述一致。 對軟體的可分離的、獨立的、最小的功能部分進行測試。 將類別中的方法視為細小的個體，並且針對這些個體做測試。

單元測試介紹2 單元測試是一種設計，通常視為附屬物編碼步驟 。 單元測試除了可以檢測我們程式碼的品質，同時是一張安全網，在整個開發過程當中當我們對程式碼作任何新增或變動時保護我們的程式碼不至於受到破壞。 單元測試用來提升開發速度及品質。

單元測試介紹3 所謂的單元指的是： 軟體裡面最小的、並且可以獨立執行編碼的單位。 採用流程語言程式設計軟體，而單元可有一個或多個接近函數組成。 採用物件導向語言設計軟體，而單元可有一個或多個類別跟方法組成。

單元測試介紹4 單元測試都是有各部分的程式設計師完成，所以必須訂立一套統一標準，維護測試品質。 注意的項目就有： 列出單元測試過程、每項內容和判斷準則 所有參考文件與實例 安排的測試時間與目標 列出測試的方法種類 重複測試結果是否相同…等

單元測試內容1 圖：單元測試內容

單元測試內容2 單元測試針對以下五個內容去進行檢查： 模組介面(interface) 主要是為了檢查輸入與輸出的資料是否正確。 區域資料結構(local data structures) 檢查區域資料結構是否能保持完整性。

單元測試內容3 邊界測試(boundary conditions) 檢查臨界資料是否正確處理 模組獨立執行路徑(independent paths) 檢查由於計算錯誤、判定錯誤、控制流錯誤導致產生的程式錯誤。 錯誤處理測試(error-handling paths) 檢查內部錯誤處理設施是否有用。

單元測試環境1 圖：單元測試的環境構成

單元測試環境2 對於每一組輸入，都應該會有預期的正常結果。 如果模組不是獨立的程式，就會需要輔助測試模組。有兩種： 驅動模組(Driver)：所測模組的主程序。 殘根模組(Stub)：用來代替所測模組呼叫的子模組。

單元測試的實施步驟1 為了使測試方法化和流程化，所以我們制定了四個實施步驟： 1.制定測試計畫：測試計畫由單元開發人員依據具體現況去設計和制定。 2.測試計畫評審：由測試人員進行，開發人員配合對測試計畫進行評改與修改，以完成最終的測試計畫。

單元測試的實施步驟2 3.測試計畫的執行：由測試操作人員按照制定的測試計畫流程化的進行，並且及時回饋。 4.測試結果分析與提交報告：由測試人員與開發人員共同對結果去進行分析、歸納，在提交測試文件報告。

單元測試的實施步驟 測試計畫 測試設計 測試執行 測試紀錄 分析 缺陷追蹤 完畢 圖：單元測試管理流程 測試總結

單元測試結論 單元測試不是只有測試，它同時提供了一個安全觀點給程式設計師設計，更進一步提供程式設計師信心。增加軟體的彈性，可以讓專案團隊隨時重整以便讓程式變的更乾淨。 同時軟體的彈性也可以允許客戶隨時變更他們的需求，而不至於因新功能的修改或新增而導致程式的不穩定甚至破壞。因此可以提供客戶更好的服務及信賴度。

整合測試 目錄 整合測試介紹 整合測試事前準備工作 整合模組界定 整合測試的過程 整合測試結論

整合測試介紹1 再單元測試之後，按照模組的功能、性能及模組與模組之間介面的測試。 測試各程式碼單元間能否相互合作完成某種功能。 整合測試可以由程式設計師或軟體品保工程師進行。

整合測試介紹2 整合測試最終目是要檢驗軟體結構中各模組的的每個功能與性能介面功能是否正常。 整合測試包括由一個模組啟用另一個相連的模，檢驗模組間的資料傳輸正確性。

整合測試介紹3 圖：整合測試的表示圖

整合測試事前準備工作 收集並閱讀系統設計書與模組設計書中的相關模組介面的描述。 找出模組間的互動、關聯和資料流通狀況。 不管測試是否測試檔是否有對整合測試有規定，都要使用原本或是加上規定來做。 如果要編寫整合實例，就要按照設計文件去編寫。

整合模組界定1 模組的界定，會因為具體的軟體結構不同而有不同的界定。 對於使用流程語言軟體的模組，模組可以是一組函數或過程，此函數擁有獨立功能和完整介面，可以去跟其他模組連接、相互作用。

整合模組界定2 對於使用物件導向語言軟體的模組，可以是一組物件，此物件擁有某一功能和完整介面，可以去跟其他模組連接、相互作用。 對於使用網頁跟使用者視窗介面，模組就是一個網頁和子網頁，或一個視窗和子視窗。

整合模組步驟與方法1 一般步驟： 但是選擇不同種類整合方法，會影響模組測試的形式，還有測試工具的 類別型、模組編號的次號和順序。 確定子系統有哪些模組，並且都通過單元測試步驟。 有開發人員組裝這些模組，生出一個子系統，使各個模組功能可以發揮出來。 設計測試用例，並且搭建所需要的測試環境。 紀錄測試結果，總結測試問題。 但是選擇不同種類整合方法，會影響模組測試的形式，還有測試工具的 類別型、模組編號的次號和順序。

整合模組步驟與方法2 常用的整合方式有： 1.由上而下的增值方式 2.由下而上的增值方式 3.混合增值方式(三明治法)

由上而下的增值方式1 將模組依據系統的程式結構，沿控制層次由上而下進行整合。 會提早驗證主要的控制和判斷點，如果知道主要控制有問題，可以盡早發現它能夠減少以後的返工。

由上而下的增值方式2 優點： 系統的整合測試可以減至最少。 最高階層的介面最先被測試，且被測試的機會最多。 高階層的模組是低階層模組最佳的測試啟動(Driver)模組。 系統的錯誤若在上階層，則可及早發現。

由上而下的增值方式3 缺點： 需要製造殘根或虛擬模組。 殘根或虛擬模組的設計通常比較複雜。 以殘根或虛擬模組執行輸入、輸出功能較困 難。 測試個案的產生可能會很困難。 測試結果較難觀察。 低階層次模組，若想做平行測試，將會受制 於其上階層模組是否已完成。

由上而下的增值方式4 圖：由上到下增值方式

由下而上的增值方式1 從程式結構的最底層模組開始組裝和測試。 因為模組是由下而上進行組裝，對於一個給定層次的模組，它的子模組已經組裝並測試完成，所以不需要殘根模組。 模組的測試過程需要從子模組得到的資訊可以直接執行子模組得到。

由下而上的增值方式2 優點： 測試個案較容易設計。 測試結果較易觀察。 系統錯誤如果在下方，則可及早發現。 最低階的測試較徹底。 缺點： 必須製造啟動模組。 整體的系統要等到最後一模組（通常是最頂端模組）加上之後才能見到全貌。

由下而上的增值方式3 圖：由下到上增值方式

混合增值方式 因為由上而下增值方式和由下而上增值方式各有優缺點，而混合增值方式(三明治法)就是把由上而下和由下而上這兩種增值方式結合起來進行整合和測試。 使用兩個方式的優點，但是屏除其缺點。

整合測試的過程1 整合測試的目的是確保每個單元在組合後，還能以原定意圖協作執行，並且保證增量行為正確。 整合測試的過程包括：制定整合測試計畫、設計整合測試、實作整合測試、執行整合測試、評估整合測試等過程

整合測試的過程2 制定整合測試計畫 設計整合測試 實作整合測試 執行整合測試 評估整合測試 制定一份設計模型和整合建構計畫。 設計一份整合測試用例的測試過程。 實作整合測試 實施整合測試用例的測試過程。 執行整合測試 執行出來後的測試結果 評估整合測試 把測試結果評估

整合測試的過程3 制定集成測試計畫 設計整合測試 實作整合測試 執行整合測試 評估整合測試 圖：整合測試過程

回歸測試 每當增加一個新的單元或是功能去集成測試，有可能會使軟體產生變化，這些變化可能會導致原本功能會有問題。 回歸測試是重新執行一些子集的測試，以確保不會產生變化跟意想不到的副作用。

整合測試結論 整合測試中程式設計部門負責的是整合之後，軟體模組間的互相呼叫測試、模組性能測試及模組介面的測試。 整合測試可以當作黑箱測試，不必直接對原始程式碼進行測試，反而只是測試含有單元的模組，這是跟單元測試最大的差異。

系統測試 目錄 系統測試介紹 系統測試事前準備工作 系統測試的測試技術 系統測試結論

系統測試介紹 系統測試就是對軟體整理進行測試，測試軟體本身運作時的各功能與性能。 系統測試是個宏觀測試，不需要再去針對軟體細節的品質。 由測試部門的測試工程師去執行。

系統測試事前準備工作1 系統測試主要是檢驗軟體本身的各種功能與介面操作是否正常，並且檢驗軟體本身強度、性能、相容性、損壞修復…等相關品質方面的指標。

系統測試事前準備工作2 系統測試事前準備工作： 收集軟體規格書，做為依據。 收集軟體設計書，作為參考。 收集測試企劃書，。

系統測試事前準備工作3 如果沒有現成的系統測試實例，則需要做大量的工作、考慮以下項目去編寫實例。 系統各種功能描述。 系統對於性能的要求與傳輸資料速率要求。 對於備份及修復的要求。 相容性與配置的描述。 安全性的要求。

系統測試方法1 強度測試 (Stress tests)： 測試系統在特殊條件下的最高實際上限度。 驗證系統在面臨同時許多要求的時候，是否 可以在繼續運作。 要求軟體進行大量重複、輸入大量資料、大 數值的資料…等。

系統測試方法2 效能測試 (Performance tests)： 測試軟體在執行時的執行效能。 通常與強度測試結合進行測試。 事先被測軟體提出效能指標。

系統測試方法3 安全測試 (Security tests)： 驗證安裝系統內的保護機構能確實的對系統 進行保護。 對於一些非法存取的使用者，驗證訪問機制 的工作。 設計一些測試專用的案例。

系統測試方法4 修復測試 (Recovery tests)： 測試系統的可靠性及可修復性。 採用人工的干擾使軟體出錯，中斷使用。 驗證系統失敗後的恢復能力，並參考效能測 試的相關測試指標。

系統測試方法5 可用性測試 (Availability tests)： 測試使用者是否能夠滿意的使用。 測試使用者再使用時會不會出現一些少見且 在之前並未被發現的錯誤。

系統測試方法6 安裝 / 移除測試 (Install / Uninstall test)： 需要對被測試的軟體結合需求分析仔細的測 試分析，建立測試案例。

系統測試方法7 α測試 是由一個使用者在開發環境下進行的測試，也可以視開發機構內部的使用者在模擬實際操作環境下進行的測試。 軟體在可以受控制的環境下進行測試，開發者會在使用者旁邊，並且隨時紀錄錯誤狀況跟使用中的問題。

系統測試方法8 β測試 由軟體的多個使用者在一個或多個使用者的實際使用環境下進行的測試。 開發者通常不在測試現場，所以β測試是在開發者無法控制的環境下進行的軟體現場應用。 所以使用者所記下的錯誤與問題，會有真實的以及主觀認定的。

系統測試結論 雖然系統測試本身涉及的部分很廣，可以如果時間、人力和物力的資源條件充足，可以在測試過程中編寫自動測試程式，以便於未來提升未來的測試效率。 如果發現系統缺陷時，都需要一一紀錄下來，以便於未來可以參考與使用。

驗收測試 目錄 驗收測試介紹 驗收測試的測試技術 驗收測試結論

驗收測試介紹 是一個流程，以獲得確認主題專家（中小型企業） ，最好是業主或客戶端的對象進行測試，通過審判或審查，該修改或增補符合雙方商定的要求。 專案客戶會制定一些驗收標準，來驗收產品。

驗收測試介紹 驗收測試是以使用者為主的測試。 使用使用者介面輸入資料，並且分析測試後的輸出結果，使用一般生產中的實際資料進行測試。 驗收測試對整個測試計畫進行一種”走查(Walkthrough)“。

驗收測試的測試技術1 用戶驗收測試 包括在工廠驗收測試，即測試完成之前，可以移動到用戶端由用戶驗收。 合約和規範驗收測試 合約驗收測試，指系統要驗收之前，此系統要已被測試採納，以確保它符合政府法律和安全標準。

驗收測試測試技術2 業務驗收測試 也可稱為業務準備測試，這是指做了檢查制度，以確保過程、程序與系統的使用和保養。這項目包括後備設施、程序、損壞恢復，最終用戶教育訓練、維修程序和安全程序。

驗收測試結論 驗收測試階段，我們的目標是提供信心，並且交付系統，以滿足業務需求和用戶。 驗收階段也可作為最後的品質觀察，凡是之前階段沒有發現的質量缺陷，都有可能在此階段發現。

測試案例設計 故障測試。 腳本測試。

故障測試 具有較高的發現可能故障的能力。 系統必須滿足使用者的需求。 故障測試關鍵取決於如何理解可能的錯誤。 故障測試可以用整合測試進而去發現可能性的故障。 可以用來確認不同類型的物件行為是否有正確性的屬性值。

腳本測試 以腳本基礎的測試主要關鍵在於使用者 的需求。 可以在一個單元測試情況下檢查多 重系統。 腳本測試會來得比案例測試更為實際，且更為複雜一點。

結論 本章介紹軟體測試的過程，主要分為四個階段：單元測試、整合測試、系統測試、驗收測試，各階段介紹測試流程，及各相關事項。 最後介紹測試案例的設計方式：故障測試與腳本測試。