基本概念：
測試是為了發現程序中的錯誤而執行程序的過程
軟件測試工程師在一家軟件企業中擔當的是“質量管理”角色，及時糾錯及時更正，確保產品的正常運作
據了解，軟件測試人員必須具有創新性和綜合分析能力，必須具備判斷准確、追求完美、執着認真、善於合作的品質，以及具有豐富的編程經驗與查檢故障的能力。
詳細分類：
根據測試目的的不同，還有回歸測試、壓力測試、性能測試等，分別為了檢驗修改或優化過程是否引發新的問題、軟件所能達到處理能力和是否達到預期的處理能力
角度細分
從是否關心軟件內部結構和具體實現的角度划分 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) 軟件測試的對象不僅僅是程序測試，軟件測試應該包括整個軟件開發期間各個階段所產生的文檔，如需求規格說明、概要設計文檔、詳細設計文檔，當然軟件測試的主要對象還是源程序