1.規範的效能測試流程
獲得測試需求→測試計畫→測試環境搭建→測試用例設計→測試資料準備→測試指令碼編寫→測試指令碼執行→瓶頸分析定位→測試結果反饋→測試報告
2.流程節點解釋
①獲取測試需求:
提出人:甲方/業務方+開發人員
依據系統後期可能達到的訪問量(甲方/業務方),以及系統架構、資料庫,伺服器等(開發人員)。確定「核心業務場景」以及「測試指標」。
②測試計畫:
需「專案經理,甲方/業務方,測試人員」溝通確認。
③測試環境搭建→測試用例設計→測試資料準備→測試指令碼編寫→測試指令碼執行:
這部分和功能測試流程大體一致。
側重點在於測試環境的搭建(壓力機構建),測試資料準備,指令碼編寫。
④瓶頸分析:
這是很重要的乙個環節。
效能測試不是一蹴而就的,要達到壓測需求,需反覆調優和壓測。
開始壓測前,需要設定壓力
檢視linux作業系統連線數
以下是我個人專案總結的幾點:1.壓力機效能需滿足壓測需求
2.本地壓測(指令碼放在系統伺服器上執行),排除網路因素,測試系統的健壯性。
3.模擬真實的業務場景(eg:裝置是連線手機熱點上報資料,壓力機的網路連線為手機熱點)
4.cpu上不去,指令碼執行大量失敗。(需經理和開發人員進行**審核)
5.低併發,cpu過高。(需**調優)
測試人員可以在伺服器上,用top命令找出cpu佔用率最大的執行緒。
top //這樣查出來的執行緒編號是:找到cpu佔用率最大程序的pid,或者是待測指令碼的pid
top -p [pid] //
只監控這個pid
h //
檢視當前程序的執行緒資訊,找到cpu消耗最高的執行緒id
jstack 11567 [pid] //
做dump,輸出整個程序資訊
執行緒id轉換為十六進製制 = dump檔案中的nid = 記憶體消耗最大的**塊,可以擷取此部分給開發看
效能測試瓶頸分析
在效能測試過程中,瓶頸猶如功能測試的bug,瓶頸的分析猶如bug的定位。效能測試工程師好比醫生,看到病象,定位 效能瓶頸的定位更像庖丁解牛,層層解剖,最後定位問題之所在。下面分享乙個記憶體洩漏的瓶頸分析。病象 tps波動非常大 狂打超時日誌 偶爾有500錯誤。看到這個現象,其實說明不了什麼問題,就象...
效能測試瓶頸分析
在效能測試過程中,瓶頸猶如功能測試的bug,瓶頸的分析猶如bug的定位。效能測試工程師好比醫生,看到病象,定位 效能瓶頸的定位更像庖丁解牛,層層解剖,最後定位問題之所在。下面分享乙個記憶體洩漏的瓶頸分析。病象 tps波動非常大 狂打超時日誌 偶爾有500錯誤。看到這個現象,其實說明不了什麼問題,就象...
效能測試瓶頸分析
在效能測試過程中,瓶頸猶如功能測試的bug,瓶頸的分析猶如bug的定位。效能測試工程師好比醫生,看到病象,定位 效能瓶頸的定位更像庖丁解牛,層層解剖,最後定位問題之所在。下面分享乙個記憶體洩漏的瓶頸分析。病象 tps波動非常大 狂打超時日誌 偶爾有500錯誤。看到這個現象,其實說明不了什麼問題,就象...