测试知识汇总
目錄
軟件測試開發流程
需求分析
評審測試用例
執行測試
提交 Bug 并推動 Bug 解決
回歸測試
編寫并提交測試報告
軟件測試方法
白盒測試
黑盒測試
等價類
?灰盒測試
動態測試
α測試
β測試
冒煙測試
回歸測試
隨機測試
探索測試
為什么引入自動化測試
自動化測試框架包含哪些模塊
基礎模塊
管理模塊
運行模塊
統計模塊
常用的測試框架類型
模塊化測試框架
數據驅動框架
關鍵字驅動框架
混合模型
測試框架設計原則
如何設計一個不錯的測試案例
第一，等價類劃分法
第二，邊界值分析方法
第三，錯誤推測方法
軟件測試開發流程
需求分析
在測試前拿到產品需求文檔，進行需求分析及需求評審前先對需求文檔進行詳細的閱讀，對有疑問的地方進行標注。
具體可從以下進行：
- 分析產品功能點
- 產品核心競爭力
- Kano模型、馬斯洛需求分析、多問幾個為什么、上下文分析法
制訂測試用例（重要）
工欲善其事，必先利其器；對測試而言，測試用例就是器，做好了才能把好關
-
使用思維導圖列舉測試大綱，盡量發散，想到什么就寫什么，；先放后收，對知識點進行總結和歸納，標記重點測試模塊，刪除冗余及重復測試點。
-
可使用邊界值法、等價類劃分法、錯誤推測法、因果圖法等設計案例
-
根據測試大綱制定測試用例，需包含模塊名、測試優先級、操作步驟、期望結果、測試結果、備注
評審測試用例
- 測試作為主導，聯合開發、項目經理、PM進行測試用例評審
- 可先講解測試大綱，讓開發、項目經理、PM心中對測試用例有個大概；后再進行詳細測試用例講解
執行測試
- 根據測試用例執行測試
- 發現問題保留現場，記錄測試方法，通知開發解決問題
- 覆蓋測試用例之外若有時間可進行探索性測試
提交 Bug 并推動 Bug 解決
-
在Bug管理工具上提交Bug，詳細記錄測試步驟
-
根據Bug嚴重程度劃分Bug等級:致命、嚴重、一般、提示
-
推動開發解決問題，記錄問題進展，一般聊天溝通，若問題嚴重則需通過郵件推動解決
回歸測試
-
對已修復的 Bug 進行驗證
-
對 Bug 所在模塊進行基本功能測試；整體進行冒煙測試，確保不會因為修改 Bug 而引起其他功能出現問題
編寫并提交測試報告
可使用金字塔原理設計測試報告，先總后分，上級統領下級，下級推導出上級，環環相扣
-
對Bug進行匯總，篩選出各個等級的Bug存活情況
-
制訂Bug發現及解決曲線圖，一般版本正常應是前期多，后期收斂，存活的是級別較低的Bug
-
總結歸納版本情況，評估發布與否
軟件測試方法
白盒測試
概念：關注程序代碼的具體細節，根據軟件內部代碼的邏輯結構分析來進行測試。主要是通過閱讀程序代碼或者通過使用開發工具中的單步調試來判斷軟件質量。關注代碼的實現細節。主要對程序模塊的所有獨立執行路徑至少測試一遍、對所有的邏輯判定，取“真”或“假”的兩種情況都要測試一遍，循環邊界和運行界限內執行循環體等等
測試用例設計方法：邏輯覆蓋、循環覆蓋、基本路徑覆蓋、判定覆蓋
優點：增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱藏的問題
缺點：系統龐大時測試開銷很大，難以測試所有運行路徑；測試基于代碼，只能驗證代碼是否正確，而不曉得代碼設計是否合理，可能會遺漏某些功能需求
黑盒測試
概念：不考慮其內部結構，即具體代碼實現，檢測軟件的各個功能能否得以實現，確認軟件功能的正確性，依靠軟件說明書來判斷測試用例,關注具體的客戶需求及軟件功能。黑盒測試主要是為了發現：1.是否有不正確的或者遺漏的功能；2.輸入是否能輸出正確的結果；3.性能上是否滿足要求
優點：①較為簡單，不需要了解程序內部的代碼及實現，與軟件內部實現無關；②從用戶角度出發，實際考慮用戶使用的功能及可能出現的問題
缺點：不可能覆蓋所有的代碼，覆蓋率較低
測試用例設計方法：邊界值分析法、等價類劃分、錯誤猜測法、因果圖法、狀態圖法、測試大綱法、隨機測試法、場景法
等價類
輸入域的各子集中，各個輸入數據對于揭露程序中的錯誤都是等效的。
- 等價類劃分：將全部輸入數據合理劃分成若干個等價類，在每一個等價類中取一個數據作為輸入條件，就可以用少量代表性測試數據取得較好的測試結果。分為有效等價類（合理、有意義的輸入數據構成的集合）和無效等價類
- 邊界值分析法：大量錯誤是發生在輸入輸出范圍的邊界上，選定測試用例時應該選取正好等于、剛剛大于、剛剛小于邊界值的值作為測試數據，而不是選取等價類中的任意值，作為對等價類劃分的補充
- 錯誤猜測法：基于經驗和直覺推測，列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據這些情況選擇測試用例
- 因果圖法：考慮輸入條件之間的相互組合，也考慮輸出結果對輸入條件的依賴關系。原因即為輸入條件或者輸入條件的等價類，結果即為輸出條件，把因果轉換為決策表，為決策表中的每一列設計測試用例。
- 場景分析法：根據用戶場景來模擬用戶的操作步驟
- 大綱法：著眼于需求。將需求轉換為大綱的形式，大綱表示為樹狀結構，在根和葉子節點之間存在唯一路徑，大綱為每條路徑定義了一個特殊的輸入條件集合，用于測試用例。
- 隨機測試法：不考慮任何用例和需求，完全站在用戶的角度對產品進行測試
?灰盒測試
關注輸入輸出的準確性，也關注內部的代碼，但是沒有白盒測試那么詳細完整。
動態測試
實際運行被測程序，輸入相應的測試用例，檢查運行結果與預期結果的差異，從而驗證程序的正確性、有效性和可靠性，并且分析系統運行的效率和健壯性。
α測試
一個用戶在開發環境下的受控測試，模擬實際操作環境
β測試
多個用戶在實際使用環境下進行的測試，如一些軟件的公測
冒煙測試
在大規模測試之前，先對軟件的基本、核心、主要功能進行測試，節省資源
回歸測試
開發修正完代碼后再回過頭來做測試
隨機測試
跳出思維的限制，沒有思想、沒有步驟地隨機進行測試
探索測試
有思想，有步驟地測試一些復雜的、不常用地功能
為什么引入自動化測試
自動化測試是將自動化工具和技術應用于軟件測試，旨在減少測試工作，更快，更經濟地驗證軟件質量。有助于以更少的工作量構建質量更好的軟件。
許多公司多多少少都在做自動化測試，但手動測試仍然占主要的比例，因為有些團隊不知道如何在開發過程中更好的利用自動化測試來替代手動測試。
手工測試通常是工程師仔細的執行預定義的測試用例，將執行結果與預期的行為進行手工比較并記錄結果。每次源代碼更改時都會重復這些手動測試，由于都是人為參與，這個過程中很容易出錯。
在組織中引入自動化測試時，需要投入大量財力和時間。 然而，一般沒有太多的財務回報，至少在小規模開始時沒有。 因此許多公司選擇開源測試自動化工具，特別是在開始引入自動化測試的階段。
通常，軟件公司害怕投資自動化測試，不是因為負擔不起這個投入，而是因為他們擔心的回報不會像預期的那樣，或者根本不會產生積極的投資回報率。
1. 降低成本（特別是問題出現時的成本）
如前所述，開始自動化測試的初始成本并不高，比如選用免費的開源工具。 但是，一旦您的組織全面展開自動化測試，您就會希望投資更好的工具、更好的服務器，雇用人力來維護基礎設施等。這些成本絕對不是無關緊要的。
自動化測試不會自動生成。創建有價值的自動化測試需要花費時間和精力，而且不會在一夜之間發生。
如果您想證明引入自動化測試的合理性，不能只關注財務回報，而應考慮應用出現問題導致的隱性成本。例如一個問題在手動測試沒有發現而出現在產品環境中，公司會花多少錢？你是否會失去客戶？需要花多少時間、資源和資金來糾正這種情況？
如果每次對代碼進行更改時，都重復執行一組非常強大的測試套件，可以降低問題出現在產品環境的風險。自動化測試有助于在軟件開發生命周期的早期發現錯誤，從而降低交付故障軟件的風險。
說到底，向市場提供高質量的產品重要性遠大于任何其他類型的節省。
2. 節省時間
雖然初期建立自動化測試需要花費大量的時間和人力，但是一旦自動化測試建立了，您就可以重用這些測試。自動化測試的執行速度明顯快于手動測試，不易出錯，且節省人力。
在日常的代碼修改過程中，您可以在每次提交時執行自動化測試，而不必通過設置環境或記住執行每個測試的步驟來持續執行手動步驟。一切都是自動完成的。
只要首次設置完成后，就可以重復運行你的自動化測試，從而將重復的手動測試時間從數周縮短至數小時。
同樣一旦編寫好，測試可以執行任意次。與手動測試儀不同，測試也可全天候，無人值守的執行。
在軟件開發團隊中，通常的做法是每天多次（通常是每次提交）運行基本單元測試，并且每天在下班后執行耗時的集成測試和UI測試。
3. CI和DevOps
自動化測試構成任何持續集成或DevOps設置的基礎。從本質上講，CI（持續集成）和DevOps都依賴于“Fail fast, Fail early”的理念。對代碼庫的每次提交都將自動進行測試，并將結果報告給開發人員。開發人員優先修復任何導致構建失敗或導致主要測試失敗的錯誤，確保主線代碼始終按預期工作。
4. 準確性和可靠性
由于運行每個測試涉及多個先決條件，手動測試容易出錯。另外每個測試可能需要不同的執行順序。
畢竟手動測試人員是人類，人有不善于執行重復枯燥工作的特點，因此可以預料手動測試不會精確并有一定的幾率出錯。這會導致不準確的結果反饋到開發團隊。
自動化測試每次都執行相同的步驟，不僅精確，而且結果可在最短的時間內提供給所有相關人員。
可靠性的另一個方面是在不同服務器上重新執行相同的測試。這使得能夠快速驗證測試是否在所有服務器上按預期運行，從而排除了服務器配置問題的可能性。
4. 性能測試
性能負載測試可確保您的應用程序可以處理預期和意外的用戶負載。
如果您當前只在項目中使用手動測試方法，則負載測試可能會推遲到開發周期結束。按照敏捷方法和持續集成理念，應及早地進行性能測試，但現實是很大一部分項目團隊執行做這個測試的時間太晚，最終導致產品發布推遲。
自動化性能測試能夠同時運行數千個測試，模擬數百萬用戶，所有這些用戶手動測試幾乎都是不可能的。
5. 增加對軟件的信心
敏捷方法建議使用sprint，即短周期的迭代。每個sprint通常2-3周。這需要一種新的方式來組織測試工作并要求更高的效率。
每個sprint都專注于開發一組小功能，但必須在其結束的時候提供較完整的新功能特性，還包括之前sprint的所有功能特性。如果沒有適當的測試，在不破壞之前正常工作的功能特性的情況下提供全功能系統的風險很高。在每個sprint中反復手動測試所有功能會效率低下。
這也是自動化測試最大的好處。自動化測試并能夠在每個sprint中快速重復測試，可以確保所有事情都按預期工作。
6. 衡量質量指標
可用于自動化測試的擴展和工具提供了測量許多代碼質量指標的功能，例如代碼覆蓋率（即實際測試的代碼百分比），技術債，代碼語義檢查等。
通常，當測試作為持續集成或DevOps工作流程的一部分執行時，可同時獲取這些方面的測量數據。
之所以能夠測量這些指標，是因為自動化測試代碼本身與產品代碼共存，通過在自動構建階段解析源代碼，能提供在幾分鐘內測量巨大代碼庫質量的機會。這在手動測試中根本不可能。
小結
如果您的產品質量是您的首要目標，我強烈建議您使用自動化測試作為日常開發實踐的一部分。它將確保您的應用程序得到正確測試，并為研發、管理人員和客戶提供信心。
自動化測試需要前期投入，并且需要花時間進行開發。這些投入會得到長期的回報：可以減少工作量，消除手動測試的錯誤，提高準確性，最終節省成本和時間。
總的來說，自動化測試是一種比手動測試更快獲得故障反饋的方法，符合“快速失敗，早期失敗”的原則。它有助于實現手動測試無法提供的質量。在自動化測試中，
行為驅動的自動化測試
現已廣泛為研發團隊所接受，基于行為驅動(BDD)的測試腳本具有上手快、易維護、方便所有stakeholders溝通等特點。
如果您還沒有一款合適的自動化測試工具來確保軟件質量，您可以了解
自動化測試框架包含哪些模塊
一個比較成熟的測試框架通常會包含 4 個部分，分別為基礎模塊，管理模塊，統計模塊和運行模塊。
基礎模塊
造房子要穩固需要良好的地基。如果把自動化測試框架比作一輛汽車，那么自動化測試基礎模塊就是那四只輪胎，沒有它們，這輛汽車寸步難行，它們一般包括如下部分。
- 可重用的組件
? ? ? ?一般來說用來降低開發成本，常見有日志模塊，時間模塊等
- 配置文件
? ? ? ?通常會包含測試環境的配置和應用程序的配置。其中測試環境配置用來減少環境版本切換，從開發到上線。
管理模塊
管理模塊就仿佛是車中的內飾，它對測試框架的使用操作體驗有著直接的影響，分為測試數據管理和測試文件管理
- 測試數據管理
測試數據一般是測試用例用到的各種測試數據，他們是為了驗證業務正確性而構造，每一組的測試案例通常會對應一對或多對測試數據。測試數據的創建又分為實時創建和事先創建，
實時創建是測試代碼運行的時候才生成測試數據。好處是測試數據和測試代碼解耦合，測試人員不用關心創建過程和業務調用鏈，通常用在測試的公用功能上。
事先創建，是指測試代碼運行前就準備好的數據文件，其好處是數據拿來即用，幾乎不耗費時間，由于沒有業務調用，所以這在一定程度上減少了調用失敗的風險；壞處則是數據文件本身需要維護，以保持可用性和正確性。
- 測試文件管理
測試文件管理就仿佛是車子的外觀，給人第一印象。一個測試用例通常需要包含三個文件，分別是Page類文件，測試類文件和對象庫文件。
這三個文件共同描述一個完整的測試用例。測試文件的結構清晰有助于他人理解測試框架的設計思想
運行模塊
運行模塊為測試框架的發送機，用于測試用例的組織和運行，通常包含下面幾個部分
-
測試用例調度，驅動機制
-
錯誤恢復機制
測試框架應該具有一定的錯誤恢復機制，測試案例執行過程中，可能出現代碼運行錯誤或環境導致的錯誤。
- 持續集成支持
測試框架應該能夠和 CI 系統低成本集成，包括通過用戶輸入參數指定運行環境、測試結束后自動生成測試報告等。
統計模塊
統計模塊相當于車子的品質和口碑。一個完整的統計模塊，可以告訴你當前測試有沒有 Bug，還能分析軟件質量的變化情況，統計模塊一般包含下面幾個模塊
- 測試報告
測試報告應該全面，包括測試用例條數統計、測試用例成功/失敗百分比、測試用例總執行時間等總體信息。其中，對于單條測試用例，還應該包括測試用例 ID、測試用例運行結果、測試用例運行時間、測試用例所屬模塊、測試失敗時刻系統截圖、測試的日志等信息。
- 日志模塊
測試框架應該包括完善的日志文件，方便出錯時進行排查和定位。
常用的測試框架類型
模塊化測試框架
模塊化測試框架是利用 OOP 思想和 PO 模式改造而來的框架。
模塊化測試框架把整個測試分為多個模塊，模塊化有以下幾個特征：
-
我們將一個業務或者一個頁面成為一個 Page 對象；
-
這個 Page 對象，我們以一個 Page 類來表示它；
-
這個 Page 類里存放有所有這個 Page所屬的頁面對象、元素操作；
-
頁面對象和元素操作組成一個個的測試類方法，供測試用例層調用。
簡單來說，使用了 PO 模式的框架就可以叫作模塊化測試框架。
-
模塊化測試框架的好處在于方便維護，你的測試用例可以由不同模塊的不同對象組成；
-
壞處在于你需要非常了解你的系統及這些模塊是如何劃分的，才能在測試腳本里自如地使用，否則你就會陷入重復定義模塊對象的循環里。
數據驅動框架
數據驅動框架主要是解決測試數據問題。
在測試中，我們常常需要為同一個測試邏輯，構造不同的測試數據以滿足業務需求，這些測試數據可以保存在測試代碼里，也可以保存在外部文件里（包括 Excel、File、DB）。
數據驅動框架的精髓在于，輸入 M 組數據，框架會自動構造出 M 個測試用例，并在測試結果中把每一個測試用例的運行結果獨立展示出來。
在 Python 架構里，最出名的數據驅動框架就是 DDT。
關鍵字驅動框架
當把一系列代碼封裝為要給關鍵字，在測試的過程中，通過組合關鍵字的方式來生成測試用例，而不關心關鍵字如何運作的，這種為關鍵字驅動框架。
混合模型
并不一定要選擇上面的三種框架之一，需要根據需求靈活的選擇測試框架，在工作中可能經常需要糅合不同的框架模型，這樣的模型就叫做混合模型。
測試框架設計原則
- 首先是清晰明了，學習成本低，其中包含代碼規范和模塊清晰明確。
-
通用性強，可維護，可擴展
-
對錯誤的處理能力強
? ? ? ?錯誤處理機制，能高效解決。系統日志清晰，方便調試。
- 運行效率高且功能強大
? ? ??支持測試環境切換，支持外部數據驅動，支持順序并發，遠程運行，報告完備詳盡。
- 支持版本控制和持續集成
? ? ?版本控制回溯復盤，持續集成全局出發
如何設計一個不錯的測試案例
「好的」測試用例一定是一個完備的集合，它能夠覆蓋所有等價類以及各種邊界值，而跟能否發現缺陷無關。
一個“好的”測試用例，必須具備以下三個特征?。
-
整體完備性?：「好的」測試用例一定是一個完備的整體，是有效測試用例組成的集合，能夠完全覆蓋測試需求。
-
等價類劃分的準確性?： 指的是對于每個等價類都能保證只要其中一個輸入測試通過，其他輸入也一定測試通過。
-
等價類集合的完備性?： 需要保證所有可能的邊界值和邊界條件都已經正確識別。
三種最常用的測試用例設計方法： 等價類劃分法、邊界值分析法、錯誤推測方法。
第一，等價類劃分法
我們只要從每個等價類中任意選取一個值進行測試，就可以用少量具有代表性的測試輸入取得較好的測試覆蓋結果?，F在，我給你看一個具體的例子：學生信息系統中有一個考試成績的輸入項，成績的取值范圍是 0~100 之間的整數，考試成績及格的分數線是 60。為了測試這個輸入項，顯然不可能用 0~100 的每一個數去測試。通過需求描述可以知道，輸入 0~59 之間的任意整數，以及輸入 60~100 之間的任意整數，去驗證和揭露輸入框的潛在缺陷可以看做是等價的。那么這就可以在 0~59 和 60~100 之間各隨機抽取一個整數來進行驗證。這樣的設計就構成了所謂的“有效等價類”。
你不要覺得進行到這里，已經完成了等價類劃分的工作，因為等價類劃分方法的另一個關鍵點是要找出所有「無效等價類」 。顯然，如果輸入的成績是負數，或者是大于100的數等都構成了“無效等價類”。
在考慮了無效等價類后，最終設計的測試用例為：
有效等價類1：0~59之間的任意整數；
有效等價類2：59~100之間的任意整數；
無效等價類1：小于0的負數；
無效等價類2：大于100的整數；
無效等價類3：0~100之間的任何浮點數；
無效等價類4：其他任意非數字字符。
第二，邊界值分析方法
邊界值分析是對等價類劃分的補充，你從工程實踐經驗中可以發現，大量的錯誤發生在輸入輸出的邊界值上，所以需要對邊界值進行重點測試，通常選取正好等于、剛剛大于或剛剛小于邊界的值作為測試數據。我們繼續看學生信息系統中“考試成績”的例子，選取的邊界值數據應該包括：-1，0，1，59，60，61，99，100，101。
第三，錯誤推測方法
錯誤推測方法是指基于對被測試軟件系統設計的理解、過往經驗以及個人直覺，推測出軟件可能存在的缺陷，從而有針對性地設計測試用例的方法。** 這個方法強調的是對被測試軟件的需求理解以及設計實現的細節把握，當然還有個人的能力。
錯誤推測法和目前非常流行的“探索式測試方法”的基本思想和理念是不謀而合的，這類方法在目前的敏捷開發模式下的投入產出比很高，因此被廣泛應用。但是，這個方法的缺點也顯而易見，那就是難以系統化，并且過度依賴個人能力。
總結：在我看來，深入理解被測軟件需求的最好方法是，測試工程師在需求分析和設計階段就開始介入，因為這個階段是理解和掌握軟件的原始業務需求的最好時機。
總結
- 上一篇： mysql limit 和 offset
- 下一篇： [测试用例设计]