基本概念：

測試是為了發現程式中的錯誤而執行程式的過程

軟體測試工程師在一家軟體企業中擔當的是“質量管理”角色，及時糾錯及時更正，確保產品的正常運作

據瞭解，軟體測試人員必須具有創新性和綜合分析能力，必須具備判斷準確、追求完美、執著認真、善於合作的品質，以及具有豐富的程式設計經驗與查檢故障的能力。

詳細分類：

根據測試目的的不同，還有迴歸測試、壓力測試、效能測試等，分別為了檢驗修改或優化過程是否引發新的問題、軟體所能達到處理能力和是否達到預期的處理能力

角度細分

  從是否關心軟體內部結構和具體實現的角度劃分
A.白盒測試
B.黑盒測試
C.灰盒測試

  從是否執行程式的角度

A.靜態測試
B.動態測試。

階段細分

  從軟體開發的過程按階段劃分有

A.單元測試
B.整合測試
C.確認測試
D.系統測試
E.驗收測試

* 單元測試：集中對用原始碼實現的每一個程式單元進行測試，檢查各個程式模組是否正確地實現了規定的功能。
* 整合測試：把已測試過的模組組裝起來，主要對與設計相關的軟體體系結構的構造進行測試。
* 確認測試：則是要檢查已實現的軟體是否滿足了需求規格說明中確定了的各種需求，以及軟體配置是否完全、正確。
* 系統測試：把已經經過確認的軟體納入實際執行環境中，與其它系統成份組合在一起進行測試。


測試模型(配圖)：

V模型
定義：是軟體開發瀑布模型的變種，它反映了測試活動與分析和設計的關係 。
描述：從左到右，描述了基本的開發過程和測試行為，非常明確地標明瞭測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發過程期間各階段的對應關係 。
左邊依次下降的是開發過程各階段，與此相對應的是右邊依次上升的部分，即各測試過程的各個階段。
使用者需求 驗收測試
需求分析和系統設計 確認測試和系統測試

概要設計 整合測試

詳細設計 單元測試

W模型

定義：相對於V模型，W模型增加了軟體各開發階段中應同步進行的驗證和確認活動。

描述：W模型由兩個V字型模型組成，分別代表測試與開發過程，圖中明確表示出了測試與開發的並行關係。 W模型強調：測試伴隨著整個軟體開發週期，而且測試的物件不僅僅是程式，需求、設計等同樣要測試，也就是說，測試與開發是同步進行的。W模型有利於儘早地全面的發現問題。例如，需求分析完成後，測試人員就應該參與到對需求的驗證和確認活動中，以儘早地找出缺陷所在。同時，對需求的測試也有利於及時瞭解專案難度和測試風險，及早制定應對措施，這將顯著減少總體測試時間，加快專案進度。 但W模型也存在侷限性。在W模型中，需求、設計、編碼等活動被視為序列的，同時，測試和開發活動也保持著一種線性的前後關係，上一階段完全結束，才可正式開始下一個階段工作。這樣就無法支援迭代的開發模型。對於當前軟體開發複雜多變的情況，W模型並不能解除測試管理面臨著困惑
H模型


H模型中， 軟體測試過程活動完全獨立，貫穿於整個產品的週期，與其他流程併發地進行，某個測試點準備就緒時，就可以從測試準備階段進行到測試執行階段。軟體測試可以儘早的進行，並且可以根據被測物的不同而分層次進行。
這個示意圖演示了在整個生產週期中某個層次上的一次測試“微迴圈”。圖中標註的其它流程可以是任意的開發流程，例如設計流程或者編碼流程。也就是說， 只要測試條件成熟了，測試準備活動完成了，測試執行活動就可以進行了
H模型揭示了一個原理：軟體測試是一個獨立的流程，貫穿產品整個生命週期，與其他流程併發地進行。H模型指出軟體測試要儘早準備， 儘早執行。不同的測試活動可以是按照某個次序先後進行的，但也可能是反覆的，只要某個測試達到準備就緒點，測試執行活動就可以開展。
X模型


X模型也是對V模型的改進，X模型提出針對單獨的程式片段進行相互分離的編碼和測試，此後通過頻繁的交接，通過整合最終合成為可執行的程式。X模型的左邊描述的是針對單獨程式片段所進行的相互分離的編碼和測試，此後將進行頻繁的交接，通過整合最終成為可執行的程式，然後再對這些可執行程式進行測試。己通過整合測試的成品可以進行封裝並提交給使用者，也可以作為更大規模和範圍內整合的一部分。多根並行的曲線表示變更可以在各個部分發生。由圖中可見，X模型還定位了探索性測試，這是不進行事先計劃的特殊型別的測試，這一方式往往能幫助有經驗的測試人員在測試計劃之外發現更多的軟體錯誤。但這樣可能對測試造成人力、物力和財力的浪費，對測試員的熟練程度要求比較高

測試工具：

總的 來說分為功能測試工具、效能測試工具、測試管理工具．
測試管理工具有td，qc，jira，bugzilla
缺陷管理工具，像TD阿，bugzilla阿，mantis
五類測試工具:負載壓力測試工具、功能測試工具、白盒測試工具、測試管理工具、測試輔助工具

  負載壓力測試工具
這類測試工具的主要目的是度量應用系統的可擴充套件性和效能，是一種預測系統行為和效能 的自動化測試工具
  功能測試工具
其主要目的是檢測應用程式是否能夠達到預期的功能並正常執行   
  白盒測試工具
一般是針對程式碼進行測試，測試中發現的缺陷可以定位到程式碼級。根據測試工具原理的不同，又可以分為靜態測試工具和動態測試工具
  測試管理工具
對測試需求、測試計劃、測試用例、測試實施進行管理，並且測 試管理工具還包括對缺陷的跟蹤管理
  測試輔助工具
這些工具本身並不執行測試，例如它們可以生成測試資料，為測試提供資料準

測試用例
目的：統一測試用例編寫的規範，以保證使用最有效的測試用例，保證測試質量。
範圍：適用於公司對產品的業務流程、功能測試測試用例的編寫

術語解釋

  測試分析：對重要業務、重要流程進行測試前的分析。
 業務流程測試用例：關於產品業務、重要流程的測試用例
測試用例設計的方法:等價類劃分法、邊界值分析法
測試用例設計的原則：全面性、正確性、模擬性、可操作性

測試方法：
1、等價類法
定義：是把所有可能的輸入資料，即程式的輸入域劃分成若干部分(子集)，然後從每一個子集中選取少數具有代表性的資料作為測試用例。該方法是一種重要的，常用的黑盒測試用例設計方法
劃分等價類：有效等價類、無效等價類
  1)有效等價類
是指對於程式的規格說明來說是合理的、有意義的輸入資料構成的集合。利用有效等價類可檢驗程式是否實現了規格說明中所規定的功能和效能。

  2)無效等價類
與有效等價類的定義恰巧相反。無效等價類指對程式的規格說明是不合理的或無意義的輸入資料所構成的集合。對於具體的問題，無效等價類至少應有一個，也可能有多個。
設計測試用例時，要同時考慮這兩種等價類。因為軟體不僅要能接收合理的資料，也要能經受意外的考驗，這樣的測試才能確保軟體具有更高的可靠性。
靜態測試：
（1）程式碼檢查：程式碼會審、程式碼走查、桌面檢查
（2）靜態結構分析
（3）程式碼質量度量

動態測試：
（1）黑盒測試：又稱功能測試。這種方法把被測軟體看成黑盒，在不考慮軟體內部結構和特性的情況下測試軟體的外部特性。
     黑盒測試技術主要有等價類劃分法、邊界值法、因果圖法、狀態圖法、測試大綱法以及各類典型的軟體故障模型等；
（2）白盒測試：又稱結構測試。這種方法把被測軟體看成白盒，根據程式的內部結構和邏輯設計來設計測試例項，對程式的路徑和過程進行測試
     白盒測試的主要技術有語句覆蓋、分支覆蓋、判定覆蓋、基本路徑覆蓋等

心理依據：
程式測試的過程具有破壞性：
不要只是為了證明程式能夠正確執行而去測試程式。相反，應該一開始就假設程式中隱藏著錯誤（這種假設幾乎對所有的程式都成立），然後測試程式，發現儘可能多的錯誤
事實上，如果把測試目標定位於要證明程式中沒有缺陷，那麼就會在潛意識中傾向於實現這個目標。也就是說，測試人員會傾向於挑選那些使程式失效的可能性較小的測試資料。另一方面，如果把測試目標定位於要證明程式中存在缺陷，那麼就會選擇一些容易發現程式缺陷的測試資料。而後一種態度會比前者給程式增加更多的價值。

具體內容：
軟體測試主要工作內容是驗證和確認
驗證(verification)是保證軟體正確地實現了一些特定功能的一系列活動， 即保證軟體以正確的方式來做了這個事件(Do it right)
確認(validation)是一系列的活動和過程，目的是想證實在一個給定的外部環境中軟體的邏輯正確性。即保證軟體做了你所期望的事情。(Do the right thing)
軟體測試的物件不僅僅是程式測試，軟體測試應該包括整個軟體開發期間各個階段所產生的文件，如需求規格說明、概要設計文件、詳細設計文件，當然軟體測試的主要物件還是源程式