性能測試的基礎知識：
性能測試：使用自動化工具，模擬不同的場景，對軟件各項性能指標進行測試和評估的過程
?
QPS：即 Per 的縮寫，每秒能處理查詢數目。是一臺服務器每秒能夠相應的查詢次數，是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準。每秒鐘處理完請求的次數；注意這里是處理完，具體是指發出請求到服務器處理完成功返回結果。可以理解在中有個，每處理一個請求加1，1秒后=QPS。QPS = 并發量 / 平均響應時間
?
TPS：即 Per 的縮寫，每秒處理的事務數目。一個事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程。客戶機在發送請求時開始計時，收到服務器響應后結束計時，以此來計算使用的時間和完成的事務個數，最終利用這些信息作出的評估分。
?
RPS：即 Per 的縮寫，每秒能處理的請求數目。等效于QPS。
?
PV：page view，頁面瀏覽量，用戶每一次對網站中的每個頁面訪問均被記錄1次。用戶對同一頁面的多次刷新，訪問量累計。
?
UV： ，獨立訪客，通過客戶端的實現。即同一頁面，客戶端多次點擊只計算一次，訪問量不累計。
?
IP： ，本意本是指網絡協議，在數據統計這塊指通過ip的訪問量。 即同一頁面，客戶端使用同一個IP訪問多次只計算一次，訪問量不累計。
?
RT：響應時間，處理一次請求所需要的平均處理時間
面試題：
1、描述一下你們公司的性能測試流程？
1）分析性能需求（用戶使用最頻繁的場景進行測試），確定性能指標（例如：事務通過率100%，top99%是5秒，最大并發是2000，CPU和內存都是70%以下）
2）制定性能測試計劃，明確測試時間、測試環境和測試工具
3）編寫測試用例
4）搭建測試環境，準備測試數據、編寫測試腳本
5）測試腳本優化：設置檢查點，參數化，關聯，集合點，事務，調整思考時間等
6）設計測試場景，運行測試腳本和監控服務器
7）分析測試結果，收集相關日志提單給開發
8）回歸測試
9）編寫測試報告
2、如果確定系統最大負載？
通過負載測試，不斷增加用戶數，隨著用戶數的增加，各項性能指標也會相應產生變化，當出現了拐點，如：當用戶數達到某個數量級時，響應時間突然增長，那這個拐點就是系統的最大用戶數
3、并發數是怎么確定的？
1）先上線一段時間，根據收集到的用戶訪問數據進行預估
2）根據需求來確定（使用高峰期，登錄用戶數，響應時間）
4、性能測試在什么環境執行？
我們一般會搭建一套獨立的性能測試環境進行測試
5、性能測試什么時候執行？
功能測試之后，系統比較穩定的時候做性能測試
6、性能測試需求的來源？
1）客戶提供需求
2）開發提供需求
** 7、如何實現300用戶的并發？**
絕對并發：在腳本對應的請求后添加集合點
相對并發：線程組設置300線程數
8、什么情況下要做關聯，關聯是怎么做的？
當腳本的上下文有聯系則用關聯；如：登錄的token關聯，增刪改查主鍵ID
9、有驗證碼的功能，怎么做性能測試？
1）將驗證碼暫時屏蔽，完成性能測試后，再恢復
2）使用萬能的驗證碼
10、性能測試指標有哪些？分別是什么含義？
tps：每秒事務量，代表了系統的處理能力，tps越高，性能越好
響應時間：從發出請求到接受到系統響應數據所花費的時間，響應時間越短，性能越好
吞吐量：網絡上行和下行流量的總和，吞吐量是網絡瓶頸定位的重要指標
錯誤率：在壓測過程中系統出現錯誤的比例
11、如果判斷系統瓶頸？
從TPS指標分析，TPS即系統單位內處理事務的數量，觀察當隨著用戶數的增長期系統每秒可處理的事務數是否也會增長
12、如何分析性能測試結果？
首先看事務通過率，然后分析響應時間、CPU、內存等指標是否滿足需求，如果結果不可信，則分析異常原因并復測
確定性能結果可信之后，如發現以下問題，按下面思路來定位問題：
1）響應時間不達標：首先看事務所消耗的時間主要是在網絡傳輸還是服務器，如果是網絡，就需要結合網絡吞吐量圖，計算寬帶是否存在瓶頸，如果存在就需要考慮增加寬帶；如果不存在則有可能是網絡不穩定導致的。如果是服務器，就要分別查看web服務器和數據庫服務器的CPU、內存的使用率是否過高，因為過高的CPU，內存必定會造成響應時間過長、
2）服務器CPU指標異常：把web服務器對應上對應的用戶操作日志取下來，發給開發定位
3）數據庫CPU指標異常：把數據庫服務器對應上對應的日期取下來，發給開發定位
4）內存泄漏：把內存的heap數據取下來，分析是那個對象消耗內存最多，然后發給開發定位
5）程序在單用戶場景下運行成功，多用戶運行失敗，提示連不上服務器：程序可能是單線程處理機制
13、你在性能測試中遇到哪些性能問題？
響應時間過長、tps過低、內存溢出、CPU使用率過高
h5頁面響應時間過長
h5的分頁經常卡死，sql查詢過多，數據量過大
導出excel時間過長，頁面503，后臺報內存溢出
功能涉及到算法的時候，一定要在測試環境用大量數據去模擬
只要點擊，后臺cpu立刻就是300%
14、性能測試如何防止數據污染？
生產數據備份、數據隔離、擋板
15、怎么根據線下環境評估線上環境的性能？
1）首先線下必須有專門的性能測試環境
2）線下環境單臺機器配置和線上不能相差很大，可以通過單臺的機器性能推 算出多臺機器性能
3）如果線下機器配置差，只能測試出程序有無性能問題，這樣搞線下測試處后來的數據對線上沒有太大參考意義
4）如果想獲取比較準確的線上性能情況，建議最好做線上的性能測試
16、出現內存泄露的根本原因是什么？你是怎么定位內存泄露原因的？
一.內存泄漏:是指在程序代碼中動態申請的、堆上的內存 由于某種原因、在使用后沒有被釋放，進而造成內存的浪費。少部分的內存泄漏不會影響程序的正常運行，不過如果是持續的內存泄漏會耗光系統內存，最終會導致程序卡死甚至系統崩潰。如果程序在正常地使用過程中，占用的內存隨著時間推移不斷增長，一般就說明存在內存泄漏的情況。
例:
1.使用 申請的內存要主動調用 free，new 申請的內存要主動調用 ，否則就會導致內存泄漏
2.使用 new 申請的數組，釋放的時候要用 [] 刪除，如果錯誤地使用 刪除，就會造成內存泄漏
原因：內存泄漏的根本原因是jvm中存在著大量存活的對象，這些對象不能被GC回收掉高并發服務器是進程還是線程，從而占滿了整個內存，造成jvm一直處于FGC的狀態，程序沒有響應，服務器報oom錯誤
定位問題：主要通過分析老年代中占用空間最大的類都有哪些，然后去代碼中找對應的類的創建。通常可以使用jdk提供的和jmap進行堆內存的分析
17、tps壓不上去，可能有哪些方面的原因？
1)壓力機本身性能瓶頸
2)網絡IO瓶頸
3)中間件（/nginx/mysql）連接數限制
4)Java線程的阻塞、等待
5)本系統資源的瓶頸（cpu、內存、磁盤、網絡等）
18、性能場景怎么設計？一般都有哪些性能場景？
基本的場景包括：基準測試、單交易測試、混合測試、穩定性測試、高可用性測試、異常測試等
19、什么是集合點，什么場景下需要用集合點？
集合點是測試腳本中的一個標記，當每個虛擬用戶執行到標記處時，會停留在標記處等待其他的虛擬用戶，當達到預期設置的并發數時，標記處的所有用戶同時啟動執行后續的請求
集合點會產生瞬間高并發，但是也會降低平均壓力。所以在壓測過程中，如果有要求瞬間高并發的業務，就需要使用集合點，比如搶購，秒殺之類的業務
20、服務器的cpu使用率和load(負載)是什么關系？
通常情況下，cpu使用率和load值是正比關系，即cpu使用率越高，load值越高。但是在一些特殊情況下，也會出現cpu使用率不高，但是load值較高的情況，比如某系統只能使用CPU中的單核運行，它可以占用單核%，但從整體cpu使用率來看，只是使用了一小部分。而隨著并發的增大，單核CPU的任務隊列會越來越長，造成了load值較高
21、性能測試腳本中為什么要做參數化？
參數化把測試腳本中的請求數據動態化，避免使用單一固定參數進行壓測。這也是為了更加真實的模擬用戶的請求
22、性能腳本中的亂碼問題怎么解決？
1）如果在腳本中不使用或不判斷亂碼部分的數據，那可用忽略此問題高并發服務器是進程還是線程，因為亂碼并不影響性能
2）如果需要使用亂碼數據，可以通過壓測工具提供的一些方法進行編碼轉換
23、在性能測試工具中，使用線程和進程壓測有什么區別，和分別使用什么進行發壓？
1）同時支持進程和線程發壓。當選擇進程時，每個虛擬用戶單獨啟動一個進程，當選擇線程時，每50個線程啟動一個進程
2）只支持線程發壓；進程和線程的主要區別為，進程之間是獨享內存的，線程之間是共享內存的。使用進程壓測占用的資源會大一些。在高并發下，會減少壓測工具自身的異常情況
24、性能測試腳本中，定義事務的原則是什么？
在測試腳本中，事務定義的業務流程越短越好。同時腳本中不要寫過多復雜的邏輯，對于一個復雜的場景，可以考慮把腳本拆解成多個簡單的腳本
25，怎么進行性能場景設計？
1） 單接口測試場景
2） 混合接口測試場景
3） 高可用性場景（集群情況下）
4） 網絡異常場景
5） 穩定性場景
6）其他業務相關場景
25、性能測試包含的方法有哪些（至少列舉5種）？
SEI 負載測試計劃過程，RBI方法，性能下降曲線分析法，和segue提供的性能測試方法，PTGM模型。
26、一個web系統，用戶從打開瀏覽器輸入網址頁面顯示在瀏覽器中，這個過程當中，頁面給用戶總的響應時間通常可以細分為哪些？
從客戶端到服務端的請求時間（請求網絡傳輸時間），從服務端返回數據到客戶端的時間（響應網絡傳輸時間），頁面渲染時間（客戶端瀏覽器加載頁面的時間），處理器的處理時間（應用服務器+數據庫服務器處理時間）。
27、軟件為什么會有性能問題？
軟件在高負載訪問下，業務邏輯比較復雜。軟件是運行在環境當中的，不同的軟硬件資源都會引起性能問題，還有軟件本身的代碼、數據庫等引起的性能問題。
28、響應時間和吞吐量直接的關系是什么？
吞吐量圖顯示的是虛擬用戶每秒鐘從服務器接收到的字節數。當和響應時間比較時，可以發現隨著吞吐量的降低，響應時間也降低，同樣的，吞吐量的峰值和最大響應時間差不多在同時出現。
平均響應時間越短，系統吞吐量越大；平均響應時間越長，系統吞吐量越小；
29、如何識別性能瓶頸？
找出最先出問題的點，即短板，再進行分析。
首先，要先做一份現有系統的性能測試報告，如CPU消耗、內存消耗、磁盤I/O、網卡I/O、帶寬、頁面交換等，如果發現其中一項或多項達到瓶頸，那么就要考慮是硬件不夠導致性能上不去，還是系統實現不合理導致滿了；如果是硬件問題，那么就早考慮擴容；如果是資源都沒到極限或確認系統實現有問題，那么就要針對性的對系統相應功能進行相應的拆解或者是監控函數級的耗時。
比如：
隨著負載不斷升高，tps也是不斷升高的，正常邏輯
隨著負載不斷增加，tps不再增加，甚至下降。表示單位線程的tps實際在衰減。tps的瓶頸點
30、 請描述壓力測試和負載測試的區別？
壓力測試的預期結果就是系統出現問題，我們考察的是系統處理問題的能力。
負載測試是考察軟件系統在既定負載下的性能表現。
壓力測試是能讓我們識別系統的弱點和在極限負載下程序將如何運行
31、對于一個缺乏性能明確需求的項目，你是如何提取性能需求的？
與客戶交流，查看歷史日志，跟同類產品對比，根據以往的經驗。
32、什么是點擊率
點擊率是指客戶端每秒鐘向服務器提交的HTTP請求數
33、性能測試準入與退出標準
性能測試開始應該是從系統設計開始準入的。
準出條件是判斷測試的結果是否達到性能目標，或者說是否達到可容忍標準。
34、壓力工具的工作原理是什么？
工作原理：基于協議，通過多線程的方式模擬用戶行為，設計各種場景壓測服務端，得到性能數據，分析性能瓶頸
