所有的測試都應該追溯到使用者。
越早測越好，測試過程與開發過程應該是互相結合的。
測試的規模 從小到大，從單元測試到系統測試。
不能為了便於測試而擅自修改程式。
既應該測試軟體能做什麼，也應該測試軟體不能做什麼。
測試做到什麼程度並沒有乙個固定答案。只要滿足兩個顯式條件和乙個隱含條件就要一直進行。
顯式條件：
隱含條件：
測試只是展示缺陷測試只能表明缺陷存在,卻不能證明沒有缺陷。測試能降低未發現缺陷留存的概率,卻 不能證明軟體是絕對正確的。 正如某些數學命題,你可以窮舉 1-n,證明其正確,卻依然無法證明對於 n+1 仍然正確。測試的標準窮盡測試是不可能的
測試所有的輸入和條件組合是不可能的,除非是極其簡單的情況。可以取而代之的是基 於風險和優先順序的測試。 當不懂裝懂的老闆要求你徹底測試乙個軟體的時候,這是你反駁的最好支援,當然要說 的委婉一點。
早期測試
要較早發現缺陷,就要在軟體週期盡可能早的時候開始測試,而且要專注於已定義的測 試目標。 盡早開始測試!這句話估計早就把大家的耳朵磨起繭了。為什麼要早?因為越早發現問 題,解決的代價就越小。
缺陷簇生
要對缺陷發現率高的模組投入更多的測試。少量的模組往往隱藏了大部分的缺陷。 這不僅僅是所謂的物以類聚。缺陷發現率高的模組往往於需求不清,設計不當,編碼復 雜度高等內在原因關聯,所以從風險的角度來看必然較高,多花些時間絕對值得。
殺蟲劑悖論
相同的測試再重複多次後就無法再找到缺陷了。要克服「殺蟲劑悖論」,測試用例要不斷評審修改,不斷新增新的和不同的測試,就有可能找到更多缺陷。 隨著對系統的加深理解,必然會有更多的測試用例產生。另外缺陷本身也是新用例的很 好**。
測試是上下文相關的
測試在不同上下文環境中的執行是不同的。比方說 安全關鍵系統 (safety critical system)和電子商務**的測試方法就有很大不同。 這個原理相對難理解。這裡其實強調的是不能用相同的態度和手段來測試不同型別的系 統。安全關鍵系統的概念要到高階大綱中才出現,指的是對系統安全要求苛刻的系統, 較之一般的電子商務系統的測試要求更為嚴苛。
無錯謬論
假如建立的系統不穩定或不能滿足使用者需要和期望,那麼發現和修復缺陷就毫無幫助了。 缺陷數量往往用來評估某軟體的質量,但要是系統本身背離了使用者要求,那就算缺陷再 少也沒用,因為沒有人會去用它。所以測試時要注意驗證(verification)和確認(validation)的區別。需求規格說明和其他文件只是需求的不完全載體。文字說明必然有遺漏和偏差, 而各人的理解更有可能出錯。要不斷通過各種途徑保證所生產的的確就是使用者需要的。 常用的方式就是邀請領域專家或使用者盡可能多地參與到開發活動來,特別是需求評審和 演示(demo)。
所有的軟體測試都應該追溯使用者的需求，測試人員要始終站在使用者的角度去看問題、去判斷的軟體缺陷的影響，系統最嚴重的錯誤是那些導致程式無法滿足使用者需求的缺陷。
熟悉產品／專案為什麼要避免測試自己的程式？需求評審
測試需求
測試計畫
測試用例
**試第一輪測試
第二輪回歸測試
第三輪測試
測試報告
測試總結
由於心理因素，人們潛意識都不希望找到自己的錯誤。基於這種思維定勢，人們難於發現自己的錯誤。
軟體質量是軟體測試的目標，也是軟體測試工作的中心，一切從質量出發，也就是一切從客戶需求出發。任何違背質量的東西都是問題，測試就是要找出這些問題。
人是決定的因素，測試人員的態度、素質、能力決定著測試的效果，對測試產品的質量也有很大的影響。測試人員因素包括測試組織結構、角色和責任的定義。
軟體測試技術，包括方法、工具。
主要是指測試環境中所需要的硬體裝置、網路環境，甚至包括測試資料。另外乙個重要因素就是測試時間，時間也是測試的資源，但測試人員不能看做資源，每個人的能力千差萬別，不同的測試人員擔任不同的角色，不能相互代替。這也是軟體圖書的經典之作——《人件》的作者反對將人作為資源對待的原因。
從測試計畫和測試用例的建立、評審到測試的執行、報告，設定每個階段的進出標準。軟體產品質量評價國際標準
iso 14598把軟體質量定義為：軟體特性的總和，軟體滿足規定或潛在使用者需求的能力。上述定義反應如下3個方面的問題：
缺陷發現率ddp是另乙個衡量測試工作效率的軟體質量成本的指標。
缺陷發現率ddp＝bugs（tester）/ （bugs（tester）+ bugs（customer））缺陷發現率越高，也就是測試者發現的錯誤多，發布後客戶發現的錯誤就越少，降低了外部故障不一致成本，達到節約總成本的目的，可獲得較高的測試投資回報率。
黑盒測試
功能劃分
等價類劃分
邊界值劃分
因果圖（魚骨圖）
錯誤推測
#### 白盒測試
對應於程式的一些主要結構：語句、分支、邏輯路徑、變數；
語句覆蓋方法
分支覆蓋方法
邏輯覆蓋方法
單元測試
整合測試
系統測試
驗收測試
自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程。
自動測試將測試人員從反覆、煩雜的測試執行中解放出來，用更多的時間進行測試設計和結果分析
上述這些優點所能帶來直接好處是，測試用例的除錯、分析和維護成本最低。每個測試用例應該盡可能的簡單，只驗證你所要驗證的內容。
測試用例替代產品文件功能原則
單次投入成本和多次投入成本原則
使測試結果分析和除錯最簡單化原則
測試用例主要包括用例編號、用例描述、前提條件、輸入資料、測試步驟和期望結果6項關鍵內容：
根據專案相關文件，需要定義測試範圍、測試策略、人員分配、軟硬體配置、進度表以及測試過程每個階段需要達到的目標。
軟體缺陷是指系統或系統部件中那些導致系統或部件不能實現其應有功能的缺陷。一般定義缺陷有以下5條原則：
bug描述的基本要求是分類準確、敘述簡潔、步驟清楚、實際結果描述準確、複雜問題有據可查（截圖或其他形式的附件）。基本要求如下：
軟體測試學習筆記
筆記僅用於自我理解與自我總結，不全面之處請包含，錯誤之處請指正。功能性測試 黑盒測試，軟體實現未知。任何程式被看做是軟體規格說明 需求 中輸入定義域取值到輸出值域的轉換，理想的程式本應該規矩的完成這個職責。所以對於理想的程式，黑盒測試的測試用例完全可以根據軟體規格 需求 說明書來建立，並能夠覆蓋程式...
軟體測試學習筆記
軟體測試學習筆記 利用人工或自動的手段來執行或測量軟體系統的過程，以檢驗軟體系統是否滿足規定的要求，並找出與預期結果之間的差異。軟體測試並不是只測試整個程式，而是貫穿整個程式研發的始終。軟體測試的物件包括 軟體需求 軟體概要設計 軟體詳細設計 軟體執行環境 可執行程式 軟體源 軟體測試的五大要素 質...
軟體測試 學習筆記
1 測試按照特性分類 白盒測試 灰盒測試 黑盒測試。白盒測試 直接在源程式上進行測試 修改 複測。灰盒測試 介於黑白測試之間。黑盒測試 從終端使用者角度進行的功能測試。2 在軟體開發過程中，軟體測試還可以分為單元測試 整合測試 系統測試 使用者驗收測試及回歸測試，其中系統測試是驗證軟體需求規格說明書...