前言
每個系統的成型，上線都離不開測試，這段時間陸陸續續的學習測試，在這里總結一番；作為學習交流之用；
正文
軟件測試概述
軟件測試的歷史：
什么是軟件測試：
早期定義：軟件測試是對程序能夠按預期運行建立起一種信心。
經典定義：測試是為了發現錯誤而執行程序的過程。
IEEE定義（ISO/IEC/IEEE 29119）：使用人工或者自動的手段來運行或測量軟件系統的過程，以檢驗軟件系統是否滿足規定的要求，並找出與預期結果之間的差異。
軟件測試≠程序測試
五大要素和兩個目標：
五大要素有：質量、人員、資源、流程、技術。
其中最主要的是軟件質量，其他四個要素都是為質量服務的。
其次是人員，決定了技術，資源，流程，以及配置和使用。
技術包含了：軟件測試技術、軟件測試方法、使用的工具。技術是手段。
流程：測試計划，測試用例，測試執行，測試報告。有一些進入進出的標准（規范性，對軟件測試做一個規范的要求）。
資源：測試所需要的硬件設備、網絡環境、測試設備、測試時間（周期）。
注意：人不是資源。
目標：
①提升測試覆蓋率-> 能夠有效的保證軟件的質量
②提升測試效率->能夠使我們更好地完成軟件測試
軟件測試所遵循的原則
一、測試顯示缺陷的存在，但不能證明系統不存在缺陷。
經過軟件測試，可以發現軟件中的故障；但是經過軟件測試，不能保證軟件就沒有故障了。
二、窮盡測試是不可能的，應設定及時終止的條件。
三、測試應該盡早進行
四、缺陷具備群集特性
越是發現問題多的模塊，越是需要重點測試的對象
五、測試的殺蟲劑悖論
在測試中，如果采用同樣的測試用例，同樣的測試方法。多次重復的測試某一個模塊，最后就不能再發現新的缺陷。所以說，測試用例和測試方法應該不定期的評審修改，並且增加不同的測試方法和用例來測試不同的部分，從而更多的發現軟件的缺陷。
六、測試的二八原則
測試時間和資源往往是有限的，要找出所有的缺陷是不可能的，這時我們需要遵循二八原則。
把80%的時間或者資源用在20%的重點模塊上，重點測試模塊中20%的重要模塊。來達到測試效率和資源配置的最佳的比例。
七、測試活動依賴於測試背景
針對不同的測試背景針對的活動是不同的，比如：電信級的軟件對性能、大並發量的訪問會有更高的要求。而金融，銀行系統相關的軟件，對安全性能要求更高。
軟件測試階段，手段，模式
按測試階段來分類
單元測試、繼承測試、系統測試、驗收測試
單元測試
什么是單元測試
對軟件中的最小可測試單元進行檢查和驗證
單元測試的原則：
1.盡可能保證各個測試用例是相互獨立的；
2.一般由代碼的開發人員來實施，用以檢驗所開發的代碼功能符合自己的設計要求。
單元測試的益處：
1.能盡早發現缺陷；收益最高；
2.有利於重構；
3.簡化集成；
4.文檔；
5.用於設計；
單元測試的限制
1.不可能覆蓋所有的執行路徑，所以不可能保證捕捉到所有路徑的錯誤；
2.每一行代碼，一般需要3-5行測試代碼才能完成單元測試。所以存在投入和產出的一個平衡；
單元測試框架：
Xunit，JUnit，nunit，PPUnit，CppUnit
集成測試：
定義:
在單元測試的基礎上，測試在將所有的軟件單元按照概要設計規格說明的要求組裝成模塊、子系統或系統過程中各部分工作是否達到或實現相應技術指標及要求的活動
集成測試的主要實施方案
1.Big Bang 全部完成，測試
2.自頂向下
3.自底向上 從最低層測試，逐步組裝測試；（常用測試）
4.核心系統集成
5.高頻集成
集成測試&單元測試
1.測試的對象不同；
2.測試的一舉不同；
3.測試的方法不同；
系統測試
定義：是將經過集成測試的軟件，作為計算機系統的一個部分，系統中其他部分結合起來，在實際運行環境下對計算機系統進行的一系列嚴格有效的測試，以發現軟件潛在的問題，保證系統的正常運行。
關注點
關注系統本身的使用
關注系統與其他相關系統間的連通
關注系統在不同使用壓力下的表現
關注系統在真實使用環境下的表現
系統測試&集成測試
測試環境：
集成測試：由通過了單元測試的各個模塊所集成起來的構件
系統測試：除了軟件之外，還包括計算機硬件及相關的外圍設備、數據采集和傳輸機構、支持軟件、系統操作人員等整個系統；
測試時間：
集成測試介於單元測試和系統測試之間測試
系統測試在集成測試之后
測試內容：
集成測試：各個單元模塊之間的接口
系統測試：整個系統的功能和性能
測試角度：
集成測試：偏向於技術角度的驗證
系統測試：偏向於業務角度的驗證
驗收測試
定義：也稱交付測試，針對用戶需求、業務流程的正式的測試，確定系統是否滿足驗收標准，由用戶、客戶、或其他授權機構決定是否接受系統。
細分
用戶驗收測試
運行驗收測試
合同和規范驗收測試
alpha測試
Beta測試
按測試手段來分類：
黑盒測試、白盒測試
靜態測試、動態測試
手工測試、自動化測試
黑盒測試
定義：把程序看作一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。主要針對軟件界面和軟件功能進行測試。
圖例：
優點：
1.容易實施，不需要關注內部的實現
2.更貼近用戶的使用角度
缺點：
1.測試覆蓋率角度，一般只能覆蓋到代碼量的不到40%；
2.針對黑盒測試的自動化測試，復用率較低，維護成本較高；
關注點：
1.是否有不正確或者遺漏的功能？
2.在接口上，輸入是否能正確的接受？能否輸出正確的結果？
3.是否有數據結構錯誤或者外部信息(例如數據文件)訪問錯誤？
4.性能上是否能夠滿足要求?
黑盒測試的主要設計方法
白盒測試
定義
白盒測試又稱結構測試、透明盒測試、邏輯驅動測試或基於代碼的測試。白盒測試是一種測試用例方法，盒子指的是被測試的軟件，白盒指的是盒子是可視的，你清楚盒子內部的東西以及里面是如何運作的。"白盒"法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。"白盒"法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯着手，得出測試數據。貫穿程序的獨立路徑數是天文數字。
圖示：
優點：
1.迫使測試人員去仔細思考軟件的實現，理解原理
2.可以檢測代碼中的每一條分支和路徑
3.揭示隱藏在代碼中的錯誤
4.對代碼的測試比較徹底
缺點：
1.昂貴
2.無法檢測代碼中遺落的路徑和數據敏感性錯誤
3.不能直接驗證需求的正確性
主要測試方法：
靜態測試
定義:
靜態測試是指無須執行被測程序，而是通過評審軟件文檔或代碼，度量程序靜態復雜度，檢查軟件是否符合編碼標准，借以發現編寫的程序的不足之處，減少錯誤出現的概率；
方式：
動態測試
定義：
動態測試時指通過運行被測程序，檢查運行結果與預期結果的差異，並分析運行效率，正確性和健壯性等；
手動測試
定義：
由專門的測試人員從用戶視角來驗證軟件是否滿足設計要求的行為。更適用針對深度的測試和強調主管判斷的測試。
方法：眾包測試，探索式測試
自動化測試：
定義：使用單獨的測試工具軟件控制測試的自動化執行以及對預期和結果進行自動檢查。
方法：單元測試，接口測試，性能測試等
手工測試VS自動化測試
按測試模式來測試來分類
瀑布模型、敏捷測試、基於腳本的測試、基於風險的測試、探索式測試等
傳統瀑布模型
瀑布模型的優缺點
V模型
W模型
X模型
H模型
敏捷測試
Agile Testing --遵循敏捷宣言的一種測試實踐
敏捷宣言
關注點：
強調從客戶角度進行測試
重點關注迭代測試新功能，不在強調測試階段
盡早測試，不間斷測試，具備條件即測試
強調持續反饋
預防缺陷重於發現缺陷
敏捷測試VS傳統測試
探索式測試（ET）
完全拋開測試腳本的測試
它是一種測試風格、思維而不是一種技術
優點：
更能激發測試人員的創造性和工作樂趣
增加了發現新的或較深入Bug的可能性
在較短時間內找到更多Bug以及對SUT作一個快速的評估
有利於更加有效地實施自動化
更加適用於敏捷項目
減少了在簡單、繁復上用例的無謂編寫時間
測試管理上有局限性，較難協調和控制
對於Bug的重復利用和重現上作用有限
對測試人員的測試技能和業務知識深度依賴較大
只有在SUT已完全可用的前提下才更有作用
ET的生產率很難定義
ET本身較難進行自動化
局部探索式測試
輸入、狀態、代碼路徑、用戶數據、執行環境
全局探索式測試
探索式測試的流程
基於風險的測試-RBT
Risk-based Testing
一種基於對軟件失效的風險評估並以此指導測試計划、設計、執行、結果評估的軟件測試類型
那些是風險？
質量風險、管理風險
風險級別=風險可能性X風險嚴重度
未完待續。。
歡迎大家關注公眾號，不定時干貨，只做有價值的輸出
作者：Dawnzhang
出處：https://www.cnblogs.com/clwydjgs/p/9390488.html
版權：本文版權歸作者
轉載：歡迎轉載，但未經作者同意，必須保留此段聲明；必須在文章中給出原文連接；否則必究法律責任