3.1 軟件測試流程概述
軟件測試流程與軟件開發流程類似，也包括測試計劃、測試設計、測試開發、測試執行和測試評估幾個部分。
(1) 測試計劃。根據用戶需求報告中關於功能要求和性能指標的規格說明書，定義相應的測試需求報告，使得隨後所有的測試工作都將圍繞着測試需求來進行。同時，適當選擇測試內容，合理安排測試人員、測試時間及測試資源等。
(2) 測試設計。測試設計是指將測試計劃階段制訂的測試需求分解、細化爲若干個可執行的測試過程，併爲每個測試過程選擇適當的測試用例，保證測試結果的有效性。
(3) 測試開發。建立可重複使用的自動測試過程。
(4) 測試執行。執行測試開發階段建立的自動測試過程，並對所發現的缺陷進行跟蹤管理。測試執行一般由單元測試、集成測試、確認測試以及迴歸測試等步驟組成。
(5) 測試評估。結合量化的測試覆蓋域及缺陷跟蹤報告，對應用軟件的質量和開發團隊的工作進度及工作效率進行綜合評價。
在上述測試流程中，測試執行按以下步驟進行：單元測試、集成測試、確認測試和驗收測試，如圖3.1所示。
圖3.1 軟件測試執行過程
(1) 單元測試：通過對每個最小的軟件模塊進行測試，對源代碼的每一個程序單元實行測試，檢查各個程序模塊是否正確地實現了規定的功能，確保其能正常工作。
(2) 集成測試：對已測試過的模塊進行組裝集成，目的在於檢驗與軟件設計相關的程序結構問題。
(3) 確認測試：檢驗軟件是否滿足需求規格說明中的功能和性能需求，確定軟件配置完全、正確。同時檢驗軟件產品能否與實際運行環境中整個系統的其它部分(如硬件、數據庫及操作人員)協調工作。
(4) 驗收測試：作爲檢驗軟件產品質量的最後一道工序，主要讓用戶對軟件進行測試，並重新執行已經做過的測試的某個子集，保證沒有引入新的錯誤。
3.2 單 元 測 試
1．單元測試內容
單元測試針對程序模塊進行測試，主要有以下5個任務：模塊接口測試、局部數據結構測試、邊界條件測試、執行路徑測試和出錯處理測試，如圖3.2所示。
圖3.2 單元測試要解決的任務
1) 模塊接口測試
通過對被測模塊的數據流進行測試，檢查進出模塊的數據是否正確。因此，必須對模塊接口，包括參數表、調用子模塊的參數、全程數據、文件輸入/輸出等操作進行測試。具體涉及以下內容。
(1) 模塊接受輸入的實際參數個數與模塊的形式參數個數是否一致。
(2) 輸入的實際參數與模塊的形式參數的類型是否匹配。
(3) 輸入的實際參數與模塊的形式參數所使用的單位是否一致。
(4) 調用其它模塊時，所傳送的實際參數個數與被調用模塊的形式參數的個數是否相同。
(5) 調用其它模塊時，所傳送的實際參數與被調用模塊的形式參數的類型是否匹配。
(6) 調用其它模塊時，所傳送的實際參數與被調用模塊的形式參數的單位是否一致。
(7) 調用內部函數時，參數的個數、屬性和次序是否正確。
(8) 在模塊有多個入口的情況下，是否引用與當前入口無關的參數。
(9) 是否修改了只讀型參數。
(10) 全局變量是否在所有引用它們的模塊中都有相同的定義。
如果模塊內包括外部I/O，還應該考慮下列因素:
(1) 文件屬性是否正確。
(2) OPEN與CLOSE語句是否正確。
(3) 緩衝區容量與記錄長度是否匹配。
(4) 在進行讀/寫操作之前是否打開了文件。
(5) 在結束文件處理時是否關閉了文件。
(6) 正文書寫/輸入有無錯誤。
(7) I/O錯誤是否檢查並做了處理。
2) 局部數據結構測試
測試用例檢查局部數據結構的完整性，如數據類型說明、初始化、缺省值等方面的問題，並測試全局數據對模塊的影響。
在模塊工作過程中，必須測試模塊內部的數據能否保持完整性，包括內部數據的內容、形式及相互關係不發生錯誤。
局部數據結構應注意以下幾類錯誤：不正確的或不一致的類型說明；錯誤的初始化或默認值；錯誤的變量名，如拼寫錯誤或書寫錯誤；下溢、上溢或者地址錯誤。
3) 執行路徑測試
測試用例對模塊中重要的執行路徑進行測試，其中對基本執行路徑和循環進行測試往往可以發現大量路徑錯誤。測試用例必須能夠發現由於計算錯誤、不正確的判定或不正常的控制流而產生的錯誤。
常見的錯誤如下：誤解的或不正確的算術優先級；混合模式的運算錯誤；錯誤的初始化；精確度不夠精確；表達式的不正確符號表示。
針對判定和條件覆蓋，測試用例能夠發現如下錯誤：不同數據類型的比較錯誤；不正確的邏輯操作或優先級；應當相等的地方由於精確度的錯誤而不能相等；不正確的判定或不正確的變量；不正確的或不存在的循環終止；當遇到分支循環時不能退出；不適當地修改循環變量。
4) 出錯處理測試
檢查模塊的錯誤處理功能是否包含錯誤或缺陷。例如，是否拒絕不合理的輸入，出錯的描述是否難以理解，是否對錯誤定位有誤，是否出錯原因報告有誤，是否對錯誤條件的處理不正確，在對錯誤處理之前錯誤條件是否已經引起系統的干預等。
測試出錯處理的重點是當模塊在工作中發生錯誤時，其中的出錯處理設施是否有效。
5) 邊界條件測試
邊界條件測試是單元測試的最後一步，必須採用邊界值分析方法來設計測試用例。測試在爲限制數據處理而設置的邊界處，測試模塊是否能夠正常工作。
一些與邊界有關的數據類型，如第一個、最後一個、最大值、最小值、最長、最短、最高、最低等。
在邊界條件測試中，應設計測試用例檢查以下情況：
(1) 在n次循環的第0次、1次……n次是否有錯誤。
(2) 運算或判斷中取最大值、最小值時是否有錯誤。
(3) 數據流、控制流中剛好等於、大於、小於確定的比較值時是否出現錯誤。
2. 單元測試步驟
單元測試通常在編碼階段進行。在源程序代碼編制完成並經過評審和驗證，確認沒有語法錯誤之後，開始設計單元測試的測試用例。
模塊並不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯繫，因此使用一些輔助模塊去模擬與被測模塊相關的其它模塊。輔助模塊分爲以下兩種：
(1) 驅動模塊(Drive)：用來模擬被測模塊的上一級模塊，相當於被測模塊的主程序，用於接收測試數據，並把這些數據傳送給被測模塊，啓動被測模塊，最後輸出實測結果。
(2) 樁模塊(Stub)：用來模擬被測模塊工作過程中所調用的模塊。樁模塊一般只進行很少的數據處理，不需要把子模塊的所有功能都帶進來，但不允許什麼事情也不做。
被測模塊、與它相關的驅動模塊及樁模塊共同構成了一個“測試環境”，如圖3.3所示。
圖3.3 單元測試的測試環境
3.3 集 成 測 試
按照軟件設計要求，將經過單元測試的模塊連接起來，組成所規定的軟件系統的過程稱爲“集成”。集成測試就是針對這個過程，按模塊之間的依賴接口關係圖進行的測試。圖3.4給出了軟件分層結構的示例圖。
由於集成測試不是在真實環境下進行，而是在開發環境或是一個獨立的測試環境下進行的，因此集成測試所需人員一般從開發組中選出，在開發組長的監督下進行。開發組長負責保證在合理的質量控制和監督下使用合適的測試技術執行充分的集成測試。在集成測試過程中，由一個獨立測試觀察員來監控測試工作。
圖3.4 軟件分層結構的示意圖
1. 集成測試的主要任務
集成測試是組裝軟件的系統測試技術之一，按設計要求把通過單元測試的各個模塊組裝在一起之後，要求軟件系統符合實際軟件結構，發現與接口有關的各種錯誤。集成測試主要適應於如下幾種軟件系統：
(1) 對軟件質量要求較高的軟件系統，如航天軟件、電信軟件、系統底層軟件等。
(2) 使用範圍比較廣、用戶羣數量較大的軟件。
(3) 使用類似C/C++帶有指針的程序語言開發的軟件。
(4) 類庫、中間件等產品。
集成測試的主要任務是解決以下5個問題：
(1) 將各模塊連接起來，檢查模塊相互調用時數據經過接口是否丟失。
(2) 將各個子功能組合起來，檢查能否達到預期要求的各項功能。
(3) 一個模塊的功能是否會對另一個模塊的功能產生不利的影響。
(4) 全局數據結構是否有問題，會不會被異常修改。
(5) 單個模塊的誤差積累起來是否被放大，從而達到不可接受的程度。
2. 集成測試方法
集成測試主要測試軟件的結構問題，因此測試建立在模塊接口上，多爲黑盒測試，適當輔以白盒測試。執行集成測試應遵循如下步驟。
步驟1：確認組成一個完整系統的模塊之間的關係。
步驟2：評審模塊之間的交互和通信需求，確認模塊間的接口。
步驟3：生成一套測試用例。
步驟4：採用增量式測試，依次將模塊加入到系統並測試這個過程按邏輯/功能順序重複進行。
集成測試過程中尤其要注意關鍵模塊測試，關鍵模塊一般具有下述一個或多個特徵：
(1) 同時對應幾項需求功能；
(2) 具有高層控制功能；
(3) 複雜，易出錯；
(4) 有特殊的性能要求。
集成測試的主要目的是驗證組成軟件系統的各模塊的接口和交互作用，因此集成測試對數據的要求從難度和內容上不是很高。集成測試一般不使用真實數據，可以使用一部分代表性的測試數據。在創建測試數據時，應保證數據充分測試軟件系統的邊界條件。
集成測試包括非增量式集成測試和增量式集成測試。
1) 非增量式集成測試方法
非增量式集成測試方法採用一步到位的方法來進行測試，對所有模塊進行個別的單元測試後，按程序結構圖將各模塊連接起來，把連接後的程序當作一個整體進行測試。
2) 增量式集成測試方法
增量式集成測試方法具體包括自頂向下增量式測試、自底向上增量式測試以及三明治集成測試。
(1) 自頂向下增量式測試。自頂向下增量式測試按結構圖自上而下進行逐步集成和逐步測試。模塊集成的順序是首先集成主控模塊(主程序)，然後按照軟件控制層次結構向下進行集成。自頂向下的集成方式可以採用深度優先策略和廣度優先策略，如圖3.5所示。
圖3.5 自頂向下增量式測試示意圖
(2) 自底向上增量式測試。自底向上增量式測試是從“原子”模塊(軟件結構中最底層的模塊)開始，按結構圖自下而上逐步進行集成和測試。圖3.6表示採用自底向上增量式測試的過程。
圖3.6 自底向上增量式測試示意圖
(3) 三明治集成測試。三明治集成也稱混合集成，它將自頂向下和自底向上的優點和缺點集於一身。三明治集成是把系統分爲三層，中間一層爲目標層。測試時對目標層上面的一層採用自頂向下的集成測試方式，而對目標層下面的一層使用自底向上的集成策略，最後再對目標層進行測試。
如圖3.7所示，使用程序樁S2、S3和S4對用戶界面M1進行測試，使用驅動程序D5和D6對最底層功能模塊M7、M8和M9進行測試。當整個系統集成時，將程序樁S2、S3和S4換成中間層模塊M2、M3和M4，驅動程序D5和D6對換成中間層模塊M5和M6，從而對中間層的功能模塊進行測試。
圖3.7 三明治集成測試示意圖
3.4 確 認 測 試
確認測試用於驗證軟件的有效性，即驗證軟件的功能和性能及其它特性是否與用戶的要求一致。
在確認測試階段需要做的工作如圖3.8所示。首先要進行有效性測試以及軟件配置複審，然後進行驗收測試和安裝測試，在通過了專家鑑定之後，才能成爲可交付的軟件。
圖3.8 確認測試的步驟
1. 有效性測試
有效性測試是在模擬的環境下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規格說明書列出的需求。爲此，需要制定測試計劃，規定要做測試的種類，制定一組測試步驟，描述具體的測試用例。通過實施預定的測試計劃和測試步驟，確定軟件的特性是否與需求相符，確保所有的軟件功能需求都能得到滿足，所有的軟件性能需求都能達到，所有的文檔都是正確的且便於使用。
2. 軟件配置複查
軟件配置複查的目的是保證軟件配置的所有成分，包括與實際運行環境中整個系統的支持環境都齊全，各方面的質量都符合要求。在確認測試的過程中，應當嚴格遵守用戶手冊和操作手冊中規定的使用步驟，以便檢查這些文檔資料的完整性和正確性，記錄發現的遺漏和錯誤，並且適當地補充和改正。
3.5 驗 收 測 試
驗收測試是以用戶爲主的測試，軟件開發人員和質量保證人員也應參加。由用戶參加設計測試用例，通過用戶界面輸入測試數據，分析測試的輸出結果。一般使用生產中的實際數據進行測試。在測試過程中，除了考慮軟件的功能和性能外，還應對軟件的可移植性、兼容性、可維護性、錯誤的恢復功能等進行確認。
3.5.1 α測試和β測試
在軟件交付使用之後，用戶將如何實際使用程序，對於開發者來說是無法預測的。因爲用戶在使用過程中常常會發生各種問題，如對軟件操作使用方法的誤解；異常的數據組合；產生對某些用戶來說似乎是清晰的，但對另一些用戶來說卻難以理解的輸出，等等。
α測試和β測試用於發現可能只有最終用戶才能發現的錯誤。α測試可以是一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的測試。α測試是在受控制的環境下進行的測試。α測試的目的是評價軟件產品的FURPS，即功能、可使用性、可靠性、性能和支持，尤其注重產品的界面和特色。α測試可以從軟件產品編碼結束之時開始，或在模塊(子系統)測試完成之後開始，也可以在確認測試過程中產品達到一定的穩定度和可靠程度之後再開始。
β測試是由軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。與α測試不同的是，開發者通常不在測試現場。因而，β測試是在開發者無法控制的環境下進行的軟件現場應用。在β測試中，由用戶記下遇到的所有問題，包括真實的以及主觀認定的，定期向開發者報告；開發者在綜合用戶的報告之後，做出修改，最後將軟件產品交付給全體用戶使用。β測試着重於產品的支持性，包括文檔、客戶培訓和支持產品生產能力。只有當α測試達到一定的可靠程度時，才能開始β測試。
3.5.2 迴歸測試
軟件生命週期中的任何一個階段，只要軟件發生了改變，就可能給該軟件帶來缺陷問題。而軟件的改變可能是源於發現了錯誤並做了修改，也有可能是因爲在集成或維護階段加入了新的模塊等多種情況。迴歸測試是一種驗證已變更的系統的完整性與正確性的測試技術，是指重新執行已經做過的測試的某個子集，以保證修改沒有引入新的錯誤或者發現由於更改而引起的之前未發現的錯誤，也就是保證改變沒有帶來非預期的副作用。因此，軟件開發的各個階段會進行多次迴歸測試。
1．迴歸測試的實施前提
(1) 當軟件中所含錯誤被發現時，如果錯誤跟蹤與管理系統不夠完善，可能會遺漏對這些錯誤的修改；
(2) 開發者對錯誤理解得不夠透徹，也可能導致所做的修改只修正了錯誤的外在表現，而沒有修復錯誤本身，從而造成修改失敗；
(3) 修改還有可能產生副作用從而導致軟件未被修改的部分產生新的問題，使本來工作正常的功能產生錯誤。
2．迴歸測試的兩個策略
迴歸測試是貫穿整個測試的各個階段的測試活動，其目的是檢驗已經發現的缺陷有沒有正確修改和修改過程中有沒有引發新的缺陷。可以採用如下的策略進行迴歸測試。
1) 完全重複測試
完全重複測試是指將所有的測試用例全部再完全地執行一遍，以確認問題修改的正確性和修改後周邊是否受到影響的測試方法。其缺點是由於要把用例全部執行，因此會增加項目成本，也會影響項目進度，所以很難完全執行。
2) 選擇性重複測試
選擇性重複測試是指可以選擇一部分進行執行，以確認問題修改的正確性和修改後周邊是否受到影響的測試方法。下面介紹幾種選擇性重複測試的方法：
(1) 覆蓋修改法。
(2) 周邊影響法。
(3) 指標達成法。
(4) 基於操作剖面測試法。
(5) 基於風險選擇測試法。
3．迴歸測試的流程
迴歸測試的流程一般具有如下步驟。
步驟1：在測試策略制定階段，制定迴歸測試策略。
步驟2：確定迴歸測試版本。
步驟3：迴歸測試版本發佈，按照迴歸測試策略執行迴歸測試。
步驟4：迴歸測試通過，關閉缺陷跟蹤單。
步驟5：迴歸測試不通過，缺陷單返回；開發人員重新修改，再次做迴歸測試。
4．迴歸測試與一般測試的比較
迴歸測試與一般測試相比具有許多不同點，下面分別從測試計劃的可獲性、測試範圍、時間分配、開發信息、完成時間和執行效率等方面進行介紹。
(1) 測試計劃的可獲性：一般測試根據系統規格說明書和測試計劃，測試用例都是新的；而回歸測試可能是更改了的規格說明書、修改過的程序和需要更新的測試計劃。
(2) 測試範圍：一般測試的目標是檢測整個程序的正確性；而回歸測試的目標是檢測被修改的相關部分的正確性以及它與系統原有功能的整合。
(3) 時間分配：一般測試所需時間通常是在軟件開發之前預算；而回歸測試所需的時間(尤其是修正性的迴歸測試)往往不包含在整個產品進度表中。
(4) 開發信息：一般測試關於開發的知識和信息可隨時獲取；而回歸測試可能會在不同的地點和時間進行，需要保留開發信息以保證迴歸測試的正確。
(5) 完成時間：由於迴歸測試只需測試程序的一部分，因此完成測試所需時間通常比一般測試所需時間少。
(6) 執行頻率：迴歸測試在一個系統的生命週期內往往要多次進行，一旦系統經過修改就需要進行迴歸測試。