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之間的任何浮點數；
	其他恩義非數字字元；
複製程式碼

邊界值分析

成績系統：-1、0、1、59、60、61、99、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，目前暫無開源，商業工具較多；