一.概述
1.軟件測試定義兩面性
2.測試的生命週期
測試需求分析-->測試設計-->測試計劃-->測試執行-->質量評估
3.軟件測試過程：
需求評審和設計評審是驗證軟件產品的需求定義和設計實現，驗證所定義的產品特性是否符合客戶的期望、系統的設計是否合理、是否具有可測試性以及滿足非功能質量特性的要求。這個階段主要通過對需求文檔、設計文檔等閱讀、討論，從中發現軟件需求工程和系統設計中所存在的問題 。
單元測試的對象是程序系統中的最小單元---模塊或組件上，在編碼階段進行，針對每個模塊進行測試，主要通過白盒測試方法，從程序的內部結構出發設計測試用例，檢查程序模塊或組件的已實現的功能與定義的功能是否一致、以及編碼中是否存在錯誤。多個模塊可以平行地、對立地測試，通常要編寫驅動模塊和樁模塊 單元測試一般由編程人員和測試人員共同完成。
集成測試，也稱組裝測試、聯合測試、子系統測試，在單元測試的基礎上，將模塊按照設計要求組裝起來同時進行測試，主要目標是發現與接口有關的模塊之間問題 兩種集成方式：一次性集成方式和增殖式集成方式。
功能測試一般須在完成集成測試後進行，而且是針對應用系統進行測試。功能測試是基於產品功能說明書，是在已知產品所應具有的功能，從用戶角度來進行功能驗證，以確認每個功能是否都能正常使用。
系統測試是將軟件放在整個計算機環境下，包括軟硬件平臺、某些支持軟件、數據和人員等，在實際運行環境下進行一系列的測試，包括恢復測試、安全測試、強度測試和性能測試等。
驗收測試的目的是向未來的用戶表明系統能夠像預定要求那樣工作，驗證軟件的功能和性能如同用戶所合理期待的那樣 。
安裝測試是指按照軟件產品安裝手冊或相應的文檔，在一個和用戶使用該產品完全一樣的環境中或相當於用戶使用環境中，進行一步一步的安裝操作性的測試。
軟件測試與開發關係：
二.需求和設計評審
1. 產品需求審查是軟件開發重要環節之一，也是測試活動之一，即靜態測試——需求驗證。藉助需求審查保證用戶需求在市場/產品需求文檔及其相關文檔中得到準確、完整、無歧義的反映，並使各類開發人員在需求理解上達成一致。
2.測試需求：
測試目標取決於軟件質量需求，而這種需求分爲功能性需求和非功能性需求，功能性的需求相對容易確定，非功能性的測試需求難以確定。
- 在制定測試計劃之前，必須清楚測試需求
- 明確測試需求的優先級
- 測試需求分解得越細，對測試用例的設計質量越有幫助
- 詳細的測試需求還是衡量測試覆蓋率的重要依據
- 測試需求是規劃具體項目資源和時間的基礎。
3.功能性測試需求
（1）功能性測試需求主要是根據產品規格說明書來檢驗被測試的系統是否滿足軟件各方面的功能的使用要求，包括用戶界面的友好性。
- 程序安裝、啓動正常，有相應的提示框、錯誤提示
- 各項功能符合設計要求，正常運行並輸出正確結果
- 功能邏輯合理，並能處理各種異常操作
- 能接受正確的數據輸入，輸出結果準確，格式清晰
- 系統的各種狀態按照業務流程而變化並保持穩定
支持各種應用環境，能配合硬件設備
（2）功能測試需求分析
瞭解需求範圍-->明確目標用戶-->分析功能步驟-->挖掘隱藏需求
- 瞭解需求想要做什麼，要完成哪些功能模塊
- 需求目標是誰？不同的用戶角色，功能和權限是否一樣？
- 要完成功能，用戶需要哪些步驟
- 挖掘隱藏需求
4.用戶界面及其顯示要求
用戶界面是和用戶進行交互的窗口，其友好程度直接影響用戶對於軟件產品或軟件服務的滿意度。良好的用戶體驗，簡單、方便和明瞭，讓用戶舒暢、愉悅
- 通用框架、浮動窗口和文字等整體佈局合理
- 文字顯示正常，且內容格式正確、美觀。
- 色彩協調，風格前後一致， 文字標記和超鏈接可以打開和跳轉成功
5.非功能性需求
非功能性質量需求，包括系統性能、安全性、兼容性、擴充性，其測試需求會因不同的項目類型差異較大。
- 客戶端軟件，如字處理軟件、媒體播放軟件等佔用較少資源，在容錯性、兼容性等方面要求高。
- Web應用系統對性能、安全性等有很高要求 客戶端/服務器應用系統。
- 大型複雜企業級系統。
6.測試人員在需求評審中作用
需求評審歸爲靜態測試範疇，包含了文檔評審和技術評審雙重內容，通常通過正式的評審會議來進行。而測試人員主要起着評審員的作用，檢查需求定義是否合理和清楚。
- 明確自己的角色和責任
- 熟悉評審內容，爲評審做好準備
- 針對問題闡述觀點，而非針對個人
- 從客戶角度想問題，多問幾個爲什麼
- 在會前或會後提出自己建設性的意見
- 對發現的問題跟蹤到底
- 針對需求文檔等報告問題
7.設計審查
1）成功的產品開發和演化依賴於體系結構恰當的選擇。軟件設計一般可以分爲體系結構設計和詳細設計。測試人員參與設計評審保證需求能在設計中得到準確和完整的表示，也就是保證產品規格說明書的質量。
- 系統架構的審查
- 設計規格說明書的審查
- 系統部署設計的審查
- 多層次審查:high-level low-level
2）系統架構設計的審查
系統架構設計的基本要求就是保證系統具有高性能、高可靠性、高安全性、高擴展性和可管理性 。系統架構設計評審就是保證這些特性在設計中得到充分考慮。
3）組件設計的審查
- 功能和接口定義正
- 算法的有效性和優化
- 合理的數據結構、數據流和控制流
- 可測試性 等
4）系統部署設計的審查
系統部署設計的審查是基於軟件服務的質量目標，用來審查軟件部署的目標、策略是否合理，是否得到徹底的執行
- 着重是否服從和遵守部署設計的技術規範
- 邏輯設計的審查
- 物理設計的審查
- 可用性設計的審查
- 可伸縮型設計的驗證
- 安全性設計的驗證
三.測試用例設計
1.測試用例（test case）是可以被獨立執行的一個過程，這個過程是一個最小的測試實體，不能再被分解。測試用例也就是爲了某個測試點而設計的測試操作過程序列、條件、期望結果及其相關數據的一個特定的集合。
2.測試用例的元素：
3.如何設計出高質量的測試用例
- 客戶需求導向的設計思路
- 責任到人
- 靈活的設計方法
- 測試用例設計不能侷限於輸入數據 儘量避免含糊的、冗長的或複雜的測試用例
- 儘量將具有相類似功能的測試用例抽象並歸類
4.良好測試用例的特徵
- 可以最大程度地找出軟件隱藏的缺陷
- 可以最高效率的找出軟件缺陷
- 可以最大程度地滿足測試覆蓋要求
- 既不過分複雜、也不能過分簡單 使軟件缺陷的表現可以清楚的判定
- 測試用例包含期望的正確的結果
- 待查的輸出結果或文件必須儘量簡單明瞭
- 不包含重複的測試用例
- 測試用例內容清晰、格式一致、分類組織
5.測試用例設計步驟
6.測試用例的創建
建立合適的、可擴展的測試用例框架，從而藉助這個框架能有效地組織衆多的測試用例，包括對測試用例的分類、清晰的層次結構等。
7.測試用例套件
測試套件是由一系列測試用例並與之關聯的測試環境組合而構成的集合，已滿足測試執行的特定要求。通過測試套件，將服務於同一個測試目標、特定階段性測試目標或某一運行環境下的一系列測試用例有機地組合起來
.
四.單元測試
1.單元測試方法：
單元測試主要採用白盒測試方法，輔以黑盒測試方法。白盒測試方法應用於代碼評審、單元程序檢驗之中，而黑盒測試方法則應用於模塊、組件等大單元的功能測試之中。
2.黑白盒測試方法：
黑盒測試方法（Blake-box Testing），是把程序看作一個不能打開的黑盒子，不考慮程序內部結構和內部特性，而是考察數據的輸入、條件限制和數據輸出，完成測試。
白盒測試方法（White-box Testing），也稱結構測試或邏輯驅動測試。白盒測試方法是根據模塊內部結構瞭解，基於內部邏輯結構，針對程序語句、路徑、變量狀態等來進行測試，檢驗程序中的各個分支條件是否得到滿足、每條執行路徑是否按預定要求正確的工作。
驅動程序（driver），對底層或子層模塊進行（單元或集成）測試時所編制的調用被測模塊的程序，用以模擬被測模塊的上級模塊
樁程序（stub），也有人稱爲存根程序，對頂層或上層模塊進行測試時，所編制的替代下層模塊的程序，用以模擬被測模塊工作過程中所調用的模塊。
3.白盒測試方法的用例設計
語句覆蓋，使得程序中每一條可執行語句至少被執行一次
分支覆蓋，使得程序中每一個分支都至少被執行一次
|
節點① |
N < 0 : 如N= -1， -2， …， -10， … |
|
N >= 0: 如N=1，2， …， 10， … |
|
|
節點③ |
(K<N) and (R<=Max) 成立 （True） |
|
(K<N) and (R<=Max) 不成立 （False） |
|
|
節點⑤ |
R<= Max |
|
R> Max |
N= -2，Max = 10: 覆蓋①②③④③④③⑥
N= 5，Max = 1: 覆蓋①②③④③④③⑦
分支覆蓋VS語句覆蓋
條件覆蓋，程序中每一個條件至少有一次被滿足
條件覆蓋 vs. 分支覆蓋
條件覆蓋不能保證分支覆蓋，例如設計兩個測試用例N= 1、Max = -1和N= 0、Max = 1
(K<N) and (R<=Max)＝.T. 的分支沒有被覆蓋
設計兩個測試用例N= 3、Max = 10和N= -1、Max = 0，即覆蓋了所有條件，也覆蓋了所有分支
路徑覆蓋，對程序模塊的所有獨立的基本路徑至少要測試一次
路徑覆蓋就是設計所有的測試用例，來覆蓋程序中的所有可能的執行路徑。基本路徑測試法是在程序控制流圖的基礎上，通過分析控制構造的環路複雜性，導出基本可執行路徑集合，從而設計測試用例的方法。設計出的測試用例要保證被測試程序的每個可執行語句至少被執行一次。
示例：
確定基本路徑獲得測試用例：
環路複雜性：
圖形矩陣：
4.代碼審查
代碼審查的目的就是爲了產生合格的代碼，檢查源程序編碼是否符合詳細設計的編碼規定，確保編碼與設計的一致性和可追蹤性
代碼規範性的審查
- 代碼規範性的審查將助於更早地發現缺陷，代碼質量的提高，而且可以幫助程序員遵守規則、養成好的習慣，以達到預防缺陷的目的
- 代碼風格和編程規則兩者不可缺一，都應列入代碼評審的範圍裏
- 命名規則 、縮進與對齊 、註釋 和函數處理 等。
5.集成測試
非漸增式測試模式
採用大棒集成方法,先是對每一個子模塊進行測試（單元測試階段），然後將所有模塊一次性的全部集成起來進行集成測試 。
因爲所有的模塊一次集成的，所以很難確定出錯的真正位置、所在的模塊、錯誤的原因。這種方法並不推薦在任何系統中使用，適合在規模較小的應用系統中使用。
非漸增式測試模式：先分別測試每個模塊，再把所有模塊按設計要求放在一起結合成所要的程序，如大棒模式。
漸增式測試模式：把下一個要測試的模塊同已經測試好的模塊結合起來進行測試，測試完以後再把下一個應該測試的模塊結合進
驅動程序/驅動模塊（driver），用以模擬被測模塊的上級模塊。驅動模塊在集成測試中接受測試數據，把相關的數據傳送給被測模塊，啓動被測模塊，並打印出相應的結果。
樁程序/樁模塊（stub），也有人稱爲存根程序，用以模擬被測模塊工作過程中所調用的模塊。樁模塊由被測模塊調用，它們一般只進行很少的數據處理，例如打印入口和返回，以便於檢驗被測模塊與其下級模塊的接口來測試。
自頂向下法(Top-down Integration)
自底向上法(Bottom-up Integration)
微軟VSTS的單元測試
Visual Studio Team System（VSTS）是一套工具集，全面整合了軟件設計、開發、測試、部署和人員協作工具，其開發版（Development Edition）提供了靜態分析、代碼剖析、代碼涵蓋以及其它單元測試所需的功能特性。
- 創建單元測試項目。
- 設置項目引用。
- 添加適當的測試類（一個或多個）。
- 生成主幹的單元測試框架（Unit Test Framework）類和屬性。
- 創建單個測試方法。
- 創建適合特定接口的邏輯
五.自動化測試
自動化測試（automated test）是相對手工測試（manual test）而存在的一個概念，由手工逐個地運行測試用例的操作過程被測試工具自動執行的過程所代替。 測試工具的使用是自動化測試的主要特徵
六.功能測試
1.功能測試，依據產品設計規格說明書完成對產品功能進行操作，以驗證系統是否滿足用戶的功能性需求
2.等價類法
等價類是某個輸入域的子集，在該子集中每個輸入數據的作用是等效的
將程序可能的輸入數據分成若干個子集，從每個子集選取一個代表性的數據作爲測試用例
在分析需求規格說明的基礎上劃分等價類，列出等價類表
3.有效等價類是有意義的、合理的輸入數據，可以檢查程序是否實現了規格說明中所規定的功能和性能
無效等價類和有效等價類相反，即不滿足程序輸入要求或者無效的輸入數據構成的集合
（設計測試用例時，要同時考慮這兩種等價類。因爲軟件不僅要能接收合理的數據，也要能經受意外的考驗。經過正反的測試才能確保軟件具有更高的可靠性。）
4.確定等價類的方法
在輸入條件規定了取值範圍或值的個數的情況下，則可以確立一個有效等價類和兩個無效等價類。
（2）邊界值計方法
程序的很多錯誤發生在輸入或輸出範圍的邊界上，因此針對各種邊界情況設置測試用例，可以更有效地發現缺陷。
設計方法： 確定邊界情況（輸入或輸出等價類的邊界） 選取正好等於、剛剛大於或剛剛小於邊界值作爲測試數據
（3）因果圖法
在實際應用的測試之中，經常碰到多種條件及其組合的情況 通過因果圖，可以建立輸入條件和輸出之間的邏輯模型，從而比較容易確定輸入條件組合和輸出之間的邏輯關係，有利於設計全面的測試用例
輸入與輸出關係：
E約束（異）：多個條件中至少有一個條件不成立，即Ci不能同時爲1。
I約束（或）：多個條件中至少有一個條件成立，即Ci不能同時爲0。
O約束（唯一）；多個條件中必須有一個且僅有一個條件成立，即Ci中只有一個爲1
R約束（要求）：一個條件對另一個條件有約束，如C1是1，C2也必須須是1。
設計步驟：
分析軟件規格說明書中的輸入輸出條件並劃分出等價類，將每個輸入輸出賦予一個標誌符
分析規格說明中的語義，通過這些語義來找出多個輸入因素之間的關係。
找出輸入因素與輸出結果之間的關係，將對應的輸入與輸出之間的關係關聯起來，並將其中不可能的組合情況標註成約束或者限制條件，形成因果圖。
由因果圖轉化成決策表，任何由輸入與輸出之間關係構成的路徑，形成決策表的一列 將決策表的每一列拿
實例（1）
根據因果圖，就可以轉化爲判定表。這裏根據條C2 與C3、C4與C5的E約束（互斥），可以減少組合
決策表方法：
一個決策表由“條件和活動”兩部分組成，也就是列出了一個測試活動執行所需的條件組合。所有可能的條件組合定義了一系列的選擇，而測試活動需要考慮每一個選擇。
條件樁，列出問題的所有條件
動作樁：列出可能針對問題所採取的操作
條件項：針對所列條件的具體賦值（可取真值和假值）
動作項：列出在條件項組合情況下應該採取的動作
規則：任何一個條件組合的特定取值及其相應要執行的操作
功能圖法：
每個程序的功能通常由靜態說明和動態說明組成，靜態說明描述了輸入條件和輸出條件之間的對應關係，而動態說明描述了輸入數據的次序或者轉移的次序。
功能圖法就是爲了解決動態說明問題的一種測試用例的設計方法
功能圖由狀態遷移圖（state transition diagram，STD）和邏輯功能模型（logic function model， LFM）構成
狀態遷移圖，描述系統狀態變化的動態信息——動態說明，由狀態和遷移來描述，狀態指出數據輸入的位置（或時間），而遷移則指明狀態的改變
如何設計測試用例？
功能圖法設計測試用例，就是如何覆蓋軟件所表現出來的所有狀態，可以轉化爲兩個層次的測試用例
從功能邏輯模型（決策表或因果圖）導出局部測試用例，即設計測試用例覆蓋某個狀態的各種輸入數據的組合
從狀態遷移圖導出整體的測試用例，以覆蓋系統（程序）控制的邏輯路徑
功能圖法是綜合運用黑盒方法和白盒方法來設計測試用例，即整體上選用白盒方法——路徑覆蓋、分支和條件覆蓋等，而局部上選用的是黑盒方法——決策表或因果圖方法
七.系統測試
1.用戶的需求可以分爲功能性需求和非功能性需求，而非功能性的需求被歸納爲軟件產品的各種質量特性，如安全性、兼容性和可靠性等 系統測試就是針對這些非功能特性展開的，就是驗證軟件產品符合這些質量特性的要求，從而滿足用戶和軟件企業自身的非功能性需求。所以，系統測試分爲負載測試、性能系統、容量測試、安全性測試、兼容性測試和可靠性測試等
2.負載測試過程
- 確定所要模擬的角色及其對應的關鍵業務操作路徑。
- 確定輸入/輸出參數，制定負載測試方案。
- 準備測試環境，並完成相應的測試腳本的開發。
- 設計具體的測試場景，如負載水平、加載方式等。
- 執行測試，監控輸出參數，如數據吞吐量、響應時間、資源佔有率等。
- 對測試結果進行分析。
- 結果不滿意，需要調整測試場景，進入下一個循環。
輸入參數：
負載測試是通過模擬用戶的操作方式來考察系統的行爲，所以人們肯定會問：如何模擬用戶的行爲？
- 併發用戶數、併發連接數等。
- 思考時間（think time），用戶發出請求之間的間隔時間 加載的循環次數或持續時間 每次請求發送的數據量。
- 加載的方式或模式，如均勻加載、峯值交替加載等
輸出參數：
- 數據傳輸的吞吐量（Transactions）
- 數據處理效率（Transactions per second）
- 數據請求的響應時間（Response time）
- 內存和CPU使用率 連接時間（Connect Time）、發送時間（Sent Time）
- 處理時間（Process Time）、頁面下載時間
- 第一次緩衝時間
- 每秒（SSL）連接數
- 每秒事務總數、每秒下載頁面數
- 每秒點擊次數、每秒HTTP 響應數
- 每秒重試次數
3.一些常見的性能問題
- 資源泄漏，包括內存泄漏
- 資源瓶頸，內部資源（線程、放入池的對象）變得稀缺
- CPU使用率達到100%、系統被鎖定等
- 線程死鎖、線程阻塞等
- 數據庫連接成爲性能瓶頸
- 查詢速度慢或列表效率低
- 受外部系統影響越來越大
4.壓力測試：
壓力測試是在系統（如CPU、內存和網絡帶寬等）處於飽和狀態下，測試系統是否還具有正常的會話能力、數據處理能力或是否會出現錯誤，以檢查軟件系統對異常情況的抵抗能力，找出性能瓶頸、功能不穩定性等問題
5.兼容性測試
是在特定的或不同的硬件、網絡環境和操作系統平臺上、不同的應用軟件之間，驗證軟件系統能否正常地運行，以及能否正確存取原先版本的用戶數據所進行的測試
- 與硬件兼容
- 與操作系統、平臺的兼容
- 與數據庫系統的兼容
- 與瀏覽器的兼容
- 與第三方系統的兼容
- 與內部業務系統的兼容
- 與自身系統的不同版本的用戶數據兼容等
向後兼容是指新發布的軟件版本可以使用該軟件的以前版本所產生的數據。
向前兼容是指在設計和開發軟件一個新版本時，考慮如何和未來版本的數據兼容。
八.總結
軟件測試定義：在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟件質量，並對其是否能滿足設計要求進行評估的過程。
軟件測試過程：通常按照測試階段分爲單元測試、集成測試、確認測試、系統測試、驗收測試、迴歸測試、Alpha測試、Beta測試。
單元測試，又稱模塊測試，是針對軟件設計的最小單位 ─ 程序模塊，進行正確性檢驗的測試工作。其目的在於發現各模塊內部可能存在的各種差錯。
1. 單元測試的內容
(1) 模塊接口測試
* 在單元測試的開始，應對通過被測模塊的數據流進行測試。測試項目包括：
– 調用本模塊的輸入參數是否正確；
– 本模塊調用子模塊時輸入給子模塊的參數是否正確；
– 全局量的定義在各模塊中是否一致
* 在做內外存交換時要考慮：
– 文件屬性是否正確；
– OPEN與CLOSE語句是否正確；
– 緩衝區容量與記錄長度是否匹配；
– 在進行讀寫操作之前是否打開了文件；
– 在結束文件處理時是否關閉了文件；
– 正文書寫/輸入錯誤，
– I/O錯誤是否檢查並做了處理。
(2) 局部數據結構測試
* 不正確或不一致的數據類型說明
* 使用尚未賦值或尚未初始化的變量
* 錯誤的初始值或錯誤的缺省值
* 變量名拼寫錯或書寫錯
* 不一致的數據類型
* 全局數據對模塊的影響
(3) 路徑測試
* 選擇適當的測試用例，對模塊中重要的執行路徑進行測試。
* 應當設計測試用例查找由於錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。
* 對基本執行路徑和循環進行測試可以發現大量的路徑錯誤。
(4) 錯誤處理測試
* 出錯的描述是否難以理解
* 出錯的描述是否能夠對錯誤定位
* 顯示的錯誤與實際的錯誤是否相符
* 對錯誤條件的處理正確與否
* 在對錯誤進行處理之前，錯誤條件是否已經引起系統的干預等
(5) 邊界測試
* 注意數據流、控制流中剛好等於、大於或小於確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例，認真加以測試。
* 如果對模塊運行時間有要求的話，還要專門進行關鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運行時間的因素。
2. 單元測試的步驟
* 模塊並不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯繫，用一些輔助模塊去模擬與被測模塊相聯繫的其它模塊。
– 驅動模塊 (driver)
– 樁模塊 (stub) ── 存根模塊
* 如果一個模塊要完成多種功能，可以將這個模塊看成由幾個小程序組成。必須對其中的每個小程序先進行單元測試要做的工作，對關鍵模塊還要做性能測試。
* 對支持某些標準規程的程序，更要着手進行互聯測試。有人把這種情況特別稱爲模塊測試，以區別單元測試。
集成測試，也叫組裝測試、聯合測試
1. 一次性集成方式(big bang)
* 它是一種非增殖式組裝方式。也叫做整體拼裝。
* 使用這種方式，首先對每個模塊分別進行模塊測試，然後再把所有模塊組裝在一起進行測試，最終得到要求的軟件系統。
2. 增殖式集成方式
* 這種集成方式又稱漸增式集成
* 首先對一個個模塊進行模塊測試，然後將這些模塊逐步組裝成較大的系統
* 在集成的過程中邊連接邊測試，以發現連接過程中產生的問題
* 通過增殖逐步組裝成爲要求的軟件系統。
(1) 自頂向下的增殖方式
* 這種集成方式將模塊按系統程序結構，沿控制層次自頂向下進行組裝。
* 自頂向下的增殖方式在測試過程中較早地驗證了主要的控制和判斷點。
* 選用按深度方向組裝的方式，可以首先實現和驗證一個完整的軟件功能。
(2) 自底向上的增殖方式
* 這種集成的方式是從程序模塊結構的最底層的模塊開始集成和測試。
* 因爲模塊是自底向上進行組裝，對於一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經組裝並測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。
* 自頂向下增殖的方式和自底向上增殖的方式各有優缺點。
* 一般來講，一種方式的優點是另一種方式的缺點。
(3) 混合增殖式測試
* 衍變的自頂向下的增殖測試
– 首先對輸入/輸出模塊和引入新算法模塊進行測試；
– 再自底向上組裝成爲功能相當完整且相對獨立的子系統；
– 然後由主模塊開始自頂向下進行增殖測試。
* 自底向上-自頂向下的增殖測試
– 首先對含讀操作的子系統自底向上直至根結點模塊進行組裝和測試；
– 然後對含寫操作的子系統做自頂向下的組裝與測試。
確認測試，又成有效性測試。
1. 進行有效性測試（黑盒測試）
* 有效性測試是在模擬的環境 (可能就是開發的環境) 下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規格說明書列出的需求。
* 首先制定測試計劃，規定要做測試的種類。還需要制定一組測試步驟，描述具體的測試用例。
* 通過實施預定的測試計劃和測試步驟，確定
– 軟件的特性是否與需求相符；
– 所有的文檔都是正確且便於使用；
– 同時，對其它軟件需求，例如可移植性、兼容性、出錯自動恢復、可維護性等，也都要進行測試
* 在全部軟件測試的測試用例運行完後，所有的測試結果可以分爲兩類：
– 測試結果與預期的結果相符。這說明軟件的這部分功能或性能特徵與需求規格說明書相符合，從而這部分程序被接受。
– 測試結果與預期的結果不符。這說明軟件的這部分功能或性能特徵與需求規格說明不一致，因此要爲它提交一份問題報告。
2. 軟件配置複查
軟件配置複查的目的是保證軟件配置的所有成分都齊全；
各方面的質量都符合要求；
具有維護階段所必需的細節；
而且已經編排好分類的目錄。
應當嚴格遵守用戶手冊和操作手冊中規定的使用步驟，以便檢查這些文檔資料的完整性和正確性。
系統測試，是將通過確認測試的軟件，作爲整個基於計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其它系統元素結合在一起，在實際運行環境下，對計算機系統進行一系列的組裝測試和確認測試。
驗收測試，以用戶爲主的測試
應交付的文檔有：
– 確認測試分析報告
– 最終的用戶手冊和操作手冊
– 項目開發總結報告。
軟件測試方法：是指測試軟件的方法。如，兼容性測試、UI測試、冒煙測試、隨機測試、本地化能力測試、國際化測試、安裝測試、卸載測試、白盒測試、黑盒測試、自動化測試、端到端、性能測試、負載測試、壓力測試、強迫測試、健全測試、衰竭測試、恢復測試、安全測試、接口測試。
兼容性測試，指測試軟件是否可以被成功移植到指定的硬件或軟件平臺上。
1，瀏覽器兼容測試
2，分辨率兼容測試
硬件兼容：與整機兼容、與外設兼容
軟件兼容：操作系統/平臺、應用軟件之間的兼容、不同瀏覽器的兼容、數據庫的兼容、軟硬件配合兼容
數據兼容：不同版本間的數據兼容、不同軟件間的數據兼容
UI測試，是指軟件中的可見外觀及其底層與用戶交互的部分。
用戶界面的風格是否滿足客戶要求
文字是否正確
頁面是否美觀
文字，圖片組合是否完美
操作是否友好
包括菜單，對話框及對話框上所有按鈕，文字，出錯提示，幫助信息 (Menu 和Help content)等方面的測試。
冒煙測試的對象是新編譯的每一個需要正式測試的軟件版本，目的是確認軟件基本功能正常，可以進行後續的正式測試工作。冒煙測試的執行者是版本編譯人員。
隨機測試，沒有書面測試用例、記錄期望結果、檢查列表、腳本或指令的測試。主要是根據測試者的經驗對軟件進行功能和性能抽查。隨機測試是根據測試說明書執行用例測試的重要補充手段，是保證測試覆蓋完整性的有效方式和過程。重點對一些特殊點情況點、特殊的使用環境、併發性、進行檢查。尤其對以前測試發現的重大Bug，進行再次測試，可以結合迴歸測試一起進行。
本地化能力測試，指不需要重新設計或修改代碼，將程序的用戶界面翻譯成任何目標語言的能力。
典型錯誤包括：字符的硬編碼（即軟件中需要本地化的字符寫在了代碼內部），對需要本地化的字符長度設置了固定值，在軟件運行時以控件位置定位，圖標和位圖中包含了需要本地化的文本，軟件的用戶界面與文檔術語不一致等。
國際化測試，指驗證軟件程序在不同國家或區域的平臺上也能夠如預期的那樣運行，而且還可以按照原設計尊重和支持使用當地常用的日期，字體，文字表示，特殊格式等等。國際化測試數據必須包含東亞語言、德語、複雜腳本字符和英語（可選）的混合字符。
安裝測試，是確保軟件在正常情況和異常情況下，例如，進行首次安裝、升級、完整的或自定義的安裝都能進行安裝的測試。異常情況包括磁盤空間不足、缺少目錄創建權限等場景。覈實軟件在安裝後可立即正常運行。安裝測試包括測試安裝代碼以及安裝手冊。安裝手冊提供如何進行安裝，安裝代碼提供安裝一些程序能夠運行的基礎數據。
卸載測試，是對軟件的全部、部分或升級卸載處理過程的測試。主要是測試軟件能否卸載，卸載是否乾淨，對系統有無更改，在系統中的殘留與後來的生成文件如何處理等。還有原來更改的系統值是否修改回去。
白盒測試，是把測試對象看作一個打開的盒子。利用白盒測試法進行動態測試時，需要測試軟件產品的內部結構和處理過程，不需測試軟件產品的功能。白盒測試法的覆蓋標準有邏輯覆蓋、循環覆蓋和基本路徑測試。其中邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。
常用工具有：Jtest、VcSmith、Jcontract、C++ Test、CodeWizard、logiscope。
黑盒測試，根據軟件的規格對軟件進行的測試，以用戶的角度，通過各種輸入和觀察軟件的各種輸出結果來發現軟件存在的缺陷，而不關心程序具體如何實現的一種軟件測試方法。
常用工具有：Autorunner、winrunner
自動化測試，使用自動化測試工具來進行測試，這類測試一般不需要人干預，通常在GUI、性能等測試和功能測試中用得較多。通過錄制測試腳本，然後執行這個測試腳本來實現測試過程的自動化。
常用工具有QTP、Testcomplete、Autorunner和TAR等。
端到端，涉及整個應用系統環境在一個現實世界使用時的模擬情形的所有測試。例如與數據庫對話，用網絡通訊，或與外部硬件、應用系統或適當的系統對話。端到端架構測試包含所有訪問點的功能測試及性能測試。端到端架構測試實質上是一種"灰盒"測試，一種集合了白盒測試和黑盒測試的優點的測試方法。
性能測試，是在交替進行負荷和強迫測試時常用的術語。理想的“性能測試”(和其他類型的測試)應在需求文檔或質量保證、測試計劃中定義。性能測試一般包括負載測試和壓力測試。通常驗證軟件的性能在正常環境和系統條件下重複使用是否還能滿足性能指標。或者執行同樣任務時新版本不比舊版本慢。一般還檢查系統記憶容量在運行程序時會不會出現內存泄露(memory leak)。比如，驗證程序保存一個巨大的文件新版本不比舊版本慢。
負載測試，測試一個應用在重負荷下的表現。例如測試一個 Web 站點在大量的負荷下，何時系統的響應會退化或失敗，以發現設計上的錯誤或驗證系統的負載能力。在這種測試中，將使測試對象承擔不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行爲，以及持續正常運行的能力。此外，負載測試還要評估性能特徵，例如，響應時間、事務處理速率和其他與時間相關的方面。
壓力測試，壓力測試是一種基本的質量保證行爲，它是每個重要軟件測試工作的一部分。壓力測試的基本思路很簡單：不是在常規條件下運行手動或自動測試，而是在計算機數量較少或系統資源匱乏的條件下運行測試。通常要進行壓力測試的資源包括內部內存、CPU 可用性、磁盤空間和網絡帶寬等。一般用併發來做壓力測試。
強迫測試，是在交替進行負荷和性能測試時常用的術語。也用於描述對象在異乎尋常的重載下的系統功能測試之類的測試，如某個動作或輸入大量的重複，大量數據的輸入，對一個數據庫系統大量的複雜查詢等。
健全測試，是指一個初始化的測試工作，以決定一個新的軟件版本測試是否足以執行下一步大的測試能力。例如，如果一個新版軟件每5分鐘與系統衝突，使系統陷於泥潭，說明該軟件不夠“健全”，不具備進一步測試的條件。
衰竭測試，是指軟件或環境的修復或更正後的“再測試”。可能很難確定需要多少遍再次測試。尤其在接近開發週期結束時。自動測試工具對這類測試尤其有用。
恢復測試，是測試一個系統從如下災難中能否很好地恢復，如遇到系統崩潰、硬件損壞或其他災難性問題。恢復測試指通過人爲的讓軟件（或者硬件）出現故障來檢測系統是否能正確的恢復，通常關注恢復所需的時間以及恢復的程度。恢復測試主要檢查系統的容錯能力。當系統出錯時，能否在指定時間間隔內修正錯誤並重新啓動系統。恢復測試首先要採用各種辦法強迫系統失敗，然後驗證系統是否能儘快恢復。對於自動恢復需驗證重新初始化（reinitialization）、檢查點(checkpointing mechanisms)、數據恢復(data recovery)和重新啓動 (restart)等機制的正確性；對於人工干預的恢復系統，還需估測平均修復時間，確定其是否在可接受的範圍內。
安全測試，是測試系統在防止非授權的內部或外部用戶的訪問或故意破壞等情況時怎麼樣。這可能需要複雜的測試技術。安全測試檢查系統對非法侵入的防範能力。安全測試期間，測試人員假扮非法入侵者，採用各種辦法試圖突破防線。例如：
①想方設法截取或破譯口令；
②專門定做軟件破壞系統的保護機制；
③故意導致系統失敗，企圖趁恢復之機非法進入；
④試圖通過瀏覽非保密數據，推導所需信息，等等。
接口測試，測試系統組件間接口的一種測試。要進行接口，需要完善的文檔進行保障，沒有測試文檔，接口測試將寸步難行，接口測試將增加開發過程規範化產出，而規範化產出也保證了項目質量