問題:測試好多都是性能小白,雖學了些性能知識,但在實際工作做開展性能測試,都很茫然,求指導,應該怎么處理?
回答:
從小入手,從簡單的開始,然后慢慢的做更系統更復雜的性能測試。
確定需求
剛接觸性能測試的同學往往不知道性能測試是有需求的。比如
-
給我測一下系統的性能
-
線上xx服務器掛了,能否重現一下線上問題
如果你是性能測試同學,假設時間有限,這兩個需求你只能接一個,你是接哪個?
很多同學會選第一個,因為第一個需求似乎是性能測試的需求,第二個跟性能測試似乎沒有特別強烈的關系。
但是第一個需求太泛泛了,如果不細化的話操作起來會很難,第二個盡管看起來是亡羊補牢的行為,但現實工作中這類的需求很多,操作起來也是有套路的,不會特別發散。
總之,建議新人在需求分析的時候接一些具體的,可以操作的需求。需求是否可以細化分解,基本就注定了性能測試能否順利完成
了解業務
比如重現線上問題的需求,拿到手之后,我們就必須熟悉線上的業務。用戶是怎么操作的,系統崩潰的時段是哪個,這個時段里有多少用戶在使用系統,他們都在做什么?
盡可能精確的重現用戶的行為或者預測用戶的行為,這是性能腳本的是否符合實際的關鍵。而這種精確是建立在了解業務的基礎之上的。
搭建測試環境
盡可能搭建跟線上環境一致的性能測試專用環境。
關鍵字
-
一致:最好跟線上環境一樣,如果不可能的話,可以減配,但是要保證架構一致。比如線上集群100台,測試環境沒那么多資源的情況下,可以適量減少,比如測試環境集群2台,但是一定要是集群,不然就沒意義了
-
專用:測試環境是性能測試專享的,其他測試不要在上面搞
實現腳本
比如可以用jmeter實現測試腳本,另外一些基本的性能知識也是必要的。
腳本執行及監控
根據負載模型去執行相應的腳本,這里就不展開了。
收集測試結果
對於新人來說,只需要把測試結果提交給項目組的開發人員分析就好了。對於有一定經驗的性能測試人員,希望可以通過監控和代碼走查的方式找到系統瓶頸,並給出部署的建議方案。
持續學習
-
linux知識:比如服務器kpi指標,簡單監控命令,並發模型等
-
架構知識:最簡單的方式,自己搭建性能測試環境或者線上環境,多搞幾次就熟了
-
更多知識:總之遇到不懂的就學,比如數據庫優化,jvm優化等知識
綜上。希望對你有所幫助。