靚湯：這是我第一次使用塗鴉的方式寫文章，請允許我，感謝梅子引路。另外本系列Chat希望通過由淺入深的方式帶大家認識性能測試。一些調優和測試方法會在後面的Chat同樣以塗鴉的方式展示給大家。後面三場會重點介紹如何進行性能測試，從需求到最後的調優。第一場主要希望沒有接觸過或接觸過但認識不全的同學帶去一些思考。比如紅亮燈那個塗鴉就是做了些與目標不一致的事情。這是大家測試中常常犯的錯，所以我希望是接觸到的同學能抓住要點，即目標爲導向，不去做一些看起來是性能測試的性能測試。另外針對大家提出的意見我希望在後面的Chat中，好好去完善。感謝。
問：性能測試最好什麼時候開始更好？需求階段、設計階段、還是測試階段？
答：有些同事在測試幾輪之後，功能穩定了開始介入性能測試，這時才發現性能根本支撐不了預期值。這個時候開發再回頭進行系統調優，如果事先選的架構能支撐就好，如果不能達不到預期值，後面討論或者請教高手發現原先的架構缺陷，再調整架構代價就非常大。基本導致前期的功能測試成果作廢。其實各個階段都有事情做。需求階段可以整理，評審出性能需求，評審需求可行性時就考慮好數據量和用戶量。設計階段--對預估的需求做設計，舉個例子。背景：我們現在使用的是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性能優化的書看看推薦《高性能JavaScript》。
問：性能測試個人覺得二點是性能數據分析及性能測試覆蓋面，我們在面對性能測試是用什麼想法能達到最大的覆蓋面，避免遺漏某些重要的性能測試點，因爲某些產品在不同的地區可能會因不同的時間差異出現不同的性能測試點，靚湯老師有沒有一個好的辦法來儘量避免這種“漏測”現象，也就是how的問題；數據分析基於產品歷史數據或公司/市面差異化產品數據，做性能測試數據分析時有哪些坑需要注意？
答：覆蓋率避免漏測：
- 場景。
- 數據分析。
問：希望能結合具體的案例，講講怎麼設計場景，增加壓力的策略是怎麼樣的，如果在性能指標不明確的情況下，又該怎麼探索去測試，對於測試結果的分析也希望以後多講講。
答：場景設計、用例設計、性能分析在後面的chat有專門的分享，一下子說不完整。我把主要的提一下：一把性能測試的關鍵字段都列出來如：參數化、關聯、集合點、思考時間、虛擬IP、負載機請求數、帶寬要求、參數化策略、集合點策略等，每一項都寫清楚。其實這個同漏測有很大關係：
這就是一個常見的模板，把容易出的問題都設計上去了。所以拉80%的時間做設計，20%的時間做執行。當然所有數據的填寫都是基於調研的。所以性能測試應該開始於調研的時候，而不是測試的時候。測試指標的指定是在調研後同產品或需求或業務制度出來的。一定要有明確的性能指標在進行測試，纔會事半功倍。所以指標不明確是團隊需要改變的地方。
問：做性能測試可以使用第三方工具，也可以自己開發代碼，這兩種情況分別有什麼樣的適用範圍？您最看重性能測試工具那些方面的特性？能不能介紹一下對性能工程師來說使用工具進行測試最大的痛點在哪裏？能不能描述一下您理想中的性能測試工具（或者庫）要有什麼功能？
答：總原則：以目標位出發點，不要受方法和工具限制。在回到爲什麼需要工具，工具幫我們在有限資源下，提升效率和生產力：有限制條件，有限資源。
-
測試需要投入大量的資源（解決方法資源共享）不可能準備10W臺機器讓你壓奧運會售票系統。
-
可重複性非常差，操作步驟多，人爲不一定記得住，不能重現。
-
測試準確性較差（人工超做有誤差，比如說是集體發力，但你就可能晚了0.001s。
工具與開發比較：
- 先用第三方工具，當第三方工具不能滿足的時候就自己寫代碼或者使用另外的工具。
好的輔助工具可以是這樣的：有功能開關、可以記錄日誌、原子性強（比如單元級別的性能測試，能去除垃圾時間，記錄業務其實時間，可以記錄日誌）、針對性強，用推廣可能（測試kafka性能、測試redis性能工具類、測試MQ推送與消費）。
問：作者覺得何時安排做性能測試比較合適？性能測試的頻率是怎樣的？
答： 時間安排其實前面都有表述，應改能解決這個問題。性能測試的頻率根據業務場景需要就測、評估需求的時候，發現有性能要求就計劃做，但建議主要功能每隔3個小版本，關注一下業務量，業務量快達到預估值時進行一次，另外要考慮業務高峯期，比如雙11、雙12、618、春節等，建議之前都做一次。當然不同行業有不同的高峯期。
問：每次性能測試的內容都是一樣的麼？在性能測試的設計和選擇上需要主要考慮哪些內容？
答：不一樣，要根據目標來定。比如，產品要路演，可能只需要單個用戶響應速度OK，就可以了。如果現在換成做促銷，這個時候就好考慮同時有多少個用戶來請求了。那麼場景的設計、參數化策略也不一樣了。又比如說，新功能是大數據量下載，這個時候就要對下載做功能測試，可能是多用戶併發需求；有可能是少用戶，大數據量，比如要下載100W條記錄的數據。當然要看研發如何實現了，是後臺分批壓縮。還是定時任務完成。這個同研發實現有關。這也是爲什麼花一次chat來給大家講性能測試目的，其實性能設計就是以目的出發的。
可以考慮一下幾個方面：
- 測試數據（基礎數據、業務數據）不多解釋這個文章中有。
- 測試場景（基礎場景、綜合場景）場景一定要同業務過，看看是不是真實的，或遺漏了。最好是用戶，而非業務。
- 參數化策略（如何參數化、如何取數、數據用完後怎麼辦等，這個後面的Chat會分享）。
- 集合點策略（全部虛擬用戶都到了在壓，還是等到%XX就可以壓，還是業務成功達到多少在壓）。
- 檢查點（又叫斷言，判讀事務是否成功）這是很多初學同學容易遺漏的。
- 環境（網絡、服務器配置、防火牆等、中間件配置、定時任務頻率、應用配置等）。
- 負載機情況，需要把負載機的監控納入監控範圍。（很多失敗原因都是沒有關注負載機情況導致測試走彎路）,這也是常見問題。需要特別說明的是“網絡”這是也是遇到最多的問題。（可能負載機的網絡帶寬限制，導致無論怎麼樣壓，壓力都上不去，一直找不到原因）。
問：經常看到有很多同行或者同事做的性能場景很複雜(非綜合場景)，需要很多步驟組成，寫的腳本也很長，當然我本人沒做過那麼複雜的，不知道實際情況，所以我想問一下是不是實際上真的存在這麼複雜場景的性能測試，或者這些很複雜的場景是否可以簡化成對某個接口的測試？
答：腳本一定不要太長，能抽象一定抽象，太長自己看不到邏輯關係。所有我寫腳本都會先寫僞代碼。建議大家也這麼做，先設計表格，依照表格寫僞代碼。比如剛剛的場景用例設計表格。文字最好懂，代碼不易懂。然後能抽象出去的就抽象出去。需要加的關鍵點都在場景設計和用例設計時一表格的形式列出來，專家也好評審。對於接口測試，你的思路是對的，我們可以拆解，但接口測試代替不了頁面測試。
提前做接口的，甚至先讓研發做單元的性能測試（多線程壓一下）。
數據從後端到前端，瀏覽器要渲染等操作會佔用這個響應時間，所以接口OK了，還要測頁面。
另外前端性能也是一個大的方向，比如，js/圖片/css，緩存等。其實性能測試還要考慮好緩存到底能不能模擬真實情況。緩存在性能測試中干擾最多，又是是需要緩存來模擬真實情況，但有時參數化有會導致不需要的緩存出現。所有參數化，是結合業務的一門學問。靜態服務器，就是靜態資源下載帶來的壓力。
問： 如果部署環境和測試環境不一致，如何在性能測試過程中的測試結果具有代表性？和可證明性。
答：這個需要一定的換算標準。當然有些土豪公司就是一比一的設備來進行測試。測試的配置是否與生產一致。如果測試的配置與生產一致的話。可以按照乘以它的百分比，咱最後再乘以70%。這樣的話就建議提服務器的人通常同配置，這樣便於你計算。如果沒有這種等比例的配置，算起來就比較麻煩。服務器型號不同，沒有關係，但CPU的核數，以及CPU的頻率以及內存。包括你的中間價，你的網絡。建議越接近的配置最好。
問： https的手機端，在開發給不出靠譜的接口文檔的時候，如何錄製或抓取數據流，公司主要用的lr。
答： 可以讓研發做一些單元壓力測試。完善後再做，不建議用lr，可以換jmeter試試。
問：性能測試有什麼好的自動化方案嗎？
答：目前我們的做法是和一些持續集成工具或者是自己的寫一些腳本串聯。當然，可以試着寫個平臺，包括調度、監控都做了。成熟了在變成黑盒之前建議都白盒。
問： 如何快速定位數據庫問題？有沒有好的實例講解？用LR如何做到？
答：可以先做一部分，比如說你先解決，性能測試監控指標，回傳和展示。數據庫的問題和建議進行數據庫相關設置。比如說慢sql，比如spitlight工具。慢sql會記錄所有系統查詢較慢的sql語句，根據語句找到相應代碼進行優化。根據語句，找到相應代碼進行優化。