一文告訴你黑盒測試、白盒測試、集成測試和系統測試的區別與聯繫

於開發人員來講，每每對各類測試方法感到疑惑。特別是在整合代碼的時候，咱們就能深入感受受到測試的重要性。不少開發人員只注重寫代碼，輕視測試的重要性。老是代碼一寫完提交而後就交給測試組測試了，沒多久測試組發回測試報告。而後又苦惱的修改本身代碼的bug，慢慢地就開始討厭測試組人員。沒有通過本身細心測試的代碼，不只浪費了別人時間更影響到了本身的心情。
接下來爲你們細心講述一下各類測試應用的環境及做用

1、測試環境和角色
黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試 ：
這些測試的範圍正好是逐步遞增的關係，可是測試的人員角色是不一樣。

黑盒測試、白盒測試、單元測試：開發人員分在不一樣的開發階段要作的事情
黑盒測試、集成測試、系統測試：測試人員在測試周期內級層作的工做
驗收測試：通常是在用戶方作的工做

2、根據不一樣的範圍
測試能夠分爲單元測試、集成測試、系統測試和驗收測試。
體現了測試由小到大、又內至外、按部就班的測試過程和分而治之的思想。

3、測試的功能

1.單元測試 粒度最小，通常由開發小組採用白盒方式來測試，主要測試單元是否符合「設計」。
單元測試（unit testing），是指對軟件中的最小可測試單元進行檢查和驗證。對於單元測試中單元的含義，通常來講，要根據實際狀況去斷定其具體含義，如C語言中單元指一個函數，Java裏單元指一個類，圖形化的軟件中能夠指一個窗口或一個菜單等。總的來講，單元就是人爲規定的最小的被測功能模塊。單元測試是在軟件開發過程當中要進行的最低級別的測試活動，軟件的獨立單元將在與程序的其餘部分相隔離的狀況下進行測試。

2.集成測試 界於單元測試和系統測試之間，起到「橋樑做用」，通常由開發小組採用白盒加黑盒的方式來測試，既驗證「設計」，又驗證「需求」。 主要用來測試模塊與模塊之間的接口，同時還要測試一些主要業務功能。集成測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴展。它最簡單的形式是：把兩個已經測試過的單元組合成一個組件，測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合爲程序的更大部分。方法是測試片斷的組合，並最終擴展成進程，將模塊與其餘組的模塊一塊兒測試。最後，將構成進程的全部模塊一塊兒測試。此外，若是程序由多個進程組成，應該成對測試它們，而不是同時測試全部
集成測試進程。

3.系統測試 粒度最大，通常由獨立測試小組採用黑盒方式來測試，主要測試系統是否符合「需求規格說明書」。在通過以上各階段測試確認以後，把系統完整地模擬客戶環境來進行的測試。系統測試是將已經確認的軟件、計算機硬件、外設、網絡等其餘元素結合在一塊兒，進行信息系統的各類組裝測試和確認測試，其目的是經過與系統的需求相比較，發現所開發的系統與用戶需求不符或矛盾的地方，從而提出更加完善的方案.。它的的任務是儘量完全地檢查出程序中的錯誤，提升軟件系統的可靠性，其目的是檢驗系統"作得怎樣？"。這階段又可分爲三個步驟：模塊測試，測試每一個模塊的程序是否有錯誤；組裝測試，測試模塊之間的接口是否正確；確認測試，測試整個軟件系統是否知足用戶功能和性能的要求。該階段結束應交付測試報告，說明測試數據的選擇，測試用例以及測試結果是否符合預期結果。測試發現問題以後要通過調試找出錯誤緣由和位置，而後進行改正。是基於系統總體需求說明書的黑盒類測試，應覆蓋系統全部聯合的部件。系統測試是針對整個產品系統進行的測試，目的是驗證系統是否知足了需求規格的定義，找出與需求規格不相符合或與之矛盾的地方。
系統測試的對象不只僅包括須要測試的產品系統的軟件，還要包含軟件所依賴的硬件、外設甚至包括某些數據、某些支持軟件及其接口等。所以，必須將系統中的軟件與各類依賴的資源結合起來，在系統實際運行環境下來進行測試

4.驗收測試與系統測試類似，主要區別是測試人員不一樣，驗收測試由用戶執行。

5.黑盒測試：不考慮程序內部結構和邏輯結構，主要是用來測試系統的功能是否知足需求規格說明書。 通常會有一個輸入值，一個輸入值，和指望值作比較。黑盒測試也稱功能測試，它是經過測試來檢測 每一個功能是否都能正常使用。在測試中，把程序看做一個不能打開的黑盒子，在徹底不考慮程序 內部結構和內部特性的狀況下，在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。黑盒測試着眼於程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。
6.白盒測試：主要應用在單元測試階段，主要是對代碼級的測試，針對程序內部邏輯構，測試手段有：語句覆蓋、斷定覆蓋、條件覆蓋、路徑覆蓋、條件組合覆蓋。白盒測試也稱結構測試或邏輯驅動測試，它是按照程序內部的結構測試程序，經過測試來檢測產品內部動做是否按照設計規格說明書的規定正常進行，檢驗程序中的每條通路是否都能按預約要求正確工做。 這一方法是把測試對象看做一個打開的盒子，測試人員依據程序內部邏輯結構相關信息，設計或選擇測試用例，對程序全部邏輯路徑進行測試，經過在不一樣點檢查程序的狀態，肯定實際的狀態是否與預期的狀態一致。

系統測試和集成測試的區別

通常的小系統區分不是很大的

1.計劃和用例編制的前後順序
從V模型來說，在需求階段就要制定系統測試計劃和用例，HLD的時候作集成測試計劃和用例，有些公司的具體實踐不同，可是順
序確定是先作系統測試計劃用例，再作集成

2.用例的粒度
系統測試用例相對很接近用戶接受測試用例
集成測試用例比系統測試用例更詳細，並且對於接口部分要重點寫，畢竟要集成各個模塊或者子系統

3.執行測試的順序
先執行集成測試，待集成測試出的問題修復以後，（配置管理，基線化），再作系統測試。

4.用例的數量
系統測試的用例數量通常比集成測試的用例數量少，具體的數量要根據各個公司的性能基線來肯定，通常寫不到這個數量的測試用例還通不過審計

系統測試這個稱呼每每被用於壓力測試、容量測試、性能測試、安全測試等方面。

而集成測試這個稱呼每每被用於細節化的功能測試的超集——從用戶需求來設計和組織較大顆粒度的功能測試。

系統測試最主要的就是功能測試，測試軟件《需求規格說明書》中提到的功能是否有遺漏，是否正確的實現。作系統測試要嚴格按照《需求規格說明書》，以它爲標準。測試方法通常都使用黑盒測試法；
集成測試在系統測試以前，單元測試完成以後系統集成的時候進行測試。集成測試主要是針對程序內部結構進行測試，特別是對程序之間的接口進行測試。集成測試對測試人員的編寫腳本能力要求比較高。測試方法通常選用黑盒測試和白盒測試相結合。

集成測試：是在軟件系統集成過程當中所進行的測試，其主要目的是檢查軟件單位之間的藉口是否正確。它根據集成測試計劃 ，一邊將模塊或其餘年間單位組合成愈來愈大的系統，一邊運行該系統，以分析所組成的系統是否正確，各個組成部分是否合拍。集成測試的策略主要有自頂向下和自底向上兩種。也能夠理解爲在軟件設計單元、功能模塊組裝、集成爲系統時，對應用系統的各個部件（軟件單元、功能模塊接口、連接等）進行的聯合測試，以決定他們可否在一塊兒共同工做，部件能夠是代碼塊、獨立的應用、網絡上的客戶端或服務器端程序。

系統測試：系統測試是基於軟件需求說明書的黑盒測試，是對已經集成好的軟件系統進行完全的測試，以驗證軟件系統的正確性和性能等知足其規約所指定的要求，檢查軟件的行爲和輸出是否正確，並不是一項簡單的任務，被稱爲測試的「先知者問題」。所以，系統測試應該按照測試計劃進行，其輸入、輸出和其餘的動態運行行爲應該與軟件規約進行對比。軟件系統測試的方法不少，主要有功能測試，性能測試，隨機測試等。

總結：
通俗的講，一個產品從研發到出廠的工程中，測試分爲三個階段：單元測試、集成測試、系統測試； 單元測試：一個模塊的功能及常規錯誤測試； 集成測試：完成單元測試後，各模塊聯調測試；集中在各模塊的接口是否一致、各模塊間的數據流和控制硫是否按照設計實現其功能、以及結果的正確性驗證等等；可使整個產品的集成測試，也可使大模塊的集成測試； 系統測試：針對整個產品的全面測試，既包含各模塊的驗證性測試（驗證前兩個階段測試的正確性）和功能性（產品提交個用戶的功能）測試，又包括對整個產品的健壯性、安全性、可維護性及各類性能參數的測試

在這裏推薦一個我本身建立的軟件測試交流羣，qq :642830685,羣中會不按期的分享軟件測試資源，測試面試題以及行業資訊，你們能夠在羣中積極交流技術，還有行業大佬爲你答疑解惑，美哉美哉。

寫在最後：對待生命你不妨大膽冒險一點, 由於好歹你要失去它。若是這世界上真有奇蹟，那只是努力的另外一個名字。生命中最難的階段不是沒有人懂你，而是你不懂你本身。也許你感受本身的努力老是徒勞無功，但沒必要懷疑，你天天都離頂點更進一步。今天的你離頂點還遙遙無期。但你經過今天的努力，積蓄了明天勇攀高峯的力量。最後但願你們天天努力一點點，一菲期待屬於你的一飛沖天。