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

把某某系統的效能測一下

把這幾個介面的效能測一下

我們要對這個專案做效能測試，你來搞一下

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

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

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

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

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

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

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

透過測試工具來實現效能測試指令碼，來模擬發生效能測試的時間段內使用者對系統的訪問情況，並在測試環境上進行除錯。這是完成測試指令碼。

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

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

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

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

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