對於想要從事軟件測試的新人或者想要對軟件測試有初步瞭解的朋友來說，趙斌的《軟件測試技術經典教程》是一本很不錯的書。
下面是我通過閱讀此書後總結的書中所介紹的基礎知識要點。
一、基本概念
軟件中BUG的定義
軟件的bug指的是軟件中(包括程序與文檔)不符合用戶需求的問題。這個定義使我們判斷一個軟件問題是否是bug的唯一標準
軟件測試的最終目的
是檢驗實際的軟件系統是否符合用戶的需求，所以不能爲了發現錯誤而發現錯誤。
測試環境
是檢驗實際的軟件系統是否符合用戶的需求，所以不能爲了發現錯誤而發現錯誤。
測試環境
測試環境 = 軟件+硬件+網絡
軟件主要是指軟件運行的操作系統。
軟件環境的分類
軟件開發環境：軟件在開發過程中使用的環境
軟件生產運行環境：最終用戶使用環境
軟件測試環境要與軟件生產運行環境保持一致，要從開發環境中獨立出來。
測試用例
測試用例 = 輸入+輸出+測試環境（+測試步驟）
輸入：測試數據和操作步驟
輸出：期望結果
測試環境：系統環境設置
編寫測試用例的唯一標準是用戶需求，具體參考資料是《系統需求規格說明書》和軟件原型。
優點：便於團隊交流，便於重複測試，便於跟蹤統計，便於用戶自測。
二、軟件測試分類
二、軟件測試分類
黑盒測試與白盒測試——按是否查看源代碼劃分
三、軟件測試基本原則
黑盒測試：把被測的軟件看做是一個黑盒子，不關心盒子裏面的結構是什麼樣子的，只關心軟件的輸入數據和輸出結果。
白盒測試：把盒子蓋打開，去研究裏面的源代碼和程序結構，查看程序的源代碼具體是怎麼實現的。
靜態測試與動態測試：——按是否運行程序劃分
靜態測試：static testing 不實際運行被測軟件，而只是靜態的檢查程序代碼（包括檢查註釋），界面或者文檔中可能存在的錯誤的過程。
動態測試：dynamic testing 實際運行被測程序，輸入相應的測試數據，檢查實際輸出結果和預期結果是否相符。
判斷一個測試屬於動態測試還是靜態測試，唯一的標準是看是否運行程序。
單元測試、集成測試、系統測試、驗收測試：——按階段劃分
時間比例1:2:4:2
單元測試：unit testing 對軟件中的最小可測單元進行檢查和驗證（單元是指認爲規定的最小被測功能模塊）
依據：源程序，《詳細設計文檔》
一般步驟：1.編譯運行程序
2.靜態測試（檢查代碼是否符合規範）
3.動態測試
樁模塊和驅動模塊
樁模塊：stub 模擬被測模塊所調用的模塊
驅動模塊：driver 用來接收測試數據，啓動被測模塊並輸出結果
集成測試：integration testing 單元測試的下一階段，將通過測試的單元模塊組裝成系統或子系統，再進行測試，重點測試不同模塊的接口，檢查各個單元模塊結合到一起能否協同配合，正常運行。
依據：單元測試的模塊以及《概要設計文檔》
系統測試：system testing 將整個軟件系統看做一個整體進行測試，包括對功能，性能，以及軟件所運行的軟硬件環境進行測試。
需要花大量時間和精力去完成的，也是軟件交給用戶進行驗收測試的最後一道關卡。
依據：《系統需求規格說明書》
驗收測試：acceptance testing 系統測試的後期，以用戶測試爲主，或有測試人員等質量保障人員共同參與的測試。
分爲 a（a fa）測試 【由用戶，測試人員，開發人員等共同參與的內部測試】和 b (be ta)測試【內測後的公測，完全交給最終用戶的測試】
功能測試盒性能測試：——屬於黑盒測試
功能測試：function testing 檢查實際軟件的功能是否符合用戶的需求
功能測試又可以細分爲很多種：邏輯功能測試logic function testing，界面測試UI testing，易用性測試usability，安裝測試installation，兼容性測 試compatibility等。
性能測試：performance testing 一般要使用自動化測試工具。軟件性能主要包括時間性能和空間性能。
性能測試分爲：一般性能測試，穩定性測試，負載測試，壓力測試
一般性能測試：讓被測系統在正常的軟硬件環境下運行，不向其施加任何壓力的性能測試。
穩定性測試：reliability 也叫做可靠性測試。連續運行被測系統，檢查系統運行時的穩定程度。
負載測試：load 讓被測系統在其能忍受的壓力的極限範圍之內連續運行，來測試系統的穩定性。
壓力測試：stress 持續不斷的給被測系統增加壓力，只要將被測系統壓垮爲止，用來測試系統所能承受的最大壓力。
迴歸測試，冒煙測試，隨機測試：
迴歸測試：regression 對軟件的新的版本測試時，重複執行上一個版本測試時的用例。
冒煙測試：smoke 是指對一個新版本進行系統大規模的測試之前，先驗證一下軟件的基本功能是否實現，是否具備可測性。
隨機測試：random 測試中所有的輸入數據都是隨機生成的，其目的是模擬用戶的真是操作，並發現一些邊緣性的錯誤
1.zero bug 和good enough原則
zero bug ： 軟件沒有任何的錯誤
good enough：只要軟件達到一定的質量要求，就可以停止測試了。（過分的測試浪費資源）
2.不要試圖窮舉測試
3.開發人員不能既是運動員又是裁判
4.軟件測試要儘早執行
5.軟件測試應該追溯需求
6.缺陷的二八定理
一般情況下，軟件80%的缺陷集中在20%的模塊
7.缺陷具有免疫性
此外還有相關黑盒測試以及白盒測試的方法介紹，給大家推薦一下這本書。O(∩_∩)O
此外還有相關黑盒測試以及白盒測試的方法介紹，給大家推薦一下這本書。O(∩_∩)O