軟體測試的定義和目的
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是我們無法解決的或者解決成本過大的。所以我們在進行修復時，可以不單單選擇修改程式碼，還可以選擇在用戶手冊中進行提示等方式，來解決問題。方法多樣，靈活選擇。
除了以上一點最重要的目的，我們還引申出兩點有意義的：
-
利用測試過程中得到的測試結果和資訊，作為未來測試的參考，減少類似錯誤的發生
-
不斷地提高測試的效率和產品的品質
最後提一下，測試和調試的區別。它們一個是軟體測試概念，一個是開發概念，注意區別即可。
