回答：從小入手，從簡單的開始，然後慢慢的做更系統更複雜的效能測試。
剛接觸效能測試的同學往往不知道效能測試是有需求的。比如
如果你是效能測試同學，假設時間有限，這兩個需求你只能接乙個，你是接哪個？
很多同學會選第乙個，因為第乙個需求似乎是效能測試的需求，第二個跟效能測試似乎沒有特別強烈的關係。
但是第乙個需求太泛泛了，如果不細化的話操作起來會很難，第二個儘管看起來是亡羊補牢的行為，但現實工作中這類的需求很多，操作起來也是有套路的，不會特別發散。
總之，建議新人在需求分析的時候接一些具體的，可以操作的需求。需求是否可以細化分解，基本就注定了效能測試能否順利完成
比如重現線上問題的需求，拿到手之後，我們就必須熟悉線上的業務。使用者是怎麼操作的，系統崩潰的時段是哪個，這個時段裡有多少使用者在使用系統，他們都在做什麼？
盡可能精確的重現使用者的行為或者**使用者的行為，這是效能指令碼的是否符合實際的關鍵。而這種精確是建立在了解業務的基礎之上的。
盡可能搭建跟線上環境一致的效能測試專用環境。
關鍵字比如可以用jmeter實現測試指令碼，另外一些基本的效能知識也是必要的。
根據負載模型去執行相應的指令碼，這裡就不展開了。
對於新人來說，只需要把測試結果提交給專案組的開發人員分析就好了。對於有一定經驗的效能測試人員，希望可以通過監控和**走查的方式找到系統瓶頸，並給出部署的建議方案。
綜上。希望對你有所幫助。
測試過程控制 如何開展效能測試
效能測試的提前準備關注點 1 效能測試的環境配置需要能夠盡可能的模擬版本的現場使用，包括外網的裝置，軟體網元，各種硬體平台，作業系統，軟體平台 2 效能測試需要準備合適的模擬指令碼來盡可能全真的模擬客戶可能的操作，比如同時並行網頁操作，同時進行socket連線等。而且要超出客戶的真實可能情況。效能測...
如何在實際工作中發現模式（一）
前提 模式的發現是可遇不可求的，既然是發現，就有機會的成分存在。不可能當我們希望發現模式時就一定能夠發現，困此發現模式的第 個前提是不要為了發現而發現，這樣你會失望的。然而，機會從來是被有準備的人抓住的。重構原有的專案 學習同行的經驗和總結是發現模式的最好時機。需要強調的是，不僅僅只有設計模式，分析...
如何在實際工作中發現模式（二）
描述解決方案 如果forces描述非常吸引人，那麼使用者會迫切希望知道解決方案。軟體開發人員通常希望採用圖示法描述解決方案，因為一張圖勝過千行字。然而需要注意的是，如果採用圖示，一定要確保使用者知道圖示的含義。如果採用uml等標準的圖示語言，一定要準確合理 如果是非標準的圖示，一定要註明圖例的含義。...