關於效能測試的這點事，值得收藏~

問： 效能測試最好什麼時候開始更好？需求階段、設計階段、還是測試階段？

答： 有些同事在測試幾輪之後，功能穩定了開始介入效能測試，這時才發現效能根本支撐不了預期值。這個時候 開發 再回頭進行系統調優，如果事先選的架構能支撐就好，如果不能達不到預期值，後面討論或者請教高手發現原先的架構 缺陷 ，再調整架構代價就非常大。基本導致前期的 功能測試 成果作廢。其實各個階段都有事情做。需求階段可以整理，評審出效能需求，評審需求可行性時就考慮好資料量和使用者量。設計階段--對預估的需求做設計，舉個例子。背景：我們現在使用的是 mysql資料庫 （公司去oracle化），我們要從一個5000W的一個資料表的6個不同查詢維度查詢資料，比如說城市、行業、地址型別、愛好、性別、時間範圍。這樣對於 mysql 的查詢常見的最佳化設計可能是分表、建立索引，但，對於這個場景就不好處理了。資料耦合強，沒有辦法分表。索引，組合索引太多。後面的處理辦法是用mongodb、nosql的方法解決。對於編碼和測試階段可以這樣去分不同階段做不同事情。

編碼階段，可以提出需要，讓研發透過 單元測試 （開多執行緒）的方式進行壓力測試。進行一些單元壓力測試測試階段---測試階段也有策略的，建議先做一下單一場景單一使用者的效能測試。常常會遇到有些同事在沒有壓單個場景的情況下，就進行負載測試，到處定位瓶頸，最後發現單一使用者單一場景都是問題。這就是繞了一圈回到了起點。對於不同類別測試後面會專門的chat介紹。

問： 怎樣才能更有效的獲得效能需求？以便更好設計、執行效能測試。平時做的基本是根據專案歷史資料，或者根據經驗想出來的，這樣經常會漏測，導致上線後新的效能問題出現，唐總有沒好的建議或經驗分享下。

答： 獲取效能需求，可以一下步驟：

收集。

分析。

比如業務人員很多，底層給中層、再給高層。

分析歷史資料、競品、業務。業務需要分析業務常見、業務高峰（大的時間和小的時間段）

效能問題還存在可以細分一下是場景遺漏、還是資料遺漏。場景遺漏常常由於需求傳遞變味導致。

處理方法。 做好策略和設計，如果針對現在的問題：可以做一個checklist不斷最佳化你的策略設計能力。

問： 文章有說透過資料分析識別瓶頸問題，能否稍展開，有沒有具體的方法、流程步驟等，還是主要靠經驗？效能測試剛入門，請大師指點。

答： 效能瓶頸分析有專場的chat，本次就談一下瓶頸分析幾大原則和幾個關注可以參考：

邏輯極簡化原則：就是去繁為簡。

割據分段法：就是假設問題最可能出現在什麼地方,分段分析，使用打樁的方法。

路由堵截法：就是從壓力產生的資料流向開始分析。

資源監控法：資源監控，主要關注資源有：

CPU（使用者佔用<透過演算法最佳化等方法解決>、系統佔用<堵篩>）

記憶體（頁面失效（軟頁面和硬頁面）可以剩餘記憶體、可以快取）

磁碟I/O

網路

程式（處理器時間、程式產生的頁面失效、程式所分配的無法與其他程式共享的當前位元組數量，看是否有記憶體洩露等）

儲存，也需要關注。

問： 在做效能測試時，為了追求模擬資料的真實性，我傾向於把能引數化的欄位都做成引數，但是很顯然過多的引數會給客戶端帶來不少的效能壓力。所以有時想想，其實我們是不是可以走另一個極端，只引數化那些已知與效能有關的那些欄位，其他欄位一律寫死就行了？但是這樣會不會導致有些欄位其實也會影響效能，只是自己認為不影響，從而漏測一些效能問題？

答：  我個人是認可的，但我們要具體分析一下。為什麼要引數化，更多的人會是是為了模擬真實情況。其實大家想問的是，什麼才叫真實情況。有人會說是使用者的實際場景。我個人認為這是表面現象。真實情況應該是：能模擬磁碟、CPU、記憶體的真實情況，才是我們 測試人員 想要的真實情況。 業務的真實情況最後都會變成對資源的消耗情況。

快取的存在與否，比如大家都知道資料庫有快取、CPU有快取那麼產生模擬真實資料的原因更多再也此，我們要規避不需快取的時候快取了、以及合理的模擬快取，根據真實架構設計來設計測試資料。

資料庫歷史資料（業務基礎資料量和質量是否滿足）；資料庫業務交易資料是否滿足，資料的單一問題是否帶來查詢壓力減輕了，不能模擬真實情況。

測試資料的寫死，是否到賬業務場景遺漏。比一些邊界場景和一下主流場景組合的綜合場景。特別是這種組合很容易遺漏，非主流+主流。

斷言（檢查點）是否能滿足，出現過多次的真實案例，不設定檢查點。去掉直接認為沒有必要的請求。在動靜分離的系統中，去掉了靜態資源請求，結果上線後靜態資源 伺服器 被壓死了。一個原則，就是會給資源帶來壓力的真實情況一個都不放過，這就是引數化和資料準備的原則。

問： 老師怎麼看待js的效能，以及測試如何下手這個環節。開發認為js效能受終端配置影響嚴重且多數使用者會自認為是不是我的網不好之類的，從而忽略掉這個環節的效能測試。

答： 首先，效能是設計出來的不是被測試出來的。這個文章中有提到。因此一個好的效能需要做好前期的效能可行性設計。沒有這個流程的同學，建議研發流程中加入，效能可行性設計。給出現狀（使用工具檢視現狀）：js效能工具: JSLitmus、jsperf、chrome瀏覽器的profile等。可以檢查網頁效能情況比如chrome的profeil，操作簡單，錄製+停止。

可以用工具看到js大小，載入速度等，還可以看看研發的程式碼。要讓研發動起來就的找方法：js常見的最佳化方法：建議動靜分離、建議壓縮、建議快取、建議版本標示、檔案合併、方法抽象、避免全域性、解耦html和css，具體方法很多。動靜分離是常見的。就是把，js、圖片、css等靜態檔案放到不同的伺服器上。js由於是靜態資源，可以做動靜分離，來減輕伺服器壓力。js做快取，js由於版本特徵明顯，需要做好版本標示，保證不會由於快取帶來功能問題。tags可以透過程式碼或設定中介軟體如gizp壓縮（壓縮登記等），其實不光js前臺的圖片等都有很多最佳化方法，後面的chat會提到。比如nginx中介軟體，設定nginx.cfg就能壓縮。可以買一本js效能最佳化的書看看推薦《高效能 Java Script》。

問： 效能測試個人覺得二點是效能資料分析及效能測試覆蓋面，我們在面對效能測試是用什麼想法能達到最大的覆蓋面，避免遺漏某些重要的效能測試點，因為某些產品在不同的地區可能會因不同的時間差異出現不同的效能測試點，靚湯老師有沒有一個好的辦法來儘量避免這種“漏測”現象，也就是how的問題；資料分析基於產品歷史資料或公司/市面差異化產品資料，做效能測試資料分析時有哪些坑需要注意？

答： 覆蓋率避免漏測：

場景。

資料分析。

問： 做效能測試可以使用第三方工具，也可以自己開發程式碼，這兩種情況分別有什麼樣的適用範圍？您最看重效能 測試工具 那些方面的特性？能不能介紹一下對效能 工程師 來說使用工具進行測試最大的痛點在哪裡？能不能描述一下您理想中的效能 測試工具 （或者庫）要有什麼功能？

答： 總原則：以目標位出發點，不要受方法和工具限制。在回到為什麼需要工具，工具幫我們在有限資源下，提升效率和生產力：有限制條件，有限資源。

測試需要投入大量的資源（解決方法資源共享）不可能準備10W臺機器讓你壓奧運會售票系統。

可重複性非常差，操作步驟多，人為不一定記得住，不能重現。

測試準確性較差（人工超做有誤差，比如說是集體發力，但你就可能晚了0.001s。

工具與開發比較：

先用第三方工具，當第三方工具不能滿足的時候就自己寫程式碼或者使用另外的工具。

可以得道的幫助，網上 資料 少與網上 資料 多當然不一樣 輕量級和重量級。敏捷下個人更建議輕量級。比如用jmeter，而不用LR. 如果剛學習，可以學LR，因 可以得道的幫助，網上 資料 少與網上 資料 多當然不一樣輕量級和重量級。敏捷下個人更建議輕量級。比如用jmeter，而不用LR. 如果剛學習，可以學LR，因為知識面廣什麼都涉及。支援人員（ 開源 工具，需要看社群活躍度等）；如果是自己開發、後續開發能支撐不？後續維護能支撐？這是要考慮的。效能測試工具其實就是：多執行緒、能模擬交易（主要是協議和代理）、能模擬真實資料。能共享資源、能分散式負載（有些工具要測試人員自己去寫排程，就很累了）能不能錄製，就是後面要考慮的事情了。說到用工具的痛：就是到處拼湊，找合適的工具拼湊，以前自己寫過排程工具來排程其他壓力測試機（SOAPUI的壓力測試）。目前沒有一款能完全合適自己產品的，都有學習成本，如果功能測試人員能0成本介入就好了（橋樑需要效能測試開發人員去做）所以大家可以在自己公司去搭平臺的。

好的輔助工具可以是這樣的：有功能開關、可以記錄日誌、原子性強（比如單元級別的效能測試，能去除垃圾時間，記錄業務其實時間，可以記錄日誌）、針對性強，用推廣可能（測試kafka效能、測試redis效能工具類、測試MQ推送與消費）。

問： 作者覺得何時安排做效能測試比較合適？效能測試的頻率是怎樣的？

答：  時間安排其實前面都有表述，應改能解決這個問題。效能測試的頻率根據業務場景需要就測、評估需求的時候，發現有效能要求就計劃做，但建議主要功能每隔3個小版本，關注一下業務量，業務量快達到預估值時進行一次，另外要考慮業務高峰期，比如雙11、雙12、618、春節等，建議之前都做一次。當然不同行業有不同的高峰期。

問： 每次效能測試的內容都是一樣的麼？在效能測試的設計和選擇上需要主要考慮哪些內容？

答： 不一樣，要根據目標來定。比如，產品要路演，可能只需要單個使用者響應速度OK，就可以了。如果現在換成做促銷，這個時候就好考慮同時有多少個使用者來請求了。那麼場景的設計、引數化策略也不一樣了。又比如說，新功能是大資料量 下載 ，這個時候就要對 下載 做功能測試，可能是多使用者併發需求；有可能是少使用者，大資料量，比如要下載100W條記錄的資料。當然要看研發如何實現了，是後臺分批壓縮。還是定時任務完成。這個同研發實現有關。這也是為什麼花一次chat來給大家講效能測試目的，其實效能設計就是以目的出發的。

可以考慮一下幾個方面：

測試資料（基礎資料、業務資料）不多解釋這個文章中有。

測試場景（基礎場景、綜合場景）場景一定要同業務過，看看是不是真實的，或遺漏了。最好是使用者，而非業務。

引數化策略（如何引數化、如何取數、資料用完後怎麼辦等，這個後面的Chat會分享）。

集合點策略（全部虛擬使用者都到了在壓，還是等到%XX就可以壓，還是業務成功達到多少在壓）。

檢查點（又叫斷言，判讀事務是否成功）這是很多初學同學容易遺漏的。

環境（網路、伺服器配置、防火牆等、中介軟體配置、定時任務頻率、應用配置等）。

負載機情況，需要把負載機的監控納入監控範圍。（很多失敗原因都是沒有關注負載機情況導致測試走彎路）,這也是常見問題。需要特別說明的是“網路”這是也是遇到最多的問題。（可能負載機的網路頻寬限制，導致無論怎麼樣壓，壓力都上不去，一直找不到原因）。

問： 經常看到有很多同行或者同事做的效能場景很複雜(非綜合場景)，需要很多步驟組成，寫的指令碼也很長，當然我本人沒做過那麼複雜的，不知道實際情況，所以我想問一下是不是實際上真的存在這麼複雜場景的效能測試，或者這些很複雜的場景是否可以簡化成對某個介面的測試？

答： 指令碼一定不要太長，能抽象一定抽象，太長自己看不到邏輯關係。所有我寫指令碼都會先寫虛擬碼。建議大家也這麼做，先設計表格，依照表格寫虛擬碼。比如剛剛的場景用例設計表格。文字最好懂，程式碼不易懂。然後能抽象出去的就抽象出去。需要加的關鍵點都在場景設計和用例設計時一表格的形式列出來，專家也好評審。對於介面測試，你的思路是對的，我們可以拆解，但介面測試代替不了頁面測試。

提前做介面的，甚至先讓研發做單元的效能測試（多執行緒壓一下）。 資料從後端到前端，瀏覽器要渲染等操作會佔用這個響應時間，所以介面OK了，還要測

提前做介面的，甚至先讓研發做單元的效能測試（多執行緒壓一下）。

資料從後端到前端，瀏覽器要渲染等操作會佔用這個響應時間，所以介面OK了，還要測頁面。

另外前端效能也是一個大的方向，比如，js/圖片/css，快取等。其實效能測試還要考慮好快取到底能不能模擬真實情況。快取在效能測試中干擾最多，又是是需要快取來模擬真實情況，但有時引數化有會導致不需要的快取出現。所有引數化，是結合業務的一門學問。靜態伺服器，就是靜態資源下載帶來的壓力。

問：   如果部署環境和測試環境不一致，如何在效能測試過程中的測試結果具有代表性？和可證明性。

答： 這個需要一定的換算標準。當然有些土豪公司就是一比一的裝置來進行測試。測試的配置是否與生產一致。如果測試的配置與生產一致的話。可以按照乘以它的百分比，我們最後再乘以70%。這樣的話就建議提伺服器的人通常同配置，這樣便於你計算。如果沒有這種等比例的配置，算起來就比較麻煩。伺服器型號不同，沒有關係，但CPU的核數，以及CPU的頻率以及記憶體。包括你的中間價，你的網路。建議越接近的配置最好。

問：  https的手機端，在開發給不出靠譜的介面文件的時候，如何錄製或抓取資料流，公司主要用的lr。

答：  可以讓研發做一些單元壓力測試。完善後再做，不建議用lr，可以換jmeter試試。

問：   如何快速定位資料庫問題？有沒有好的例項講解？用LR如何做到？

答： 可以先做一部分，比如說你先解決，效能測試監控指標，回傳和展示。資料庫的問題和建議進行資料庫相關設定。比如說慢sql，比如spitlight工具。慢sql會記錄所有系統查詢較慢的sql語句，根據語句找到相應程式碼進行最佳化。根據語句，找到相應程式碼進行最佳化。