上週收到幾位同學的面試反饋，講到自己面試過程中被問及性能測試相關知識後，僅僅會使用一些性能或自動化工具的錄製功能，面試官問到的指標與專業術語卻說不清。這裡需要強調的一點是，大家在學習一個新領域的知識時，首先要清楚自己要做什麼事？訴求是什麼？然後根據需求點去找自己需要學習的東西，而工具僅僅是輔助我們做這件事的其中一個環節而已，而且如果僅僅是停留在使用工具層面，即使用得再熟練 ，也只能是一個執行者，而不是決策者或設計者。

所以，踏踏實實先把基本的概念理解透徹，再進行下一步，你會發現很多問題會迎刃而解。（但也不建議啃書模式， 從最基本概念瞭解，偏難的在工作中碰到再去攻克，循序漸進）

這裡分享下性能測試中常見的一些性能指標~

說明下，一般在測試工程師面試中，也經常會問到: 之前做過哪些性能測試項目？說說項目中都關注哪些性能指標了，xx指標，你怎麼理解他的含義？你是怎麼做穩定性測試的？並發數如何計算的？等等。

性能指標與常見術語

深入透徹地理解本節中的基本概念後，即可一一解答這些問題。日後的學習也事半功倍~

並發數

首先，理解三個用戶數的概念：

系統用戶數、在線用戶數、並發用戶數

系統用戶數就是一個系統中所有的註冊用戶數。eg. 當前微信中的所有註冊用戶數；在線用戶數是當前登錄系統的用戶數，eg.當前登錄微信的總用戶數 （均為在線狀態，不管該用戶做什麼操作）；並發用戶數是指對Server產生壓力的用戶數，eg.當前微信所有登錄用戶中，正在進行操作的用戶數（僅指對Server產生壓力的操作）

我們測試時僅關注並發用戶數，一般，需求採集人員會將線上的並發用戶數根據日誌或工具分析統計出。測試時，要以性能測試需求為準，此外，並發操作也包含多種情況 ，如所有用戶同時進行購買或支付操作；或多個用戶同時發出多個不同請求，如加入購物車、刪除商品、增減數量、支付、退款等操作。

響應時間

先看一個請求從發出到用戶看到結果的過程：用戶發送一個請求後，通過網路傳輸、DNS解析等步驟到達Server端後，Server通過各種演算法處理，將結果通過網路傳輸返回到Client，Client要經過解析渲染等步驟，最後才呈現給用戶。

通過以上流程可知，響應時間的計算模式：響應時間=請求傳輸時間+Server處理時間+響應傳輸時間+前端解析渲染時間。

由此可見，在工作中，一方面響應時間要根據不同業務及用戶的具體要求而定；另一方面分析結果時要注意當前的業務模型（如前端性能測試與伺服器性能測試）

TPS

即Transaction Per Second，每秒通過事務數。TPS是直接反映系統性能的指標。TPS值與系統性能成正比。

環境不變的情況下，一個系統是有一個最大TPS值的。分析結果時，一般將TPS與平均事務響應時間作對比，以得出事務數量對響應時間的影響趨勢。

吞吐量

即單位時間內系統能處理的請求數量，吞吐量也是可直接反映伺服器所能承受的壓力。

資源利用率

關於資源利用率初期瞭解以下幾個重要指標即可：

CPU

對於CPU都不陌生，簡言之，是用來處理＼判斷事務的，CPU一般有系統CPU與用戶CPU，前者是 處理系統佔用的資源 ；而後者是處理應用程序佔用的資源 。

網路

即網路傳輸的流量，測試過程中對網路的監控以，以分析是否存在瓶頸。

IO

即，Input/Output，輸入/輸出。關注與磁碟的交互頻率等

內存

即數據存儲區域。一般讀數據時從內存中讀取要比硬碟讀取快很多 ，但需要關注的是內存溢出或內存泄漏問題。

隊列

屬於數據結構的概念了 ，是一種線性表，可以在隊列前刪除，在隊尾處進行插入。測試過程中，如果發現隊列越來越長，很可能會發生阻塞問題。

思考時間

簡單理解 ，就是用戶在幾個操作時的間隔時間，是為了最大程度的模擬用戶的實際操作；而有些系統會直接設定某些操作的間隔時間，如發布動態、申請提現等。尤其做壓力測試時需要根據實際業務來設計場景。

推薦閱讀：

相關文章