角度細分

從是否關心軟體內部結構和具體實現的角度劃分（按測試分類）

A.白盒測試

B.黑盒測試

C.灰盒測試

從是否執行程式的角度

A.靜態測試

B.動態測試。

階段細分

從軟體開發的過程按階段劃分有

A.單元測試

B.整合測試

C.確認測試

D.系統測試

E.驗收測試

F.迴歸測試

G.Alpha測試

H.Beta測試

* 測試過程按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 應當嚴格遵守使用者手冊和操作手冊中規定的使用步驟，以便檢查這些文件資料的完整性和正確性。

系統測試（System Testing）

* 系統測試，是將通過確認測試的軟體，作為整個基於計算機系統的一個元素，與計算機硬體、外設、某些支援軟體、資料和人員等其它系統元素結合在一起，在實際執行環境下，對計算機系統進行一系列的組裝測試和確認測試。

* 系統測試的目的在於通過與系統的需求定義作比較， 發現軟體與系統的定義不符合或與之矛盾的地方。

驗收測試（Acceptance Testing）

* 在通過了系統的有效性測試及軟體配置審查之後，就應開始系統的驗收測試。

* 驗收測試是以使用者為主的測試。軟體開發人員和QA（質量保證）人員也應參加。

* 由使用者參加設計測試用例，使用生產中的實際資料進行測試。

* 在測試過程中，除了考慮軟體的功能和效能外，還應對軟體的可移植性、相容性、可維護性、錯誤的恢復功能等進行確認。

*確認測試應交付的文件有：

– 確認測試分析報告

– 最終的使用者手冊和操作手冊

– 專案開發總結報告。

測試流程

測試流程

1、制定測試計劃

2、編輯測試用例

3、執行測試用例

4、發現並提交BUG

5、開發組修正BUG

6、對已修正BUG進行返測

7、修正完成的BUG將狀態置為已關閉，未正確修正的BUG重新啟用

測試階段

測試階段

單元測試

單元測試是對軟體組成單元進行測試，其目的是檢驗軟體基本組成單位的正確性，測試的物件是軟體設計的最小單位：模組。

整合測試

整合測試也稱聯合測試，將程式模組採用適當的整合策略組裝起來，對系統的介面及整合後的功能進行正確性檢測的測試工作。其主要目的是檢查軟體單位之間的介面是否正確，整合測試的物件是已經經過單元測試的模組。

系統測試

系統測試 主要包括功能測試、介面測試、可靠性測試、易用性測試、效能測試。 功能測試主要針對包括功能可用性、功能實現程度（功能流程&業務流程、資料處理&業務資料處理）方面測試。

迴歸測試

迴歸測試指在軟體維護階段，為了檢測程式碼修改而引入的錯誤所進行的測試活動。迴歸測試是軟體維護階段的重要工作，有研究表明，迴歸測試帶來的耗費佔軟體生命週期的1/3總費用以上。

與普通的測試不同，在迴歸測試過程開始的時候，測試者有一個完整的測試用例集可供使用，因此，如何根據程式碼的修改情況對已有測試用例集進行有效的複用是迴歸測試研究的重要方向，此外，迴歸測試的研究方向還涉及自動化工具，面向物件迴歸測試，測試用例優先順序，迴歸測試用例補充生成等。

測試模型

V模型

測試階段:

單元測試

整合測試

系統測試

實現意義

V模型是軟體開發瀑布模型的變種，它反映了測試活動與分析和設計的關係 。

從左到右，描述了基本的開發過程和測試行為，非常明確地標明瞭測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發過程期間各階段的對應關係 。

左邊依次下降的是開發過程各階段，與此相對應的是右邊依次上升的部分，即各測試過程的各個階段。

使用者需求 驗收測試

需求分析和系統設計 確認測試和系統測試

概要設計 整合測試

詳細設計 單元測試

編碼

軟體測試V模型

V模型問題

1.測試是開發之後的一個階段。

2.測試的物件就是程式本身。

3.實際應用中容易導致需求階段的錯誤一直到最後系統測試階段才被發現。

4.整個軟體產品的過程質量保證完全依賴於開發人員的能力和對工作的責任心，而且上一步的結果必須是充分和正確的，如果任何一個環節出了問題，則必將嚴重的影響整個工程的質量和預期進度

W模型

W模型由Evolutif公司公司提出，相對於V模型，W模型增加了軟體各開發階段中應同步進行的驗證和確認活動。W模型由兩個V字型模型組成，分別代表測試與開發過程，圖中明確表示出了測試與開發的並行關係。 W模型強調：測試伴隨著整個軟體開發週期，而且測試的物件不僅僅是程式，需求、設計等同樣要測試，也就是說，測試與開發是同步進行的。W模型有利於儘早地全面的發現問題。例如，需求分析完成後，測試人員就應該參與到對需求的驗證和確認活動中，以儘早地找出缺陷所在。同時，對需求的測試也有利於及時瞭解專案難度和測試風險，及早制定應對措施，這將顯著減少總體測試時間，加快專案進度。 但W模型也存在侷限性。在W模型中，需求、設計、編碼等活動被視為序列的，同時，測試和開發活動也保持著一種線性的前後關係，上一階段完全結束，才可正式開始下一個階段工作。這樣就無法支援迭代的開發模型。對於當前軟體開發複雜多變的情況，W模型並不能解除測試管理面臨著困惑。

軟體測試

H模型

H模型中， 軟體測試過程活動完全獨立，貫穿於整個產品的週期，與其他流程併發地進行，某個測試點準備就緒時，就可以從測試準備階段進行到測試執行階段。軟體測試可以儘早的進行，並且可以根據被測物的不同而分層次進行。

軟體測試

這個示意圖演示了在整個生產週期中某個層次上的一次測試“微迴圈”。圖中標註的其它流程可以是任意的開發流程，例如設計流程或者編碼流程。也就是說， 只要測試條件成熟了，測試準備活動完成了，測試執行活動就可以進行了。

H模型揭示了一個原理：軟體測試是一個獨立的流程，貫穿產品整個生命週期，與其他流程併發地進行。H模型指出軟體測試要儘早準備， 儘早執行。不同的測試活動可以是按照某個次序先後進行的，但也可能是反覆的，只要某個測試達到準備就緒點，測試執行活動就可以開展。

X模型

X模型也是對V模型的改進，X模型提出針對單獨的程式片段進行相互分離的編碼和測試，此後通過頻繁的交接，通過整合最終合成為可執行的程式。X模型的左邊描述的是針對單獨程式片段所進行的相互分離的編碼和測試，此後將進行頻繁的交接，通過整合最終成為可執行的程式，然後再對這些可執行程式進行測試。己通過整合測試的成品可以進行封裝並提交給使用者，也可以作為更大規模和範圍內整合的一部分。多根並行的曲線表示變更可以在各個部分發生。由圖中可見，X模型還定位了探索性測試，這是不進行事先計劃的特殊型別的測試，這一方式往往能幫助有經驗的測試人員在測試計劃之外發現更多的軟體錯誤。但這樣可能對測試造成人力、物力和財力的浪費，對測試員的熟練程度要求比較高。

測試工具

Test Platform軟體測試平臺，簡稱TP，是業界唯一的對軟體測試全過程進行支撐的軟體測試工具。

業界已有的軟體測試工具基本上都侷限在測試執行階段，只能支撐測試執行階段的活動，而測試分析、測試設計、測試實現這三個前期階段的活動缺乏有效的測試工具支撐，直接影響了軟體測試的完整性和充分性，從而影響最終研發的軟體質量。David.yuan這樣說：企業使用了博為峰TP測試平臺，整個軟體測試過程的 測試覆蓋率提高到前所未有的高度和廣度，可以極好的達成軟體在安全性、健壯性、穩定性和功能、效能方面的要求，即使是沒有很多年測試經驗的管理和測試人員，通過TP測試平臺就可以完成智慧化地管理、設計、分析、執行整個測試過程，達到一流測試管理專家所做到的效果。

引入缺陷分析模型

在業界首先將各種有效的缺陷分析模型引入到該軟體平臺中，包括ODC分析、Gompertz分析、Rayleigh分析、四象限分析、缺陷注入分析、DRE/DRM等工程方法，幫助管理者建立軟體研發過程的質量基線、測試能力基線，並幫助管理者將專案實際缺陷、能力資料和基線資料進行對比分析，發現軟體過程中的改進點，判斷測試是否可以退出、軟體是否可以釋出，並對軟體中殘留缺陷數進行預測；

利用理論框架分析

建立了測試分析和設計的理論框架和一整套工程方法，能夠很好的支撐測試的輔助分析和設計；

建立測試跟蹤關係

建立“開發需求項－>測試項－>測試子項－>測試用例－>缺陷”的測試跟蹤關係，能夠及時的反應開發需求和設計的變更對測試的影響範圍，保證軟體的一致性和測試的充分性，從而保證軟體的質量；

使用TestPlatform

能夠全面的管理軟體質量工作，具有高度的整合性，一款TestPlatform能夠完成多款其他各類的相關質量管理工具整合在一起才能完成的軟體質量管理工作。它集成了需求跟蹤、靜態測試、動態測試、測試人員管理、測試環境管理、測試計劃管理、測試用例管理、缺陷管理、缺陷分析等軟體質量相關的流程。

AutoRunner是國內第一款自動化測試工具，可以用來完成功能測試、迴歸測試、每日構建測試與自動迴歸測試等工作。是具有指令碼語言的、提供針對指令碼完善的跟蹤和除錯功能的、支援IE測試和Windows native測試的自動化測試工具。

TestCenter是一款功能強大測試管理工具，它可以幫助您：實現測試用例的過程管理，對測試需求過程、測試用例設計過程、業務元件設計實現過程等整個測試過程進行管理。實現測試用例的標準化即每個測試人員都能夠理解並使用標準化後的測試用例，降低了測試用例對個人的依賴；提供測試用例複用，用例和指令碼能夠被複用，以保護測試人員的資產；提供可伸縮的測試執行框架，提供自動測試支援；提供測試資料管理，幫助使用者同意管理測試資料，降低測試資料和測試指令碼之間的耦合度。

TAR(Terminal AutoRunner)適用於VT100、VT220等標準的應用系統，支援命令列模式和視窗模式（使用Cursors編寫的應用程式），支援自動錄製指令碼、所見即所得的資源和指令碼編輯，穩定的自動同步功能。是目前國內最好的銀行業務測試工具.

TestDirector是全球最大的軟體測試工具提供商Mercury Interactive公司生產的企業級測試管理工具，也是業界第一個基於Web的測試管理系統，它可以在您公司內部或外部進行全球範圍內測試的管理。通過在一個整體的應用系統中集成了測試管理的各個部分，包括需求管理，測試計劃，測試執行以及錯誤跟蹤等功能，TestDirector極大地加速了測試過程。