對於開發人員來說，往往對各種測試方法感到疑惑。特別是在整合代碼的時候，我們就能深刻感覺受到測試的重要性。很多開發人員只注重寫代碼，輕視測試的重要性。總是代碼一寫完提交然后就交給測試組測試了，沒多久測試組發回測試報告。然后又苦惱的修改自己代碼的bug，慢慢地就開始討厭測試組人員。沒有經過自己細心測試的代碼，不僅浪費了別人時間更影響到了自己的心情。
接下來為大家細心講述一下各種測試應用的環境及作用
一、測試環境和角色
黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試 ：
這些測試的范圍正好是逐步遞增的關系，但是測試的人員角色是不同。
黑盒測試、白盒測試、單元測試：開發人員分在不同的開發階段要做的事情
黑盒測試、集成測試、系統測試：測試人員在測試周期內級層做的工作
驗收測試：一般是在用戶方做的工作
二、根據不同的范圍
測試可以分為單元測試、集成測試、系統測試和驗收測試。
體現了測試由小到大、又內至外、循序漸進的測試過程和分而治之的思想。
三、測試的功能
1.單元測試 粒度最小，一般由開發小組采用白盒方式來測試，主要測試單元是否符合“設計”。
單元測試（unit testing），是指對軟件中的最小可測試單元進行檢查和驗證。對於單元測試中單元的含義，一般來說，要根據實際情況去判定其具體含義，如C語言中單元指一個函數，Java里單元指一個類，圖形化的軟件中可以指一個窗口或一個菜單等。總的來說，單元就是人為規定的最小的被測功能模塊。單元測試是在軟件開發過程中要進行的最低級別的測試活動，軟件的獨立單元將在與程序的其他部分相隔離的情況下進行測試。
2.集成測試 界於單元測試和系統測試之間，起到“橋梁作用”，一般由開發小組采用白盒加黑盒的方式來測試，既驗證“設計”，又驗證“需求”。 主要用來測試模塊與模塊之間的接口，同時還要測試一些主要業務功能。集成測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴展。它最簡單的形式是：把兩個已經測試過的單元組合成一個組件，測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合為程序的更大部分。方法是測試片段的組合，並最終擴展成進程，將模塊與其他組的模塊一起測試。最后，將構成進程的所有模塊一起測試。此外，如果程序由多個進程組成，應該成對測試它們，而不是同時測試所有
集成測試進程。
3.系統測試 粒度最大，一般由獨立測試小組采用黑盒方式來測試，主要測試系統是否符合“需求規格說明書”。在經過以上各階段測試確認之后，把系統完整地模擬客戶環境來進行的測試。系統測試是將已經確認的軟件、計算機硬件、外設、網絡等其他元素結合在一起，進行信息系統的各種組裝測試和確認測試，其目的是通過與系統的需求相比較，發現所開發的系統與用戶需求不符或矛盾的地方，從而提出更加完善的方案.。它的的任務是盡可能徹底地檢查出程序中的錯誤，提高軟件系統的可靠性，其目的是檢驗系統"做得怎樣？"。這階段又可分為三個步驟：模塊測試，測試每個模塊的程序是否有錯誤；組裝測試，測試模塊之間的接口是否正確；確認測試，測試整個軟件系統是否滿足用戶功能和性能的要求。該階段結束應交付測試報告，說明測試數據的選擇，測試用例以及測試結果是否符合預期結果。測試發現問題之后要經過調試找出錯誤原因和位置，然后進行改正。是基於系統整體需求說明書的黑盒類測試，應覆蓋系統所有聯合的部件。系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不相符合或與之矛盾的地方。
系統測試的對象不僅僅包括需要測試的產品系統的軟件，還要包含軟件所依賴的硬件、外設甚至包括某些數據、某些支持軟件及其接口等。因此，必須將系統中的軟件與各種依賴的資源結合起來，在系統實際運行環境下來進行測試
4.驗收測試與系統測試相似，主要區別是測試人員不同，驗收測試由用戶執行。
5.黑盒測試：不考慮程序內部結構和邏輯結構，主要是用來測試系統的功能是否滿足需求規格說明書。 一般會有一個輸入值，一個輸入值，和期望值做比較。黑盒測試也稱功能測試，它是通過測試來檢測 每個功能是否都能正常使用。在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序 內部結構和內部特性的情況下，在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。黑盒測試着眼於程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。
6.白盒測試：主要應用在單元測試階段，主要是對代碼級的測試，針對程序內部邏輯構，測試手段有：語句覆蓋、判定覆蓋、條件覆蓋、路徑覆蓋、條件組合覆蓋。白盒測試也稱結構測試或邏輯驅動測試，它是按照程序內部的結構測試程序，通過測試來檢測產品內部動作是否按照設計規格說明書的規定正常進行，檢驗程序中的每條通路是否都能按預定要求正確工作。 這一方法是把測試對象看作一個打開的盒子，測試人員依據程序內部邏輯結構相關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試，通過在不同點檢查程序的狀態，確定實際的狀態是否與預期的狀態一致。
系統測試和集成測試的區別【轉】
一般的小系統區分不是很大的
1.計划和用例編制的先后順序
從V模型來講，在需求階段就要制定系統測試計划和用例，HLD的時候做集成測試計划和用例，有些公司的具體實踐不一樣，但是順
序肯定是先做系統測試計划用例，再做集成
2.用例的粒度
系統測試用例相對很接近用戶接受測試用例
集成測試用例比系統測試用例更詳細，而且對於接口部分要重點寫，畢竟要集成各個模塊或者子系統
3.執行測試的順序
先執行集成測試，待集成測試出的問題修復之后，（配置管理，基線化），再做系統測試。
4.用例的數量
系統測試的用例數量一般比集成測試的用例數量少，具體的數量要根據各個公司的性能基線來確定，一般寫不到這個數量的測試用例還通不過審計
系統測試這個稱呼往往被用於壓力測試、容量測試、性能測試、安全測試等方面。
而集成測試這個稱呼往往被用於細節化的功能測試的超集——從用戶需求來設計和組織較大顆粒度的功能測試。
系統測試最主要的就是功能測試，測試軟件《需求規格說明書》中提到的功能是否有遺漏，是否正確的實現。做系統測試要嚴格按照《需求規格說明書》，以它為標准。測試方法一般都使用黑盒測試法；
集成測試在系統測試之前，單元測試完成之后系統集成的時候進行測試。集成測試主要是針對程序內部結構進行測試，特別是對程序之間的接口進行測試。集成測試對測試人員的編寫腳本能力要求比較高。測試方法一般選用黑盒測試和白盒測試相結合。
集成測試：是在軟件系統集成過程中所進行的測試，其主要目的是檢查軟件單位之間的借口是否正確。它根據集成測試計划 ，一邊將模塊或其他年間單位組合成越來越大的系統，一邊運行該系統，以分析所組成的系統是否正確，各個組成部分是否合拍。集成測試的策略主要有自頂向下和自底向上兩種。也可以理解為在軟件設計單元、功能模塊組裝、集成為系統時，對應用系統的各個部件（軟件單元、功能模塊接口、鏈接等）進行的聯合測試，以決定他們能否在一起共同工作，部件可以是代碼塊、獨立的應用、網絡上的客戶端或服務器端程序。
系統測試：系統測試是基於軟件需求說明書的黑盒測試，是對已經集成好的軟件系統進行徹底的測試，以驗證軟件系統的正確性和性能等滿足其規約所指定的要求，檢查軟件的行為和輸出是否正確，並非一項簡單的任務，被稱為測試的“先知者問題”。因此，系統測試應該按照測試計划進行，其輸入、輸出和其他的動態運行行為應該與軟件規約進行對比。軟件系統測試的方法很多，主要有功能測試，性能測試，隨機測試等。
通俗的講，一個產品從研發到出廠的工程中，測試分為三個階段：單元測試、集成測試、系統測試； 單元測試：一個模塊的功能及常規錯誤測試； 集成測試：完成單元測試后，各模塊聯調測試；集中在各模塊的接口是否一致、各模塊間的數據流和控制硫是否按照設計實現其功能、以及結果的正確性驗證等等；可以使整個產品的集成測試，也可以使大模塊的集成測試； 系統測試：針對整個產品的全面測試，既包含各模塊的驗證性測試（驗證前兩個階段測試的正確性）和功能性（產品提交個用戶的功能）測試，又包括對整個產品的健壯性、安全性、可維護性及各種性能參數的測試