1. 軟件的組成
軟件由程序，數據，文檔三部分組成，由此也指引出軟件測試的方向，即為以上三部分。
2. bug的定義
bug一詞由來已久。它的起源可追溯到計算機的上古時代，起因是Grace Hopper在解決計算機故障時，發現一只蟲子因觸電死在了繼電器上，導致運行失敗。於是她將這樣的計算機缺陷稱之為 bug ，找缺陷為 debug。
作為軟件測試人員，我們主要的工作也是與bug打交道，預防bug，尋找bug等等。那我們應該如何定義一個bug呢。我們這里參考一下Ron Patton在《軟件測試》一書中的定義：
軟件未實現產品說明書中要求的功能
軟件出現了產品說明書中指明不應該出現的功能
軟件實現了產品說明書中未提到的功能
軟件未實現產品說明書中雖未明確提及但應該實現的功能
軟件難以理解，不易使用，運行緩慢，或（從測試的角度）最終用戶會認為不好
我們首先明晰一個概念：產品說明書，這與我們可以將它理解為需求/需求文檔。
分析以上五點，軟件的缺陷從兩個層面進行定義：一是客觀層面（1~4），二是主觀層面（5）。
客觀層面前兩點比較好理解，軟件與需求不符即為bug，這點與我們的認知相符。但后兩點開始模棱兩可了，軟件實現了需求之外的功能，與沒實現隱性需求，均與需求文檔不符。但我們不能輕易判斷這是否是一個缺陷。需求之外的功能可能是行業標准，隱性需求可能不是剛需，那這樣就不算是一個bug。反之這就是一個應該被提交的問題。這就要求我們測試必須足夠靈活，來做好這個判斷。這也提醒我們提交一個軟件缺陷一定要有理有據，才令人信服。由上我們可以認識到，缺陷在客觀層面與需求緊密相連，一個好的需求文檔應該滿足兩點原則：明確 和 合理 。這也是我們測試需求文檔的重要思想。
主觀層面可以說非常考驗測試人員了，什么叫難以理解，不易使用，運行緩慢，這些都沒有統一的標准。最終用戶會覺得不好還是你不喜歡？要想做好最后這一點，對測試人員的經驗、能力、處事多方面都提出了高要求，這也是測試難做的點，沒有統一客觀標准。所以我們必須再次提出，作為測試人員，一定要靈活。這樣的靈活能力來自於我們積累的經驗，我們的專業判斷，和對產品深入的理解。
所有不滿足需求或超出需求的都是缺陷
沒有不存在缺陷的軟件，只有迄今為止尚未發現的缺陷
3. 軟件測試的定義
雖然bug早在計算機誕生后不久就提出了，但軟件測試的概念直到70年代中期才開始被提出來。這與計算機軟件越來越龐大，而軟件質量越來越難以保證有很大關系。1975年《測試數據選擇的原理》文章發表，軟件測試被確定為一中研究的方向。軟件質量保證的號角也開始漸漸吹響，其中不乏一些優秀和經典的作品，比如《軟件測試的藝術》。
對於軟件測試，有多個角度的定義方式，這里我們一個一個來看：
-
正向思維定義：順着軟件運行邏輯，以確信其最終能夠正常運行為目標/導向而展開的任何行為，是軟件測試。
-
反向思維定義：抱着懷疑主義的精神，相信軟件一定存在缺陷的想法作為出發點。逆着軟件運行的內生邏輯，以證明其存在的缺陷為目標/導向而開展的任何行為，是軟件測試。
一個好的測試用例在於它能發現以前未發現的錯誤
一個成功的測試是發現了以前未發現的錯誤的測試
關於這里的雙向思維定義，感觸頗多。正向和方向的思維方式不光在測試里有用，推而廣之，這也是我們解決任何問題的原則之一：多角度看問題。通過這樣的思考方式，既有助於我們解決問題，也變相幫我們驗證了問題本身。而當我們運用這樣的思維方式進行反推會發現，其實這也是“條條大路通羅馬”的一個應用實踐。這條雞湯也再一次提醒我們：be flexible，要靈活!
- IEEE定義：
在規定的條件下運行系統或構件的過程：觀察和記錄結果，並對系統或構建的某些方面給出評價
分析軟件項目的過程：檢測現有狀況與所需狀況之間的不同，並評估軟件項目的特性
前面雙向思維式的定義是從軟件測試的方法出發，給出軟件測試的定義。而審視IEEE對軟件測試的定義，從更加宏觀的角度，回答了軟件測試是什么。
第一條，我們注意兩點，一是在規定條件下運行系統或構建，這個過程就是軟件測試。規定條件可以是我們運用上面正反向思維框定的測試用例，也可以是其他測試方法下的用例。二是作為測試人員，我們的工作內容是什么？是三部分：設計測試用例（為軟件規定條件），運行用例，觀察和記錄運行的結果，最后對被測試的軟件進行評價。這里引入評價這一點很精髓，既展示出測試工作的成果，又有助於我們確定軟件改進的方向。
第二條，在明晰了測試和測試人員的主要工作后，進一步將測試的范圍擴大，從對軟件本身的測試，推廣到對整個軟件項目過程（生命周期）的測試，在這一層，我們測試人員需要做做三點：對軟件生命周期各個階段進行分析，檢測/覺察出現實狀況與我們所需要的狀況之間的差異，最后做出我們對整個軟件項目的評估/評價/總結。這一條無疑是非常難以做到的，需要我們的日積月累，厚積薄發。
- 廣義定義：軟件測試是對軟件形成過程中的所有工作產品（包括程序及相關文檔）進行測試，而不僅僅是對程序的運行進行測試
這是一個單純的對軟件測試的定義，了解IEEE的定義，我們不難看出廣義的定義其實也是它的一個子集。不過它很好的提示了我們，不要只看到狹義的軟件測試（對程序本身的測試），還要擴展到對軟件開發整個過程的質量保證。
這里我們提出兩個重要的軟件測試的術語：
-
確認（validation）：通過檢查和提供客觀證據來證實特定目的的功能或應用是否已經實現。
-
驗證（verification）：通過檢查和提供客觀證據來證實指定的需求是否滿足。
這兩個詞是遞進的關系，驗證包含了確認。確認用來檢查功能有沒有實現，而驗證更進一步，看實現的功能滿不滿足需求（實現了功能不代表會滿足需求）。
學習完以上四點定義，我們對軟件測試是什么，和軟件測試做些什么有了一定的了解，那軟件測試的目的什么呢？我們來談談。
借用Ron Patton的話來說，軟件測試的目的就是一點：
盡早地發現軟件缺陷，並確保其得以修復。
這也是作為軟件測試人員來說，我們最重要的使命。這里我們需要注意幾個關鍵詞，“盡早”是指我們應該在項目早期就介入，以期從根源減少缺陷的出現。另一個是“修復”，注意修復不是單純指改bug，因為我們知道，有些bug是我們無法解決的或者解決成本過大的。所以我們在進行修復時，可以不單單選擇修改代碼，還可以選擇在用戶手冊中進行提示等方式，來解決問題。方法多樣，靈活選擇。
除了以上一點最重要的目的，我們還引申出兩點有意義的：
-
利用測試過程中得到的測試結果和信息，作為未來測試的參考，減少類似錯誤的發生
-
不斷地提高測試的效率和產品的質量
最后提一下，測試和調試的區別。它們一個是軟件測試概念，一個是開發概念，注意區別即可。