軟件測試筆記（一）理論篇

軟件測試筆記（一）理論篇

有句話是這麼說的：能動手就別嗶嗶，尤爲是在工做節奏堪比跑馬的今天，你們都推崇實幹精神，能解決問題就好，去他的理論。可是無能否認的是，良好的理論素養不管是解決工做中遇到的問題，仍是將來的職業發展，都幫助甚大。本文整理彙總了軟件測試行業中常見的一些測試理論，供你們參考。

一、軟件測試按照測試分類有：黑盒測試和白盒測試。

黑盒測試

黑盒測試也稱功能測試，它是經過測試來檢測每一個功能是否都能正常使用。在測試中，把程序看做一個不能打開的黑盒子，在徹底不考慮程序內部結構和內部特性的狀況下，在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。黑盒測試着眼於程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。
黑盒測試是以用戶的角度，從輸入數據與輸出數據的對應關係出發進行測試的。很明顯，若是外部特性自己設計有問題或規格說明的規定有誤，用黑盒測試方法是發現不了的。
新人入行基本上都是採用黑盒測試的方法來入門的。

白盒測試

白盒測試又稱結構測試、透明盒測試、邏輯驅動測試或基於代碼的測試。白盒測試是一種測試用例設計方法，盒子指的是被測試的軟件，白盒指的是盒子是可視的，你清楚盒子內部的東西以及裏面是如何運做的。"白盒"法全面瞭解程序內部邏輯結構、對全部邏輯路徑進行測試。"白盒"法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯着手，得出測試數據。貫穿程序的獨立路徑數是天文數字。

我們以空調爲例來看什麼是黑盒測試，什麼是白盒測試：
當一臺新的空調組裝完成，質監部門須要對這臺空調的各個功能進行測試，好比開關機是否正常，製冷制熱功能是否正常，定時功能是否正常，等等，並將測試的結果一一記錄下來，若是有問題，及時反饋給設計部來解決，這就是黑盒測試的範疇。
對於空調的設計師們，他們的測試可能就會更復雜一些，除了對空調的各項功能進行測試以外，還要從空調的內在原理來分析，他們甚至會跟蹤空調的內部實現代碼，分析空調的各項數據狀態來看是否正常運行，而不僅是從表面功能來看，這就是白盒測試的範疇。

二、按照測試的階段能夠分爲：單元測試、集成測試、確認測試和系統測試及驗收測試

單元測試

單元測試（unit testing），是指對軟件中的最小可測試單元進行檢查和驗證。對於單元測試中單元的含義，通常來講，要根據實際狀況去斷定其具體含義，如C語言中單元指一個函數，Java裏單元指一個類，圖形化的軟件中能夠指一個窗口或一個菜單等。總的來講，單元就是人爲規定的最小的被測功能模塊。單元測試是在軟件開發過程當中要進行的最低級別的測試活動，軟件的獨立單元將在與程序的其餘部分相隔離的狀況下進行測試。
在一種傳統的結構化編程語言中，好比C，要進行測試的單元通常是函數或子過程。在像C++這樣的面向對象的語言中， 要進行測試的基本單元是類。對Ada語言來講，開發人員能夠選擇是在獨立的過程和函數，仍是在Ada包的級別上進行單元測試。單元測試的原則一樣被擴展到第四代語言（4GL)的開發中，在這裏基本單元被典型地劃分爲一個菜單或顯示界面。
常常與單元測試聯繫起來的另一些開發活動包括代碼走讀（Code review)，靜態分析（Static analysis)和動態分析（Dynamic analysis)。靜態分析就是對軟件的源代碼進行研讀，查找錯誤或收集一些度量數據，並不須要對代碼進行編譯和執行。動態分析就是經過觀察軟件運行時的動做，來提供執行跟蹤，時間分析，以及測試覆蓋度方面的信息。

集成測試

集成測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將全部模塊按照設計要求（如根據結構圖）組裝成爲子系統或系統，進行集成測試。
實踐代表，一些模塊雖然可以單獨地工做，但並不能保證鏈接起來也能正常的工做。一些局部反映不出來的問題，在全局上極可能暴露出來。

確認測試
確認測試的目的是向將來的用戶代表系統可以像預約要求那樣工做。經集成測試後，已經按照設計把全部的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接着就應該進一步驗證軟件的有效性，這就是確認測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。

系統測試

系統測試，英文是System Testing。是將已經確認的軟件、計算機硬件、外設、網絡等其餘元素結合在一塊兒，進行信息系統的各類組裝測試和確認測試，系統測試是針對整個產品系統進行的測試，目的是驗證系統是否知足了需求規格的定義，找出與需求規格不符或與之矛盾的地方，從而提出更加完善的方案。系統測試發現問題以後要通過調試找出錯誤緣由和位置，而後進行改正。是基於系統總體需求說明書的黑盒類測試，應覆蓋系統全部聯合的部件。對象不只僅包括需測試的軟件，還要包含軟件所依賴的硬件、外設甚至包括某些數據、某些支持軟件及其接口等。

驗收測試

驗收測試是部署軟件以前的最後一個測試操做。在軟件產品完成了單元測試、集成測試和系統測試以後，產品發佈以前所進行的軟件測試活動。它是技術測試的最後一個階段，也稱爲交付測試。驗收測試的目的是確保軟件準備就緒，而且可讓最終用戶將其用於執行軟件的既定功能和任務。
驗收測試是向將來的用戶代表系統可以像預約要求那樣工做。經集成測試後，已經按照設計把全部的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接着就應該進一步驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。
驗收測試，系統開發生命週期方法論的一個階段，這時相關的用戶和獨立測試人員根據測試計劃和結果對系統進行測試和接收。它讓系統用戶決定是否接收系統。它是一項肯定產品是否可以知足合同或用戶所規定需求的測試。這是管理性和防護性控制。
在工程及其餘相關領域中，驗收測試是指確認一系統是否符合設計規格或契約之需求內容的測試，可能會包括化學測試、物理測試或是性能測試。在系統工程中驗收測試可能包括在系統（例如一套軟件系統、許多機械零件或是一批化學制品）交付前的黑箱測試。軟件開發者常會將系統開發者進行的驗收測試和客戶在接受產品前進行的驗收測試分開。後者通常會稱爲使用者驗收測試、終端客戶測試、實機（驗收）測試、現場（驗收）測試。在進行主要測試程序以前，經常使用冒煙測試做爲一個此階段的驗收測試。

三、其餘的測試理論還有：自動化測試、迴歸測試、冒煙測試、性能測試

自動化測試

通常是指軟件測試的自動化，軟件測試就是在預設條件下運行系統或應用程序，評估運行結果，預先條件應包括正常條件和異常條件。一般，在設計了測試用例並經過評審以後，由測試人員根據測試用例中描述的規程一步步執行測試，獲得實際結果與指望結果的比較。在此過程當中，爲了節省人力、時間或硬件資源，提升測試效率，便引入了自動化測試的概念。
自動化測試分爲web自動化測試、接口自動化測試、APP自動化測試。

迴歸測試

迴歸測試是指修改了舊代碼後，從新進行測試以確認修改沒有引入新的錯誤或致使其餘代碼產生錯誤。自動迴歸測試將大幅下降系統測試、維護升級等階段的成本。迴歸測試做爲軟件生命週期的一個組成部分，在整個軟件測試過程當中佔有很大的工做量比重，軟件開發的各個階段都會進行屢次迴歸測試。在漸進和快速迭代開發中，新版本的連續發佈使迴歸測試進行的更加頻繁，而在極端編程方法中，更是要求天天都進行若干次迴歸測試。所以，經過選擇正確的迴歸測試策略來改進迴歸測試的效率和有效性是頗有意義的。

冒煙測試

這一術語源自硬件行業。對一個硬件或硬件組件進行更改或修復後，直接給設備加電。若是沒有冒煙，則該組件就經過了測試。在軟件中，「冒煙測試」這一術語描述的是在將代碼更改嵌入到產品的源樹中以前對這些更改進行驗證的過程。在檢查了代碼後，冒煙測試是肯定和修復軟件缺陷的最經濟有效的方法。冒煙測試設計用於確認代碼中的更改會按預期運行，且不會破壞整個版本的穩定性。

性能測試

性能測試是經過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，二者能夠結合進行。經過負載測試，肯定在各類工做負載下系統的性能，目標是測試當負載逐漸增長時，系統各項性能指標的變化狀況。壓力測試是經過肯定一個系統的瓶頸或者不能接受的性能點，來得到系統能提供的最大服務級別的測試。