JB的閱讀之旅-軟件測試52講（上）

說明

因掘金一文章不能超過2W字，所以分開上下篇；

前言

本文閱讀來自極客，課程連接以下： time.geekbang.org/column/103

做者：茹炳晟

我的感想

先把我的感想列出來吧，全文很長，耐心看，可能要20分鐘+，部份內容會比較詳，閱讀體驗可能會比較差，由於都是文字爲主；

總的來講，這個課程值這個價格，看完了以後，以爲知識面廣了不少，不必定對實際工做有用，可是用來擴展知識面，是一個很不錯的課程，同時也瞭解其餘企業是怎麼作的，建議小夥伴都看一下；

經過這個課程目錄，其實也能夠看得出，不少大公司的測試工程師，並不帶帶是業務測試，具有開發能力是必要條件，由於也但願能給本身一個警戒；

若是非要推薦，第5章的自動化測試工具跟35章的數據構建值得一看，裏面的內容很豐富；

這個課程，陸陸續續看了很久，看的很認真，包括評論都不放過，所以看到有意思的評論，都會貼出來；

下面的內容都是親手打出來的，由於jb依然相信，本身寫/打出來的東西，印象會加深~

做者的軟件測試修煉之道

經歷過的變革：

• 自動化測試用例設計與開發
• 測試框架選型
• 測試框架自行研發
• 測試框架架構設計
• 測試服務化

趨勢總結：

• 自動化測試在軟件質量工程中的地位發生了質的變化，從原來的已自動化測試爲輔，但如今以自動化測試爲主
• 產品迭代週期縮短，須要一套完善的高併發測試執行基礎架構支持
• 合格的測試工程師關注的是純粹的測試，優秀的測試工程師關心的是總體交付的質量
• 如何構建低維護成本，能夠靈活組裝的自動化腳本，涉及到分層設計模型

1）真的懂測試嗎？從用戶登陸測試談起

測試場景

輸入用戶名和密碼，點擊確認按鈕，驗證是否登陸成功便可

最經常使用黑盒測試方法

等價類劃分

將全部可能的輸入數據劃分紅若干個子集，在每一個子集中，若是任意一個輸入數據對於揭露程序中潛在錯誤都具備同等效果，這樣的子集就構成一個等價類；

邊界值分析

是選取輸入、輸出的邊界值進行測試； 簡單描述就是正好等於、剛剛大於、剛剛小於；

邊界值算是對等價類劃分的補充

窮盡測試

指包含了軟件輸入值和前提條件全部可能組合的測試方法，徹底窮盡測試的系統裏應該不殘留任何未知的軟件缺陷；

但這種作法不實際，由於受時間成本，通常採用基於風險驅動的模式，有所側重地選擇測試範圍和設計測試用例；

顯式功能性測試用例

顯式功能性需求指的是軟件自己須要實現的功能；

基於等價類劃分和邊界值分析方法：

輸入已註冊的用戶名和正確的密碼，驗證是否登陸成功；
輸入已註冊的用戶名和不正確的密碼，驗證是否登陸失敗，而且提示信息正確；
輸入未註冊的用戶名和任意密碼，驗證是否登陸失敗，而且提示信息正確；
用戶名和密碼都爲空，驗證是否登陸失敗，而且提示信息正確；
用戶名額密碼二者之一爲空，驗證是否登陸失敗，而且提示信息正確；
若是登陸功能啓用了驗證碼功能，在用戶名和密碼正確的前提下，輸入正確的驗證碼，驗證是否登錄成功；
若是登陸功能啓用了驗證碼功能，在用戶名和密碼正確的前提下，輸入錯誤的驗證碼，驗證是否登錄失敗，而且提示信息正確；
複製代碼

其餘場景用例：

用戶名和密碼是否大小寫敏感；
頁面上的密碼框是否加密顯示；
後臺系統建立的用戶第一次登錄成功時，是否提示修改密碼；
忘記用戶名和忘記密碼的功能是否可用；
前端頁面是否根據設計要求限制用戶名和密碼長度；
若是登錄功能須要驗證碼，點擊驗證碼圖片是否能夠更換驗證碼，更換後的驗證碼是否可用；
刷新網頁是否會刷新驗證碼；
若是驗證碼具備時效性，須要分別驗證時效內和時效外驗證碼的有效性；
用戶登陸成功可是會話超時後，繼續操做是否會重定向到用戶登陸界面；
不一樣別的用戶，好比管理員用戶和普通用戶，登陸系統後的權限是否正確；
頁面默認焦點是否認位在用戶名的輸入框裏；
快捷鍵Tab和Enter等，是否能夠正常使用；
網絡延遲或者弱網或者切換網絡或者斷網時正常登錄是否正常
是否支持第三方登錄；
是否可記住密碼，記住的密碼保存是否加密；
記住密碼是否有有效期，過時以後是否會清空密碼；
用戶名密碼是否支持特殊字符和中文；
是否能夠使用登陸的api發送登陸請求，並繞開驗證碼校驗；
是否能夠用抓包工具抓倒的請求包直接登陸；
截取到的token等信息，是否能夠在其餘終端上直接使用，繞開登陸；
後端是否有校驗內容的格式長度；
登陸後輸入登陸URL，是否還能再次登陸；
登陸錯誤後的提示是否有安全隱患；
密碼強弱型校驗；
空和輸入空字符串的校驗是否一致；
安全性方面異地登陸校驗、更換設備登陸校驗；
設備互斥；
密碼錯誤限制次數；
輸入帳號密碼時對鍵盤格式是否有要求；
密碼一欄是否須要設置明暗碼切換按鈕；
輸入帳號密碼格式不規範時是否將按鈕設置爲不可點擊；
輸入欄是否設置快速刪除按鈕；
多設備多平臺同帳號登陸是否有互踢機制；
修改密碼後，前密碼不生效；
用戶名規則、密碼規則；
先後臺切換，橫豎屏切換；
複製代碼

非功能性需求

主要涉及安全性、性能和兼容性測試；

安全性測試用例：

用戶密碼後臺存儲是否加密；
用戶密碼在網絡傳輸過程當中是否加密；
密碼是否具備有效期，密碼有效期到期後，是否提示須要修改密碼；
不登陸的狀況下，在瀏覽器中直接輸入登陸後的url地址，驗證是否會重定向到用戶登陸頁面；
密碼輸入框是否不支持複製和粘貼；
密碼輸入框內輸入的密碼是否均可以在頁面源碼模式下被查看；
用戶名和密碼的輸入框中分別輸入典型的SQL注入攻擊字符串，驗證系統的返回頁面；
用戶名和密碼的輸入框中分別輸入典型「XSS跨站腳本攻擊」字符串。驗證系統行爲是否被篡改；
連續屢次登陸失敗狀況下，系統是否會阻止後續的嘗試以應對暴力破解；
同一用戶在同一終端的多種瀏覽器上登陸，驗證登陸功能的互斥性是否符合設計預期
同一用戶前後在多臺終端的瀏覽器上登陸，驗證登陸是否具備互斥性；
用戶登錄後存儲在數據庫中的用戶我的信息是否加密；
用戶登錄過程當中log中是否有我的信息明文打印；
是否使用到緩存；
複製代碼

性能壓力測試用例：

單用戶登陸的響應時間是否小於3秒；
單用戶登陸時，後臺請求數據是否過多；
高併發場景下用戶登陸的響應時間是否小於5秒；
高併發場景下服務端監控指標是否符合預期；
高集合點併發場景下，是否存在資源死鎖和不合理的資源等待；
長時間大量用戶連續登陸和登出，服務器端是否存在內存泄露；
同時支持10個用戶登陸，同時9個或者11個用戶登陸是否正確或者提示信息正確；
複製代碼

兼容性測試用例：

不一樣瀏覽器下，驗證登陸頁面的顯示以及功能正確性
相同瀏覽器的不一樣版本下，驗證登陸頁面的顯示以及功能正確性
不一樣移動設備終端的不一樣瀏覽器下，驗證登陸頁面的顯示以及功能正確性
不一樣分辨率的界面下，驗證登陸頁面的顯示以及功能正確性
複製代碼

小結

1）用例設計須要考慮明確的顯示功能性需求，還要考慮兼容性、安全性、性能等一系列的非功能性需求；

2）用例設計是不可窮盡的，受限於時間成本，所以須要兼顧缺陷風險和研發成果之間的平衡；

2）如何設計一個「好的」測試用例

可以覆蓋全部等價類以及各類邊界值的用例都是好用例；

好的測試用例必須具有的特徵

總體完備性

是一個完備的總體，是有效測試用例組成的集合，可以徹底覆蓋測試需求；

等價類劃分的準確性

對於每一個等價類都能保證只要其中一個輸入測試經過，其餘輸入也必定測試經過；

等價類和的完備性

保證全部可能的邊界值和邊界條件都已經正確識別；

3種最經常使用測試用例設計方法

等價類劃分

等價類中任意一個輸入數據對於揭露程序中潛在錯誤都具備同等效果；

成績系統，取值範圍0-100之間的整數，及格60分；
有效等價類：
	0-59之間的任意整數；
	59-100之間的任意整數；
無效等價類：
	小於0的負數；
	大於100的整數；
	0-100之間的任何浮點數；
	其餘恩義非數字字符；
複製代碼

邊界值分析

成績系統：-一、0、一、5九、60、6一、9九、100、101
複製代碼

錯誤推測方法

指基於對被測試軟件系統設計的理解、過往經驗以及我的直覺，推測出軟件可能存在的缺陷，從而有針對性地設計測試用例的方法，相似於探索性測試；
複製代碼

如何才能設計出好的測試用例

在具體的用例設計時，首先須要搞清楚每個業務需求所對應的多個軟件功能需求點，而後分析出每一個軟件功能需求點對應的多個測試需求點，再針對每一個測試需求點設計測試用例；

2個關鍵點：

• 從軟件功能需求出發，全面地、無遺漏地識別出測試需求
• 對於每一個測試需求點，須要綜合運用等價類劃分、邊界值分析和錯誤推測方法來全面設計用例

用例設計的其餘經驗

只有深刻理解被測試軟件的架構，才能設計出更好的測試用例，去發現系統邊界值以及潛在缺陷；

必須深刻理解被測軟件的設計和實現細節，深刻理解軟件內部的處理邏輯；

須要引入需求覆蓋率和代碼覆蓋率來衡量測試執行完備性；

小結

1）好的測試用例必定是一個完備的集合，可以覆蓋全部等價類以及各類邊界值； 大部分狀況是採用過後的角度，從漏測率和問題嚴重程度來評估用例的好壞；

2）設計而是用例的方法有不少種，但綜合運用等價類劃分、邊界值分析和錯誤推測方法，能知足絕大多數的需求； 需求合理性測試，即用戶體驗測試；

3）好的測試用例再設計時，須要從軟件功能需求出發，全面、無遺漏的識別出測試需求；

4）想設計好一個好的測試用例，必需要深刻理解被測軟件的架構設計，深刻軟件內部的處理邏輯，而且使用需求覆蓋率和代碼覆蓋率來衡量測試執行的完備性；

3）什麼是單元測試？如何作好單元測試

什麼是單元測試

單元測試是指，對軟件中的最小可測試單元在與程序其餘部分相隔離的清空下進行檢查和驗證的工做，這裏的最小和測試單元一般是指函數或者類；

單元測試通常以自動化的方式執行，在大量回歸測試的場景下更能帶來高收益；

電視機的生成、測試和軟件的開發、測試對比：

電子元器件就像是軟件中的單元，一般是函數或者類，對單個元器件的測試就像是軟件測試中的單元測試；
組裝完成的功能電路板就像是軟件中的模塊，對電路板的測試就像是軟件中的集成測試；
電視機所有組裝完成就像是軟件完成了預發佈的版本，點司機所有組裝完成後的開機測試就像是軟件中的系統測試；
複製代碼

如何作好單元測試

概念

單元測試的對象是代碼；

單元測試的主要手段有驅動代碼、樁代碼、mock代碼；

手段

代碼的基本特徵與產生錯誤的緣由：

• 條件分支、循環處理和函數調用
• 若是有任何一個分類遺漏、分類錯誤、分類沒有正確沒有遺漏，但處理邏輯錯誤，都會產生缺陷
• 若是要實現正確的功能邏輯，會有哪幾種正常的輸入
• 是否有須要特殊處理的多種邊界輸入
• 各類潛在非法輸入的可能性以及如何處理

單元測試用例詳解

通常狀況下，單元測試的用例是一個輸入數據和預計輸出的集合；

在明確了代碼須要實現的邏輯功能基礎上，什麼輸入，應該產生什麼輸出；

輸入數據：

被測試函數的輸入參數
被測試函數內部須要讀取的全局靜態常量
被測試函數內部須要讀取的成員變量
函數內部調用子函數得到的數據
函數內部調用子函數改寫的數據
嵌入式x系統中，在中斷調用時改寫的數據
複製代碼

預計輸出：

被測試函數的返回值
被測試函數的輸出參數
被測試函數所改寫的成員變量
被測試函數所改寫的全局變量
被測試函數中進行的文件更新
被測試函數中進行的數據庫更新
被測試函數中進行的消息隊列更新
複製代碼

驅動代碼，樁代碼和mock代碼

驅動代碼是用來調用被測函數的；

驅動模塊一般包括調用被測函數前的數據準備、調用被測函數以及驗證相關結果三個步驟；

樁代碼和mock代碼是用來代替被測函數調用的真實代碼；

樁代碼是用來代替真實代碼的臨時代碼；

樁函數內部實現：

• 樁代碼的應用首先起到隔離和補齊的做用，使被測代碼可以獨立編譯、連接、並獨立容許
• 樁函數要具備與原函數徹底相同的原形，僅僅是內部實現不一樣，這樣測試代碼才能正確連接到樁函數
• 用於實現隔離和補齊的樁函數比較簡單，只需保持原函數的聲明，加一個空的實現，目的是經過編譯連接
• 實現控制功能的樁函數是應用最普遍的，要根據測試用例的須要，輸出合適的數據做爲被測函數的內部輸入

mock代碼跟樁代碼很是相似，都是用來代替真實代碼的臨時代碼；

mock跟樁代碼的本質區別-測試期待結果的驗證：
對於mock代碼來講，關注點是mock方法有沒有被調用，以什麼樣的參數被調用，被調用的次數，以及多個mock函數的前後調用順序；
複製代碼

對於樁代碼，關注點是利用stub來控制被測函數的執行路徑，不會去關注stub是否被調用以及怎麼樣被調用；

實際項目中如何開展單元測試

並非全部的代碼都要進行單元測試，一般只有底層模塊或者核心模塊的測試中才會採用單元測試；

須要肯定單元測試框架的選型：

• Java，junit和TestNG
• C/C++，CppTestParasort C/C++test

引入代碼覆蓋率：

• Java，jacoco
• JavaScript，Istanbul

執行單元測試、代碼覆蓋率統計和持續集成流水線； 確保每次代碼提交都會自動觸發單元測試；

開展單元測試可能會遇到的問題

精密耦合的代碼難以隔離；
隔離後編譯連接運行困難；
代碼自己的k可測試性較差，一般代碼的可測試性和代碼規模成正比；
沒法經過樁代碼直接模擬系統底層函數的調用；
代碼覆蓋率越日後越難提升；
複製代碼

小結

1)介紹了單元測試概念，討論了用例的組成，以及實際項目中開發單元測試的方法;

2)開展過程須要注意3個問題:

• 代碼要作到功能邏輯正確，必須作到分類正確而且完備無遺漏，同時每一個分類的處理邏輯必須正確;
• 單元測試是對軟件中的最小和測試單元在與軟件其餘部分相隔離的狀況下進行的代碼級別;
• 樁代碼起到了隔離和補齊的做用，使被測代碼可以獨立編譯、連接，並運行;

4）爲何要作自動化測試？什麼樣的項目適合作自動化測試

什麼是自動化測試

把人對軟件的測試行爲轉化爲由機器執行測試行爲的一種實踐；

本質就是寫一段代碼，而後去測試另一段代碼； 實現自動化測試用例自己屬於開發工做，還須要隨着被測對象的改變而不斷更新，維護用例成本；

當自動化用例維護成本高於其節省的測試成本時，自動化測試失去了價值；

爲何須要自動化測試

優點

• 自動化測試能夠替代大量的手工機械重複性操做，測試工程師能夠把更多的時間花在更全面的用例設計和新功能的測試上；
• 自動化測試能夠大幅提高迴歸測試的效率，很是適合敏捷開發過程；
• 自動化測試能夠更好的利用無人值守時間，去更頻繁的執行測試，特備適合如今非工做時間執行測試，工做時間分析失敗用例的工做模式；
• 自動化測試能夠高效實現某些受共呢個測試沒法完成或者代價巨大的測試類型，好比關鍵業務7X24小時持續運行的系統穩定性測試和高併發場景的壓力測試等；
• 自動化測試還能夠保證每次測試執行的操做以及驗證的一致性和可重複性，避免認爲的遺漏或疏忽；

劣勢

• 自動化測試並不能取代手工測試，只能替代手工測試中執行頻率高、機械化的重複步驟；
• 自動測試遠比手動測試脆弱，沒法應對被測系統的變化； 自動化測試並非全能，只是循序漸進的執行事先定義好的測試步驟並驗證結果；
• 自動化測試用例的開發工做量遠大於單純的手工測試 只有當開發完成的測試用例的有效執行次數大於等於5次時，才能收回自動化測試的成本；
• 手動測試發現的缺陷數量一般比自動化測試的要多；
• 測試的效率很大程度上依賴自動化測試用例的設計以及實現質量；
• 實行自動化測試的初期，用例開發效率一般都很低；
• 業務測試專家和自動化測試專家一般是兩批人，前者懂業務不懂技術，後者懂技術不懂業務，須要二者配合；
• 自動化測試開發人員必須具有必定的編程能力；

什麼樣的項目適合自動化測試

• 需求穩定，不會頻繁變動；
• 研發和維護週期長，須要頻繁執行迴歸用例；
• 須要在多種平臺上重複運行相同測試的場景；
• 某些測試項目經過手工測試沒法重現，或者成本高；
• 被測軟件的開發較爲規範，可以保證系統的可測試性；
• 測試人員已經具有必定的編程能力；

小結

1）自動化測試是，把人工對軟件的測試轉化爲由機器執行測試行爲的一種實踐，能夠把測試工程師從機械重複的測試工做中解脫出來，將更多的經歷放在新功能的測試和更全面的測試用例設計上；

2）自動化測試是一把雙刃劍，必定程度上解放測試工程師的勞動力，完成一些人工沒法實現的測試，但並不是萬能；一旦維護成本高於節省的測試成本，自動化就不合適了；

5）你知道軟件開發各階段都由哪些自動化測試技術嗎

單元測試自動化技術

單元測試自己就是自動化測試，由於它根據軟件詳細設計採用等價類劃分和邊界值分析方法來設計測試用例，在測試代碼段實現後再以自動化的方式統一執行；

廣義上講，單元測試階段的自動化內涵不只僅指測試用例執行的自動化，還應該包含如下5個方面：

• 用例框架代碼生成的自動化；
• 部分測試輸入數據的自動化生成；
• 自動樁代碼的生成；
• 被測代碼的自動化靜態分析；
• 測試覆蓋率的自動統計與分析；

用例框架代碼生成的自動化

有些框架代碼是由自動化工具生成的，而並不是手工完成的，這樣，開發者就能夠把更多的精力放在測試邏輯的覆蓋和測試數據的選擇上；

好比selenium的代碼能夠經過錄制生成，TestNG框架代碼由自動化工具生成；

部分測試輸入數據的自動化生成

這部分是指，自動化工具可以根據不一樣變量類型自動生成測試輸入數據；

自動樁代碼的生成

自動樁代碼的生成是指自動化工具能夠對被測試代碼進行掃面分析，自動爲被測函數內部調用的其餘函數生成可編程的樁代碼，並提供基於測試用例的樁代碼管理機制；

那什麼是抽樁？在單元測試階段，假如函數A內部調用的函數B是樁代碼，那麼在代碼級集成測試階段，但願函數A再也不調用假的函數B，而是調用真是的函數B，這個用真實函數B代替本來樁代碼函數B的操做，就成爲抽樁；

被測代碼的自動化靜態分析

靜態分析主要指代碼的靜態掃描，目的是識別出違反編碼規則或編碼風格的代碼；

一般這部分工做是結合項目具體的編碼規則和編碼風格，由自動化工具經過內建規則和用戶自定義規則自動化完成的；

經常使用的靜態代碼分析工具備Sonar和Coverity；

測試覆蓋率的自動統計與分析

單元測試用例執行結束後，自動化工具能夠自動統計各類測試覆蓋率，包括代碼行覆蓋率、分支覆蓋率、MD/DC覆蓋率等；

這些自動統計的指標，能夠幫助衡量單元測試用例集合的充分性和完備性，並能夠爲你增補測試用例以提升測試覆蓋率的依據；

代碼級集成測試的自動化技術

簡單的說，代碼級集成測試是指將已經開發完成的軟件模塊放在一塊兒測試；

代碼級集成測試與單元測試最大的區別是，代碼級集成測試中被測函數內部調用的其餘函數必須是真實的，不容許使用樁代碼代替，而單元測試仲容許使用樁代碼來模擬內部調用的其餘函數；

Web Server測試的自動化技術

Web Server測試，主要是指SOAP API和REST API這兩類API測試，最典型的是採用SoapUI和Postman等相似的工具；

但這類測試工具基本都是界面操做手動發起requests並驗證response，因此難以和CI/CD集成，因而乎就出現了API自動化測試框架；

若是採用API自動化測試框架來開發測試用例，那麼這些測試用例的表現形式就是代碼，以下：

對於基於代碼的API測試用例，一般包含3個步驟：

• 準備API調用時須要的測試數據；
• 準備API的調用參數併發起API的調用；
• 驗證API調用的返回結果；

目前最流行的API自動測試框架是REST Assured，能夠方便的發起Restful API調用並驗證返回結果；

一樣的，Web Server的自動化測試內涵不只僅包括API測試用例執行的自動化，還包括如下幾個方面：

• 測試腳手架代碼的自動化生成；
• 部分測試輸入數據的自動生成；
• response驗證的自動化；
• 基於SoapUI或者Postman的自動化腳本生成；

測試腳手架代碼的自動化生成

在開發API測試的過程當中更加關心的是，如何設計測試用例的輸入參數以及組合，以及在不一樣參數組合狀況下response的驗證；

這時候就須要測試腳手架代碼的自動生成技術； 生成的測試腳手架代碼包含被測試API的調用、測試數據與腳本的分離，以及response驗證的空實現；

部分測試輸入數據的自動生成

與單元測試的輸入數據的自動化生成相似，惟一不一樣的是，單元測試針對的參數是函數輸入參數和函數內部輸入，而API測試對應的是API的參數以及API調用的Payload；

數據生成的原則一樣遵循邊界值原則；

response驗證的自動化

對於API調用返回結果的驗證，比較關注的點是返回狀態碼、Scheme結構以及具體的字段值；

核心思想是自動化比較兩次相同API調用的返回結果，並自動識別出有差別的字段值，比較過程能夠經過規則配置去掉諸如時間戳、會話ID(Session ID)等動態值；

基於SoapUI或者Postman的自動化腳本生成

SoapUI或者Postman都是單一調試，累積到必定程度，裏面會有大量測試用例集，若是引入基於代碼實現的API測試框架，這意味着這些大量的用例都須要用代碼的方式重寫一遍，這是很是噁心的；

建議是，開發一個自動化代碼轉換生成工具，這個工具的輸入是SoapUI或者Postman的測試用例元數據（JSON文件），輸出是符合API測試框架規範的基於代碼實現的測試用例，好處是原來積累的用例能夠直接轉換成在CI/CD上能夠直接接入的自動化測試用例；

新增的用例，能夠在SoapUI或者Postman測試驗證，沒問題，直接轉化成符合API測試框架規範的測試用例；

postman集成CICD，經過Postman+newman+jenkins，在Postman導出一個json文件，在另外一個服務器部署newman，命令行執行Postman導出的json文件，而後直接在服務器用newman工具就能測試並生成測試報告；

robot framework+requestslibrary的方式來作API自動化測試，識別編程能力不強的團隊；

GUI測試的自動化技術

核心思想是基於頁面元素識別技術，對頁面元素進行自動化操做，以模擬實際終端用戶的行爲並驗證軟件功能的正確性；

• 對於傳統Web瀏覽器的GUI自動化測試，業內主流的開源方案採用Selenium,商業方案採用Micro Focus的UFT（前身是HP的QTP）；
• 對於移動端原生應用，一般採用主流的Appium它對IOS環境集成了XCUITest，對Android環境集成了UIAutomator和Espresso；

小結

介紹了軟件研發生繆功能週期各個階段的自動化測試技術，包括單元測試、代碼級集成測試、Web Service測試和GUI測試的自動化技術；

6）你真的懂測試覆蓋率嗎

測試覆蓋率一般被用來衡量測試的充分性和完整性，從廣義的角度來說，測試覆蓋率主要分爲兩大類： 面向項目的需求覆蓋率和技術的代碼覆蓋率；

需求覆蓋率

需求覆蓋率是指測試對需求的覆蓋程度，一般的作法是將每一條分解後的軟件需求和對應的測試簡歷一對多的映射關係，最終目標是保證測試能夠覆蓋每一個需求，以保證軟件產品的質量；

一般會採用ALM，Doors和TestLink等需求管理工具來創建需求和測試的對應關係，以此計算測試覆蓋率；

需求覆蓋率統計方法屬於傳統瀑布模型下的軟件工程實踐，傳統瀑布模型追求自上而下地制定計劃、分析需求、設計軟件、編寫代碼、測試和運維，屬於重量級流程，已經很難適應當今胡麗娜網時代下的敏捷開發；

因此，通常的覆蓋率，默認是指代碼覆蓋率，而並不是需求覆蓋率；

代碼覆蓋率

是指，至少被執行了一次的條目數佔整個條目數的百分比；

若是條目數是語句，對應的就是代碼行的覆蓋率； 若是條目數是函數，對應的就是函數覆蓋率； 若是條目數是路徑，那麼對應的就是路徑覆蓋率；

三種代碼覆蓋率指標

• 行覆蓋率又稱爲語句覆蓋率，指已經被執行到的語句佔總可執行語句的百分比（不包括代碼註釋、空行或者頭文件等）；這是最經常使用也是最低要求的覆蓋率指標；
• 斷定覆蓋又稱分支覆蓋，用以度量程序中每個斷定的分支是否都被測試到了，即代碼中每一個判斷的取真分支和取嫁分支是否各被覆蓋只是各一次；
• 條件覆蓋是指，斷定中的每一個條件的可能取值至少知足一次，度量斷定中的每一個條件的結果TRUE 和FALSE是否都被測試到了；

代碼覆蓋率的價值

統計代碼覆蓋率的根本目的是找出潛在的遺漏測試用例，並有針對性的進行補充，同時還能夠識別出代碼中那些因爲需求變動等緣由形成的不可達的廢棄代碼；

代碼覆蓋率越高越能說明你的測試用例設計是充分且完備的，但測試的成本會隨着覆蓋率的提升以指數的方式迅速增長；

代碼覆蓋率的侷限性

代碼覆蓋率反饋的僅僅是已有代碼的哪些邏輯被執行過了，哪些邏輯尚未被執行過，但若是其餘模塊依賴這段代碼，能確保必定沒有問題嗎？

其根本緣由在於代碼覆蓋率的計算是基於現有代碼；

高的代碼覆蓋率不必定能保證軟件的質量，但低的代碼覆蓋率必定不能保證軟件的質量；

代碼覆蓋率工具

JaCoCo是一款Java代碼的主流開源覆蓋率功能，很方便的嵌入到Ant、Maven，而且能夠很好的集成到jenkins等主流持續集成工具；

JaCoCo的代碼覆蓋率報告長啥樣的？

如圖所示，包括了每一個Java代碼文件的行覆蓋率以及分支覆蓋率，並給出了每一個Java代碼文件的行數、方法數和類數等信息；

下圖所示爲每一個Java文件內部詳細的代碼覆蓋率狀況，綠色行表示已經被覆蓋，紅色行表示還沒有被覆蓋，黃色行表示部分覆蓋； 左側綠色菱形塊表示該分支已經被徹底覆蓋、黃色菱形塊表示該分支僅被部分覆蓋；

經過這個報告，就能夠知道代碼真實的執行狀況，而後再能夠針對性的設計測試用例；

前端能夠考慮使用jest;

代碼覆蓋率工具的實現原理

實現代碼覆蓋率的統計，最基本的方法就是注入(Instrumentation)； 注入就是在被測代碼中自動插入用於覆蓋率統計的探針（Probe）代碼，並保證插入的探針代碼不會給源代碼帶來任何影響；

對於Java代碼來講，根據注入目標的不一樣，能夠分爲源代碼（Source Code）注入和字節碼（Byte Code）輸入兩大類； 基於JVM自己特性以及執行效率的緣由，目前主流的工具基本都是使用字節碼注入，注入的具體實現採用ASM技術；

ASM是一個Java字節碼操縱框架，能被用來動態生成類或者加強既有類的功能，直接直接產生class文件，也能夠在類被加載入JVM以前動態改變類行爲；

根據注入發生的時間點，字節碼注入又能夠分爲兩大模式： On-The-Fly注入模式和Offline注入模式；

On-The-Fly注入模式

特色在於無需修改源代碼，也無需提早進行字節碼插樁，適用於支持Java Agent的運行環境；

優勢是能夠在系統不停機的狀況下，實時收集代碼覆蓋率信息，缺點是運行環境必須容許使用Java Agent;

實現 On-The-Fly 模式，主要有兩種技術方案：

• 開發自定義的類裝載器（Class Loader）實現類裝在策略，每次類加載前，須要在class文件中插入探針，早期的Emma就是使用這種方案實現的探針插入；
• 藉助Java Agent，利用執行在main()方法以前的攔截器方法premain()來插入探針，實際使用過程當中須要在JVM的啓動參數中添加"-javaagent"並制定用於實時字節碼注入的代理程序，這樣代理程序在裝在每一個class文件前，先判斷是否已經插入了探針，若是沒有則須要將探針插入class文件中，目前主流的JaCoCo就是使用這種方式；

Offline注入模式

Offline 模式也無需修改源代碼，可是須要在測試開始以前先對文件進行插樁，並事先生成插過樁的class文件；

這種方式適用於不支持Java Agent的運行環境，以及沒法使用自定義類裝載器的場景；

優勢是JVM啓動時再也不須要使用Java Agent額外開啓代碼，缺點是沒法實時獲取代碼覆蓋率信息，只能在系統停機時下獲取；

Offlinne模式根據是生成新的class文件仍是直接修改原class文件，又能夠分爲Replace和Inject兩種不一樣模式；

和On-The-Fly注入模式不一樣，Replace和Inject的實現是在廁所運行前就已經經過ASM將探針插入了class文件，而在測試的運行過程當中不須要任何額外的處理；

Cobertura就是使用Offline模式的典型表明；

小結

測試覆蓋率一般被用來衡量測試的充分性和完整性，包括面向項目的需求覆蓋率和偏向技術的代碼覆蓋率；

而需求覆蓋率的統計方式再也不適用於如今的敏捷開發模式，全部如今談到的測試覆蓋率，大可能是指代碼覆蓋率；

高的代碼覆蓋率不必定能保證軟件的質量，由於代碼覆蓋率是基於現有代碼，沒法發現那些未考慮某些輸入已經未處理某些狀況造成的缺陷；

7）如何高效填寫軟件缺陷報告

缺陷報告是測試工程師與開發工程師交流溝通的重要橋樑，也是測試工程師平常工做的重要輸出，把發現的缺陷準確無歧義地表達清楚，是測試工程師最基本的一項技能；

準確無歧義的表達就意味着，開發工程師能夠根據缺陷報告快速理解缺陷，並精肯定位問題；開發經理能夠準確預估缺陷修復的優先級；產品經理能夠額瞭解缺陷對用戶或業務的影響以及嚴重性；

缺陷報告自己的質量將直接關係到缺陷被修復的速度以及開發工程師的效率，同時還會影響測試工程師的信用、測試與開發人員寫做的有效性；

缺陷標題

缺陷標題一般是別人最早看到的部分，是對缺陷的歸納性描述，一般使用"在什麼狀況下發生了什麼問題"的模式；

描述不只要作到清晰簡潔，最關鍵是要足夠具體，切忌不能採用過於籠統的描述；描述的同時還必須清楚地表述發生問題的上下文，也就是問題出現的場景；

並且缺陷的標題不易過長，對缺陷更詳細的描述應該放在缺陷概述裏；

缺陷概述

缺陷概述一般會提供更多歸納性的缺陷本質與現象的描述，是缺陷標題的細化；

缺陷概述的目的，清晰簡潔地描述缺陷，使開發工程師可以聚焦缺陷的本質；

缺陷影響

缺陷影響描述的是，缺陷引發的問題對用戶或者對業務的影響範圍以及嚴重程度；

缺陷影響決定了缺陷的優先級（Priority）和嚴重程度（Severity）,開發經理會以此爲依據來決定修復該缺陷的優先級；產品經理會以此爲依據來衡量缺陷的嚴重 程度，並以爲是否要等該缺陷被修復後才能發佈產品；

準確描述缺陷影響的前提是，必須對軟件的應用場景以及需求有深刻的理解，這也是對測試工程師業務基本功的考驗；

環境配置

環境配置用以詳細描述測試環境的配置細節，爲缺陷的重現提供必要的環境信息，好比操做系統類型和版本、被測軟件軟包、瀏覽器的種類和版本、被測軟件的配置信息、集羣的配置參數等等；

須要注意的是，環境配置的內容是按需描述，就是隻描述那些重現缺陷的環境敏感信息；

前置條件

前置條件是指測試步驟開始前系統應該處在的狀態，目的是減小缺陷重現步驟的描述，排除沒必要要的干擾，使其更有針對性；

缺陷重現步驟

缺陷重現步驟是整個缺陷報告中最核心的內容，目的在於用簡潔的語言像開發工程師展現缺陷重現的具體操做步驟；

須要注意的是，操做步驟一般是從用戶角度出發來描述，每一個步驟都應該是可操做且連貫的；

在寫缺陷重現步驟時，要反覆執行這些步驟確認：

• 確保缺陷的可重現性；
• 找到最短的重現路徑；

而對於缺陷重現步驟的描述，應該要避免3個場景問題：

• 籠統的描述，缺少可操做的具體步驟；
• 出現與缺陷重現不相關的步驟；
• 缺少對測試數據的相關描述；

指望結果和實際結果

在描述重現步驟的過程當中，須要明確說明指望結果和實際結果； 指望結果來自於對需求的理解，而實際結果來自於測試執行的結果；

優先級（Priority）和嚴重程度（Severity）

根據百度百科的解釋，缺陷優先級是指缺陷必須被修復的緊急程度，而缺陷嚴重程度是指因缺陷引發的故障對軟件產品的影響程度；

嚴重程度是缺陷自己的屬性，一般確認後就再也不變化，而優先級是缺陷的工程屬性，會隨着項目進度、解決缺陷的成本等因素而變更；

那缺陷優先級和嚴重程度是什麼關係？

• 缺陷越嚴重，優先級越高；
• 缺陷影響的範圍越大，優先級也會越高；
• 有些缺陷雖然從用戶影響角度來講不算嚴重，可是會妨礙測試或者是自動化測試的執行，這類缺陷屬於典型的嚴重程度低，但優先級高的問題；
• 有些缺陷雖然嚴重程度比較高，可是考慮到修復成本以及技術難度，也會出現優先級較低的狀況；

變通方案（Wordaround）

變通方案是提供一種臨時繞開當前缺陷而不影響產品功能的方式，一般由測試工程師或者開發工程師完成，或者一同決定；

變通方案的有無以及實施的難易程度，是決定缺陷優先級和嚴重程度的重要依據；

根緣由分析如

若是在發現缺陷的同時，定位出問題的根本緣由，清楚地描述缺陷產生的緣由並反饋給開發工程師，那麼開發工程師修復缺陷的效率就會大幅提高；

附件

附件一般是爲缺陷的存在提供必要的證據支持，常見的附件有界面截圖、測試用例日誌、服務器端日誌、GUI測試的執行食品等；

小結

一份高效的軟件缺陷報告，應該包括缺陷標題、缺陷概述、缺陷影響、環境配置、前提條件、缺陷重現步驟、指望結果和實際結果、優先級和嚴重程度、變通方案、緣由分析、附件這幾大塊；

其餘想說說

如何對一個階段的BUG進行統計、分析並報告？

這種屬於測試缺陷統計，bug趨勢分析，bug收斂狀況，bug模塊分佈，bug發現階段統計等等，屬於面向管理層和質量流程保障團隊，通常這種都是利用缺陷管理系統的自帶功能來生成相似的報告；

除了上面所須要的內容，還須要如下內容：

• 缺陷模塊，方便後期統計；
• 能準確指派BUG給具體負責人，最簡單說，先確認是後端仍是前端的問題；
• 出現的機率；
• 對比性炎症；

8）以終爲始，如何才能作好測試計劃

在早期的軟件工程實踐中，軟件測試計劃的制定一般是在需求分析以及測試需求分析完成後開始，而且是整個軟件研發聲明週期中的重要環節；

沒有測試計劃會怎麼樣？

若是沒有測試計劃，會帶來什麼問題？

• 很難確切地知道具體的測試範圍，以及應該採起的具體測試策略；
• 很難預估具體的工做量和所須要的測試工程師數量，同時還會形成各個測試工程師的分工不明確，引起某些測試工做被重複執行，而有些測試則被遺漏的問題；
• 測試的總體進度徹底不可控，甚至很難確切知道母親測試的完成狀況，對於測試完成時間就更難預估準確的時間節點；
• 整個項目對潛在風險的抵抗能力很弱，很難應對需求的變動以及其餘突發事件；

從這些問題，能夠逆向思惟推導出，一份好的測試計劃要包括如下幾點： 測試範圍、測試策略、測試資源、測試進度和測試風險預估；

測試範圍

顧名思義，測試範圍描述的是被測對象以及主要的測試內容；

測試範圍的肯定一般是在測試需求分析完成後進行，因此肯定測試範圍的過程在必定程度上也是對測試需求分析的進一步校驗，有助於在早期階段發現潛在的測試遺漏；

測試策略的話題

測試策略簡單來說就是需求明確"先測什麼後測什麼"和"如何來測"兩個問題；

測試策略會要求明確測試的重點，以及各項測試的前後順序；

測試策略還須要說明，採用什麼樣的測試類型和測試方法；不只要給出爲何要選用這個測試類型，還要詳細說明具體的實施方法；

功能測試

根據測試需求分析的思惟導圖來設計測試用例；

這裏須要注意，要先實現主幹業務流程的測試自動化；

對於須要手工測試的測試點，要決定採用什麼類型的測試用例設計方法，以及如何準備相關的測試數據；

還要評估被測軟件的可測試性，若是有可測試性的問題，須要提早考慮切實可行的變通方案，甚至要求開發人員提供可測試性的接口；

兼容性測試

Web測試須要肯定覆蓋的瀏覽器類型和版本，移動設備測試須要肯定覆蓋的設備類型和具體IOS/Android的版本等；

那怎麼肯定須要覆蓋的移動設備類型以及IOS/Android的版本列表？

• 若是舊產品，經過產品統計數據分析歷史數據，得出Top30%的移動設備機型及版本信息，兼容性覆蓋這批固件便可；
• 若是是一個新產品，能夠經過相似TalkingData這種網站來查看目前主流的移動設備，分辨率大小、IOS/Android等信息來肯定測試範圍；

通常來講，兼容性測試是功能測試的後期，等功能基本穩定後，纔會開始兼容性測試；

假如是接入一些新框架，這時候就須要評估接入新框架的信息，此時就須要先進行兼容性測試，以確保後期不會引入沒法解決的兼容性問題；

而兼容性用例的選取，基本上是來自於已經實現的自動化測試用例；

性能測試

須要在明確了性能需求（併發用戶數、響應時間、事務吞吐量、CPU、內存、IO、帶寬、事務成功率、超時錯誤率等）前提下，結合被測系統的特色，設計性能測試場景並肯定性能測試框架；

好比，是直接在 API 級別發起壓力測試，仍是必須模擬終端用戶行爲進行基於協議的壓力測試。再好比，是基於模塊進行壓力測試，仍是發起全鏈路壓測。

若是性能是背景數據敏感的場景，還須要肯定背景數據量級與分佈，並決定產生背景數據的技術方案，好比是經過 API 併發調用來產生測試數據，仍是直接在數據庫上作批量 insert 和 update 操做，或者是兩種方式的結合。

無論採用哪一種方式，都須要明確待開發的單用戶腳本數量，以便後續可以順利組裝壓測測試場景；

性能測試的實施，是一個比較複雜的問題； 須要根據你想要解決的問題，肯定性能測試的類型，而後根據具體的性能測試類型開展測試；

• 性能測試的實施，要先根據業務場景來決定須要開發哪些單用戶腳本，腳本的開發會涉及到不少性能測試腳本特有的概念，好比思考時間、集合點、動態關聯等；
• 腳本開發完成後，要以腳本爲單位組織測試場景（Scenario），場景定義簡單來講就是百分之多少的用戶在作登陸、百分之多少的用戶在作查詢、每一個用戶的操做步驟之間須要等待多少時間、併發用戶的增速是X秒一個等；
• 最後，纔是具體的測試場景執行，和自動化功能測試不一樣，性能測試執行完成後的性能測試報告的解讀，是整個測試過程當中最關鍵的點；

測試資源

測試資源一般包括測試人員和測試環境，這兩類的資源是有限的；

而測試計劃的目的就是，保證在有效資源下的產出最大化，因此，測試資源就是須要明確"誰來測"和"在哪裏測"和"怎麼測"的問題；

測試人員是最重要的，直接關係到整個測試項目的成敗和效率，測試人員的資源一般由2個維度：

• 測試工程師的數量；
• 測試工程師的我的經驗和能力；

測試進度

測試進度主要描述各種測試的開始時間，所需工做量，預計完成時間，並以此爲依據來建議最終產品的上線發佈時間；

在傳統瀑布模型中，測試進度徹底依賴於開發完成並遞交測試版本的時間；若是開發案提交測試版本發生了延誤，那麼在不裁剪測試需求的狀況下，產品總體的上線時間就一樣會延期；

然而在敏捷模式下，測試會貫穿於整個開發過程，不少測試工做會和開發工做同步進行，這樣測試進度就不會徹底依賴於開發遞交能夠測試版本的時間；

行爲驅動開發(Behavior-Driven-Development)，就是平時所說的BDD，只的是能夠經過天然語言書寫非程序員可讀的測試用例，並經過StepDef來關聯基於天然語言的步驟描述和具體的業務操做，最典型的框架就是Cucumber；

測試風險評估

計劃趕不上變化，一般需求表更、開發延期、發現重大缺陷和人員變更是引入項目測試風險的主要緣由；

因此，在制定測試計劃的時候，就要預估整個測試過程當中可能存在的潛在風險，以及當這些風險發生時的應對策略；

小結

一份成功的測試計劃，必須清楚的描述：測試範圍、測試策略、測試資源、測試進度和測試風險預估這5個重要的方面；

• 測試訪問須要明確測什麼和不測什麼；
• 測試策略須要明確先測什麼後測什麼和如何來測；
• 測試資源須要明確誰來測和在哪裏測；
• 測試進度是須要明確各種測試的開始時間，所需工做量和估計完成時間；
• 測試風險預估是須要明確如何有效應對各類潛在的變化；

其餘想說

在快速迭代過程，建議增長產品需求測試，意義在開發和測試開發前，保證全部人對需求理解的一致性；

9）軟件測試工程師的核心競爭力是什麼

目前測試工程師分爲兩大類別，一類是作業務功能測試，另外一類是作測試開發的；

傳統測試工程師應該具有的核心競爭力

按照對測試工程師重要程度進行排序，以下：

• 測試策略設計能力
• 測試用例設計能力
• 快速學習能力
• 探索性測試思惟
• 缺陷分析能力
• 自動化測試技術
• 良好溝通能力

測試策略設計能力

這項是核心競爭力；

測試策略設計能力是指，對於各類不一樣的被測軟件，可以快速準確地理解需求，並在有限的時間和資源下，明確測試重點以及最適合的測試方法的能力；

具有出色的測試策略設計能力，能夠很是明確地回答出測試過程當中遇到的這些關鍵問題：

• 測試要具體執行到什麼程度；
• 測試須要藉助什麼工具；
• 如何運用自動化測試以及自動化測試框架，以及如何選型；
• 測試人員自願如何合理分配；
• 測試進度如何安排；
• 測試風險如何應對；

出色的測試策略設計能力，不是一朝一夕的事情，須要經歷大量的實際歷練，還要保持持續思考，主動去提煉共性的內容；

測試用例設計能力

測試用例設計能力是指，不管對於什麼類型的測試，都能設計出高效地發現缺陷，保證產品質量的優秀測試用例；

要作好測試用例設計，不只須要深刻理解被測軟件的業務需求和目標用戶的使用習慣，還要熟悉軟件的具體設計和運行環境，包括技術架構、緩存機制、中間件技術、第三方服務集成等等。

要想提升測試用例設計能力，平時就要多積累，對常見的缺陷模式、典型的錯誤類型以及遇到過的缺陷，要不斷地總結、概括，才能逐漸造成體系化的用例設計思惟。

還能夠閱讀一些好的測試用例設計實例開闊思路；

快速學習能力

包含兩個層面的含義：

• 對不一樣業務需求和功能的快速學習與理解能力；
• 對於測試新技術和新方法的學習與應用能力；

學習工具，直接看官方文檔會更快，由於裏面的內容確定是最新最權威的；

在學習新內容時，必定要作到理解其原理，而不是隻停留在表面的、簡單的操做和使用，長期保持這種學習狀態，能夠在很大程度上提升邏輯思惟和理解能力；

探索性測試思惟

探索性測試是指測試工程師在執行測試的過程當中不斷學習被測系統，同時結合基於本身經驗的錯誤猜想和邏輯推理，整理和分析出更多的針對性的測試關注點；

本質上，探索性測試思惟是測試用例設計能力和快速學習能力結合的必然結果；

優秀的探索性測試思惟能夠幫助實現低成本的精準測試，精準測試最通俗的理解能夠歸納爲針對開發代碼的變動，目標明確而且有針對性地對變動點以及變動關聯點作測試，也是目前敏捷測試主推的測試時之一；

缺陷分析能力

包含3個層面的含義：

• 對於已經發現的缺陷，結合發生錯誤的上下文以及後臺日誌，能夠預測或者定位缺陷的發生緣由，甚至能夠明確指出具體出錯的代碼行，由此能夠大幅縮短缺陷的修復週期，並提升開發工程師對於測試工程師的承認以及信任度；
• 根據已經發現的缺陷，結合探索性測試思惟，推斷同類缺陷存在的可能性，並由此找出全部相關的潛在缺陷；
• 能夠對一段時間內所發生的缺陷類型和缺陷進行合理分析，由點到面預估總體質量的健康狀態，並可以對高頻缺陷類型提供系統性的發現和預防措施，並以此類調整後續的測試策略；

這3個層面是依次遞進的關係，越日後越能提現出測試工程師的核心競爭力；

自動化測試技術

自動化測試的核心價值仍是測試自己，自動化僅僅是手段；

良好的溝通能力

測試工程師在項目中的做用，有點想潤滑劑：

• 一方面，須要對接產品經理和項目經理，已確保需求的正常實現和項目總體質量的達標；
• 另外一方面，還要和開發人員不斷的溝通、協調，確保缺陷的及時修復和驗證；

溝通能力會直接影響事務開展的效率，是一塊敲門磚；

測試開發工程師的核心競爭力

測試系統需求分析能力

除了代碼開發能力，測試開發工程師要具有測試系統需求分析能力； 要可以站在測試架構師的高度，識別出測試基礎架構的需求和提升效率的應用場景；

更寬廣的知識體系

測試開發工程師須要具有很是寬廣的知識體系，你不只須要和傳統的測試開發工程師打交道，由於他們是你構建的測試工具或者平臺的用戶； 並且還要和 CI/CD、和運維工程師們有緊密的聯繫，由於你構建的測試工具或者平臺，須要接入到 CI/CD 的流水線以及運維的監控系統中去。

除此以外，你還要了解更高級別的測試架構部署和生產架構部署、你還必須對開發採用的各類技術很是熟悉。。

性能測試工程師

性能測試工程師的核心價值不在於會多少性能測試工具，而是對於性能問題的直覺和定位能力，這個須要靠紮實的基礎理論知識和大量的實踐才能培養出來；

小結

測試工程師按照工做內容，分爲了功能測試工程師和測試開發工程師兩類；

對於功能測試工程師來講，其核心競爭力包括：測試策略設計能力、測試用例設計能力、快速學習能力、探索性測試思惟、缺陷分析能力、自動化測試技術和良好的溝通能力這七大部分，你能夠有針對性地提高本身某方面的能力，去獲取更大發展空間的「敲門磚」。

而對於測試開發工程師來講，你須要具有優秀的測試系統需求分析能力和完備的知識體系，這樣才能保證你設計的測試工做和平臺，能夠更好地知足提高測試效率的要求。

爲何測試會迷茫

歷來沒有見過開發會迷茫，每每是測試在迷茫，想了好久，也許是這些緣由吧：

• 開發學習線路提和發展路線清晰，測試大多數是摸着石頭過河；尤爲對於功能測試入門，就更容易迷茫；
• 測試工程師涉及的內容太普遍，什麼都要懂，可是什麼都不精，接着就不知道職業該如何發展，天天被各類瑣事淹沒；
• 性能測試、自動化測試瓶頸大，自學開發難度大；

10）軟件測試工程師須要掌握的非測試知識有哪些

開發工程師一般是深度遍歷，關注的是點； 而測試工程師一般是廣度遍歷，關注的是面；

• 小到 Linux/Unix/Windows 操做系統的基礎知識，Oracle/MySQL 等傳統關係型數據庫技術，NoSQL 非關係型數據庫技術，中間件技術，Shell/Python 腳本開發，版本管理工具與策略，CI/CD 流水線設計，F5 負載均衡技術，Fiddler/Wireshark/Tcpdump 等抓包工具，瀏覽器 Developer Tool 等；
• 大到網站架構設計，容器技術，微服務架構，服務網格（Service Mesh），DevOps，雲計算，大數據，人工智能和區塊鏈技術等。

基本上看，全部都覆蓋到了。。但人的時間是有限的，確定不會這樣逐個介紹，所以調了點佔做比較重要的；

網站架構的核心知識

除了功能測試，還要性能測試、穩定性測試、全鏈路壓測、故障切換測試、動態集羣容量伸縮測試、服務降級測試和安全滲透測試；

• 好比，若是不清楚 Memcached 這類分佈式緩存集羣的應用場景和基本原理，若是不清楚緩存擊穿、緩存雪崩、緩存預熱、緩存集羣擴容侷限性等問題，就設計不出針對緩存系統特有問題的測試用例；
• 再好比，若是對網站的可伸縮性架構設計不瞭解，不清楚應用服務器的各類負載均衡實現的基本原理，不瞭解數據庫的讀寫分離技術，就沒法完成諸如故障切換、動態集羣容量伸縮、服務降級等相關的測試，同時對於性能測試和全鏈路壓測過程當中可能遇到的各類瓶頸，也會很難定位和調整。

容器技術

對測試開發工程師來講，須要應用容器的場景就更多了。好比，目前主流的 Selenium Grid 就已經提供了官方 Docker 版本，能夠直接以容器的方式創建測試執行環境，也能夠很方便地在 Pivotal Cloud Foundry 和 Google Cloud Platform 等雲計算平臺上快速創建測試執行環境。

基於 Docker 的 Selenium Grid 大大減輕了批量虛擬機節點上 Web Driver、瀏覽器版本和守護者進程版本等升級維護的工做量。

測試開發工程師還能夠經過 Docker Image 的形式，提供某些測試工具，而不是以傳統的安裝包或者 JAR 文件的形式，能夠實現測試工具開箱即用。

雲計算技術

對於雲計算的學習，側重點應該是如何使用雲提供的基礎設施以及服務；

能夠嘗試用雲服務去部署本身的應用，同時還能夠結合雲平臺提供的各種服務（配置服務，數據庫服務）和你的應用作集成；

DevOps思惟

DevOps強調的是，開發、測試和運維等組織團隊之間，經過高效自動化工具的寫做和溝通，來完成軟件的全聲明週期管理，從而實現更頻繁持續交付高質量的軟件，根本目的是要提高業務的交付能力；

DevOps的具體表現形式能夠是工具、方法和流水線，但起更深層次的內涵仍是在思想方法，以敏捷和精益爲核心，經過發現問題，以系統性的方法或者工具來解決問題，從而實現持續改進；

對於 DevOps，我建議的學習路徑是，你能夠從深刻掌握 Jenkins 之類的工具開始，到熟練應用和組合各類 plugin 來完成靈活高效的流水線搭建，以後再將更多的工具逐漸集成到流水線中以完成更多的任務。

前端開發技術

從測試工程師的角度來說，若是你可以掌握前端開發技術，也就意味着你能夠更高效地作前端的測試，更容易發現潛在缺陷。同時，你還能夠本身構建測試頁面，來完成各種前端組件的精細化測試，大大提升測試覆蓋率和效率。

關於前端技術的學習路徑，一般你首先須要掌握最基本的 JavaScript、CSS、JQuery 和 HTML5 等知識，而後再去學習一些主流的前端開發框架，好比 Angular.js、Backbone.js 等。 固然如今的 Node.js 的生態圈很是發達，你若是可以掌握 Node.js，那麼不少東西實現起來均可以駕輕就熟。

總結

軟件測試工程師須要掌握很是多的非測試專業知識，包括：網站架構、容器技術、雲計算技術、DevOps 思惟，以及前端開發技術的核心知識以及實踐。

11）互聯網產品的測試策略應該如何設計

研發流程的不一樣決定了測試策略的不一樣

傳統產品跟互聯網產品的研發自己最大的不一樣就是「快」；

發佈週期的巨大差別決定了，傳統軟件產品的測試策略必然不適用於互聯網產品的測試，二者的測試策略必然在測試執行時間和測試執行環境上有巨大差別；

發佈流程一般包含了靜態代碼掃描、單元測試、編譯、打包、上傳、下載、部署和測試的全流程；

那如何在保證測試質量和測試覆蓋率的前提下，有效縮短測試執行時間？

• 引入測試的併發執行機制，用包含大量測試執行節點的測試執行集羣來併發執行測試用例； 測試執行集羣，能夠簡單理解爲是一批專門用來併發執行測試用例的機器；
• 其次，必須從測試策略上找到突破口；

傳統軟件產品的測試策略設計

傳統軟件產品的測試策略，就以下圖的金字塔模型，在很長一段時間內，該金字塔模型都被認爲是測試策略設計的最佳實踐；

單元測試

金字塔最底部是單元測試，屬於白盒測試的範疇，通常由開發工程師本身完成，因爲越早發現缺陷其修復成本越低，全部傳統軟件產品的測試策略提倡對單元測試的高投入；

API測試

金字塔中部是API測試，主要針對的是各模塊的暴露接口，一般採用灰盒測試方法；

灰盒測試方法是介於白盒測試和黑盒測試之間的一種測試技術，其核心思想是利用測試執行的代碼覆蓋率來知道測試用例的設計；

以API接口測試爲例，首先以黑盒方式設計如何調用API的測試用例，同時在測試執行過程當中統計代碼覆蓋率，而後根據代碼覆蓋率狀況來補充更多、更有針對性的測試用例；

GUI測試

金字塔最上層的是GUI測試，也成爲端對端（E2E,end-to-end）測試，是最接近軟件真是用戶使用行爲的測試類型；

一般是模擬真是用戶使用軟件的行爲，即模擬用戶在軟件界面上的各類操做，並驗證這些操做對應的結果是否正確；

GUI測試的優勢是，可以實際模擬真實用戶的行爲，直接驗證軟件的商業價值； 缺點是執行的代碼比較大，既然使用自動化，用例的維護和執行代碼依然很大；

另外，GUI測試的穩定性問題，是長期以來阻礙GUI測試發展的重要緣由； 即時採用了不少諸如retry機制以及異常場景恢復機制等方式，GUI測試的隨機失敗率高居不下；

互聯網產品的測試策略設計

對於互聯網產品來講，金字塔模型已經不適用了；

GUI測試

互聯網產品的上線週期，決定GUI測試不能大範圍開展；

• 互聯網產品的迭代週期，決定了留給開發GUI自動化測試用例的時間很是有限；
• 互聯網產品客戶端界面頻繁變化，GUI自動化測試的效率很是低；

所以，互聯網產品的GUI測試一般採用手工爲主，自動化爲輔的測試策略；

手工測試每每利用探索性測試思想，針對新開發或者新修改的界面功能進行測試，而自動化測試的關注點主要放在相對穩定且核心業務的基本功能驗證上；

因此,GUI的自動化測試每每只覆蓋最核心且直接影響主營業務流程的場景；

從用例數量來看，傳統軟件的GUI測試是重量級的，由於測試周期長；而互聯網的GUI測試是輕量級的，畢竟上線週期過短了；

API測試

對於互聯網產品，把測試重點放在API測試上，纔是最明智的選擇；

• API 測試用例的開發與調試效率比 GUI 測試要高得多，並且測試用例的代碼實現比較規範，一般就是準備測試數據，發起 request，驗證 response 這幾個標準步驟；
• API 測試用例的執行穩定性遠遠高於 GUI 測試；
• 單個 API 測試用例的執行時間每每要比 GUI 測試短不少；
• 如今不少互聯網產品採用了微服務架構，而對微服務的測試，本質上就是對不一樣的 Web Service 的測試，也就是 API 測試。
• API 接口的改動通常比較少，即便有改動，絕大多數狀況下也須要保證後向兼容性（Backward Compatibility）。所謂後向兼容性，最基本的要求就是保證本來的 API 調用方式維持不變。

互聯網產品的這些特性決定了，API 測試能夠實現良好的投入產出比，所以應該成爲互聯網產品的測試重點。這也就是爲何互聯網產品的測試策略更像是個菱形結構的緣由。

下圖就是菱形的測試策略，遵循「重量級 API 測試，輕量級 GUI 測試，輕量級單元測試」的原則；

單元測試

互聯網產品一般會分爲應用層和後端服務，後端服務又能夠進一步細分爲應用服務和基礎服務；

後端基礎服務和一些公共應用服務相對穩定，並且對於系統全局來講是「牽一髮而動全身」，因此後端服務頗有必要開展全面的單元測試； 而對於變更很是頻繁的客戶端應用和非公用的後端應用服務，通常不多會去作單元測試。

另外，對於一些核心算法和關鍵應用，好比銀行網關接口，第三方支付集成接口等，也要作比較全面的單元測試。

總結來說，互聯網產品的全面單元測試只會應用在那些相對穩定和最核心的模塊和服務上，而應用層或者上層業務服務不多會大規模開展單元測試。

小結

傳統軟件一般採用金字塔模型的測試策略，而如何的互聯網產品每每採用菱形模型；

菱形模型有如下4個關鍵點：

• 以中間層的API測試爲重點作全面的測試；
• 輕量級的GUI測試，只覆蓋最核心直接影響主營業務流程的E2E場景；
• 最上層的GUI測試一般利用探索式測試思惟，以人工測試的方式發現儘量多的潛在問題；
• 裁人測試採用分而治之的思想，支隊那些穩定而且核心的服務和模塊開展全面的單元測試，而應用層或者上層業務只會作少許的單元測試；

12）從0到1：你的第一個GUI自動化測試

本章主要介紹自動化的思想及selenium的原理，這裏很少說，感興趣的同窗可點擊這裏閱讀；

13) 效率爲王：腳本與數據的解耦 + Page Object模型

問題：測試腳本中既有測試數據又有測試操做，全部操做都集中在一個腳本

測試腳本和數據解耦

測試輸入數據單獨保存，測試腳本的輸入數據採用變量代替；
常見的就是csv，每行讀取；
複製代碼

這種模式叫數據驅動；

好處在於：

• 解決了大量重複腳本的問題；
• 其餘數據也能夠存放到文件裏作判斷；

頁面對象（Page Object）模型

頁面對象模型」的核心理念是，以頁面爲單位來封裝頁面上的控件以及控件的部分操做。
而測試用例使用頁面對象來完成具體的界面操做。
複製代碼

14）更接近業務的抽象：讓自動化測試腳本更好地描述業務

如何把控操做函數的粒度

操做函數的粒度是指，一個操做函數到底應該包含多少操做步驟纔是最合適的；
複製代碼

• 粒度過大，會下降函數的可重用性；
• 粒度太小，就失去函數封裝的意義；

通常會以完成一個業務流程爲主線，抽離出高內聚低耦合的操做步驟集合；

業務流程抽象

業務流程抽象是，基於操做函數的更接近於實際業務的更高層次的抽象方式。
基於業務流程抽象實現的測試用例每每具備較好的靈活性，能夠根據實際測試需求方便地組裝出各類測試用例；
複製代碼

業務流程的核心思想是，從業務的維度來指導測試業務流程的封裝；

15）過不了的坎：聊聊GUI自動化過程當中的測試數據

從建立的技術手段上來說，建立測試數據的方法主要分爲三種：

• API 調用；
• 數據庫操做；
• 綜合運用 API 調用和數據庫操做；

從建立的時機來說，建立測試數據的方法主要分爲兩種：

• 測試用例執行過程當中，實時建立測試數據；
• 測試用例執行前，事先建立好「開箱即用」的測試數據；

16）GUI測試還能這麼玩（Page Code Gen + Data Gen + Headless）？

• GUI 測試數據自動生成，主要是基於測試輸入數據的類型以及對應的自定義規則庫實現的，而且對於多個測試輸入數據，能夠基於笛卡爾積來自動組合出完整的測試用例集合；

• 無頭瀏覽器，就是在執行過程當中看不到運行的界面，優勢在於速度快，簡化環境搭建；

• 頁面對象自動生成技術，基本思路是，不用再手工維護Page Class 了，只須要提供 Web 的 URL，就會自動生成這個頁面上全部控件的定位信息，並自動生成 Page Class，目前暫無開源，商業工具較多；