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使用率過高
14、性能測試如何防止數據污染？
生產數據備份、數據隔離、擋板
15、怎么根據線下環境評估線上環境的性能？
1）首先線下必須有專門的性能測試環境；
2）線下環境單臺機器配置和線上不能相差很大，可以通過單臺的機器性能推 算出多臺機器性能；
3）如果線下機器配置差，只能測試出程序有無性能問題，這樣搞線下測試處后來的數據對線上沒有太大參考意義；
4）如果想獲取比較準確的線上性能情況，建議最好做線上的性能測試。
16、出現內存泄露的根本原因是什么？你是怎么定位內存泄露原因的？
原因：內存泄漏的根本原因是jvm中老年代中存在著大量存活的對象，這些對象不能被GC回收掉，從而占滿了整個老年代，造成jvm一直處于FGC的狀態，程序沒有響應，服務器報oom錯誤；
定位問題：主要通過分析老年代中占用空間最大的類都有哪些，然后去代碼中找對應的類的創建。通�？梢允褂胘dk提供的jvisualvm和jmap進行堆內存的分析。
17、tps壓不上去，可能有哪些方面的原因？
1）壓力機本身性能瓶頸；
2）網絡IO瓶頸；
3）中間件（tomcat/nginx/mysql）連接數限制；
4）Java線程的阻塞、等待；
5）本系統資源的瓶頸（cpu、內存、磁盤、網絡等）。
18、性能場景怎么設計？一般都有哪些性能場景？
基本的場景包括：基準測試、單交易測試、混合測試、穩定性測試、高可用性測試、異常測試等
19、什么是集合點，什么場景下需要用集合點？
集合點是測試腳本中的一個標記，當每個虛擬用戶執行到標記處時，會停留在標記處等待其他的虛擬用戶，當達到預期設置的并發數時，標記處的所有用戶同時啟動執行后續的請求
集合點會產生瞬間高并發，但是也會降低平均壓力。所以在壓測過程中，如果有要求瞬間高并發的業務，就需要使用集合點，比如搶購，秒殺之類的業務
20、服務器的cpu使用率和load是什么關系？
通常情況下，cpu使用率和load值是正比關系，即cpu使用率越高，load值越高。但是在一些特殊情況下，也會出現cpu使用率不高，但是load值較高的情況，比如某系統只能使用CPU中的單核運行，它可以占用單核cpu100%，但從整體cpu使用率來看，只是使用了一小部分。而隨著并發的增大，單核CPU的任務隊列會越來越長，造成了load值較高
21、性能測試腳本中為什么要做參數化？
參數化把測試腳本中的請求數據動態化，避免使用單一固定參數進行壓測。這也是為了更加真實的模擬用戶的請求
22、性能腳本中的亂碼問題怎么解決？
1）如果在腳本中不使用或不判斷亂碼部分的數據，那可用忽略此問題，因為亂碼并不影響性能；
2）如果需要使用亂碼數據，可以通過壓測工具提供的一些方法進行編碼轉換。
23、在性能測試工具中，使用線程和進程壓測有什么區別，Loadrunner和Jmeter分別使用什么進行發壓？
1）Loadrunner同時支持進程和線程發壓。當選擇進程時，每個虛擬用戶單獨啟動一個進程，當選擇線程時，每50個線程啟動一個進程；
2）Jmeter只支持線程發壓，進程和線程的主要區別為，進程之間是獨享內存的，線程之間是共享內存的。使用進程壓測占用的資源會大一些。在高并發下，會減少壓測工具自身的異常情況。
24、性能測試腳本中，定義事務的原則是什么？
在測試腳本中，事務定義的業務流程越短越好。同時腳本中不要寫過多復雜的邏輯，對于一個復雜的場景，可以考慮把腳本拆解成多個簡單的腳本。
25，怎么進行性能場景設計？
1）單接口測試場景；
2）混合接口測試場景；
3）高可用性場景（集群情況下）；
4）網絡異常場景；
5）穩定性場景；
6）其他業務相關場景。
