JB的閱讀之旅-軟體測試52講（下）

17）精益求精：聊聊提高GUI測試穩定性的關鍵技術

問題：同樣的測試用例在同樣的環境上，時而測試通過，時而測試失敗；

造成GUI測試不穩定的常見五種因素：

• 非預計的彈出對話方塊；
• 頁面控制元件屬性的細微變化；
• 被測系統的A/B測試；
• 隨機的頁面延遲造成控制元件識別失敗；
• 測試資料問題；

非預計的彈出對話方塊

新增異常場景恢復流程，一旦發現控制元件無法定位時，就走到該邏輯下，遍歷滿足的情況，執行相應的操作，缺點就是，不同對話方塊需要更新到該程式了，存在維護成本；

頁面控制元件屬性的細微變化

比如控制元件ID屬性發生變化，也建議新增定位控制元件邏輯處理：

• 根據指令碼里的屬性找控制元件，如果沒找到，嘗試找控制元件的文字；
• 文字符合，獲取該文字對應的控制元件屬性；
• 判斷指令碼里的屬性跟獲取到的屬性是否相似，相似則判定一致；

上面的方法只是一種思路，可以根據不同業務特性歸總一定適用的方法來在出錯時定位控制元件，提高識別率；

還可以使用xpath，但也一樣存在屬性被改的情況，只是相對控制元件元素，概率會少一點；

被測系統的A/B測試

在測試指令碼內部對不同的被測版本做分支處理，指令碼需要能夠區分 A 和 B兩個的不同版本，並做出相應的處理；

隨機的頁面延遲造成控制元件識別失敗

增加重試機制，當操作失敗時，自動發起重試；

18）眼前一亮：帶你玩轉GUI自動化的測試報告

主要是說，好的測試報告，需要有截圖及高亮顯示操作元素功能；

如果使用selenium，需要擴充套件selenium原來的操作函式和hook函式實現；

19）真實的戰場：如何在大型專案中設計GUI自動化測試策略

• 對那些自定義開發的元件進行完整全面的測試；
• 基於前端模組封裝開發業務流程指令碼；
• 站在終端的視角以黑盒的方式使用網站的端到端的測試；
• 對各個前端業務模組的頁面物件庫和業務流程指令碼，實施版本化管理機制；

20）與時俱進：淺談移動應用測試方法與思路

三類移動應用的特點

• web app，移動端的web瀏覽器，技術棧是傳統的HTML、js、css等，優點是跨平臺；
• native APP，移動端的原生應用，安卓是apk（Java），ios是ipa（objective-c），能提供比較好的使用者體驗跟效能，方便操作手機本地資源；
• hybrid APP，介於web APP和native APP兩者之間的一種形態，在原生內嵌webview，通過webview來訪問網頁，優點是具備跨平臺，維護更新，是主流的開發模式；

三類移動應用的測試方法

從業務功能測試的角度看，移動應用的測試用例設計和傳統 PC 端的 GUI 自動化測試策略比較類似，只是測試框架不同，資料驅動、頁面物件模型和業務流程封裝依舊適用；

移動應用專項測試的思路和方法

交叉事件測試

也稱場景測試，模擬各種交叉場景，手工測試為主；

相容性測試

• 不同作業系統的相容性，比如android和ios；
• 不同解析度的相容性；
• 不同機型的相容性；
• 不同語言的相容性；
• 不同網路的相容性；
• 不同操作版本的相容性；

因為需要大量真實社保，所以使用第三方的雲測平臺較多；

流量測試

• APP執行業務操作引起的流量；
• APP在後臺執行時的消耗流量；
• APP安裝後首次啟動耗費的流量；
• APP安裝包的size；
• APP內下載/升級需要的流量；

藉助於Android 和 iOS 自帶的工具進行流量統計，也可以利用 tcpdump、Wireshark 和 Fiddler 等網路分析工具；

對於 Android 系統，網路流量資訊通常儲存在 /proc/net/dev 目錄下，也可以直接利用 ADB 工具獲取實時的流量資訊。另外，推薦一款 Android 的輕量級效能監控小工具 Emmagee，類似於 Windows 系統效能監視器，能夠實時顯示 App 執行過程中 CPU、記憶體和流量等資訊；

對於 iOS 系統，可以使用 Xcode 自帶的效能分析工具集中的 Network Activity，分析具體的流量使用情況；
複製程式碼

常見流量優化的方法：

• 壓縮圖片；
• 優化資料格式，比如使用json；
• 壓縮加密；
• 減少api呼叫次數；
• 回傳資料只需要必要資料；
• 快取機制；

耗電量測試

耗電量一般從三個方面思考：

• APP執行但沒有執行業務操作時的耗電量；
• APP執行且密集執行業務操作時的耗電量；
• APP後臺執行的耗電量；

檢驗方法，偏硬體的是耗電儀，軟體則如下：

• 安卓adb 命令adb shell dumpsys battery來獲取應用的耗電量資訊；
• 安卓，Google推出的history batterian工具；
• iOS 通過 Apple 的官方工具 Sysdiagnose來收集耗電量資訊，然後，可以進一步通過 Instrument工具鏈中的 Energy Diagnostics 進行耗電量分析；

弱網路測試

日常生活中，弱網的場景比較多，如地鐵、隧道、車庫，伴隨著就是丟包、延遲、斷線的異常場景；

文中作者推薦Augmented Traffic Control，是Facebook的開源行動網路測試工具，詳情請點選這裡查閱；

而jb日常用的比較多的是fiddler來模擬弱網，感興趣的點選這裡查閱；

邊界測試

意思就是找出程式的臨界值場景，驗證這些臨界場景是否正常，常見的就是最大值最小值；

21）移動測試神器：帶你玩轉Appium

本文主要是介紹了Appium及安裝使用，網上也有很多，請自行查閱；

Appium 的內部原理可以總結為：

Appium 屬於 C/S 架構，Appium Client 通過多語言支援的第三方庫向 Appium Server 發起請求，基於 Node.js 的 Appium Server 會接受 Appium Client 發來的請求，接著和 iOS 或者 Android 平臺上的代理工具打交道，代理工具在執行過程中不斷接收請求，並根據 WebDriver 協議解析出要執行的操作，最後呼叫 iOS 或者 Android 平臺上的原生測試框架完成測試。
複製程式碼

22）從0到1：API測試怎麼做？常用API測試工具簡介

常用的api測試工具有cURL、postman，還有jmeter跟soapui也算；

cURL

cURL是一款命令列工具，需要安裝，然後執行下面的命令發起api呼叫；

curl -i -H "Accept: application/json" -X GET "https://www.baidu.com"
複製程式碼

返回的內容如圖：

常見的引數解析：

引數	含義
-i	顯示response的header資訊；
-H	設定request中的header；
-X	執行執行方法，如get、post、Put，不指定-X，則預設使用get；
-d	設定http引數，引數之間用&串接；
-b	需要cookie時，指定cookie檔案路徑；

Session 的場景

curl -i -H "sessionid:XXXXXXXXXX" -X GET "http://XXX/api/demoAPI"

複製程式碼

Cookie 的場景 使用 cookie，在認證成功後，後端會返回 cookie給前端，前端可以把該 cookie 儲存成為檔案，當需要再次使用該 cookie 時，再用-b cookie_File的方式在 request 中植入 cookie 即可正常使用；

// 將 cookie 儲存為檔案
curl -i -X POST -d username=robin -d password=password123 -c ~/cookie.txt "http://XXX/auth"

// 載入 cookie 到 request 中
curl -i -H "Accept:application/json" -X GET -b ~/cookie.txt "http://XXX/api/demoAPI"
複製程式碼

Postman

相對於cURL，postman用的比較頻繁，官網地址點這裡；

結果驗證 點選Test右側的SNIPPETS，挑選一些需要驗證的場景，程式碼就會自動生成，當然也可以自己寫；

基於postman的測試程式碼自動生成 點選右側的code，選擇需要的語言，儲存即可；

又或者，使用newman工具，直接執行postman的collection；

newman run examples/sample-collection.json;
複製程式碼

複雜場景的api測試

多個api呼叫協助

通過程式碼將上個 API 呼叫返回的response中的某個值傳遞給下一個 API；

api依賴第三方

mock server；

非同步api

非同步 API 是指，呼叫後會立即返回，但是實際任務並沒有真正完成，而是需要稍後去查詢或者回撥的API；

• 測試非同步呼叫是否成功，檢查返回值和後臺工作現成是否被建立即可判斷；
• 測試非同步呼叫的業務邏輯處理是否正確，去訪問、運算元據庫或者訊息佇列看對應的資料是否被建立或更新，沒許可權就直接訪問日誌檔案看記錄；

23）API自動化測試框架的前世今生

早期的基於 Postman 的 API 測試在面臨頻繁執行大量測試用例，以及與 CI/CD 流水線整合的問題時，顯得心有餘而力不足。

為此，基於命令列的 API 測試實踐，也就是 Postman+Newman`，具有很好的靈活性，解決了這兩個問題。

但是，Postman+Newman 的測試方案，只能適用於單個 API 呼叫的簡單測試場景，對於連續呼叫多個 API 並涉及到引數傳遞問題時，這個方案就變得不那麼理想和完美了。隨後，API 測試就過渡到了基於程式碼的 API 測試階段；

respons結果發生變化時自動識別

具體實現的思路是，在 API 測試框架裡引入一個內建資料庫，推薦採用非關係型資料庫（比如 MongoDB），然後用這個資料庫記錄每次呼叫的 request 和 response 的組合，當下次傳送相同 request 時，API 測試框架就會自動和上次的 response 做差異檢測，對於有變化的欄位給出告警；

24）微服務模式下API測試要怎麼做？

單體架構

單體架構是將所有的業務場景的表示層、業務邏輯層和資料訪問層放在同一個工程中，最終經過編譯、打包，並部署在伺服器上。

缺點：

• 靈活性差，每次都要整包編譯；
• 可擴充套件性差，不能以模組為單位擴充套件容量；
• 穩定性差，某模組出錯會導致整體不可用；
• 可維護性差；

微服務架構

在微服務架構下，一個大型複雜軟體系統不再由一個單體組成，而是由一系列相互獨立的微服務組成；

測試的挑戰

龐大的測試用例數量

消費者契約的 API 測試的核心思想是： 只測試那些真正被實際使用到的 API 呼叫，如果沒有被使用到的，就不去測試；

微服務之間的耦合關係

契約的本質就是 Request 和 Response 的組合，基於契約的 Mock Service 完美地解決了 API 之間相互依賴耦合的問題；

25）掌握程式碼級測試的基本理念與方法

常見程式碼錯誤型別：

• 語法特徵錯誤，編譯語法發生錯誤；
• 邊界行為特徵錯誤；
• 經驗特徵錯誤，根據過往經驗發現程式碼錯誤；
• 演算法錯誤，程式碼完成的功能和之前設定的不一致，會直接影響到業務邏輯；
• 部分演算法錯誤，在一些特定的條件或者輸入情況下，演算法不能準確完成業務要求實現的功能，這是常見的型別；

程式碼級測試常用方法:

• 靜態方法，顧名思義就是在不實際執行程式碼的基礎上發現程式碼缺陷的方法，又可以進一步細分為人工靜態方法和自動靜態方法；
• 動態方法是指，通過實際執行程式碼發現程式碼中潛在缺陷的方法，同樣可以進一步細分為人工動態方法和自動動態方法。

這四類測試方法的特點，以及可以覆蓋的錯誤型別，可以概括如下：

• 人工靜態方法，本質上通過開發人員程式碼走查、結對程式設計、同行評審來完成的，理論上可以發現所有的程式碼錯誤，但也因為其對“測試人員”的過渡依賴，侷限性非常大；
• 自動靜態方法，主要的手段是程式碼靜態掃描，可以發現語法特徵錯誤、邊界行為特徵錯誤和經驗特徵錯誤這三類“有特徵”的錯誤；
• 人工動態方法，就是傳統意義上的單元測試，是發現演算法錯誤和部分演算法錯誤的最佳方式；
• 自動動態方法，其實就是自動化的邊界測試，主要覆蓋邊界行為特徵錯誤；

評論裡面有提及到，Facebook 開源的靜態分析工具 Infer，感興趣的可以看看；

26）深入淺出之靜態測試方法

人工靜態方法

• 程式碼走查，code review，開發人員減產程式碼；
• 結對程式設計，一個開發實現程式碼，另一個審查輸入的每一行程式碼；
• 同行評審，pull到master之前先稽核，類似code review；

自動靜態方法

常見的工具包括收費的企業級應用，比如Coverity。

其它免費的應用，比如Findbugs(Spotbugs), Java Checker Framework, PREfast, Splint, SPIN, Microsoft SLAM, PMD, Facebook Infer；

自動的特點在於：

• 相比於編譯器，可以做到對程式碼更加嚴格、個性化的檢查；
• 不真正檢測程式碼的邏輯功能，只是站在程式碼本身的視角，基於規則，儘可能多地去發現程式碼錯誤；

能發現很多小問題：

• 使用未初始化的變數；
• 變數在使用前未定義；
• 空指標引用等等；

27）深入淺出之動態測試方法

人工動態方法

也就是單元測試，測試基本用不著，不展開；

自動動態方法

基於程式碼自動生成邊界測試用例並執行來捕捉潛在的異常、崩潰和超時的測試方法；

如何實現邊界測試用例的自動生成？

根據被測函式的輸入引數生成可能的邊界值；
複製程式碼

28）解讀不同視角的軟體效能與效能指標

• 終端使用者是軟體系統的最終使用者；

終端使用者眼中的軟體效能

使用者在介面上完成一個操作開始，到系統把本次操作的結果以使用者能察覺的方式展現出來的全部時間；
複製程式碼

• 系統響應時間，細分為應用系統處理時間、資料庫處理時間和網路傳輸時間；
• 前端展示時間，取決於使用者端的處理能力；

運維人員眼中的軟體效能

軟體效能除了包括單個使用者的響應時間外，更要關注大量使用者併發訪問時的負載，以及在負載下的系統健康狀態、併發處理能力、當前部署的系統容量、可能的系統瓶頸、系統配置層面的調優、資料庫的調優，以及長時間執行穩定性和可擴充套件性；

開發人員眼中的軟體效能

在軟體設計開發人員眼中，軟體效能通常會包含演算法設計、架構設計、效能最佳實踐、資料庫相關、軟體效能的可測試性這五大方面；

• 演算法設計
• • 核心演算法的設計與實現是否高效；
• • 設計上是否採用 buffer 機制以提高效能，降低 I/O；
• • 是否存在潛在的記憶體洩露；
• • 是否存在併發環境下的執行緒安全問題；
• • 是否存在不合理的執行緒同步方式；
• • 是否存在不合理的資源競爭；
• 架構設計
• • 站在整體系統的角度，是否可以方便地進行系統容量和效能擴充套件；
• • 應用叢集、快取叢集、資料庫的可擴充套件性是否經過測試和驗證；
• 效能
• • 程式碼實現是否遵守開發語言的效能最佳實踐；
• • 關鍵程式碼是否在白盒級別進行效能測試；
• • 是否考慮前端效能的優化；
• • 必要的時候是否採用資料壓縮傳輸； 對於既要壓縮又要加密的場景，是否採用先壓縮後加密的順序；
• 資料庫
• • 資料庫表設計是否高效；
• • 是否引入必要的索引；
• • SQL 語句的執行計劃是否合理；
• • SQL 語句除了功能是否要考慮效能要求；
• • 資料庫是否需要引入讀寫分離機制；
• • 系統冷啟動後，快取大量不命中的時候，資料庫承載的壓力是否超負荷；
• 軟體效能的可測試性
• • 是否為效能分析（Profiler）提供必要的介面支援；
• • 是否支援高併發場景下的效能打點；
• • 是否支援全鏈路的效能分析。

效能測試人員眼中的軟體效能

三個最常用的指標：併發使用者數、響應時間，以及系統吞吐量；

併發使用者數

併發使用者數，包含了業務層面和後端伺服器層面的兩層含義；

• 業務層面的併發使用者數，指的是實際使用系統的使用者總數；
• 後端伺服器層面的併發使用者數，指的是“同時向伺服器傳送請求的數量”，直接反映了系統實際承載的壓力；

獲取使用者行為模式的方法，主要分為兩種：

• 對於已經上線的系統來說，往往採用系統日誌分析法獲取使用者行為統計和峰值併發量等重要資訊；
• 而對於未上線的全新系統來說，通常的做法是參考行業中類似系統的統計資訊來建模，然後分析；

響應時間

響應時間反映了完成某個操作所需要的時間，其標準定義是“應用系統從請求發出開始，到客戶端接收到最後一個位元組資料所消耗的時間”，是使用者視角軟體效能的主要體現；
複製程式碼

響應時間，可以分為前端展現時間和系統響應時間：

• 前端時間，又稱呈現時間，取決於客戶端收到伺服器返回的資料後渲染頁面所消耗的時間；
• 系統響應時間，可以劃分為web伺服器時間、應用伺服器時間、資料庫時間，以及各伺服器間通訊的網路時間；

系統吞吐量

是直接體現軟體系統負載承受能力的指標；

所有對吞吐量的討論都必須以“單位時間”作為基本前提；
複製程式碼

以不同方式表達的吞吐量可以說明不同層次的問題：

• Bytes/Second和Pages/Second表示的吞吐量，主要受網路設定、伺服器架構、應用伺服器制約，考察http或者業務層面；
• Requests/Second表示的吞吐量，主要受應用伺服器和應用本身實現的制約，考察系統層面或網路層面；

一個優秀的效能測試工程師，一般需要具有以下技能：

• 效能需求的總結和抽象能力；
• 根據效能測試目標，精準的效能測試場景設計和計算能力；
• 效能測試場景和效能測試指令碼的開發和執行能力；
• 測試效能報告的分析解讀能力；效能瓶頸的快速排查和定位能力； - 效能測試資料的設計和實現能力；
• 面對網際網路產品，全鏈路壓測的設計與執行能力，能夠和系統架構師一起處理流量標記、影子資料庫等的技術設計能力；
• 深入理解效能測試工具的內部實現原理，當效能測試工具有限制時，可以進行擴充套件二次開發；
• 極其寬廣的知識面，既要有“面”的知識，比如系統架構、儲存架構、網路架構等全域性的知識，還要有大量“點”的知識積累，比如資料庫 SQL 語句的執行計劃調優、JVM 垃圾回收（GC）機制、多執行緒常見問題等等；

小結

• 終端使用者希望自己的業務操作越快越好；
• 系統運維人員追求系統整體的容量和穩定；
• 開發人員以“效能工程”的視角關注實現過程的效能；
• 效能測試人員需要全盤考量、各個擊破；

最常用的指標：併發使用者數，響應時間，系統吞吐量：

• 併發使用者數包含不同層面的含義，既可以指實際的併發使用者數，也可以指伺服器端的併發數量；
• 響應時間也包含兩層含義，技術層面的標準定義和基於使用者主觀感受時間的定義；
• 系統吞吐量是最能直接體現軟體系統承受負載能力的指標，但也必須和其他指標一起使用才能更好地說明問題；

29）效能測試的基本方法與應用領域

併發使用者數、響應時間、系統吞吐量之間的關係

當系統併發使用者數較少時，系統的吞吐量也低，系統處於空閒狀態，這個階段稱為 “空閒區間”；
當系統整體負載並不是很大時，隨著系統併發使用者數的增長，系統的吞吐量也會隨之呈線性增長，稱為 “線性增長區間”；
隨著系統併發使用者數的進一步增長，系統的處理能力逐漸趨於飽和，因此每個使用者的響應時間會逐漸變長。相應地，系統的整體吞吐量並不會隨著併發使用者數的增長而繼續呈線性增長，稱為系統的“拐點”；
隨著系統併發使用者數的增長，系統處理能力達到過飽和狀態。此時，如果繼續增加併發使用者數，最終所有使用者的響應時間會變得無限長；相應地，系統的整體吞吐量會降為零，系統處於被壓垮的狀態，稱為“過飽和區間”；
複製程式碼

後端效能測試的測試負載，一般只會把它設計在線性增長區間內；而壓力測試的測試負載，則會將它設計在系統拐點上下，甚至是過飽和區間;

常用的七種效能測試方法

後端效能測試

也叫服務端效能測試，是通過效能測試工具模擬大量的併發使用者請求，然後獲取系統效能的各項指標，並且驗證各項指標是否符合預期的效能需求的測試手段；

這裡的效能指標，除了包括併發使用者數、響應時間和系統吞吐量外，還應該包括各類資源的使用率，比如系統級別的 CPU 佔用率、記憶體使用率、磁碟 I/O 和網路 I/O 等，再比如應用級別以及 JVM 級別的各類資源使用率指標等；

後端效能測試的場景設計主要包括以下兩種方式：

• 基於效能需求目標的測試驗證；
• 探索系統的容量，並驗證系統容量的可擴充套件性；

前端效能測試

通常來講，前端效能關注的是瀏覽器端的頁面渲染時間、資源載入順序、請求數量、前端快取使用情況、資源壓縮等內容，希望藉此找到頁面載入過程中比較耗時的操作和資源，然後進行有針對性的優化，最終達到優化終端使用者在瀏覽器端使用體驗的目的；

而業界普遍採用的前端測試方法，是根據雅虎前端團隊總結的優化規則，可以點選這裡檢視；

以下列出作者覺得重要的規則：

• 減少http請求次數，http請求數量越多，執行過程越長；
• 減少dns查詢次數，dns作用是將URL轉化為實際IP地址，是分級查詢，需要耗費20ms+；
• 避免頁面跳轉；
• 使用內容分發網路CDN；
• Gzip壓縮傳輸檔案，壓縮可以減少傳輸檔案大小，減少；

程式碼級效能測試

程式碼級效能測試，是指在單元測試階段就對程式碼的時間效能和空間效能進行必要的測試和評估，以防止底層程式碼的效率問題在專案後期才被發現的尷尬；

最常使用的改造方法是：

• 將原本只會執行一次的單元測試用例連續執行 n 次，這個 n 的取值範圍通常是 2000~5000；
• 統計執行 n 次的平均時間。如果這個平均時間比較長（也就是單次函式呼叫時間比較長）的話，比如已經達到了秒級，那麼通常情況下這個被測函式的實現邏輯一定需要優化；

壓力測試

壓力測試，通常指的是後端壓力測試，一般採用後端效能測試的方法，不斷對系統施加壓力，並驗證系統化處於或長期處於臨界飽和階段的穩定性以及效能指標，並試圖找到系統處於臨界狀態時的主要瓶頸點，壓力測試往往被用於系統容量規劃的測試；

配置測試

用於觀察系統在不同配置下的效能表現，通常使用後端效能測試的方法：

• 通過效能基準測試建立效能基線；
• 調整配置；
• 基於同樣的效能基準測試，找到特定壓力模式下的最佳配置；

這裡的配置是廣義，包含且不止：

• 宿主作業系統的配置；
• 應用伺服器的配置；
• 資料庫的配置；
• JVM的配置；
• 網路環境的配置；

併發測試

指的是在同一時間，同時呼叫後端服務，期間觀察被呼叫服務在併發情況下的行為表現，旨在發現諸如資源競爭、資源死鎖之類的問題；

可靠性測試

驗證系統在常規負載模式下長期執行的穩定性，本質就是通過長時間模擬真實的系統負載來發現系統潛在的記憶體洩漏、連結池回收等問題；

效能測試的應用領域

這裡“應用領域”主要包括能力驗證、能力規劃、效能調優、缺陷發現四大方面；

能力驗證

主要是驗證某系統能否在 A 條件下具有 B 能力，通常要求在明確的軟硬體環境下，根據明確的系統效能需求設計測試方案和用例；

能力規劃

能力規劃關注的是，如何才能使系統達到要求的效能和容量，通常情況下會採用探索性測試的方式來了解系統的能力；

能力規劃解決的問題，主要包括以下幾個方面：

• 能否支援未來一段時間內的使用者增長；
• 應該如何調整系統配置，使系統能夠滿足不斷增長的使用者數需求；
• 應用叢集的可擴充套件性驗證，以及尋找叢集擴充套件的瓶頸點；
• 資料庫叢集的可擴充套件性驗證；
• 快取叢集的可擴充套件性驗證；

效能調優

效能調優主要解決效能測試過程中發現的效能瓶頸的問題，通常會涉及多個層面的調整，包括硬體裝置選型、作業系統配置、應用系統配置、資料庫配置和應用程式碼實現的優化等等；

缺陷發現

通過效能測試的各種方法來發現諸如記憶體洩露、資源競爭、不合理的執行緒鎖和死鎖等問題；

最常用的測試方法主要有併發測試、壓力測試、後端效能測試和程式碼級效能測試；

30)後端效能測試工具原理與行業常用工具簡介

完整的後端效能測試應該包括效能需求獲取、效能場景設計、效能測試指令碼開發、效能場景實現、效能測試執行、效能結果報告分析、效能優化和再驗證；

使用效能測試工具獲得效能測試報告只是效能測試過程中的一個必要步驟而已，而得出報告的目的是讓效能測試工程師去做進一步的分析，以得出最終結論，並給出效能優化的措施；

效能測試場景設計

常用的工具

業內有很多成熟的後端效能測試工具，比如LoadRunner、JMeter、NeoLoad 等，還有很多雲端部署的後端效能測試工具或平臺，比如 CloudTest、Loadstorm、阿里的 PTS 等；

目前最主流的是jmeter，因為開源免費、靈活、功能也強大，適合網際網路企業；

而LR是按照併發使用者數收費的，而且LR對定製功能支援不是特別好，傳統企業用的會比較多；

原理

• 首先通過虛擬使用者指令碼生成器生成虛擬使用者指令碼；
• 然後根據效能測試場景設計的要求，通過壓力控制器控制協調各個壓力產生器以併發的方式執行虛擬使用者指令碼；
• 同時在測試執行過程中，通過系統監控器收集各種效能指標以及系統資源佔用率；
• 最後，通過測試結果分析器展示測試結果資料；

前端效能測試工具原理與行業常用工具簡介

webPagetest

是前端效能測試的利器：

• 可以為我們提供全方位的量化指標，包括頁面的載入時間、首位元組時間、渲染開始時間、最早頁面可互動時間、頁面中各種資源的位元組數、後端請求數量等一系列資料；
• 還可以自動給出被測頁面效能優化水平的評價指標，告訴哪些部分的效能已經做過優化處理了，哪些部分還需要改進；
• 同時，還能提供 Filmstrip 檢視、Waterfall 檢視、Connection 檢視、Request` 詳情檢視和頁面載入視訊慢動作；

引數解讀

First Byte Time

指的是使用者發起頁面請求到接收到伺服器返回的第一個位元組所花費的時間。這個指標反映了後端伺服器處理請求、構建頁面，並且通過網路返回所花費的時間；

本次測試的結果，首次開啟頁面（First View）花費的時間是 999 ms，重複開啟頁面（Repeat View）花費的時間是 860 ms。這兩個指標都在 1 s 以下，所以 WebPagetest 給出了 A 級的評分；

Keep-alive Enabled

要求每次請求使用已經建立好的連結，它屬於伺服器上的配置，不需要對頁面本身進行任何更改，啟用了 Keep-alive 通常可以將載入頁面的時間減少 40%~50％，頁面的請求數越多，能夠節省的時間就越多；

Compress Transfer

如果將頁面上的各種文字類的資源，比如 Html、JavaScript、CSS 等，進行壓縮傳輸，將會減少網路傳輸的資料量，同時由於 JavaScript 和 CSS 都是頁面上最先被載入的部分，所以減小這部分的資料量會加快頁面的載入速度，同時也能縮短 First Byte Time。

Compress Images

為了減少需要網路傳輸的資料量，影象檔案也需要進行壓縮處理。顯然本次測試結果顯示（圖 5），所有的 JPEG 格式圖片都沒有經過必要的壓縮處理，並且所有的 JPEG 格式圖片都沒有使用漸進式 JPEG（Progressive JPEG）技術，所以 WebPagetest 給出了 D 級的評分；

Cache Static Content

頁面上的靜態資源不會經常變化，所以如果你的瀏覽器可以快取這些資源，那麼當重複訪問這些頁面時，就可以從快取中直接使用已有的副本，而不需要每次向 Web 伺服器請求資源。這種做法，可以顯著提高重複訪問頁面的效能，並減少 Web 伺服器的負載。

WebPagetest 實際使用中需要解決的問題

第一個問題是，如果被測網站部署在公司內部的網路中，那麼處於外網的 WebPagetest 就無法訪問這個網站，也就無法完成測試。

要解決這個問題，你需要在公司內網中搭建自己的私有 WebPagetest 以及相關的測試發起機。具體如何搭建，點選這裡；

第二個問題是，用 WebPagetest 執行前端測試時，所有的操作都是基於介面操作的，不利於與 CI/CD 的流水線整合。

要解決這個問題，就必須引入 WebPagetest API Wrapper；

WebPagetest API Wrapper 是一款基於 Node.js，呼叫了 WebPagetest 提供的 API 的命令列工具。也就是說，你可以利用這個命令列工具發起基於 WebPagetest 的前端效能測試，這樣就可以很方便地與 CI/CD 流水線整合了。具體的使用步驟如下：

• 通過npm install webpagetest -g安裝該命令列工具；
• 訪問 https://www.webpagetest.org/getkey.php 獲取你的 WebPagetest API Key；
• 使用webpagetest test -k API-KEY 被測頁面 URL發起測試，該呼叫是非同步操作，會立即返回，併為你提供一個 testId；
• 使用webpagetest status testId查詢測試是否完成；
• 測試完成後，就可以通過webpagetest results testId檢視測試報告，但是會發現測試報告是個很大的 JSON 檔案，可讀性較差；
• 通過npm install webpagetest-mapper -g安裝webpagetest-mapper 工具，這是為了解決測試報告可讀性差的問題，將 WebPagetest 生成的 JSON 檔案格式的測試報告轉換成為 HTML 檔案格式；
• 使用Wptmap -key API-KEY --resultIds testId --output ./test.html將 JSON 檔案格式的測試結果轉換成 HTML 格式;

32-33)基於LoadRunner實現企業級伺服器端效能測試的實踐

LR的主要模組

Virtual User Generator

用於生成模擬使用者行為的測試指令碼，生成的手段主要是基於協議的錄製，也就是由效能測試指令碼開發人員在通過 GUI 執行業務操作的同時，錄製客戶端和伺服器之間的通訊協議，並最終轉化為程式碼化的 LoadRunner 的虛擬使用者指令碼；

LoadRunner Controller

Controller 相當於效能測試執行的控制管理中心，負責控制 Load Generator 產生測試負載，以執行預先設定好的效能測試場景；

同時，還負責收集各類監控資料；

LoadRunner Analysis

Analysis 是 LoadRunner 中一個強大的分析外掛；

不僅能圖形化展示測試過程中收集的資料，還能很方便地對多個指標做關聯分析，找出它們之間的因果關係；

最根本的目的就是，分析出系統可能的效能瓶頸點以及潛在的效能問題；

從巨集觀角度來講，基於 LoadRunner 完成企業級效能測試，可以劃分為五個階段：

• 效能需求收集以及負載計劃制定；
• 錄製並增強虛擬使用者指令碼；
• 建立並定義效能測試場景；
• 執行效能測試場景；
• 分析測試報告；

35）企業級實際效能測試案例與經驗分享

效能基準測試

是每次對外發布產品版本前都需要做的型別；

• 啟動速度；
• 同一介面響應時間；
• CPU佔用率；
• 幀率；
• 卡頓等

是需要用上一個版本資料做基準，在同一操作環境下進行對比，目的是為了保證新版本整體效能不會下降；

穩定性測試

又稱可靠性測試，主要是通過長時間（7*24 小時）模擬被測系統的測試負載，來觀察系統在長期執行過程中是否有潛在的問題；

移動端裡面典型的就是monkey，一般來說，穩定性是釋出前的硬性要求；

併發測試

併發測試，是在高併發情況下驗證單一業務功能的正確性以及效能的測試手段；

容量規劃測試

是軟體產品為滿足使用者目標負載而調整自身生產能力的過程；

容量規劃的主要目的是，解決當系統負載將要達到極限處理能力時，應該如何通過垂直擴充套件（增加單機的硬體資源）和水平擴充套件（增加叢集中的機器數量）增加系統整體的負載處理能力的問題；
複製程式碼

35-38）測試資料的準備/構造

這4章都是講測試資料相關，之前也單獨提煉出一篇文章，這裡不重複，直接點選這裡檢視；

39)什麼是Selenium Grid

本篇都在講selenium grid相關，之前jb看了蟲師的selenium2的書籍，也做了一些筆記，裡面也有提及到selenium grid，因此這裡不打算重複描述，內容相似，點選[這裡]juejin.im/post/5bcd84…)檢視；

40-41） 聊聊測試執行環境的架構設計

測試執行環境

• 狹義的測試執行環境，單單指測試執行的機器或者叢集；
• 廣義的測試執行環境，除了包含具體執行測試的測試執行機以外，還包括測試執行的機器或者叢集的建立與維護、測試執行叢集的容量規劃、測試發起的控制、測試用例的組織以及測試用例的版本控制等等；

廣義的測試執行環境，也稱測試基礎架構；

測試基礎架構可以解決的問題：

• 簡化測試執行過程；
• 最大化測試執行機器的資源利用率；
• 提供大量測試用例的併發執行能力；
• 提供測試用例的版本控制機制；
• 提供友好的使用者介面；

因此在設計測試基礎架構，需要考慮幾個方面：

• 對使用者而言，測試基礎架構的透明性；
• 對維護者而言，技術基礎架構的易維護性；
• 做到對大量測試用例併發執行的可擴充套件性；
• 兼顧移動 App對測試執行環境的需求；

早期的測試基礎架構

將測試用例儲存在程式碼倉庫中，然後是用 Jenkins Job來pull程式碼並完成測試的發起工作；

在這種架構下，自動化測試用例的開發和執行流程，是按照以下步驟執行的：

• 自動化測試開發人員在本地機器開發和除錯測試用例；
• 將開發的測試用例程式碼push到程式碼倉庫；
• 在jenkins中建立一個job，用於發起測試的執行，先從測試用例程式碼倉庫中 Pull 測試用例程式碼，併發起構建操作；然後，在遠端或者本地固定的測試執行機上發起測試用例的執行；

弊端是對測試執行機器資訊不可知，比如ip等是否發生變化、環境是否一致；

經典的測試基礎架構

利用selenium Grid代替早期的遠端或本地固定的測試執行機器；

每次發起測試時，就不再需要指定具體的測試執行機器了，只要提供固定的 Selenium Hub 地址就行，然後 Selenium Hub 就會自動幫你選擇合適的測試執行機；

在測試規模比較少的情況下，可以採用第一種方式，但一旦規模龐大起來，就需要調整了；

基於 Docker 實現的 Selenium Grid 測試基礎架構

Selenium Grid雖然能解決問題，但是隨著測試用例的增加，需要維護多個Node，因此引入docker代替原來的方案，可以降低維護成本：

• 由於 Docker 的更新維護更簡單，只要維護不同瀏覽器的不同映象檔案即可，而無需為每臺機器安裝或者升級各種軟體；
• Docker 輕量級的特點，使得 Node 的啟動和掛載所需時間大幅減少，直接由原來的分鐘級降到了秒級；
• Docker 高效的資源利用，使得同樣的硬體資源可以支援更多的 Node，可以在不額外投入硬體資源的情況下，擴大 Selenium Grid 的併發執行能力；

引入統一測試執行平臺的測試基礎架構

隨著專案數量增加，jenkins配置時間也會增加，因此作者提出實現一個GUI介面系統來管理和執行這些jenkins job；

• 測試用例的版本化管理；
• 提供基於restful api的測試執行介面供CI/CD使用；

基於 Jenkins 叢集的測試基礎架構

單個 Jenkins 成了整個測試基礎架構的瓶頸節點。因為，來自於統一測試執行平臺的大量測試請求，會在 Jenkins 上排隊等待執行，而後端真正執行測試用例的 Selenium Grid 中很多 Node 處於空閒狀態；

測試負載自適應的測試基礎架構

引入了 Jenkins 叢集后，整個測試基礎架構已經很成熟了，基本上可以滿足絕大多數的測試場景了;

但是，還有一個問題一直沒有得到解決，那就是： Selenium Grid 中 Node 的數量到底多少才合適？

為了解決這種測試負載不均衡的問題，Selenium Grid 的自動擴容和收縮技術就應運而生了；

如何選擇適合自己的測試基礎架構

如果所在的企業如果規模不是很大，測試用例執行的總數量相對較少，而且短期內也不會有大變化的情況，那麼測試基礎架構完全就可以採用經典的測試基礎架構，而沒必要引入 Docker 和動態擴容等技術；

如果是大型企業，測試用例數量龐大，同時還會存在釋出時段大量測試請求集中到來的情況，那麼此時就不得不採用 Selenium Gird 動態擴容的架構了，而一旦要使用動態擴容，那麼勢必你的 Node 就必須做到 Docker 容器化，否則無法完全發揮自動擴容的優勢；

因此根據不同的情況而酌情選擇，是由測試需求推動的；

42）大型全球化電商的測試基礎架構設計

大型全球化電商網站全域性測試基礎架構的設計思路，可以總結為測試服務化；

也就是說，測試過程中需要用的任何功能都通過服務的形式提供，每類服務完成一類特定功能，這些服務可以採用最適合自己的技術棧，獨立開發，獨立部署；

理想的測試基礎架構，應該包含6種不同的測試服務：

統一測試執行服務

通過 Spring Boot 框架提供 Restful API，內部實現是通過排程 Jenkins Job 具體發起測試；

本質是統一測試執行平臺；

統一測試資料服務

統一測試資料平臺；

測試執行環境準備服務

這裡測試執行環境，特指具體執行測試的測試執行機器叢集： 對於 GUI 自動化測試來說，指的就是 Selenium Grid； 對於 API 測試來說，指的就是實際發起API呼叫的測試執行機器叢集；

被測系統部署服務

主要是被用來安裝部署被測系統和軟體；

被測報告服務

主要作用是為測試提供詳細的報告；

全域性測試配置服務

本質是要解決測試配置和測試程式碼的耦合問題；

43）探索性測試

什麼是探索性測試

• 探索式測試是一種軟體測試風格，而不是一種具體的軟體測試技術；
• 作為一種思維方法，探索式測試強調依據當前語境與上下文選擇最適合的測試技術，並且強調獨立測試工程師的個人自由和責任，其目的是為了持續優化其工作價值；
• 在整個專案過程中，將測試相關學習、測試設計、測試執行和測試結果解讀作為小相互支援的活動，並行執行；

如何開展探索性測試

• 會對軟體的單一功能進行比較細緻的探索式測試，主要是基於功能需求以及非功能性需求進行擴充套件和延伸；
• 開展系統互動的探索性測試，採用基於反饋的探索性測試方法；

探索性測試更多關注的就是循序漸進，迭代深入的過程；

44）測試驅動開發TDD

測試驅動開發，也就是 Test-Driven Develop，通常簡稱為 TDD；

核心思想，是在開發人員實現功能程式碼前，先設計好測試用例的程式碼，然後再根據測試用例的程式碼編寫產品的功能程式碼；

最終目的是讓開發前設計的測試用例程式碼都能夠順利執行通過；

TDD優勢

• 保證開發的功能一定是符合實際需求的；
• 更加靈活的迭代方式；
• 保證系統的可擴充套件性；
• 更好的質量保證；
• 測試用例即文件；

測試驅動開發的實施過程

• 需要實現的新功能新增一批測試；
• 執行所有測試，看看新新增的測試是否失敗；
• 編寫實現軟體新功能的實現程式碼；
• 再次執行所有的測試，看是否有測試失敗；
• 重構程式碼；
• 重複以上步驟直到所有測試通過；

TDD的難點

• 需要一定的程式碼能力；
• 推動TDD，需要改革整個研發流程；

TDD放大到開發流程

評論裡有一套開發流程，可以參考下：

• 所有人員參與需求評審；
• 測試編寫測試用例；
• 所有人員參與用例評審；
• 開發按照測試用例進行編碼；
• 開發執行用例，自測，到用例通過後；
• 開發提測；
• 測試介入測試；

好處：

• 提早發現不合理需求，減少後面返工的機率；
• 研發自測，提高自測質量；

以上是評論區看到的，僅供參考；

45）精準測試

核心思想

藉助一定的技術手段、通過演算法的輔助對傳統軟體測試過程進行視覺化、分析以及優化的過程，使得測試過程可視、智慧、可信和精準；

擁有幾個特徵：

• 是對傳統測試的補充；
• 採用的是黑盒與白盒相結合的模式；
• 資料可信度高；
• 不直接面對產品程式碼；
• 與平臺無關，多維度的測試分析演算法系統；

雙向mapping關係

是通過程式碼覆蓋率工具來實現的；

• 基於該產品的開發語言，選擇好一款程式碼覆蓋率工具，然後把測試用例到產品程式碼這條路打通；
• 再通過這些程式碼覆蓋率工具的APIs，等到跑完這個測試用例，拿到原始檔 、Class，Method，Line等相關資訊；
• 把測試用例資訊以及上面拿到的mapping資訊記錄表中，這樣就形成了雙向mapping；
• 這樣一旦程式碼修改，可以通過class，method等資訊，去資料庫搜到關聯的測試用例，就能實現精準測試了；

46) 滲透測試

滲透測試的定義

滲透測試指的是，由專業安全人員模擬黑客，從其可能存在的位置對系統進行攻擊測試，在真正的黑客入侵前找到隱藏的安全漏洞，從而達到保護系統安全的目的；

滲透測試的常用方法

針對性測試

針對性的測試，屬於研發層面的滲透測試；

參與這類測試的人員，可以得到被測系統的內部資料，包括部署資訊、網路資訊、詳細架構設計，甚至是產品程式碼；

需要完全瞭解系統內部情況的前提下開展；

外部測試

外部測試，是針對外部可見的伺服器和裝置（包括：域名伺服器（DNS）、Web 伺服器或防火牆、電子郵箱伺服器等等），模擬外部攻擊者對其進行攻擊，檢查它們是否能夠被入侵，以及如果被成功入侵了，會被入侵到系統的哪一部分、又會洩露多少資料；

一般是不清楚系統內部情況下開展的；

內部測試

由測試工程師模擬內部人員，在內網（防火牆以內）進行攻擊，因此測試人員會擁有較高的系統許可權，也能夠檢視各種內部資料，目的是檢查內部攻擊可以給系統造成什麼程度的損害；

盲測

盲測，指的是在嚴格限制提供給測試執行人員或團隊資訊的前提下，由他們來模擬真實攻擊者的行為和上下文；

雙盲測試

雙盲測試可以用於測試系統以及組織的安全監控和事故識別能力，及其響應過程。一般來說，雙盲測試一般是由外部的專業滲透測試專家團隊完成，所以實際開展雙盲測試的專案並不多；

執行滲透測試的步驟

• 規劃和偵察，包含定義測試的範圍和目標、初步確定要使用的工具和方法、明確需要收集的情報；
• 安全掃描，分為靜態和動態分析；
• 獲取訪問許可權，比如sql輸入、xss指令碼攻擊等方式來發現系統漏洞；
• 維持訪問許可權；
• 入侵分析，可以被利用的特定漏洞、利用該漏洞的具體步驟、能夠被訪問的敏感資料；

常用的工具

Nmap

是進行主機檢測和網路掃描的重要工具。它不僅可以收集資訊，還可以進行漏洞探測和安全掃描，從主機發現、埠掃描到作業系統檢測和 IDS 規避 / 欺騙；

Aircrack-ng

是評估 Wi-Fi 網路安全性的一整套工具。它側重於 WiFi 安全的領域，主要功能有：網路偵測、資料包嗅探、WEP 和WPA/WPA2-PSK 破解；

sqlmap

是一種開源的基於命令列的滲透測試工具，能夠自動進行 SQL 注入和資料庫接入；

Wifiphisher

是一種惡意接入點工具，可以對 WiFi 網路進行自動釣魚攻擊；

AppScan

一款企業級商業 Web 應用安全測試工具，採用的是黑盒測試，可以掃描常見的 Web 應用安全漏洞；

原理：

• 從起始頁爬取站下所有的可見頁面，同時測試常見的管理後臺；
• 利用 SQL 注入原理測試所有可見頁面，是否在注入點和跨站指令碼攻擊的可能；
• 同時，檢測 Cookie 管理、會話週期等常見的 Web 安全漏洞；

47）基於模型的測試

MBT的基本原理

MBT 是一種基於被測系統的模型，由工具自動生成測試用例的軟體測試技術；

原理是通過建立被測系統的設計模型，然後結合不同的演算法和策略來遍歷該模型，以此生成測試用例的設計；

開發者首先根據產品需求或者說明來構建模型，然後結合測試物件生成測試用例，測試用例針對測試物件執行完之後，生成測試報告比對測試結果；

常用模型簡介

有限狀態機

有限狀態機可以幫助測試人員根據選中的輸入來評估輸出，不同的輸入組合對應著不同的系統狀態；

狀態圖

狀態圖是有限狀態機的延伸，用於描述系統的各種行為，尤其適用於複雜且實時的系統；

UML

UML 即統一建模語言，是一種標準化的通用建模語言;

UML 可以通過建立視覺化模型，來描述非常複雜的系統行為;

工具簡介

BPM-X

BPM-X 根據不同的標準（比如，語句、分支、路徑、條件）從業務流程模型建立測試用例；

fMBT fMBT 是一組免費的、用於全自動測試生成和執行的工具，也是一組支援高水平測試自動化的實用程式和庫，主要被應用在 GUI 測試中；

GraphWalker

GraphWalker 以有向圖的形式讀取模型，讀取這些模型，然後生成測試路徑，更適合於多狀態以及基於事件驅動的狀態轉換的後臺系統；

MBT優勢

• 測試用例維護更輕鬆；
• 軟體缺陷發現的更早；
• 測試自動化的水平更高；
• 測試覆蓋率變的更高；
• 基於模型間接維護測試用例的方式更高效；

MBT劣勢

• 學習成本較高；
• 初期投資較大；
• 根據模型生成測試用例的技術並不是非常成熟；

49)深入淺出網站高效能架構設計

前端的高效能架構

前端高效能架構比較直觀易懂，其本質就是通過各種技術手段去優化使用者實際感受到的前端頁面展現時間。

後端伺服器的高效能架構

快取

• 瀏覽器級別的快取，用來儲存之前在網路上下載過的靜態資源；
• CDN本質就是快取，屬於部署在網路服務供應商機房中的快取；
• 反向代理伺服器也是快取，屬於使用者資料中心最前端的快取；
• 資料庫中的熱點資料，在應用伺服器叢集中有一級快取，在快取服務叢集中有二級快取；

讀取快取的處理：

• 如果讀取成功，很大程度降低訪問資料庫的時間開銷；
• 如果沒有讀取到或者失效，則會訪問資料庫獲取，獲取到後，會把資料寫入快取裡，以備下次使用；

快取主要用來儲存那些相對變化較少，並且遵從“二八原則”的資料；這裡的“二八原則”指的是 80% 的資料訪問會集中在 20% 的資料上；

快取技術並不適用於那些需要頻繁修改的資料；

與快取相關的測試場景：

• 對於前端，需要考慮快取命中和不命中下的頁面載入時間；
• 基於快取過期的設計，需要考慮到重新獲取資料的測試場景；
• 快取髒資料，即資料庫已經更新了，但是快取的資料還沒更新；
• 快取穿透，即資料不存在，這類資料會一直重複訪問資料庫；
• 分散式快取叢集，不同叢集快取演算法可能不同，需要進行測試和評估；

叢集

• 叢集容量擴充套件，新增節點，是否會對原有的session會有影響；
• 對於無狀態的應用，是否可以實現靈活的實效轉移；
• 當叢集出現當機時，對線上使用者的影響評估；
• 負載均衡演算法的效果；
• 高併發場景下，叢集能夠承載的最大容量；

50）深入淺出網站高可用架構設計

網站高可用指的就是，在絕大多的時間裡，網站一直處於可以對外提供服務的正常狀態，業界通常使用有多少個“9”來衡量網站的可用性指標，具體的計算公式也很簡單，就是一段時間內（比如一年）網站可用的時間佔總時間的百分比；

• 基本可用，99%；
• 較高可用，99.9%；
• 具備故障自動恢復能力的可用，99.99%；
• 極高可用，99.999%；

造成網站不可用的主要原因

伺服器硬體故障

如當機，需要保障的是即使出現了硬體故障，也要保證系統的高可用；

解決方案就是從硬體層面加入必要的冗餘，同時充分發揮叢集的牲口優勢；

這樣就需要準備至少兩臺同樣的伺服器，當其中一臺當機的時候，另外一臺能正常對外服務；

那麼，從測試人員的角度來看，我們依舊可以針對這種情況設計出針對部分資料伺服器發生故障時的測試用例，以完成系統應對故障的反應情況的測試。

釋出新應用的過程

在釋出過程，會因為部署新版本而重啟伺服器的情況，會導致短暫時間不可用；

解決方案就是灰度釋出，前提是伺服器必須採用叢集架構；

假如有N個節點的叢集需要更新新版本，這時候更新過程是這樣的：

• 從負載均衡器的伺服器列表中刪除其中的一個節點；
• 將新版本的應用部署到這臺刪除的節點中並重啟該服務；
• 重啟完成後，將包含新版本應用的節點重新掛載到負載均衡伺服器中，讓其真正接受外部流量，並嚴密觀察新版本應用的行為；
• 如果沒有問題，那麼將會重複以上步驟將下一個節點升級成新版本應用，如果有問題，就會回滾這個節點的上一個版本；
• 如此反覆，直至叢集的節點全部更新為新版本應用；

程式本身的問題

• 上線前回歸測試；
• 預釋出驗證；
• 線上日誌監控；

預釋出的原因是因為，經常出現測試環境沒問題，生產環境有問題，可能是因為網路、資料量、依賴的第三方庫不一樣等各種原因導致，而預釋出環境的要求是跟生產環境一模一樣，只是不會對外暴露而已；

叢集、分散式、微服務

該內容文中沒有提及到，是jb自行補充的，直接找了逼乎的例子；

分散式&叢集：分散壓力； 微服務：分散能力；

分散式一般部署到多臺，而多臺關聯的機器，可以稱為叢集；

• 分散式
• • 不同模組部署在不同伺服器上；
• • 作用：分散式解決網站高併發帶來問題；
• 叢集
• • 相同的服務多臺伺服器部署相同應用構成一個叢集；
• • 作用：通過負載均衡裝置共同對外提供服務，提供高效能；
• 微服務
• • 架構設計概念,各服務間隔離；
• • 作用：各服務可獨立應用，組合服務也可系統應用，各能力獨立，相互不影響；

廚房例子

• 當業務量過多，單機服務忙不過來，那麼多請幾個廚師，這是簡單的複製，增加人手，可以理解為一群人做事，是叢集；
• 簡單複製的話，一個廚師請假，服務不會fail，廚師長可以做負載均衡工作；
• 如果廚房斷水斷電，再多廚師也白搭。分散式並不是將業務切分為買菜，洗菜，切菜，配菜，做菜，這叫微服務，不是分散式；
• 而每一個工序都可以是分散式的，如果有必要的話。為了滿足更惡劣的條件，斷水斷電，廚師罷工，服務仍然可用，對廚房進行分散式改造，在多個地點設定廚房，每個廚房不需要包含所有工序，但不允許一個工序只在一個廚房，即分割槽容錯性；
• 同時，付出的代價是一道菜可能有多個副本，防止突發事件使得一道菜的原料丟失；
• 簡單複製的叢集當然具有分割槽容錯性，因為都一樣；
• 微服務可以使廚師專注於自己的工序，為了讓微服務能夠頂住惡劣的生存環境，需要分散式和叢集，整個廚房是分散式的，但其中的一個工序既可以是簡單複製負載平衡，也可以是一個小的，獨立的分散式；

月嫂例子：

單體架構

家裡生小寶寶啦，由於自己沒有照顧小寶寶的經驗，所以請了位經驗豐富的月嫂。 這位月嫂從買菜，到做飯，洗衣，拖地，餵奶，哄睡，洗澡，換紙尿褲，擦屁股，做排氣操，夜間陪護，給奶媽做月子餐等等，全部都做， 這種叫做單體架構。

叢集

什麼都做，一個月嫂怎麼夠呢，肯定忙不過來呀，那就請兩個月嫂吧，這叫做叢集；

高可用

有一個月嫂過生日，想請假回去和親戚打一天麻將。如果只有一個月嫂，她走了，就叫做服務中斷了；

但是因為做了叢集，有兩個月嫂，走了一個，另一個還是能用，雖然相比較吃力一些，但是畢竟還是能用的，這個現象叫做高可用；

分散式

一個月嫂，一個月的費用基本上都要1萬多，還有房貸，還有車貸，生活費用還高，實在是請不起兩位啊，那就還是請一位吧；

可是事情那麼多，她實在忙不過來，怎麼辦呢？ 那就把爺爺請過來買菜，把奶奶請過來做飯。 這樣服務本來僅僅是由月嫂一人提供的，變成了和寶寶相關的由月嫂負責，採購由爺爺負責，餐飲由奶奶負責。 這就叫做分散式了；

低耦合

做寶寶服務的月嫂去打麻將了，不影響做飯的奶奶。 做採購的爺爺去喝酒了，也不影響月嫂的寶寶服務，這叫做低耦合；

高內聚

和寶寶相關的事情都是月嫂在做，月嫂兌奶方式快慢，只會影響自己，對爺爺和奶奶的服務沒影響. 這叫做高內聚；

叢集+分散式

奶奶一個人做飯，做久了也煩啊，也累啊，也想打麻將呀。 那麼就把姥姥也請過來吧。 這樣做飯這個服務，就由奶奶和姥姥這個叢集來承擔啦。她們倆，誰想去汗蒸了，都有另一位繼續提供做飯服務。

這就叫做叢集+分散式；

51）深入淺出網站伸縮性架構設計

可伸縮性和可擴充套件性的概念區別

可伸縮性，指的是通過簡單地增加硬體配置而使服務處理能力呈線性增長的能力，最簡單直觀的例子，就是通過在應用伺服器叢集中增加更多的節點，來提高整個叢集的處理能力；

可擴充套件性，指的是網站的架構設計能夠快速適應需求的變化，當需要增加新的功能實現時，對原有架構不需要做修改或者做很少的修改就能夠快速滿足新的業務需求；

分層的可伸縮性架構

• 根據功能進行物理分離來實現伸縮；
• 物理分離後的單一功能通過增加或者減少硬體來實現伸縮；

從整體架構的角度來看，應用伺服器、快取叢集和資料庫伺服器各自都有適合自己的可伸縮性設計策略：應用伺服器主要通過叢集來實現可伸縮性，快取叢集主要通過 Hash 一致性演算法來實現，資料庫可以通過業務分庫、讀寫分離、分散式資料庫以及 NoSQL 來實現可伸縮性；

52）深入淺出網站可擴充套件性架構設計

從技術實現上來看，訊息佇列是實現可擴充套件性的重要技術手段之一；

其基本核心原理是各模組之間不存在直接的呼叫關係，而是使用訊息佇列，通過生產者和消費者模式來實現模組間的協作，從而保持模組與模組間的鬆耦合關係；

引入訊息佇列後，測試資料的建立和測試結果的驗證工作，都需要通過讀寫訊息佇列來完成。同時，我們還要考慮到訊息佇列滿、訊息佇列擴容，以及訊息佇列伺服器當機情況下的系統功能驗證；

53）全鏈路壓測

全鏈路壓測，是基於真實的生產環境來模擬海量的併發使用者請求和資料，對整個業務鏈路進行壓力測試，試圖找到所有潛在效能瓶頸點並持續優化的實踐；

全鏈路壓測的應用場景，不僅僅包括驗證系統在峰值期間的穩定性，還會包含新系統上線後的效能瓶頸定位以及站點容量的精準規劃；

單系統獨立壓測

• 根據設計的壓力來直接模擬大量的併發呼叫；
• 先獲取線上真是的流量請求，資料清洗，回放模擬大量的併發呼叫；

都會涉及到流量模擬、資料準備、資料隔離等常規操作；

侷限性：

• 單系統壓測的時候，會假設其依賴的所有系統能力都是無限的，而實際情況一定不是這樣，這就造成了單系統壓測的資料普遍比較樂觀的情況；
• 在大壓力環境下，各系統間的相互呼叫會成為系統瓶頸，但這在單系統壓測的時候根本無法體現；
• 大壓力環境下，各系統還會出現搶佔系統資源（比如網路頻寬、檔案控制程式碼）的情況，這種資源搶佔必然會引入效能問題，但是這類問題在單系統壓測過程中也無法體現出來；
• 由於是單系統測試，所以通常都只會先選擇最核心的系統來測試，這就意味著其他的非核心繫統會被忽略，而在實際專案中，這些非核心繫統也很有可能會造成效能瓶頸；

全鏈路的難點

海量併發請求的發起

這種情況一般會採用jmeter，因為LR是按併發使用者數費用，費用高；

難點：

• 採用了分散式的 JMeter 方案，併發數量也會存在上限，因此會改用Jenkins Job單獨呼叫 JMeter 節點來控制和發起測試壓力，因為jmeter是相互獨立，只有jenkins job足夠多，就可以發起足夠大的併發；
• 測試指令碼、測試資料和測試結果在分散式 JMeter 環境中的分發難題，解決方案就是基於jmeter搭建一個壓測框架，如指令碼分發、資料分發以及結果回傳等都由平臺完成；
• 流量發起的地域要求，需要在不同城市的資料中心搭建jmeter slave；

全鏈路壓測流量和資料的隔離

需要對壓測流量進行特殊的資料標記，以區別於真實的流量和資料；

實際業務負載的模擬

這裡的難點主要體現在兩個方面：

• 要估算負載的總體量級；
• 需要詳細瞭解總負載中各個操作的佔比情況以及執行頻次；

業界通常採用的策略是，採用已有的歷史負載作為基準資料，然後在此基礎上進行適當調整；

具體到執行層面，通常的做法是，錄製已有的實際使用者負載，然後在此基礎上做以下兩部分修改：

• 錄製資料的清晰，將錄製得到的真實資料統一替換成為壓測準備的資料；
• 基於使用者模型的估算，在壓測過程中，按比例放大錄製指令碼的負載；

真實交易和支付的撤銷以及資料清理

對這些交易的流量和資料進行了特定標記，可以比較方便地篩選出需要撤銷的交易，然後通過自動化指令碼的方式來完成批量的資料清理工作；