效能測試準備

效能需求評估

系統特殊要求：從實時性角度來分析，某些系統對響應時間要求比較，比如餐飲系統，系統的快慢直接影響客戶的感受，這種情況就有作併發測試的必要，在大併發量的場景下，檢視這個功能的響應時間

確定效能測試點

日請求量：確定被測專案各功能點的日請求量(可以統計不同時間粒度下的請求量如：小時，日，周，月)。如果日請求量很高，系統壓力很大，而且又是關鍵業務，該專案需要做效能測試，而且關鍵業務點，可以被確定為效能點

邏輯複雜度：判定被測專案各功能點的邏輯複雜度。如果乙個主要業務的日請求量不高，但是邏輯很複雜，則也需要通過效能測試。原因是，在分布式方式的呼叫中，當某乙個環節響應較慢，就會影響到其他環節，造成雪崩效應

運營推廣活動：根據運營的推廣計畫來判定待測系統未來的壓力。未雨綢繆，防患於未然，降低運營風險是效能測試的主要目標

被測系統的效能不僅能滿足當前壓力，更需要滿足未來一定時間段內的壓力。因此，事先了解運營推廣計畫，對效能點的制定有很大的作用

效能測試準備

1，測試環境準備

系統執行環境：測試環境，有些時候需求比較多，做效能測試擔心把環境搞垮了影響其他的功能測試，可能需要重新搭建一套專門用來做效能測試的環境

執行機環境：這個就是用來生成負載的執行機，有時候甚至需要一套執行機集群

2，測試場景設計

根據效能需求來分析來設計符合使用者使用習慣的場景，場景設計的好不好直接影響到效能測試的結果

3，效能工具準備

負載工具：根據需求分析和系統特點擊擇合適的負載工具，比如lr，jmeter等

監控工具：準備效能測試時的伺服器資源，jvm，資料庫監控工具，以便進行後續的效能測試分析與調優

4，測試指令碼準備

如果效能測試工具不能滿足被測系統的要求或只能滿足部分需求時，需要我們自己開發指令碼配合工具進行效能測試

5，測試資料準備

負載測試資料：併發測試時需要多少資料？

db資料量大小：為了盡量符合生產場景，需要模擬線上大量資料情況，那麼要往資料庫裡提前插入一定的資料量。這可能需要花費一些時間，特點是關聯系統較多，邏輯複雜的業務可能同時涉及多張表

效能測試執行

1，人工邊執行邊分析

通常我們做效能測試都是人工執行並隨時觀察系統執行的情況，資源的使用率等指標。這個過程可能會很漫長，需要不斷的調整系統配置或程式**來定位問題

2，無人值守執行效能測試

無人值守是最理想化的目標

無人值守不是說沒有人力介入，而是把人為的分析和執行過程分離，執行過程只是機器服從指令的執行而已

通常測試環境在白天比較繁忙，出現效能問題及定位難度較大且會影響功能測試

所以一般效能測試最好在晚上或週末進行，在相對較安靜的條件有利於測試結果的穩定性

效能測試報告與總結

效能測試報告是效能測試的里程碑，通過報告能展示出效能測試的最終成果，展示系統效能是否符合需求，是否有效能隱患

效能測試報告中需要闡明效能測試目標，效能測試環境，效能測試資料構造規則，效能測試策略，效能測試結果，效能測試調優說明，效能測試過程中遇到的問題和解決辦法等

效能測試工程師完成該次效能測試後，需要將測試結果進行備案，並作為下次效能測試的基線標準，具體包括效能測試結果資料，效能測試瓶頸和調優方案等。

同時需要將測試過程中遇到的問題，包括**瓶頸，配置項問題，資料問題和溝通問題，以及解決辦法或解決方案，進行知識沉澱