BATJ大廠測試人員必知的經典效能問題

Time will tell.

1、效能測試包含了哪些測試？

負載測試：負載測試是一種主要為了測試軟體系統是否達到需求文件設計的目標，譬如軟體在一定時期內，最大支援多少併發使用者數，軟體請求出錯率等，測試的主要是軟體系統的效能。

壓力測試：強度測試也就是壓力測試，壓力測試主要是為了測試硬體系統是否達到需求文件設計的效能目標，譬如在一定時期內，系統的cpu利用率，記憶體使用率，磁碟I/O吞吐率，網路吞吐量等，壓力測試和負載測試最大的差別在於測試目的不同。

容量測試：確定系統最大承受量，譬如系統最大使用者數，最大儲存量，最多處理的資料流量等。

併發測試：測試多使用者併發訪問同一個應用、模組、資料時是否產生隱藏的併發問題

基準測試：比較新的或未知測試物件與已知參照標準（如現有軟體或評測標準）的效能。

爭用測試：核實測試物件對於多個主角對相同資源（資料記錄、記憶體等）的請求的處理是否可以接受。

效能配置：核實在操作條件保持不變的情況下，測試物件在使用不同配置時其效能行為的可接受性。

負載測試：核實在保持配置不變的情況下，測試物件在不同操作條件（如不同使用者數、事務數等）下效能行為的可接受性。

強度測試：核實測試物件效能行為在異常或極端條件（如資源減少或使用者數過多）之下的可接受性。

容量測試：核實測試使用者同時使用軟體程式的最大數量

2、在給定的測試環境下進行，考慮被測系統的業務壓力量和典型場景

負載測試，是用來測定系統飽和狀態、確定閥值。其特點：

1. 這種方法的目的是找到系統處理能力的極限；通過 “檢測、加壓、閥值” 手段找到如 “響應時間不超過10秒” ， “平均CPU利用率低於65%” 等指標。
2. 這種效能測試方法需要在給定的測試環境下進行，通常也需要考慮被測系統的業務壓力量和典型場景、另外HP Mercury LoadRuner在使用該方法進行“加壓”的時候必須選擇典型場景。
3. 這種效能測試方法一般用來了解系統的效能容量，或者是配合效能調優的時候來使用。特別是該的Weblogic 和庫的效能調優。

3、什麼是效能測試、負載測試、壓力測試？

效能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項效能指標進行測試。

4、什麼時候開始執行效能測試？

在產品相對比較穩定，功能測試結束後。靈活性比較強。

5、效能測試的步驟

熟悉應用、瞭解應用的架構、功能邏輯。

測試需求：

1. 需要將開發給定的需求轉為吞吐量和響應時間。

2. 根據測試目的，細化需求

測試準備：

• 測試準備包括測試客戶端機器準備、測試資料準備、測試指令碼準備。

測試執行：

• 測試的執行中，需要監控測試客戶端和伺服器效能，監控伺服器端應用情況：

1. 客戶端的系統資源（cpu、io、memory）情況
2. 服務端的系統資源（cpu、io、memory）情況
3. 伺服器的jvm執行情況
4. 服務端的應用情況，看是否有異常
5. 響應時間、吞吐量等指標
6. 系統資源監控，linux下可以採用的工具有：vmstat、top、meminfo等
7. JVM的監控，可以用jprofiler工具，linux下面的jmap、jhat等
8. 響應時間、吞吐量等，由grinder提供。

上述這些，一般在測試結束後，均需要歸檔整理，已備後續詳細分析。

我們自己開發一套指令碼，用於以固定的頻率獲取測試客戶端和伺服器的 vmstat 和 top 輸出、 grinder 的 log ，並從中擷取有用資訊儲存，用於事後分析。每次測試執行完以後，肯定會增加很多資料，需要考慮本次執行對資料量的影響，如果資料量的變化對後續測試會有影響，則需要清理資料。

6、你如何識別效能瓶頸？

RBI方法：重點測試“吞吐量”指標，因為RBI認定80%的系統效能瓶頸由吞吐量造成。

按照網路、硬體、資料庫、應用伺服器、程式碼的順序自上而下分析效能工具：IBM、HP、OpenSource 工具都支援。需使用分析模組、根據 Weblogic、Oracle 區別有專門的工具實現RBI。

7、你如何設計負載？標準是什麼？

負載測試計劃多少使用者數量、使用什麼型別的機器、以及在什麼環境下進行。

主要基於兩個重要的文件，任務分佈圖和事務資訊，任務分佈圖告訴我們在負載時間段內，某一個事務使用的使用者數，高峰使用率及低峰使用率均來自該文件；事務資訊告訴我們事務名及優先順序，在設計場景時可以參考。

8、解釋5個常用的效能指標的名稱與具體含義

分別為：響應時間、併發使用者數，吞吐量，效能計數器，TPS，HPS。

響應時間：

• 指的是 “系統響應時間” 定義為應用系統從發出請求開始到客戶端接收到響應所消耗的時間。把它作為使用者視角的軟體效能的主要體現。

併發使用者數：

• 有兩種理解方式，一種是從業務的角度來模擬真實的使用者訪問，體現的是業務併發使用者數，指在同一時間段內訪問系統的使用者數量。

• 另一種是從伺服器端承受的壓力來考慮，這裡的“併發使用者數”指的是同時向伺服器端發出請求的客戶數，該概念一般結合併發測試使用，體現的是服務端承受的最大併發訪問數。

吞吐量：

• 是指“單位時間內系統處理的客戶請求的數量”，直接體現軟體系統的效能承載能力。

效能計數器：

• 是描述伺服器或作業系統效能的一些資料指標。例如，對Windows 系統來說，使用記憶體數，程式時間等都是常見的計數器。

• 思考時間，也被稱為 “休眠時間” ，從業務的角度來說，這個時間指的是使用者在進行操作時，每個請求之間的間隔時間。

• 從自動化測試實現的角度來說，要真實地模擬使用者操作，就必須在測試指令碼中讓各個操作之間等待一段時間，體現在指令碼中，具體而言，就是在操作之間放置一個 Think 的函式，使得指令碼在執行兩個操作之間等待一段時間。

TPS：

• Transaction per second，每秒鐘系統能夠處理的交易或者事務的數量。它是衡量系統處理能力的重要指標。

點選率：

• HPS，每秒鐘使用者向WEB伺服器提交的HTTP請求數。

9、描述不同的角色（使用者、產品開發人員、系統管理員）各自關注的軟體效能要點

使用者：重點關注開啟速度及響應時間。

開發：重點關注響應時間和資料庫互動。

管理員：重點關注使用者感受到的軟體效能；如何利用管理功能進行效能調優；如何利用其他軟硬體手段進行效能調優。

10、你是如何得到效能測試需求？怎樣針對需求設計、分析是否達到需求？

在檢視需求文件，從中提取效能測試需求，與使用者交流，瞭解實際使用情況。結合業務資訊設計操作場景總結出需測試的效能關鍵指標。執行用例後根據提取關鍵效能指標來分析是否滿足效能需求。

11、效能測試的三個核心原理是什麼？

1.基於協議。效能測試的物件是網路分散式架構的軟體，而網路分散式架構的核心是網路協議。

2.多執行緒。人的大腦是單執行緒的，電腦的cpu是多執行緒的。效能測試就是利用多執行緒的技術模擬多使用者去負載。

3.模擬真實場景。使用者的訪問時間，訪問頻率都不是固定的。

12、效能測試的核心關注點是什麼？

1.使用者關注。響應時間，穩定性、可恢復性

2.運維關注。伺服器/資料庫資源使用，伺服器端處理速度,系統能否支撐7*24小時

3.測試關注。最大訪問使用者數量，最大業務處理數量，記憶體資源能否正常回收

4.開發關注。程式碼：演算法、sql語句

13、簡述效能測試流程

1.分析效能需求。挑選使用者使用最頻繁的場景來測試，比如：登陸，搜尋，下單等等。確定效能指標，比如：事務通過率為100%，TOP99%是5秒，最大併發使用者為1000人，CPU和記憶體的使用率在70%以下。

2.制定效能測試計劃，明確測試時間(通常在功能穩定後，如第一輪測試後進行)和測試環境和測試工具。

3.編寫測試用例

4.搭建測試環境，準備好測試資料

5.編寫效能測試指令碼

6.效能測試指令碼調優。設定檢查點、引數化、關聯、集合點、事務，調整思考時間，刪除冗餘指令碼

7.設計測試場景，執行測試指令碼，監控資料

8.分析測試結果，收集相關的日誌提單給開發

9.效能測試迴歸

10.編寫測試報告

14、如何確定系統最大負載？

通過負載測試，不斷增加併發，隨著併發數的增加，各項效能指標也會相應產生變化，當出現了效能拐點，比如，當使用者數達到某個數量級時，響應時間突然增長，那麼這個拐點處對應的使用者數就是系統能承載的最大使用者數。Jmeter中可以用rps定時器或者階梯加壓執行緒組。

15、你們系統哪些功能做了效能測試？

選用了使用者使用最頻繁的功能來做測試，比如：登陸，搜尋，提交訂單。

16、你們併發使用者數是怎麼確定的？

1）會先上線一段時間，根據收集到的使用者訪問資料進行預估

2）根據需求來確定，使用高峰時間段，註冊使用者數，單次響應時間等

15、你們效能測試在什麼環境執行？

搭建一套獨立的效能測試環境進行測試。

16、你們效能測試什麼時間執行？

基準測試：功能測試之後，系統比較穩定的時候再做。

負載測試：夜深人靜，系統沒人用的時候。

17、怎麼分析效能測試結果？

首先檢視事物通過率，然後分析其他效能指標，比如，確認響應時間，事務通過率，CPU等指標是否滿足需求；如果測試結果不可信，要分析異常的原因，修改後重新測試

18、think_time 的作用是什麼？

在業務基準測試中模擬使用者的思考時間。

19、在確定效能測試結果可信後，如果發現以下問題，按下面提供的思路來定位問題。

問題一：響應時間不達標

• 檢視事務所消耗的時間主要在網路傳輸還是伺服器，如果是網路，就結合 Throughput (網路吞吐量) 圖，計算頻寬是否存在瓶頸，如果存在瓶頸，就要考慮增加頻寬，或對資料的傳輸進行壓縮處理；如果不存在瓶頸，那麼，可能是網路不穩定導致。如果主要時間是消耗在伺服器上，就要分別檢視 web 伺服器和資料庫伺服器的 CPU ，記憶體的使用率是否過高，因為過高的 CPU ，記憶體必定會造成響應時間過長，如果是 web 伺服器的問題，就把 web 伺服器對應上對應的使用者操作日誌取下來，發給開發定位；如果是資料庫的問題，就把資料庫伺服器對應上對應的日誌取下來，發給開發定位。

問題二：伺服器CPU指標異常

• 1：關注cpu利用率和負載情況，如果利用率過低負載過高，那麼可能是程式佇列過多，造成了阻塞
  2：關注上下文切換，如果主動切換過多，那麼可能是記憶體/IO瓶頸；如果被動切換過多，那麼可能時間片不夠，可以考慮調整程式優先順序來增加時間片

問題三：記憶體溢位，程式消失

• 1：觀察堆記憶體的年輕代與老年代空間分配是否合理，調整記憶體引數
  2：swap空間是否不足，觸發了oomkiller

問題四：程式在多使用者執行時嚴重超時，甚至提示連不上伺服器

• 程式可能是單執行緒處理機制，後續的執行緒全部在排隊等待

問題五：如何識別系統瓶頸？

• 1：隨著負載的增加，吞吐量是否能持續穩定的上升，找到吞吐量下滑的那個點
  2：隨著負載的增加，響應時間是否開始變長，找到響應時間突然變長的那個點
  3：隨著負載的增加，是否開始出現錯誤

20、常見的施壓模型有哪幾種？

1、併發模式（虛擬使用者模式）

• 併發是指虛擬併發使用者數，從業務角度，也可以理解為同時線上的使用者數。從客戶端的角度出發，摸底業務系統各節點能同時承載的線上使用者數，可以使用該模式設定目標併發，也就是jmeter工具裡面的執行緒數

2、RPS 模式（吞吐量模式）

• RPS（Requests Per Second）是指每秒請求數。RPS 模式即“吞吐量模式”，通過設定每秒發出的請求數，從服務端的角度出發，直接衡量系統的吞吐能力。

21、tps 無法上升原因有哪些？

1.網路頻寬

在壓力測試中，有時候要模擬大量的使用者請求，如果單位時間內傳遞的資料包過大，超過了頻寬的傳輸能力，就會造成網路資源競爭，導致服務端接收到的請求數達不到服務端的處理能力上限。

2.連線池

可用連線數太少，造成請求等待。連線池一般分為伺服器連線池（比如Tomcat）和資料庫連線池（或者理解為最大允許連線數也行）。

3.GC

如果堆記憶體分配的不合理，就會導致頻繁的gc，gc會導致執行緒暫停。尤其是fullgc，會造成執行緒長時間暫停

4.資料庫配置

高併發情況下，如果請求資料需要寫入資料庫且需要寫入多個表的時候，資料庫的最大連線數不夠，或者寫入資料的SQL沒有索引，或沒有主從分離、讀寫分離，就會導致資料庫事務處理過慢，影響到TPS。

5.硬體資源

包括CPU（配置、使用率等）、記憶體（佔用率等）、磁碟（I/O、頁交換等）

6.壓力機

單機負載能力有限，如果需要模擬的使用者請求數超過其負載極限，會影響TPS（這個時候就需要進行分散式壓測來解決問題）

22、效能測試的應用領域有哪些？

能力驗證：通過實際的測試結果證明自己系統的預期能力

瓶頸分析：通過一系列的測試手段發現系統的效能瓶頸（併發，負載，壓力，失效恢復）

效能調優：通過一系列的技術手段優化系統效能，包括響應時間，吞吐量，資源利用率

容量規劃：為了符合未來的規劃預期（使用者數，市場佔有率），對資源做相應的調整

23、Jmeter如何設計效能測試場景？

併發測試：基礎執行緒組（強調單位時間的併發，不存在絕對併發）

基準測試：反覆對比結果，驗證調優結果是否通過（tps是否提升，響應時間是否下降）

負載測試：持續不斷地增加負載，發現效能瓶頸（階梯加壓執行緒組，Concurrency Thread Group）

併發使用者模式的負載：不斷增加併發使用者數，發現瓶頸

吞吐量模式的負載：不斷增加每秒請求數（rps）對服務端施壓，發現tps瓶頸

壓力測試：tps瓶頸點上持續負載

穩定性壓力測試：tps保持高壓穩定。一般取最大tps的80%持續執行

破壞性壓力測試：目的是隻需要服務端出現異常

失效恢復測試：出現異常之後，系統可以很快的恢復

容量規劃測試：50萬，高峰時間段2小時

好嘍，如果你對更多面試題、Python自動化軟體測試感興趣，在這裡推薦一個學習資料分享群：175317069。有各項已整理好的測試學習資源，也有行業深潛多年的技術人分析講解。

測試工程師職業發展路線：
功能測試 — 介面測試 — 自動化測試 — 測試開發 — 測試架構師

新人學習自動化測試，最好能夠掌握一門程式語言，掌握一些基礎的知識，多在社群論壇交流，提升自己找問題以及解決問題的能力。加油，測試人！現在就行動，總比在路上觀望要好。

最後希望看到這裡的你終成為一名極具競爭力的高階測試工程師。

覺得還不錯就【點贊】、【評論】、【關注】吧~

Time will tell.（時間會說明一切）