性能測試場景，花5分鐘了解一下?

小白學習性能測試的過程中，最普遍的一個問題就是沒有辦法弄清楚性能測試場景，這是因為，一般來說，小白收到的性能測試需求都是這樣的

• 把某某系統的性能測一下
• 把這幾個介面的性能測一下
• 我們要對這個項目做性能測試，你來搞一下

這些需求往往讓人無所適從。當然小白們也不會坐以待斃，他們會去各種渠道求助，但是遇到這樣的需求，恐怕大多數人都會表示愛莫能助。

今天我們就花5分鐘的時間來了解一下性能測試的一種常見場景————重現線上問題。希望大家弄清楚了事情的始末之後能對性能測試場景有一定的感性認識。

事情的經過是這樣的：通過日誌發現，用戶在夜間2點到2點30分的時候， 訪問某些頁面的時候特別的慢，可能是出現了性能問題，這時候需要小白同學來重現一下性能問題，以便讓開發可以更加有目的性的進行問題排查。

小白同學大致可以這樣做。

首先確定哪些頁面的性能可能出現了問題；這是確定測試範圍。

然後找相關人員，一般是運維或開發，了解一下在出現性能問題的段里，每個頁面大概有多少用戶進行了訪問。這是確定壓力負載。

接著申請一套跟線上一致的測試環境，如果沒有辦法做到一摸一樣，那麼我們可以適當的降低規格，但是軟硬體架構和一些定時任務等都需要跟線上保持一致。這是搞定測試環境。

通過測試工具來實現性能測試腳本，來模擬發生性能測試的時間段內用戶對系統的訪問情況，並在測試環境上進行調試。這是完成測試腳本。

最後通過給予一定量的負載，並在對應的時間段(2點到2點30分)進行壓力測試，重現線上問題。這是測試執行。

在本例中，系統2點到2點30分之間訪問緩慢是因為線上定時任務在頻繁的進行資料庫操作，導致資料庫讀取緩慢，從而造成了性能問題，而小白在做測試執行時準確的重現了問題，開發經過排查，很順利的定位到了問題根源，並解決了問題。

最後的最後，小白輸出測試報告，記錄測試過程，並對結果進行建議，比如晚上的定時任務建議採用讀寫分離來提升資料庫性能之類的。

好了，這是出現問題並重現問題的過程，將這個任務的目的和過程調換一下位置，先自己想像一些測試場景，然後通過增加負載的方式去看看能不能發現問題，這是一般做先驗性質的性能測試的過程。

綜上，希望對你有所幫助，有問題歡迎留言討論。

推薦閱讀：