測試好多都是性能小白，雖學了些性能知識，但在實際工做作開展性能測試，都很茫然，求指導，應該怎麼處理？

從小入手，從簡單的開始，而後慢慢的作更系統更復雜的性能測試。

肯定需求

剛接觸性能測試的同窗每每不知道性能測試是有需求的。好比

• 給我測一下系統的性能
• 線上xx服務器掛了，可否重現一下線上問題

若是你是性能測試同窗，假設時間有限，這兩個需求你只能接一個，你是接哪一個？

不少同窗會選第一個，由於第一個需求彷佛是性能測試的需求，第二個跟性能測試彷佛沒有特別強烈的關係。

可是第一個需求太泛泛了，若是不細化的話操做起來會很難，第二個儘管看起來是亡羊補牢的行爲，但現實工做中這類的需求不少，操做起來也是有套路的，不會特別發散。

總之，建議新人在需求分析的時候接一些具體的，能夠操做的需求。需求是否能夠細化分解，基本就註定了性能測試可否順利完成

瞭解業務

好比重現線上問題的需求，拿到手以後，咱們就必須熟悉線上的業務。用戶是怎麼操做的，系統崩潰的時段是哪一個，這個時段裏有多少用戶在使用系統，他們都在作什麼？

儘量精確的重現用戶的行爲或者預測用戶的行爲，這是性能腳本的是否符合實際的關鍵。而這種精確是創建在瞭解業務的基礎之上的。

搭建測試環境

儘量搭建跟線上環境一致的性能測試專用環境。

關鍵字

• 一致：最好跟線上環境不同，若是不可能的話，能夠減配，可是要保證架構一致。好比線上集羣100臺，測試環境沒那麼多資源的狀況下，能夠適量減小，好比測試環境集羣2臺，可是必定要是集羣，否則就沒意義了

• 專用：測試環境是性能測試專享的，其餘測試不要在上面搞

實現腳本

好比能夠用jmeter實現測試腳本，推薦測試教程網的jmeter教程

對於新人來講，實現腳本每每比較困難。

另一些基本的性能知識也是必要的，推薦看測試教程網的性能基礎知識教程

腳本執行及監控

根據負載模型去執行相應的腳本，這裏就不展開了。

收集測試結果

對於新人來講，只須要把測試結果提交給項目組的開發人員分析就行了。

對於有必定經驗的性能測試人員，但願能夠經過監控和代碼走查的方式找到系統瓶頸，並給出部署的建議方案。

持續學習

• linux知識：好比服務器kpi指標，簡單監控命令，併發模型等
• 架構知識：最簡單的方式，本身搭建性能測試環境或者線上環境，多搞幾回就熟了
• 更多知識：總之遇到不懂的就學，好比數據庫優化，jvm優化等知識

綜上。但願對你有所幫助。