本文包括軟體測試模型、測試技術和測試管理。
一、測試基礎
1、軟體測試模型
所謂測試模型（Test Model），是測試和測試對象的基本特征、基本關系的抽象。
1）V模型
V模型實際是軟體開發瀑布模型的變種，它反映了測試活動與分析、設計的關系。V模型中的過程從左到右，描述了基本的開發過程和測試行為。V模型的價值在于它非常明确地标明了測試過程中存在的不同級别。
如圖所示，左邊為開發過程各階段，右邊為對應的測試階段。V模型，優點是在開發階段，測試工程師就可以介入，準備相應的測試工作，比如審查需求分析、編寫測試計劃等；缺點是仍然要在開發完成後才進入測試階段，導緻問題一直拖到後期才被發現。
V模型失敗的原因是把系統開發過程劃分為具有固定邊界的不同階段，導緻測試人員很難及時采集測試所需資訊，以及綜合不同階段資訊加以總體考慮。
2）W模型
W模型是為了解決V模型的缺陷而演化出來的模型。解決V模型在軟體開發編碼完成後才介入測試工作，導緻一些在需求和設計中的問題在後期驗收測試中才被發現，不能展現“盡早地和不斷地進行軟體測試”的基本原則的問題。
W模型認為，測試工作應對應軟體各開發階段同步進行，由兩個V字型模型組成，分别代表測試與開發過程，即一個測試V，一個開發V。
W模型強調測試階段和開發階段是同步進行的，而且測試的對象不僅僅是程式，還包括需求分析、概要設計和詳細設計，測試伴随着整個軟體開發周期。W模型有利于盡早地全面發現問題，減少總體測試時間，加快項目進度。
W模型的局限性，是與V模型一樣，将軟體的開發視為需求、設計、編碼等一系列串行的活動，測試和開發仍然保持一種線性的前後關系，嚴格遵守先後順序，無法支援疊代的開發模型，未能應付複雜多變的情況。對于開發過程中，需要事後補充文檔，或者根本沒有文檔的情況，W模型中的開發和測試人員面臨同樣的困擾。
3）H模型
V模型和W模型都存在一定的局限性，它們都把軟體的開發過程視為需求、設計、編碼等一系列串行的活動，但實際上這些活動之間存在互相牽制的關系，并且大部分時間内都可以交叉進行。嚴格的階段劃分隻是一種理想的狀态。事實上，軟體項目不可能等需求非常明确才開始進行，一般最初需求評審通過後，開發工作随即進行，邊做邊改。相應地，測試也不存在嚴格的次序關系，還會有反複觸發、疊代和增量的關系。這一點，V模型和W模型都沒有很好地展現出來。
倚天不出，誰與争鋒？有專家提出了H模型。H模型将測試活動完全獨立出來，形成一個完全獨立的流程，将測試準備活動和測試執行活動清晰地展現出來。
H模型揭示了軟體測試模型是一個獨立的流程，貫穿于整個軟體産品的周期，與其他流程并發地進行。優點是将測試從開發中獨立出來，有利于研究更新的測試技術，可同時對多個項目進行測試，與項目的耦合程度較低，獨立性強；但也是以對系統認識不夠深入，影響測試品質和效率。
4）X模型
X模型诟病V模型無法引導項目的全部過程，認為一個模型不應該與實際脫節，是對V模型的糾正和改進。X模型提出針對單獨的程式片段進行互相分離的編碼和測試，此後通過頻繁的交接和內建最終合成可執行的程式。
左邊：針對單獨程式片段進行互相分離的編碼和測試，然後頻繁交接，最終內建為可執行程式，之後又是一輪測試（系統測試？），通過後封裝，送出給使用者，或者作為更大規模和範圍内內建的一部分。多根曲線表示變更可以在各個部分發生。
優點，強調單元測試及內建測試，測試更貼近實際，修複缺陷不受項目組人員限制（就是有一定的獨立性？）；
缺點，測試不夠全面，沒有需求測試、驗收測試。
5）前置測試模型
将測試和開發緊密結合，提供一種輕松的方式，可以使項目加快速度。
前置測試将測試執行和開發結合在一起，并在開發階段以”編碼-測試-編碼-測試“的方式來展現。當程式片段一旦編寫完成，就會立即進行測試。一般是單元測試，也有可能是內建測試或其他測試。這是發現錯誤最經濟的方式。
前置測試将測試分為技術測試和驗收測試兩個獨立的程序。技術測試針對代碼的正确性，驗收測試驗證需求的滿足性，另外還可能包括負載測試、安全性測試、可用性測試等。
6）各測試模型比較
這是我根據個人了解的總結，可能有誤。
V模型、W模型、H模型、X模型、前置模型，都以V模型作為參照，作出各自的改進。V模型在測試種的地位，就相當于開發模型中的瀑布模型，繞不過去，是基礎。
V模型的特點，是開發在先，測試在後，階段分明，缺點顯而易見，開發與測試脫節；
W模型，是開發一段，測試一段，如影随形。但仍然是階段分明。
H模型，将測試完全獨立出來，按照自己的節奏，想測就測，但測試跟系統關系不夠密切，有點貌合神離的味道。
X模型，針對開發階段進一步劃分，劃分成一個個片段，加大測試的頻率，最後再內建測試、封裝成完整系統進行傳遞。貌似太瑣碎了，并且隻側重測試開發，對需求分析、系統驗收的測試不夠，缺乏總體性。真是明察秋毫，不見輿薪。
前置模型，将測試分為技術測試和驗收測試，各自獨立，完美。
2、軟體測試類型
1）分類
1、按開發階段：單元測試、內建測試、系統測試、驗收測試
2、按測試實施組織：α測試（開發方）、β測試（使用者方）、第三方測試
3、按測試執行方式：靜态測試、動态測試
4、按是否檢視代碼（或測試技術）：黑盒測試、白盒測試、灰盒測試
5、按是否手工執行劃分：手工測試、自動化測試
6、按測試對象劃分：性能測試、安全測試、相容性測試、文檔測試、易用性測試（使用者體驗測試）、業務測試、界面測試、安裝測試
或進一步細分，其中品質屬性測試有：容錯性測試、相容性測試、安全性測試、可靠性測試、維護性測試、可移植性測試、易用性測試。
7、按測試地域劃分：本地化測試、國際化測試
負載測試壓力測試強度測試穩定性測試
2）名詞解釋
（1）內建測試
又稱為組裝測試、聯合測試、子系統測試或部件測試。
分為
非增值式：先分别測試每個子產品，然後結合在一起測試；
增值式：又稱為漸增式組裝，首先一個個子產品測試，然後逐漸組裝，邊組裝邊測試
非增值式簡單，資源使用率高，缺點是成本高，難以定位錯誤；增值式能較早發現和定位問題，缺點是測試周期長，資源利用不夠充分。
（2）系統測試
對已內建好的軟體系統進行徹底的測試，以驗證軟體系統的正确性和性能等是否滿足其規約所指定的要素。
（3）驗收測試
完成了功能測試和系統測試之後，産品釋出之前所進行的軟體測試活動，是技術測試的最後一個階段，也稱為傳遞測試、釋出測試或确認測試。
【驗收測試标準】
完全執行了驗收測試計劃中的每個測試用例
在驗收測試中發現的錯誤已經得到修改并且通過了測試
完成軟體驗收測試報告
【注意事項】
必須編寫正式的、單獨的驗收測試計劃
驗收測試必須在實際的使用者運作環境中運作
由使用者和測試部門共同執行比較好。如果是公司自我開發産品，由測試部門聯合多個部門共同進行。
（4）灰盒測試
介乎于白盒測試和黑盒測試之間。既關注輸出對于輸入的正确性，同時也關注内部表現，但這種關注不像白盒測試那樣詳細、完整，隻是通過一些表征、事件、标志來判斷内部的運作狀态。灰盒測試是基于程式運作時的外部表現同時又結合程式内部邏輯結構來設計用例，執行程式，并采集程式路徑執行資訊，和外部使用者接口結果的測試技術。
黑盒測試隻需關心整個軟體系統的邊界，灰盒測試需要關心子產品之間的互動，白盒測試需要了解子產品内部的實作細節。
二、軟體測試技術
1、黑盒測試法
黑盒測試也稱為功能測試，通過測試來檢測每個功能是否都能正常使用。測試時，把被測試程式視為一個不能打開的黑盒子，在完全不考慮内部結構和内部特性的情況下進行測試。旨在檢查程式功能是否能按照需求規格說明書的規定正常使用，輸入輸出是否正确等。
黑盒測試有兩種基本方法：通過測試和失敗測試。通過測試确認軟體能做什麼；失敗測試則是通過搞垮軟體來觀察軟體的缺陷（比如壓力測試？）
黑盒測試的優點是簡單、友善，缺點是覆寫率低，自動化測試複用率不夠。
黑盒測試不可能采用窮舉法輸入測試，測試用例是将測試行為具體量化的方法之一。
黑盒測試的測試用例設計方法主要有：
1）測試區域确定法
2）資料覆寫法
3）邏輯推斷法
4）業務路徑覆寫法
2、白盒測試法
白盒測試又稱為結構測試或邏輯驅動測試。
白盒測試将測試對象看作一個透明的盒子，按照程式内部的結構測試程式，檢驗程式中的每條通路是否都能按照預定要求正确工作，而不顧它的功能。
1）靜态白盒測試
在不執行的情況下，有條理地仔細審查軟體設計、體系結構和代碼，進而找出軟體缺陷的過程。優點是盡早發現缺陷，為黑盒測試提供思路。
2）動态白盒測試
又稱為結構測試。檢視并使用代碼的内部結構，進而設計和執行測試。
三、資訊系統測試管理
測試管理是為了實作 測試工作預期目标，以 測試人員 為中心，對 測試生命周期 及其所涉及的資源進行有效的 計劃、組織、上司和控制 的協調活動。
1、測試管理概述
随着軟體開發規模增大，複雜程度增加，軟體測試更加困難，加強對測試工作的組織和管理就顯得尤為重要。
軟體測試不能隻針對程式進行測試，因為如果是系統設計上的錯誤，傳回來修改代價非常高。較理想的做法是對軟體的開發過程，按照軟體工程各階段結果進行嚴格的審查。測試的準備工作，在系統分析和設計階段就要開始。
測試管理是以測試人員為中心，對測試生命周期及相關資源進行計劃、組織、上司和控制的協調活動。管理的要素包括測試政策的制定、測試項目進度跟進、項目風險評估、測試文檔評審、測試内部和外部的協調溝通、測試人員的培養等。
注：測試周期，傳統上劃分為測試計劃、測試設計和測試執行。
2、測試管理内容
按照管理範圍和對象，測試管理可以分為部門管理和測試項目管理。部門管理就是管人，管資源等；測試項目管理就是管項目測試人員，測試計劃、政策，各項測試工作等。
3、測試監控管理
為測試活動提供回報資訊和可視性。記錄，評估，分析。重點是分析缺陷，比如存活時間，分布密度，趨勢分析等。
4、配置管理
包括搭建滿足要求的測試環境，還包括擷取正确的測試、釋出版本。
5、測試風險管理
對需求的了解、測試用例設計、測試技術、回歸測試不完全、溝通協調等，很多，不一一細說。
6、測試人員績效考核
測試周期，傳統上劃分為測試計劃、測試設計和測試執行。測試計劃面向測試經理，測試設計和執行面向測試人員。
考核内容包括：
1）工作内容考核
2）工作效率與工作品質考核
3）自動化測試人員效率的度量
自動化測試引入和使用是否合理，測試結果如何等
4）對測試項目負責人效率的度量
比如測試介入時機，測試計劃的合理性，測試跟進情況，等等