效能測試面試題大曝光，讓你如何迅速拿下 offer！

WanWuJieKeLian發表於2024-08-09
面試題

效能測試面試題精選

1、 以前做過效能測試麼？請結合例子具體說明效能測試的流程

面試考察點：效能測試的流程

  1. 首選做效能測試的需求分析，明確效能測試的目標、範圍、場景和效能指標（如響應時間、吞吐量、併發使用者數等）。

  2. 測試效能測試環境搭建：搭建與生產環境儘可能一致的測試環境，包括硬體、網路、作業系統、資料庫等。

  3. 選擇工具編寫效能測試測試指令碼，我們用的是Jmeter工具，根據測試場景編寫效能測試指令碼，模擬使用者行為和資料互動。

  4. 效能測試執行：使用CLI命令列執行指令碼，分散式壓測，包括負載測試、壓力測試、穩定性測試等。

  5. 效能測試結果分析：收集並分析測試結果，識別效能瓶頸和潛在問題。

  6. 效能調優：根據分析結果進行效能調優，最佳化系統配置、程式碼實現等。

  7. 測試報告編寫：編寫效能測試報告，總結測試結果、分析效能瓶頸、提出最佳化建議等。

2、 單臺電腦Jmeter最大可以發多大的併發？JMeter分散式環境怎麼搭建？

面試考察點：分散式壓測

1）單機壓測併發量受到多個因素的影響，比如機器配置（如CPU、記憶體）、網路頻寬、JMeter本身的資源限制以及測試指令碼的設計，單臺電腦使用JMeter進行併發測試最大能夠支援的併發量在幾百到幾千之間不等。我們之前公司就是300多就上不去了，需要使用分散式來執行。

2）JMeter分散式環境怎麼搭建？

  • 準備好助攻機和主控機：所有的主控機和助攻機都必須用有線連線網路，同一區域網；並都安裝好同一個版本的jdk和Jmeter工具

  • 助攻機配置：

    • 修改Jmeter的配置檔案：jmeter.properties，去掉認證 server.rmi.ssl.disable=true 不使用加密認證傳輸資料；

  • 主控機配置：

    • 修改Jmeter的配置檔案：jmeter.properties，去掉認證：server.rmi.ssl.disable=true，remote_hosts=助攻機器ip:埠 ，如果有多個助攻機器資訊之間用逗號分開 ；

  • 啟動助攻機：./jmeter-server -Djava.rmi.server.hostname=助攻機的IP地址。

3、效能測試有哪些指標？有專門看效能指標的軟體嗎？

考察點：效能測試結果分析和監控

1）效能測試的指標包括：

  • 業務指標有：併發使用者數，響應時間，TPS\QPS\RPS\HPS\吞吐量\吞吐率，錯誤率；

  • 系統資源指標：CPU、 記憶體、 磁碟IO、網路IO，執行緒池、JDBC連線池、JVM記憶體（GC /FGC/YGC 堆疊）等。

2）有專門看效能指標的軟體嗎？

我們公司有專門搭建的效能監控平臺，比如監控系統資源指標：prometheus + grafana+export，可以看CPU 記憶體 磁碟 網路等指標；並可以持久化儲存；監控業務指標：influxdb + grafana+Jmeter，可以持久化儲存 TPS ERR 併發使用者數等業務指標。

4、假如你正在測試一個電商網站的效能，如何確定並設定合適的併發使用者數？

考察點：併發測試和負載測試執行

  • 1）如果是已經上線過的老專案，可以根據歷史使用者資料去評估，比如高峰使用者，線上使用者數用二八原則去計算等方式確認併發使用者數；

  • 2）如果是新專案沒有歷史資料，進行負載測試【階梯壓測】，根據預期的使用者數量和行為，逐漸增加併發使用者數，同時監測系統的效能指標，以確定系統能承受的最大併發使用者數的上限；標記該併發使用者數為合適的併發使用者數，後面的效能測試就使用這個併發使用者數進行測試。關注的指標主要有：

    • 在多少併發使用者數前出現連續報錯

    • 平均響應時間超過預期範圍

    • 伺服器資源利用率超過80%

5、壓測的過程中TPS無法隨著併發數的增加而增加，CPU也上不去，可能有哪些原因？

考察點：效能測試的分析和調優

  • 1）硬體資源限制

    • CPU資源未充分利用，比如雖然CPU使用率不高，但可能由於硬體效能瓶頸（如單核效能不足或CPU核心數限制）導致無法處理更多的併發請求

    • 記憶體不足或磁碟I/O效能瓶頸也可能影響TPS，當系統記憶體不足時，會頻繁進行頁交換，導致處理速度下降。磁碟I/O效能不足則會導致資料庫讀寫操作延遲，進而影響TPS

  • 2）軟體和配置問題

    • 如果資料庫連線池或伺服器執行緒連線池的最大連線數設定過低，或者連線池中的連線無法及時釋放，都可能導致在高併發情況下請求等待連線，從而影響TPS

    • 對於使用Java等語言的系統，頻繁的垃圾回收（GC）會佔用CPU資源，導致系統響應變慢。如果GC設定不當或記憶體分配不合理，可能會導致CPU使用率不高但TPS無法提升

    • 資料庫查詢效率低下、索引不合理、SQL語句未最佳化等都可能導致資料庫處理速度變慢，進而影響TPS。此外，資料庫鎖衝突、主從同步延遲等問題也可能導致TPS下降

  • 3）網路問題

    • 網路頻寬限制：如果網路頻寬不足或網路延遲較高，資料傳輸速度會受到影響，導致請求處理時間延長，進而影響TPS

    • 網路配置問題：如網路協議選擇不當、網路擁塞控制機制不合理等都可能影響網路效能，進而影響TPS

  • 4）應用程式問題：

    • 程式碼邏輯問題：應用程式中存在低效、死迴圈、資源競爭等問題都可能導致併發處理能力下降

    • 快取策略不當：快取策略不合理（如快取命中率低、快取過期策略不當等）會導致系統頻繁訪問資料庫或其他慢速資源，從而影響TPS。

  • 5）壓測工具和環境問題：

    • 壓測工具配置不當：壓測工具的併發數設定過低、請求時間間隔不合理等都可能導致TPS表現不穩定。此外，如果壓測工具本身存在效能瓶頸或配置問題，也可能影響測試結果

    • 測試環境差異：測試環境與生產環境之間的差異（如硬體配置、網路配置、軟體版本等）可能導致測試結果不準確。因此，在進行壓測時應儘量模擬生產環境以獲取更準確的測試結果

6、 例如100個使用者同時登陸，你如何進行測試的

我使用的是Jmeter工具來編寫指令碼，使用csv引數化來實現100個使用者同時登入：

1）先在本地建立txt檔案/或者CSV檔案，錄入100組使用者名稱和密碼（逗號分隔），將使用者名稱和密碼引數化

2）Jmeter中建立執行緒組，設定執行緒數為100個使用者併發，1秒內執行，迴圈一次

3）建立CSV data set config配置元件，引用本地txt/csv檔案

4)建立http請求，填入登入介面引數資訊,並講使用者名稱和密碼資訊進行csv的引數呼叫；

5）建立同步定時器，設定100個使用者，1秒併發執行。

7、 效能測試中，tps和qps的區別是什麼？

  • QPS[Queries Per Second]每秒查詢率，是伺服器每秒能夠響應的查詢次數，是對一個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準。

  • TPS[TransactionsPerSecond]每秒事務數，它是軟體測試結果的測量單位。一個事務是指一個客戶機向伺服器傳送請求然後伺服器做出反應的過程。客戶機在傳送請求時開始計時，收到伺服器響應後結束計時，以此來計算使用的時間和完成的事務個數。

Tps即每秒處理事務數，包括了

  • 1）使用者請求伺服器

  • 2）伺服器自己的內部查詢等處理

  • 3）伺服器返回給使用者

這三個過程，每秒能夠完成N個這三個過程，Tps也就是N；

QPS基本類似於TPS，但是不同的是，對於一個頁面的一次訪問形成一個TPS；但一次頁面請求，可能產生多次對伺服器的請求，伺服器對這些請求就可計入QPS之中。所以，QPS >= TPS.

8、jmeter錄製指令碼有了解嗎？

有了解的，Jmeter可以用 ：非配置元件 > http代理伺服器來錄製指令碼；配置一個本地的代理：127.0.0.1 和埠跟Jmeter的代理埠一致，就可以錄製指令碼了。

不過我們很少會用錄製指令碼，基本上都是自己編寫的指令碼，因為錄製的指令碼有很多垃圾報文，做很多的篩選和修改。

9、怎麼保障Jmeter工具端的效能

1）在執行效能測試時，禁用所有監聽器；

2）指令碼中，能不寫斷言的不寫；

3）效能指令碼儘量簡單一些，不寫邏輯複雜的指令碼；

4）能少用元件就少用；不用beanshell元件，效能不好；

5）儘量不用定時器元件；

10、效能測試監控工具nmon安裝及使用方法？

  • 安裝：在使用nmon對linux伺服器進行資源監控前，我們需要檢視linux的版本，然後下載支援對應版本的nmon軟體，然後，在linux伺服器上解壓軟體包，即可使用。

  • nmon有三種執行模式，螢幕互動模式，資料收集模式和定時任務模式；

    • 日常效能測試時，監控伺服器資源使用情況，常用資料收集模式，如./nmon_x86_64_centos7 -f -s3 -c10 就會每隔3秒收集一次，收集10次,將結果標準輸出到一個機器名_年月日_時分的nmon檔案中。

    • 然後可以把檔案拿出來用nmon分析客戶端進行解析，得到詳細的效能監控結果，供效能結果分析用。

11、什麼是系統瓶頸?

瓶頸主要是系統某一方面或者幾個方面能力不能滿足使用者的特定業務要求，嚴格的從技術角度講所有的系統都會有瓶頸，因為大多數系統的資源配置不是完全協調的，例如CPU使用率剛好達到100%時，記憶體也正好耗盡的系統不是很多見。因此我們討論系統瓶頸要從應用的角度討論，關鍵是看系統能否滿足使用者需求。在使用者極限使用系統的情況下，系統的響應仍然正常，我們可以認為改系統沒有瓶頸或者瓶頸不會影響使用者工作。

因此我們測試系統瓶頸主要是實現下面兩個目的：

  • 發現“表面”的瓶頸。主要是模擬使用者的操作，找出使用者極限使用系統時的瓶頸，然後解決瓶頸，這是效能測試的基本目標。

  • 發現潛在的瓶頸並解決，保證系統的長期穩定性。主要是考慮使用者在將來擴充套件系統或者業務發生變化時，系統能夠適應變化。

12、是否參與過效能分析，都需要看哪些地方？

參與過效能結果分析的，主要關注以下的點：

1）效能的各項指標：

  • 響應時間：是滿足要求，我們公司要求是平均響應時間小於1.5s；

  • 吞吐量TPS：是否能隨著使用者數增加而增加，並達到的值滿足專案的需求；

  • 資源使用率：包括CPU、記憶體、磁碟和網路等資源的使用情況，一般不能超過80%；

    • 可以透過一些Linux分析命令，比如top vmstat等檢視

    • 我們公司也有一些監控平臺：prometheus + grafana可收集和統計伺服器的資源使用情況。

  • 錯誤率：一般小於0.1%，不能有連續的報錯，保證系統的穩定性和健壯性。

2）透過分析這些指標，發現了異常之後，再透過日誌、arthas、MAT等這種分析工具具體分析效能問題的原因，如程式碼問題，資料庫問題，網路問題或者中介軟體的問題等，然後依次去最佳化。

總結

以上是最近的一些學生反饋的比較高頻的效能測試面試及參考的答案。大家需要結合這些考察點自己結合自己做過的專案的實際案例和場景去組織成為自己的語言，才能拿下offer哦！

相關文章