軟體測試的一些認識

 * 測試過程按4個步驟進行，即單元測試、整合測試、確認測試和系統測試及發版測試。
* 開始是單元測試，集中對用原始碼實現的每一個程式單元進行測試，檢查各個程式模組是否正確地實現了規定的功能。

* 整合測試把已測試過的模組組裝起來，主要對與設計相關的軟體體繫結構的構造進行測試。
* 確認測試則是要檢查已實現的軟體是否滿足了需求規格說明中確定了的各種需求，以及軟體配置是否完全、正確。
* 系統測試把已經經過確認的軟體納入實際運行環境中，與其它系統成份組合在一起進行測試。
單元測試 (Unit Testing)
* 單元測試又稱模組測試，是針對軟體設計的最小單位 — 程式模組，進行正確性檢驗的測試工作。其目的在於發現各模組內部可能存在的各種差錯。
* 單元測試需要從程式的內部結構出發設計測試案例。多個模組可以平行地獨立進行單元測試。
1. 單元測試的內容
* 在單元測試時，測試者需要依據詳細設計說明書和來源程式清單，瞭解該模組的I/O條件和模組的邏輯結構，主要採用白盒測試的測試案例，輔之以黑箱測試的測試案例，使之對任何合理的輸入和不合理的輸入，都能鑒別和響應。

(1) 模組介面測試
* 在單元測試的開始，應對通過被測模組的資料流進行測試。測試專案包括：
– 調用本模組的輸入參數是否正確；
– 本模組調用子模組時輸入給子模組的參數是否正確；
– 全域量的定義在各模組中是否一致；

* 在做內外存交換時要考慮：

– 檔案屬性是否正確；
– OPEN與CLOSE語句是否正確；
– 緩衝區容量與記錄長度是否匹配；
– 在進行讀寫操作之前是否開啟了檔案；
– 在結束檔案處理時是否關閉了檔案；
– 本文書寫／輸入錯誤，
– I／O錯誤是否檢查並做了處理。

(2) 局部資料結構測試
* 不正確或不一致的資料類型說明
* 使用尚未賦值或尚未初始化的變數
* 錯誤的初始值或錯誤的預設值
* 變數名拼字錯或書寫錯
* 不一致的資料類型
* 全域資料對模組的影響
(3) 路徑測試
* 選擇適當的測試案例，對模組中重要的執行路徑進行測試。
* 應當設計測試案例尋找由於錯誤的計算、不正確的比較或不正常的控制流程而導致的錯誤。
* 對基本執行路徑和迴圈進行測試可以發現大量的路徑錯誤。
(4) 錯誤處理測試
* 出錯的描述是否難以理解
* 出錯的描述是否能夠對錯誤定位
* 顯示的錯誤與實際的錯誤是否相符
* 對錯誤條件的處理正確與否
* 在對錯誤進行處理之前，錯誤條件是否已經引起系統的幹預等
(5) 邊界測試
* 注意資料流、控制流程中剛好等於、大於或小於確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試案例，認真加以測試。
* 如果對模組已耗用時間有要求的話，還要專門進行關鍵路徑測試，以確定最壞情況下和平均意義下影響模組已耗用時間的因素。

2. 單元測試的步驟
* 模組並不是一個獨立的程式，在考慮測試模組時，同時要考慮它和外界的聯絡，用一些輔助模組去類比與被測模組相聯絡的其它模組。
– 驅動模組 (driver)
– 樁模組 (stub) —— 存根模組

* 如果一個模組要完成多種功能，可以將這個模組看成由幾個小程式組成。必須對其中的每個小程式先進行單元測試要做的工作，對關鍵模組還要做效能測試。
* 對支援某些標準規程的程式，更要著手進行互聯測試。有人把這種情況特別稱為模組測試，以區別單元測試。
整合測試（Integrated Testing）
* 整合測試 (整合測試、聯合測試）
* 通常，在單元測試的基礎上，需要將所有模組按照設計要求組裝成為系統。這時需要考慮的問題是：
– 在把各個模組串連起來的時侯，穿越模組介面的資料是否會丟失；
– 一個模組的功能是否會對另一個模組的功能產生不利的影響；

– 各個子功能組合起來，能否達到預期要求的父功能；
– 全域資料結構是否有問題；
– 單個模組的誤差累積起來，是否會放大，從而達到不能接受的程度。
在單元測試的同時可進行整合測試，
發現並排除在模組串連中可能出現
的問題，最終構成要求的軟體系統。

* 子系統的整合測試特別稱為組件測試，它所做的工作是要找出整合後的子系統與系統需求規格說明之間的不一致。
* 通常，把模組整合成為系統的方式有兩種
– 一次性整合方式
– 增殖式整合方式

1. 一次性整合方式(big bang)
* 它是一種非增殖式組裝方式。也叫做整體拼裝。
* 使用這種方式，首先對每個模組分別進行模組測試，然後再把所有模組組裝在一起進行測試，最終得到要求的軟體系統。

2. 增殖式整合方式
* 這種整合方式又稱漸增式整合
* 首先對一個個模組進行模組測試，然後將這些模組逐步組裝成較大的系統
* 在整合的過程中邊串連邊測試，以發現串連過程中產生的問題
* 通過增殖逐步組裝成為要求的軟體系統。

(1) 自頂向下的增殖方式
* 這種整合方式將模組按系統程式結構，沿控制層次自頂向下進行組裝。
* 自頂向下的增殖方式在測試過程中較早地驗證了主要的控制和判斷點。
* 選用按深度方向組裝的方式，可以首先實現和驗證一個完整的軟體功能。

(2) 自底向上的增殖方式
* 這種整合的方式是從程式模組結構的最底層的模組開始整合和測試。
* 因為模組是自底向上進行組裝，對於一個給定層次的模組，它的子模組（包括子模組的所有下屬模組）已經組裝並測試完成，所以不再需要樁模組。在模組的測試過程中需要從子模組得到的資訊可以直接運行子模組得到。

* 自頂向下增殖的方式和自底向上增殖的方式各有優缺點。
* 一般來講，一種方式的優點是另一種方式的缺點。
(3) 混合增殖式測試
* 衍變的自頂向下的增殖測試
– 首先對輸入／輸出模組和引入新演算法模組進行測試;
– 再自底向上組裝成為功能相當完整且相對獨立的子系統;
– 然後由主模組開始自頂向下進行增殖測試。

* 自底向上-自頂向下的增殖測試
– 首先對含讀操作的子系統自底向上直至根結點模組進行組裝和測試;
– 然後對含寫操作的子系統做自頂向下的組裝與測試。
* 迴歸測試
– 這種方式採取自頂向下的方式測試被修改的模組及其子模組;
– 然後將這一部分視為子系統，再自底向上測試。
關鍵模組問題
* 在組裝測試時，應當確定關鍵模組，對這些關鍵模組及早進行測試。
* 關鍵模組的特徵：
① 滿足某些軟體需求；
② 在程式的模組結構中位於較高的層次（高層控制模組）；
③ 較複雜、較易發生錯誤；
④ 有明確定義的效能要求。

確認測試（Validation Testing）
* 確認測試又稱有效性測試。任務是驗證軟體的功能和效能及其它特性是否與使用者的要求一致。
* 對軟體的功能和效能要求在軟體需求規格說明書中已經明確規定。它包含的資訊就是軟體確認測試的基礎。

1. 進行有效性測試（黑箱測試）
* 有效性測試是在類比的環境 (可能就是開發的環境) 下，運用黑箱測試的方法，驗證被測軟體是否滿足需求規格說明書列出的需求。
* 首先制定測試計劃，規定要做測試的種類。還需要制定一組測試步驟，描述具體的測試案例。

* 通過實施預定的測試計劃和測試步驟，確定
– 軟體的特性是否與需求相符；
– 所有的文檔都是正確且便於使用；
– 同時，對其它軟體需求，例如可移植性、相容性、出錯自動回復、可維護性等，也都要進行測試

* 在全部軟體測試的測試案例運行完後，所有的測試結果可以分為兩類：
– 測試結果與預期的結果相符。這說明軟體的這部分功能或效能特徵與需求規格說明書相符合，從而這部分程式被接受。
– 測試結果與預期的結果不符。這說明軟體的這部分功能或效能特徵與需求規格說明不一致，因此要為它提交一份問題報告。

2. 軟體配置複查
n 軟體配置複查的目的是保證
u 軟體配置的所有成分都齊全；
u 各方面的品質都符合要求；
u 具有維護階段所必需的細節；
u 而且已經編排好分類的目錄。
n 應當嚴格遵守使用者手冊和操作手冊中規定的使用步驟，以便檢查這些文檔資料的完整性和正確性。
驗收測試（Acceptance Testing）
* 在通過了系統的有效性測試及軟體配置審查之後，就應開始系統的驗收測試。
* 驗收測試是以使用者為主的測試。軟體開發人員和QA（品質保證）人員也應參加。
* 由使用者參加設計測試案例，使用生產中的實際資料進行測試。

* 在測試過程中，除了考慮軟體的功能和效能外，還應對軟體的可移植性、相容性、可維護性、錯誤的恢複功能等進行確認。
* 確認測試應交付的文檔有：
– 確認測試分析報告
– 最終的使用者手冊和操作手冊
– 項目開發總結報告。

系統測試（System Testing）
* 系統測試，是將通過確認測試的軟體，作為整個基於電腦系統的一個元素，與電腦硬體、外設、某些支援軟體、資料和人員等其它系統元素結合在一起，在實際運行環境下，對電腦系統進行一系列的組裝測試和確認測試。
* 系統測試的目的在於通過與系統的需求定義作比較, 發現軟體與系統的定義不符合或與之矛盾的地方。