問：性能測試最好什麼時候開始更好？需求階段、設計階段、還是測試階段？
答：有些同事在測試幾輪之後，功能穩定了開始介入性能測試，這時才發現性能根本支撐不了預期值。這個時候開發再回頭進行系統調優，如果事先選的架構能支撐就好，如果不能達不到預期值，後面討論或者請教高手發現原先的架構缺陷，再調整架構代價就非常大。基本導致前期的功能測試成果作廢。其實各個階段都有事情做。需求階段可以整理，評審出性能需求，評審需求可行性時就考慮好數據量和用戶量。設計階段--對預估的需求做設計，舉個例子。背景：我們現在使用的是mysql數據庫（公司去oracle化），我們要從一個5000W的一個數據表的6個不同查詢維度查詢數據，比如說城市、行業、地址類型、愛好、性別、時間範圍。這樣對於mysql的查詢常見的優化設計可能是分表、建立索引，但，對於這個場景就不好處理了。數據耦合強，沒有辦法分表。索引，組合索引太多。後面的處理辦法是用mongodb、nosql的方法解決。對於編碼和測試階段可以這樣去分不同階段做不同事情。
編碼階段，可以提出需要，讓研發通過單元測試（開多線程）的方式進行壓力測試。進行一些單元壓力測試測試階段---測試階段也有策略的，建議先做一下單一場景單一用戶的性能測試。常常會遇到有些同事在沒有壓單個場景的情況下，就進行負載測試，到處定位瓶頸，最後發現單一用戶單一場景都是問題。這就是繞了一圈回到了起點。對於不同類別測試後面會專門的chat介紹。
問：文章有說通過數據分析識別瓶頸問題，能否稍展開，有沒有具體的方法、流程步驟等，還是主要靠經驗？性能測試剛入門，請大師指點。
答：性能瓶頸分析有專場的chat，本次就談一下瓶頸分析幾大原則和幾個關注可以參考：
邏輯極簡化原則：就是去繁爲簡。
割據分段法：就是假設問題最可能出現在什麼地方,分段分析，使用打樁的方法。
路由堵截法：就是從壓力產生的數據流向開始分析。
資源監控法：資源監控，主要關注資源有：
CPU（用戶佔用<通過算法優化等方法解決>、系統佔用<堵篩>）
內存（頁面失效（軟頁面和硬頁面）可以剩餘內存、可以緩存）
磁盤I/O
網絡
進程（處理器時間、進程產生的頁面失效、進程所分配的無法與其他進程共享的當前字節數量，看是否有內存泄露等）
存儲，也需要關注。
問：老師怎麼看待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的問題；數據分析基於產品歷史數據或公司/市面差異化產品數據，做性能測試數據分析時有哪些坑需要注意？
答：覆蓋率避免漏測：
場景。
數據分析。
問：做性能測試可以使用第三方工具，也可以自己開發代碼，這兩種情況分別有什麼樣的適用範圍？您最看重性能測試工具那些方面的特性？能不能介紹一下對性能工程師來說使用工具進行測試最大的痛點在哪裏？能不能描述一下您理想中的性能測試工具（或者庫）要有什麼功能？
答：總原則：以目標位出發點，不要受方法和工具限制。在回到爲什麼需要工具，工具幫我們在有限資源下，提升效率和生產力：有限制條件，有限資源。
測試需要投入大量的資源（解決方法資源共享）不可能準備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語句，根據語句找到相應代碼進行優化。根據語句，找到相應代碼進行優化。