測試真的不簡單，梳理22種測試方法與詳解

黑盒測試：不基於內部設計和**的任何知識，而是基於需求和功能性。

白盒測試：基於乙個應用**的內部邏輯知識，測試是基於覆蓋全部**、分支、路徑、條件。

單元測試：最微小規模的測試；以測試某個功能或**塊。典型地由程式設計師而非測試員來做，因為它需要知道內部程式設計和編碼的細節知識。這個工作不容易作好，除非應用系統有乙個設計很好的體系結構; 還可能需要開發測試驅動器模組或測試套具。

累積綜合測試：當乙個新功能增加後，對應用系統所做的連續測試。它要求應用系統的不同形態的功能能夠足夠獨立以可以在全部系統完成前能分別工作，或當需要時那些測試驅動器已被開發出來; 這種測試可由程式設計師或測試員來做。

整合測試：乙個應用系統的各個部件的聯合測試，以決定他們能否在一起共同工作。部件可以是**塊、獨立的應用、網路上的客戶端或伺服器端程式。這種型別的測試尤其與客戶伺服器和分布式系統有關。

功能測試：用於測試應用系統的功能需求的黑盒測試方法。這類測試應由測試員做，這並不意味著程式設計師在發布前不必檢查他們的**能否工作(自然他能用於測試的各個階段)。

系統測試：基於系統整體需求說明書的黑盒類測試；應覆蓋系統所有聯合的部件。

健全測試：典型地是指乙個初始化的測試工作，以決定乙個新的軟體版本測試是否足以執行下一步大的測試努力。例如，如果乙個新版軟體每5分鐘與系統衝突，使系統陷於泥潭，說明該軟體不夠「健全」，目前不具備進一步測試的條件。

衰竭測試：軟體或環境的修復或更正後的「再測試」。可能很難確定需要多少遍再次測試。尤其在接近開發周期結束時。自動測試工具對這類測試尤其有用。

接受測試：基於客戶或終端使用者的規格書的最終測試，或基於使用者一段時間的使用後，看軟體是否滿足客戶要求。

負載測試：測試乙個應用在重負荷下的表現，例如測試乙個 web 站點在大量的負荷下，何時系統的響應會退化或失敗。

強迫測試：在交替進行負荷和效能測試時常用的術語。也用於描述象在異乎尋常的過載下的系統功能測試之類的測試，如某個動作或輸入大量的重複，大量資料的輸入，對乙個資料庫系統大量的複雜查詢等。

效能測試：在交替進行負荷和強迫測試時常用的術語。理想的「效能測試」(和其他型別的測試)應在需求文件或質量保證、測試計畫中定義。

可用性測試：對「使用者友好性」的測試。顯然這是主觀的，且將取決於目標終端使用者或客戶。使用者面談、調查、使用者對話的錄象和其他一些技術都可使用。程式設計師和測試員通常都不宜作可用性測試員。

安裝/解除安裝測試：對軟體的全部、部分或公升級安裝/解除安裝處理過程的測試。

恢復測試：測試乙個系統從如下災難中能否很好地恢復，如遇到系統崩潰、硬體損壞或其他災難性問題。

安全測試：測試系統在防止非授權的內部或外部使用者的訪問或故意破壞等情況時怎麼樣。這可能需要複雜的測試技術。

相容測試：測試軟體在乙個特定的硬體/軟體/作業系統/網路等環境下的效能如何。

比較測試：與競爭夥伴的產品的比較測試，如軟體的弱點、優點或實力。

alpha 測試：在系統開發接近完成時對應用系統的測試；測試後，仍然會有少量的設計變更。這種測試一般由終端使用者或其他人員員完成，不能由程式設計師或測試員完成。

beta 測試：當開發和測試根本完成時所做的測試，而最終的錯誤和問題需要在最終發行前找到。這種測試一般由終端使用者或其他人員員完成，不能由程式設計師或測試員完成。