針對不同研發階段的測試目的，測試活動分為需求測試、組件/單元測試、集成測試、系統測試、驗收測試、Alpha測試、Beta測試、UAT測試等級別。
一、需求測試
軟件測試雙V模型要求測試工程師在需求階段就開始制定系統測試計划，考慮系統測試方法，但這還不夠。全面的質量管理要求在每個階段都要進行驗證和確認的活動。因此在需求階段，測試工程師還需對需求本身進行測試。這個測試是必要的，因為在許多失敗的項目中，70%- 85%的返工是由於需求方面的錯誤所導致。因需求錯誤導致大量返工，造成進度延遲，缺陷發散甚至項目失敗，這是一件極其痛苦的事情。因此測試工程師需在軟件生產源頭--需求就開始測試。
需求測試(Requirement Test)的重點是檢查需求規格說明書中是否存在描述不准確、定義模糊、需求用例不正確、語言存在二義性等問題。主要從以下幾個方面考慮。
1.完整性
每一項需求都必須將所要實現的功能描述清楚，為開發工程師設計和實現這些功能制所有必要的需求依據。
2.正確性
每一項需求都必須准確地陳述其要開發的功能。
3.一致性
一致性是指與其他軟件需求的高層 (系統、業務)需求不相矛盾，或者與項目宣傳數一致。
4.可行性
每一項需求都必須是在已知系統和環境的權能和限制范圍
5.無二義性
對所有需求說明書的讀者都只能有一個明確統的解釋，由於自然語言極易導致二義性，所以盡量把每項需求用簡潔明了的用戶語言表達出來。
6.健壯性
需求說明中是否對可能出現的異常進行了分析，並且對這些異常進行了容錯處理。
7.必要性
必要性可理解為每項需求都是用來授權編寫文檔的“根源”。要使每項需求都能回溯至某項客戶的輸入，如需求用例或其他來源。
8.可測試性
每項需求都能通過設計測試用例或其他的驗證方法來進行測試。
9.可修改性
每項需求只應在軟件需求規格說明書中出現一次。 這樣更改時易於保持致性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規格說明書更容易修改。
二、單元測試 (Unit Test)
軟件系統中，系統對象的基本組成單元稱為組件或程序單元。程序代碼中的函數或者類稱為“單元”，或者實現某個獨立需求的功能模塊，稱為組件/單元。組件可能由多個單元組成。
組件/單元測試(Unit Test)是針對軟件基本組成單元(軟件設計的最小單位)來進行正確性檢驗的測試工作，其目的是檢測被測組件單元與詳細設計說明書的符合程度。通過組件/單元測試活動驗證被測對象的功能特性或非功能特性，發現其可能存在的內存泄露、算法冗爾、分支覆蓋率低、循環調用效率低等問題，此類缺陷在系統測試層面很難發現。因此，組件單元測試能夠盡早地發現缺陷，修復缺陷成本相對較低。
組件/單元測試一般由開發工程師負責，成本較高。在敏捷研發模型中，測試工程師也可能需要實施此測試活動。組件單元測試活動亦可以使用自動化測試方法。
組件/單元測試活動依據包括組件單元需求說明、詳細設計文檔、被測代碼、編程規范等，典型的測試對象一般有組件、函數、類、數據轉換/移植程序、數據庫模型、關鍵字典等，關注被測對象內部數據結構、邏輯控制、異常處理等實現的正確性。
三、集成測試 (Integration Testing)
組件單元測試通過后的組件或單元，即可進行集成測試。
集成測試(Integration Testing)是對組件/單元之間及組件/單元與第三方接口之間進行測試，其目的是驗證接口是否與設計相符，是否與需求相符。集成測試根據被測對象的集成程度，可分為3種集成:組件/單元間集成、模塊間集成、子系統間集成。集成的規模越大，發現定位缺陷的難度就越大，所以一般根據被測對象的系統結構特性，先從組件/單元間的集成測試開始，使用自底向上或自頂向下漸增式策略實施集成測試活動，大爆炸式集成策略已漸漸被淘汰。
集成測試的目的是檢測軟件模塊對《概要設計說明書》的符合程度，關注於模塊間接口和接口數據傳遞關系，以及模塊組合后的整體功能。集成測試實施人員一般是開發工程師，當然也可以是測試工程師，現在不少企業集成測試實現了自動化測試，更聚焦於接口測試。
四、系統測試 (System Test)
系統測試(System Test)是將通過集成測試的軟件，部署到某種較為復雜的計算機用戶環境進行測試，這里所說的復雜計算機用戶環境，其實就是模擬的用戶真實計算機環境。集成測試階段大多數情況下，是在一種比較干凈的系統中進行測試，所謂的干凈，即是在測試機上沒有多余的軟件，僅有所需的操作系統和被測軟件。集成測試完成后，將被測軟件置入比較復雜的運行環境下，進行集成和確認測試。在此過程中，往往有很大的收獲，例如，進行安裝測試時，會發現在集成階段安裝沒有問題，但在復雜用戶環境下，卻不能安裝。例如，某公司研發款財務軟件，軟件中采用Excel 2000版中的某些繪圖控件，在集成測試階段，測試環境中僅安裝了該財務軟件和Excel 2000，但系統測試過程中，測試環境可能還安裝了其他也需調用Excel控件的軟件，這時可能會出現控件資源爭用錯誤。
系統測試的目的在於通過與系統的需求定義做比較，發現軟件與系統的需求定義不符合或與之矛盾的地方。系統測試階段主要進行安裝卸載測試、兼容性測試、功能確認測試、性能測試、安全性測試等。系統測試階段采用黑盒測試方法，主要考查被測軟件的功能與性能表現。如果軟件可以按照用戶合理的期望方式工作，即可認為通過系統測試，相反則表現為缺陷。
系統測試過程其實也是一種配置檢查過程，檢查在軟件生產過程中是否有遺漏的地方、做到查漏補缺，以確保交付產品符合用戶質量要求。
系統測試通常由獨立的測試團隊完成，其測試依據一般包括需求規格說明書、需求用例、功能規格說明、功能需求列表、風險分析報告等，以需求規格說明書為主。測試對象包括軟件系統、用戶手冊、操作使用說明書、系統配置和配置數據等。
五、驗收測試 (Acceptance Test)
系統測試完成，在交付用戶部署應用前，往往需要進行驗收測試。驗收測試(Acceptance Test)是以用戶為主的測試，驗收組應當由項目組成員、用戶代表或系統的其他利益相關者等組成，原則上在用戶所在地進行，但如經用戶同意，也可以在公司內模擬用戶環境進行。驗收測試根據合同、《需求規格說明書》或《驗收測試計划》對成品進行驗收測試。在此階段，發現缺陷並不是其主要目的，期望通過驗收測試，使用戶建立對即將交付應用的軟件系統的信心。
對於項目類的軟件系統，一般都需要進行驗收測試。驗收測試通常情況下可有Alpha測試、Beta測試和UAT測試等驗收測試形式。
1.Alpha測試
Alpha測試是由用戶在開發環境下進行的測試，也可以是在開發機構內部的用戶模擬實際操作環境中進行測試。進行Alpha測試時，軟件在一個自然設置狀態下使用。開發者坐在用戶旁，隨時記下錯誤情況和使用問題，Alpha測試在受控的測試環境下實施，其目的主要是評價軟件產品的功能、局域化、可用性、可靠性、性能和技術支持(FLURPS)是否達標。
2.Beta測試
Beta測試是由軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。與Alpha測試不同的是，進行Beta測試時，開發者通常不在測試現場。因而，Beta測試是在開發者無法控制的環境下進行的軟件現場應用，測試者發現問題后，統一收集提交至開發工程師進行修復。
3.UAT測試 (User Acceptance Test)
測試即用戶接受度測試(User Acceptance Test) UAT一般用於商業用戶驗證系統的可用性。通常情況下，由采購方組織終端用戶或軟件利益相關方對被測對象進行選擇性功能試用，關注被測對象核心功能的應用表現，從而為接受該軟件系統提供數據依據。例如，銀行在外包項目交付時，組織多分銀行方終端應用人員(如櫃台服務人員)進行驗收性測試，即為UAT測試。