軟件測試的分類
一.按照測試階段分類：單元測試、集成測試、系統測試、驗收測試
1.單元測試（模塊測試）：
（1）定義
對軟件中的最小的可測試單元進行檢查和驗證的過程（單元：根據實際情況判定）
（2）原則
a.盡可能保證各個測試用例是相互獨立的（無依賴）
b.一般由代碼的開發人員來實施，用以檢驗所開發的代碼功能是否符合設計要求
（3）單元測試的優點
a.盡早發現缺陷（敏捷研發強調TDD測試驅動開發，先編寫單元測試代碼，再編寫功能代碼）
b.為代碼的重構提供保障，快速識別重構時出現問題的點
c.簡化集成（單元測試保證最小單元模塊的穩定性、正確性，為集成測試奠定了基礎）
d.減少文檔的修改
e.用於設計
f.具有回歸性，避免代碼出現回歸
（4）.單元測試的限制
a.不可能覆蓋所有的執行路徑，所以不可能保證捕捉到所有路徑的錯誤
b.每一行的功能代碼需要3~5行的測試代碼才能完成單元測試，所以存在投入和產出的平衡
單元測試框架：XUnit（JUnit、nunit、PHPUnit、Cppunit）
2.集成測試
（1）定義
在單元測試的基礎上，測試在將所有的軟件單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的過程 中各部分工作是否達到或實現相應技術指標及要求的活動（單元測試的基礎上，針對已經完成單元測試模塊，組裝成更高級的模塊和子系統，針對子系統進行集成，測試對象是已經經過單元測試的單元模塊之間的接口）
（2）實施方案（集成方法）
a.Big Bang
b.自頂向下
c.自底向上
d.核心系統集成
e.高頻集成
集成測試與單元測試的區別：測試的對象、依據、方法
3.系統測試
（1）定義
將經過集成測試的軟件作為計算機系統的一個部分，與系統中其他部分結合起來，在實際運行環境下對計算機系統進行的一系列嚴格有效的測試，以發現軟件潛在的問題，保證系統正常運行。（單元測試、集成測試多在模擬環境下運行，系統測試則在真實運行環境中來做，需要功能測試、性能測試、安全測試、穩定性測試等多種類型的測試）
（2）關註點
a.關註系統本身的使用
b.關註系統與其他相關系統間的連通性
c.關註系統在不同使用壓力下的表現
d.關註系統在真是使用環境下的表現
（3）系統測試與集成測試的區別：
a.測試對象（集成測試：由通過了單元測試的各個末班所集成起來的構件
系統測試：除軟件外，還包括計算機硬件及相關的外圍設備、數據采集和傳輸機構、支持軟件、系統操作人員等整個系統）
b.測試時間：集成測試結余單元測試和系統測試之間測試
系統測試在集成測試之後
c.測試內容：集成測試：各個單元模塊之間的接口
系統測試：整個系統完整的功能和性能
d.測試角度：集成測試：偏於技術角度的驗證
系統測試：偏於業務角度的驗證
4.驗收測試
（1）定義
也稱交付測試。針對用戶需求、業務流程的正式的測試，確定系統是否滿足驗收標準，由用戶、客戶或其他授權機構決定是否接受系統
（2）分為：用戶驗收測試、運行驗收測試（從運維角度）、合同和規範驗收測試、alpha測試（在開發者提供的場所或環境中運行，一般由用戶執行）、Beta測試（脫離開發者環境，在用戶提供的場所或環境下進行測試）、release版本 （正式的可供交付的版本）、（敏捷研發理論裏一種驗收測試：驗收測試驅動開發）
二.按照測試的手段分類：黑盒測試、白盒測試、靜態測試、動態測試、手工測試、自動化測試
1.黑盒測試：（也稱功能測試）
（1）定義
不考慮程序內部結構，檢查程序是否滿足需求規格說明書的規定
（2）優點
a.容易實施，不需要關註內部的實現
b.更貼近用戶的使用角度
（3）缺點
a.測試覆蓋率較低，一般只能覆蓋到代碼量的不到40%
b.針對黑盒的自動化測試，復用率較低，維護成本較高
（4）黑盒測試主要測什麽
a.是否有不正確或遺漏的功能
b.在接口上，輸入是否能正確的接受？能否輸出正確的結果？
c.是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？
d.性能是否能夠滿足要求
（5）黑盒測試的主要設計方法：
（等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、正交試驗分析法、狀態遷移圖法、流程分析法）
a.等價類劃分法：針對程序輸入等價的歸成一類，形成若幹典型的代表性的輸入，通過典型的數據進行測試用例的設計
b. 邊界值分析法：特殊的等價類劃分，關註的是邊界條件（數據的區間）
c.錯誤推測法：基於經驗或者直覺來判斷程序中可能出現錯誤的地方從而針對性的設計用例的方法（特殊字符、文件超載）
d.因果圖法：程序需求規格說明書中，針對每一種輸入和輸出，在因果圖中會把輸入和輸出看做原因和結果，對輸入和輸出付以特定的標識符，將這些情況形成因果圖，最終根據規格語義的說明形成判定表，根據判定表，編寫測試用例
e. 正交試驗分析法：通過正交性，從一組數據中篩選出典型的有代表性的數據的設計方法，主要用於篩選輸入數據，然後來設計測試用例的輸入的輸出
f.狀態遷移圖法：通過梳理軟件功能點裏的狀態遷移關系來設計測試用例（狀態遷移：例審批狀態），根據狀態關系設計測試用例
g. 流程分析法：通過梳理程序的邏輯執行的路徑，來設計測試用例
2.白盒測試
（1）定義
內部結構了解，結構化測試/透明盒測試，針對程序的邏輯結構設計測試用例，用邏輯的覆蓋率來衡量測試的完整性，
（2）主要的邏輯單位：語句、條件、條件組合、分支、路徑，不通的邏輯單位有不同的覆蓋方法判定和條件的組合覆蓋
a.語句覆蓋：測試用例設計出來執行以後，會保證程序的每條語句至少執行一次
b.判定覆蓋：保證每個分支至少執行一次
c.條件覆蓋：覆蓋到條件的表達式，所有的表達式至少計算一次
d.條件組合：覆蓋所有各種不同條件的組合情況
e.路徑覆蓋：程序當中每一條可能的路徑會至少執行一次（分支是路徑的一部分）
f.條件和判定的組合覆蓋
（3）優點
a.迫使測試人員去仔細思考軟件的實現，理解原理
b.可以檢測代碼中的每條分支和路徑（覆蓋率）
c.解釋隱藏在代碼中的錯誤
d.對代碼的測試比較徹底
（4）缺點
a.昂貴（覆蓋率高，成本高）
b.無法檢測代碼中遺漏的路徑和數據敏感性錯誤
c.不直接驗證需求的正確性
（5）主要測試方法
a.代碼檢測法、靜態結構分析法、靜態質量度量法、邏輯覆蓋法、基本路徑測試法
b.代碼檢測法：包括多面檢查、代碼審查、走查，主要檢查代碼和設計的執行，對代碼本身檢查
c. 靜態結構分析法：測試者通過使用測試工具來分析源代碼的系統結構、數據結構、內部的控制邏輯，通過這樣的內部 結構的分析來設計測試用例
d.靜態質量度量法：根據標準的質量模型，如ISO的質量標準作為基礎，然後構造質量的度量模型用於評估軟件的各個方面的要素
e.邏輯覆蓋法：6種主要邏輯覆蓋
f. 基本路徑測試法：白盒測試中主要的測試方法，在程序控制流圖的基礎上通過分析控制構造的圈復雜度，到導出基本可執行的路徑的集合，進而設計測試用例的方法
3.灰盒測試
（1）定義
介於黑、白盒測試之間的、關註輸出對於輸入的正確性，同時也關註內部表現（結合了白盒測試、黑盒測試的要素，更多的是在系統組件層評價軟件的應用）
4.靜態測試
（1） 定義
無需執行被測程序、而是通過評審軟件文檔或代碼，度量程序靜態復雜度，檢查軟件是否符合編程標準，借以發現編寫的程序的不足之處，減少錯誤出現的概率
（2）方式
互審、走查、會議（不正式到正式）
5.動態測試
（1）定義
通過運行被測程序，檢查運行結果與預期結果的差異，並分析運行效率、正確性和健壯性等（黑盒測試中多為動態測試法，白盒測試中代碼檢查法、靜態分析法為靜態測試）
6.手工測試：
（1）定義
由專門的測試人員從用戶的視角來驗證軟件是否滿足設計要求的行為，更適合針對深度的測試和強調主觀判斷的測試（例眾包測試、探索式測試）
7.自動化測試
（1）定義
使用單獨的測試工具軟件控制測試的自動化執行以及對預期和結果進行自動化檢查（強調利用第三方的測試工具來控制自動的執行及對預期結果的檢查）
單元測試、接口測試、性能測試等更多的的利用自動化測試
------------------------------------------------------------------------------------------------------------------------------------------------------
手工測試與自動糊測試的區別：
手工測試：
優點：易於發現缺陷、容易實施、創造性、靈活性、覆蓋量化難
缺點：重復測試效率低、不一致性、可靠性低、依賴人力資源
自動化測試：
優點：高效率、速度快、高復用性、覆蓋率容易度量、準確、可靠
缺點：機械、發現缺陷率低、一次性投入大
---------------------------------------------------------------------------------------------------------------------------------------------------------
三.按照測試模式分類：
瀑布模型、敏捷測試、基於腳本的測試、基於風險的測試、探索式測試等
1.傳統的瀑布模型
（1）過程
項目計劃---需求分析----軟件設計---程序開發----軟件測試-----集成維護
（每個階段都是以上一個階段的輸出作為下一個階段的輸入）
a.項目計劃：制定項目總體的研發計劃，確定主要裏程碑節點，此節點輸出項目計劃書，
b.需求分析：明確用戶的需求定義，並對定義進行清晰的描述，是充分理解客戶需求、描述產品功能的重要階段，輸出產品的需求規格書
c.軟件設計：根據需求的定義，確定產品實現的方案，包括定義軟件、硬件的結構，組建模塊的實現方法，接口、界面、數據如何進行組織，此階段輸出概要設計、詳細設計、多分設計說明書
d.程序開發：開發團隊根據需求和設計具體的實現產品，根據編程規範，構建各類的組建模塊，輸出產品版本，
e.軟件測試：獨立的測試小組或QA團隊評估產品是否滿足需求，輸出測試結果、測試報告
f.集成維護：產品經過測試後交付給用戶，根據用戶的使用情況對產品進行維護及必要的修改、升級
（2）優點
強調了需求、設計的作用；前一階段完成後，只需關註後續階段；為項目提供了按階段劃分檢查點，裏程碑清晰；文檔規範
（3）缺點
難以適應需求的頻繁變化；項目周期後段才能看到結果（增加了風險）；強制的裏程碑、完成時間點（適用能力差）；文檔工作量大
2.V模型：瀑布模型的變種
3.W模型（雙V模型）
測試伴隨整個開發周期，基本開發測試時兩個並行的過程，有利於盡早的發現問題，有利於及時了解項目風險，及早的制定相應的應對方案，加快項目的進度，局限性:需求、設計、編碼仍串行，測試、開發保持線性的先後關系，上一階段完成後才能進行下一階段，所以不支持叠代開發，
4.X模型
對V模型的改進，主要解決交接及頻繁集成的周期的問題，左邊描述的是對單獨的程序片段所進行的相互分離的編碼和測試，然後進行頻繁交接，在集成，最終形成可執行程序，再對集成的程序進行測試，
5.H模型
6.敏捷測試（Agile Testing）
遵循敏捷宣言的一種測試實踐
（1）敏捷宣言：
個體與交互重於過程和工具
可用的軟件重於完備的文檔
客戶協作重於合同談判
響應變化重於遵循計劃（後者並非全無價值，但更看重前者）
（2） 特點
a.強調從客戶角度進行測試
b.重點關註叠代測試新功能，不再強調測試階段（傳統測試中嚴格的階段劃分敏捷不強調）
c.盡早測試，不間斷測試，具備條件即測試
d.強調持續反饋（結果、過程、發現的問題都要快速的通知到相關的人員）
e.預防缺陷重於發現缺陷（給研發提出建設性意見、質量改正的建議，全方位參與到軟件研發的各個層面來提升整個團隊的工作效率，保證產品的質量）
敏捷測試VS傳統的測試：
傳統測試：測試是質量的最後保護者、嚴格變更管理、預先的計劃和細節的準備、質量級文檔；各個階段測試嚴格的入口和出口標準；更多在回歸測試時進行重量級的自動化測試；嚴格依賴流程執行；測試團隊和開發團隊是相互獨立的
敏捷測試：開發和測試人員時緊密合作的，大家都有責任對軟件負責；變更是可接受的，擁抱變更；計劃隨著進展時常調整；只需要絕對必要的文檔；各叠代之間已經沒有明顯的入口和出口標準；所有階段都需要自動測試，每個人都需要做，是項目集成的一部分；流程不再需要嚴格執行；團隊合作是無縫隙合作
（規則就是用來被打破的，註重測試結果，持續不斷質量反饋的過程，更加註重團隊的相關角色及時知曉開發過程中的質量現狀並及時改正）
四. 按照軟件測試類型
（功能測試、性能測試、部署測試、文檔測試、安全測試、兼容性測試、易用性測試、本地化測試、無障礙測試、可靠性測試）
1.功能測試
（1）概念
軟件測試中主要的一種測試類型，根據產品的特性、操作描述和用戶方案，測試一個產品的特性和可操作行為以確定他們滿足設計需求
（2） 針對的問題（功能測試關註的問題）
功能錯誤或者遺漏、界面問題、性能錯誤（軟件本身的處理性能，大數據量的加載）、數據及訪問錯誤初始化及終止錯誤
（3）功能測試工具
a.商用功能自動化測試工具：QTP（web應用）、winrunner系列（QTP的前身，主要在桌面化的軟件上面，QTP主要是web應用類的系統上自動化的工具）、silkTest、Rational robot
b.開源自動化測試工具：selenium（流行於敏捷）、Watir（基於web自動化）、Sikuli（基於屏幕截圖，測試腳本基本由截圖構成）
2.性能測試
（1）概念
驗證軟件系統的性能可以滿足需求規格給定的指標要求，（負載測試、壓力測試、穩定性測試等衍生概念）
（2）測試內容
a.負載測試：在測試過程中逐步的增加負載，並且記錄下北側系統相應的性能表現，最終確定出系統在正常的指標範圍下的最大的負載
b.壓力測試：系統在極限情況下的壓力測試，確定系統在什麽樣的負載壓力下會導致系統的失效，確定出系統所能承受的最大極限
c.穩定性測試：稍大於正常業務量的負載，對系統進行持續的長時間的測試，以確定系統在較長運行時間的情況下系統的穩定性
（3）性能指標
a.並發用戶數vu（同一時間訪問系統的用戶數）
b.每秒事物數TPS（每秒鐘系統能夠處理的業務數）
c.系統響應時間（系統響應請求所耗費的時間）
d.設備性能（運行系統的服務器相關資源的性能，如CPU、內存的使用情況、磁盤IO情況、網絡IO情況）
（4）性能測試工具：loadrunner、silkperformer、jmeter、webload、Apache bench（負載生成工具）、loadUI（主要針對http類的接口的性能測試）
（5）靜態性能評估
開發web應用時，基於一系列web應用頁面性能優化的最佳時間對web應用的頁面進行靜態分析，並給出評估結果的性能分析方法
兩種評估標準：YSlow、PageSpeed、
（6）應用性能管理
APM（Application performance management）提供對系統的實時監控以實現性能管理、故障管理的解決方案 （APM產品：聽雲）
3.安全測試
（1）概念
對軟件產品進行測試以確保其符合產品安全需求和質量標準（著重防禦、在防禦面上考慮安全、較滲透測試難）
（2）滲透測試
模擬對軟件系統的惡意攻擊行為來評估系統安全性的一種測試（著重點攻擊攻破系統，證明系統存在問題；選擇點攻破系統）
OWASP:Open Web Application Security Project（www.owasp.org）關註：top 10 、 test guide
（3）安全測試工具
Appscan（針對web應用的漏洞掃描工具）
Webinspect、Nessus（主要針對服務器、主機類的漏洞檢查工具，有免費版本）
Namp（著名的端口嗅探的工具，通過掃描主機看開放了哪些端口可以進行下一步的攻擊）
MetaSploit（非常著名的攻擊框架包含有大量的插件，可通過此框架對目標系統進行檢測、滲透測試）
webscarab（基於代理劫持的分析進行攻擊路徑的檢測）
fortify（白盒測試工具，針對開發的源代碼的靜態的分析，分析出源碼中可能存在的問題）
W3AF（開源，主要在針對web應用）
4.兼容性測試
（1）兼容性分類
軟件本身的兼容性（新開發的版本對歷史版本功能及配置、相應的數據進行兼容）
不同平臺下的兼容（軟件在多個平臺上運行）
軟件對運行設備的兼容性（軟件在不通類型設備上運行）
軟件互操作性
瀏覽器兼容性
（2）瀏覽器兼容性測試工具
BrowserShots（browsershots.org基於真實瀏覽器進行截圖比對的工具）
Browser Sandbox（通過不通插件實現瀏覽器模擬測試）
Google瀏覽器兼容測試插件（http://www.w3help.org/）（從頁面代碼層面對瀏覽器兼容性進行分析）
5.文檔測試
（1）概念
針對軟件產品的交付品，配套的文檔類部件的測試。如用戶手冊、使用說明、用戶幫助文檔等
（2）文檔測試關註點
完整性、正確性、一致性、易理解性、易瀏覽性
6.可靠性測試
軟件系統在規定的時間內或規定的條件下能夠完成規定功能的能力
7.易用性測試
指用戶使用軟件時是否感覺方便，是否能保證用戶使用體驗的測試類型（針對UI)
8.部署測試
主要驗證系統部署過程，並確保軟件經過安裝測試後可以正常使用
9.無障礙測試
Accessibility Test 也稱可訪問性測試，是指軟件需要提供便於特殊人群使用的功能，包括視障、聽障、老年人、身體殘疾用戶等，無障礙測試則是針對這部分功能的測試
五.其他測試
1.基於腳本的測試（SBT）
（Script-based Testing）先做測試設計，再執行測試（script：手工測試中指測試用例，自動化測試中指自動化測試腳本），遵照測試計劃，屬於傳統的測試
2.腳本測試（Scripted Testing）ST
3.探索式測試（Exploratory Testing）ET
（1）定義
探索式測試，完全拋開測試腳本，是一種測試風格、思維而不是一種測試技術
ET 與 ST 互補
ST：系統性強；容易管理、控制；設計在先、執行在後；主要是驗證自己的思路；可預見性
ET：自由靈活；和ST互補；執行和設計（思考）並行；不斷和系統交互，帶著問題測試；對系統深入學習的過程
（2）優點
更能激發測試人員的創造性和工作樂趣，
增加了發現新的或較深入BUG的可能性，
在較短的時間內找到更多的bug以及對SUT（software and test） 做一個快速的評估 ，
有利於更加有效的實施自動化，
更加適用於敏捷項目，
減少了在簡單、繁復上用例的無謂編寫時間，
（3） 缺點
測試管理上有局限性，較難協調和控制
對於bug的重復利用和重現上作用有限，
對測試人員的測試技能和業務知識深度依賴較大，
只有在SUT（被測系統）已完全可用的前提下才更有作用，
ET的生產率很難定義
ET難以進行自動化，更多靠創造性技能來完成
（4）分類
局部探索式測試：從被測系統的五大要素（輸入、狀態、代碼路徑、用戶數據、執行環境）著手
全部探索式測試：漫遊測試法（商業區、旅館區、歷史區、旅遊區、娛樂區、破舊區）
4.基於風險的測試（Risk-based Testing）
（1）概念
一種基於對軟件失效的風險評估並以此指導測試計劃、設計、執行、結果評價的軟件測試類型
（2） 風險有哪些
a. 質量風險：被測系統質量問題（軟件的功能、易用性、性能、軟件功能的缺失、數據轉換導致的問題等），
b.管理風險：人員的技能、項目人力不足，測試環境不具備，被測系統的需求不清晰，被測系統關聯的第三方的系統有問題無法進行聯調，
（3）具體的風險程度可以用風險級別描述：風險級別=風險的可能性*風險的嚴重度
識別風險可能性（復雜性、時間壓力、高變更率、技能水平、地理分散度）
嚴重程度（使用頻率、失效可視性、商業損失、組織負面影響和損害、社會損失和法律責任）
（4） RBT：測試工作量與風險關系、質量信心與測試完成率關系
5. 回歸測試
軟件功能修改後，對軟件進行重新測試以確認修改沒有引入新的錯誤或導致其他部分產生錯誤，測試重點在關鍵模塊、重點功能組件
6. Monkey測試
也稱搞怪測試，用一些隨機、稀奇古怪的方式來操作軟件，以測試系統的健壯和穩定性
7. 冒煙測試
來自於硬件板卡的驗證術語，軟件上則用於確認代碼中的更改是否會按照預期運行，且不會破壞整個版本的穩定性（重點在全流程）
“每日構建”中用冒煙測試來確認合入的代碼沒有影響主要功能的正常
8. AB測試
多用於互聯網行業，通過提供2個版本給用戶使用並記錄相關的用戶行為數據來確定優化設計的一種測試方案
實施要點：多個方案並行、每次測試僅改動一個變量、按照某種規則進行優勝劣汰
A/B測試優點：以真實的數據給網站的更改提供依據
A/B測試工具：Google Analytics Content Experiments （向用戶提供不同的版本後，通過嵌入分析腳本就可以收集到一系列的分析數據）
Visual Website Optiomizer
軟件測試的分類