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；

全鏈路壓測流量和數據的隔離

須要對壓測流量進行特殊的數據標記，以區別於真實的流量和數據；

實際業務負載的模擬

這裏的難點主要體如今兩個方面：

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

業界一般採用的策略是，採用已有的歷史負載做爲基準數據，而後在此基礎上進行適當調整；

具體到執行層面，一般的作法是，錄製已有的實際用戶負載，而後在此基礎上作如下兩部分修改：

• 錄製數據的清晰，將錄製獲得的真實數據統一替換成爲壓測準備的數據；
• 基於用戶模型的估算，在壓測過程當中，按比例放大錄製腳本的負載；

真實交易和支付的撤銷以及數據清理

對這些交易的流量和數據進行了特定標記，能夠比較方便地篩選出須要撤銷的交易，而後經過自動化腳本的方式來完成批量的數據清理工做；