今天我們看一看測試的理論知識，在學習測試理論知識之前我們先看看什麼是測試？
軟體測試的定義
百度詞條對測試的定義：就是使用人工或自動手段，來執行或測試某個系統的過程。其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。
G.J.Myers對測試的定義：測試是為了發現錯誤而執行程式的過程
因為測試是不能可能窮盡的，所以註定了我們的測試活動存在漏測的可能，如何在可能存在漏測的情況下保證我們測試的版本能夠正常穩定執行就成了我們測試人員需要關注的重點。所以我覺得測試應該是：在某些條件下，驗證軟體能否正常工作的過程。
我們有很多的測試人員測著測著就測偏了。就比如一個使用者名稱的輸入框，我經常會看到這樣的問題單“新建使用者名稱提示長度為1-128之間，實際限制範圍為1-127之間”。你說這樣的問題是問題麼？當然是問題的。但你說這樣的問題會影響到客戶使用麼？不會的，客戶甚至都不會建一個字元數超過32位新使用者，試想一下你建一個這樣的使用者，你輸入使用者名稱的時候不累麼？你能記住這樣一遍小作文似的使用者名稱麼？既然你作為一個使用者都不會這麼使用，那這樣一個問題又有什麼意義呢？下面我們就來談一談測試的目的。
軟體測試的目的
從上面的定義中我們總結出如下目的：
1、測試是為了發現軟體問題
2、測試是為了保證軟體在某種條件下能夠正常執行
3、測試是為了驗證軟體是否滿足軟體使用者需求
還是使用剛剛那個使用者名稱輸入限制的例子來看，它確實發現了問題，但這個問題可能不是影響到版本質量的問題，純粹是為了發現軟體問題。那從這樣來看，我其實就不是很認同G.J.Myers的觀點了，在他思想的指導下容易出現測試的功利主義——純粹為了發現問題而測試。要知道我們測試的目的不是為了客戶拿到手的是一個完美的產品，我們不僅做不到，即使可以做到也完全沒有必要。我們測試是為了客戶在使用我們產品的時候沒有問題，至於客戶不使用的地方有問題，又有誰會去關係呢。
軟體測試的分類
從測試階段看
單元測試：在我們熟知的V模型中，單元測試對應的就是詳細設計。將軟體拆分為許多單元，然後就對單元進行測試。這種測試的輸入資料單一，測試針對性強，發現問題的修改成本很低。
整合測試：同樣，在我們熟知的V模型中，整合測試對應的就是概要設計。軟體多個相互耦合的單元組成一個模組，然後對這個模組進行測試。這個時候的測試主要是發現單元之間的連線邏輯問題，發現問題的修改成本低
系統測試：對應的就是V模型中需求分析的內容，系統測試就是針對著軟體功能的測試了，這個時候更加註重產品功能的實現，發現問題的修改成本已經比較高了
驗收測試：另外有的公司在系統測試結束之後還會有一輪的驗收測試，這個針對的就是產品部署方案的測試，不再侷限於單個功能點，而是基於產品的應用場景。這個時候再發現致命問題的修改成本就更高了。
從測試內容看
功能測試：軟體功能是否符合規格要求
效能測試：軟體效能是否符合規格要求
配置測試：軟體配置操作能否正常下發、生效
穩定性測試：長時間執行情況的測試
壓力測試：裝置即將達到、達到或者超過規格的情況下的測試
異常測試：利用一些攻擊手段，對裝置的安全性進行測試
相容性測試：前後版本、瀏覽器適配等相容性測試
從是否執行程式碼看
動態測試：程式碼執行起來的測試，包含有輸入輸出
靜態測試：不實際執行軟體的測試，如：程式碼檢查、程式碼評審等活動
從程式碼是否可見看
黑盒測試：程式碼不可見，測試人員在不考慮程式碼結構的情況下，根據輸入輸出結果判斷測試結果的測試活動
白盒測試：程式碼可見，測試人員在考慮程式碼結構和特定條件的情況下，檢驗內部流程是否正確
灰盒測試：介於黑盒測試和白盒測試之間， 灰盒測試多用於整合測試階段，不僅關注輸出、輸入的正確性，同時也關注程式內部的情況。
從測試執行看
手工測試：通過人工去執行測試活動
自動化測試：通過測試指令碼去執行測試活動