1、性能測試的流程是什么？
需求調研-環境搭建-腳本編寫-准備數據-執行測試-回歸調優-測試報告
2、什么是關聯？在什么情況下需要做關聯？
關聯是將服務器返回的數據通過一定的規則過濾出來，將其保存成參數，以供后續代碼中使用
當服務器返回的數據是動態變化的，且后續腳本中需要使用這個變化的數據時，才需要做關聯
3、loadrunner中unique參數化是怎么實現的？
unique參數化主要原理：根據並發用戶個數，將某個連續的范圍分段，每個用戶使用其中的一段數據，
unique規定了第一段的起始值和每一段的size，從而使每個用戶在各自的數據段的取值，而不會產生重復的值
4、loadrunner中參數和C語言變量的區別是什么？分別用哪兩個函數進行轉換？
主要區別：參數往往是LR自動保存的，如關聯、檢查點函數等，它可以在LR的web類函數的參數中直接使用；
變量是用戶自己定義的，不可以直接放在web函數中使用
lr_save_string：變量轉參數
lr_eval_string：參數轉變量
5、Jmeter中怎么寫Java腳本，簡要說下步驟
a)通過eclipse等工具手動編寫一個Java類，實現JavaSamplerClient接口
b)將要寫的代碼放到JavaSamplerClient接口對應的實現方法中，如果需要暴露出參數，將參數添加到getDefaultParameters方法中
c)腳本調試通過后，將寫好的腳本達成runnable jar，將jar包和依賴的lib文件夾放到Jmeter的lib/ext下，重啟Jmeter
d)在Jmeter中添加JavaSampler，選擇jar包中的測試類
6、一般在什么情況下會在Jmeter中使用BeanShell
a)被測接口調用前需要對參數做一些邏輯處理，可以使用BeanShell前置處理器
b)需要對接口的返回值做一些邏輯判斷，可以使用BeanShell斷言
7、怎么根據線下環境評估線上環境的性能
a)首先線下必須要有專門的性能測試環境
b)線下環境單台機器配置和線上不能相差很大，可以通過單台的機器性能推算出多台機器性能（需考慮一定的性能損耗）
c)如果線下機器配置很差，只能測試出程序有無性能問題，這樣線下測試出來的數據對線上沒有太大參考意義
d)如果想獲取比較准確的線上性能情況，建議最好做線上的性能測試
8、對於Linux系統，主要的監控指標有哪些？他們的各自閾值是多少？
cpu使用率：<80%
load值：<cpu的核數
系統內存：使用率<80%
磁盤IO：<100%-90%
網絡IO：<帶寬上限
9、線程都有幾種狀態？哪些狀態需要關注？
線程狀態：runnable、waitting、timed-waitting、blocked、terminated
最影響性能的是blocked狀態（阻塞，鎖）的線程，timed-waitting（限時等待）
10、Jvm中持久代（方法區）中主要存放什么數據？老年代主要存放什么數據？
持久代中主要存放靜態數據、常量、類的基本信息等
老年代中主要存放對象的實例和數組等
11、應用服務器cpu高和數據庫服務器cpu高的分析思路是什么？
應用服務器的cpu高，先要看tps和響應時間，如果tps比較高，我們認為是正常的cpu消耗；如果tps比較低，那么往往某些代碼過於消耗cpu，可以考慮使用jprofiler分析下
數據庫服務器cpu高，往往是因為sql語句執行效率比較低，可以通過對數據庫慢查詢是監控，結合執行計划進行分析，是否是相關表沒有索引或索引未生效
12、出現內存泄露的根本原因是什么？你是怎么定位內存泄露原因的？
內存泄露的根本原因是Jvm中老年代中存在着大量存活的對象，這些對象不能被GC回收掉，從而占滿了整個老年代，造成Jvm一直處於FGC的狀態，程序沒有響應，服務器報OOM錯誤
內存泄露主要通過分析老年代中占用空間最大的類都有哪些，然后去代碼中找對應的類的創建。通常可以使用jdk提供的jvisualvm和jmap進行堆內存的分析
13、tps壓不上去，可能有哪些方面的原因？
a)壓力機本身性能瓶頸
b)網絡IO瓶頸
c)中間件（tomcat/nginx/mysql）連接數限制
b)Java線程的阻塞、等待
e)本系統資源的瓶頸（cpu、內存、磁盤、網絡等）
f)其他外部系統響應時間過長，造成本系統的time-wait
14、性能場景怎么設計？一般都有哪些性能場景？
一般基本的場景包括：基准測試、單交易測試、混合測試、穩定性測試
其他場景的可選場景：高可用性測試、異常測試等，以及其他的結合各自項目業務的場景
15、測試數據怎么構造？你一般都是采用哪些方法來造數據？
a)調用業務接口構造數據
b)直接寫jdbc代碼造數據
c)存儲過程造數據
16、常見的性能指標有哪些？分別是什么含義？
tps：每秒事務量，代表了系統的處理能力，tps越高，性能越好
響應時間：從發出請求到接受到系統響應數據所花費的時間，響應時間越短，性能越好
吞吐量：網絡上行和下行流量的總和，吞吐量是網絡瓶頸定位的重要指標
錯誤率：在壓測過程中系統出現錯誤的比例
17、什么是集合點，什么場景下需要用集合點
集合點是測試腳本中的一個標記，當每個虛擬用戶執行到標記處時，會停留在標記處等待其他的虛擬用戶，當達到預期設置的並發數時，標記處的所有用戶同時啟動執行后續的請求
集合點會產生瞬間高並發，但是也會降低平均壓力。所以在壓測過程中，如果有要求瞬間高並發的業務，就需要使用集合點，比如搶購，秒殺之類的業務。
沒有類似業務則不需要加集合點
18、性能測試過程中，怎么判斷網絡瓶頸？
一般性能測試都是在局域網內進行，在壓測過程中，可以監控到服務器上網卡的流量，判斷此流量是否已經達到局域網內網絡設備的上限，比如路由器、交換機、網卡等
在這些設備中，一般是服務器網卡網絡吞吐量最低。服務器的網卡大多是千兆網卡，換算成MB=1000/8=125MB
19、服務器的cpu使用率和load是什么關系？
通常情況下，cpu使用率和load值是正比關系，即cpu使用率越高，load值越高。但是在一些特殊情況下，也會出現cpu使用率不高，但是load值較高的情況
比如某系統只能使用CPU中的單核運行，它可以占用單核cpu100%，但從整體cpu使用率來看，只是使用了一小部分。而隨着並發的增大，單核CPU的任務隊列會越來
越長，造成了load值較高
20、性能測試腳本中為什么要做參數化？
參數化把測試腳本中的請求數據動態化，避免使用單一固定參數進行壓測。這也是為了更加真實的模擬用戶的請求
21、Linux系統中的buffer和cache都起到什么作用。內存占用有大量的buffer和cache是異常情況嗎？
buffer和cache都是Linux中的緩存機制，cache里一般會緩存一些文件的內容，buffer會緩存一些需要寫入磁盤的數據。
Linux會利用空閑的內存做一些緩存，加快文件的訪問速度。如果系統可用內存不足時，Linux會釋放掉buffer和cache所占用的內存。
所以內存占用中有大量的buffer和cache也是正常現象
22、性能腳本中的亂碼問題怎么解決？
1、如果在腳本中不使用或不判斷亂碼部分的數據，那可用忽略此問題，因為亂碼並不影響性能
2、如果需要使用亂碼數據，可以通過壓測工具提供的一些方法進行編碼轉換（如LR的lr_convert_encoding_string函數，Jmeter修改配置文件等方式）
23、在性能測試工具中，使用線程和進程壓測有什么區別，Loadrunner和Jmeter分別使用什么進行發壓？
Loadrunner同時支持進程和線程發壓。當選擇進程時，每個虛擬用戶單獨啟動一個進程，當選擇線程時，每50個線程啟動一個進程
Jmeter只支持線程發壓
進程和線程的主要區別為，進程之間是獨享內存的，線程之間是共享內存的。使用進程壓測占用的資源會大一些。在高並發下，會減少壓測工具自身的異常情況
24、性能測試腳本中，定義事務的原則是什么？
在測試腳本中，事務定義的業務流程越短越好。同時腳本中不要寫過多復雜的邏輯，對於一個復雜的場景，可以考慮把腳本拆解成多個簡單的腳本
25，產品就只給一個需求，需求調研的內容都不知道，也沒人告訴你，怎么開展性能測試？
a> 沒有任何途徑進行需求調研的情況下，可以跳過需求調研，直接開始壓測。
b> 壓測完成后，可以把本次壓測數據開會討論，共同決定是否滿足性能需求；
c> 或者根據行業內的通用指標規范，比如高頻接口響應時間<100ms，低頻<200ms的標准來判斷
26，如何定位一個系統的性能瓶頸？
見《性能案例分析》PPT
27，怎么進行性能場景設計？
通用類場景：
a> 單接口測試場景
b> 混合接口測試場景
c> 高可用性場景（集群情況下）
d> 網絡異常場景（如有必要）
e> 穩定性場景
f> 其他業務相關場景
28，給你一種xx協議的系統，怎么測試
a> 先了解協議的格式，數據交互
b> 查找壓測工具是否支持本協議
c> 如果不支持，通過自己寫代碼的方式發送協議包進行測試
29、雲上部署的應用怎么壓測？
a> 在雲上申請一台機器當做壓力機，與部署應用同區域機房，這樣相當於在雲上內網壓測
b> 與局域網壓測一樣，使用通用工具LR、Jmeter進行壓測