壓力測試流程指導規範
轉載：http://www.51testing.com/html/98/n-3715998.html
(1)需求評估
a、評估是否需要做性能測試。
• 需要做性能測試
新產品要上線，預估單臺機器QPS峯值超過100。
已經上線過的產品，由於接入了新的業務或者用戶量增加，預估單臺機器QPS峯值超過100。
• 不需要做性能測試
單臺機器QPS峯值低於50的需求。
有相同產品實現邏輯的產品，且已經做過性能測試。
例如：假如一個請求，每次用戶開啓應用時都會發送到服務器，服務器則會返回給客戶端本賬號在好友中的積分排名情況。從產品的角度認爲，每次應用啓動，都會觸發服務器查詢一次數據庫。這樣會數據庫會造成很大壓力。而測試再瞭解了具體實現後發現：針對每個用戶機器碼的排序數據是從redis服務器返回的，而redis服務器會每隔一小時請求存儲的mysql服務器來更新賬號排名信息，這樣看來mysql服務器請求頻率很低，沒有任何壓力。由於redis服務器的性能之前已經測試過類似的，沒有性能問題，所以這次並不需要對mysql服務器做壓力測試。
• 設計上缺陷
如產品同上例子，就沒有走緩存，直接是讀取數據庫的壓力，在需求評審階段，就需要確認數據需要讀取。
如當前表可能是一個百萬數據級別的表，在設計階段就應該有涉及到查詢的索引。
• QPS評估方法：
產品已經灰度或者上過線，可直接參考灰度數據來推算全量用戶的QPS峯值。
產品未上過線，可通過類似已上線的產品來評估線上QPS
以上兩種都不符合，可通過通用算法來推算QPS。
b、如何選用哪種計算模型：
平穩型（正常的訪問量，用戶訪問的數據是按照用戶的作息時間訪問，沒有過多的誘導性訪問）
每臺服務器每秒處理請求的數量=((80%*總PV量)/(24小時*60分*60秒*20%)) / 服務器數量。
其中關鍵的參數是80%、20%。表示一天中有80%的請求發生在一天的20%的時間內。24小時的20%是4.8小時，有80%的請求發生一天的4.8個小時當中（很適合互聯網的應用，白天請求多，晚上請求少）。
爆發式（帶有比較強的推廣和規則的誘導，造成用戶某一時間內的訪問量髮量比較集中）
這個需要跟進自身需求的來定義α係數 * (PV/24*60*60)
α係數評估方式就是我們的PV的大部分會在多長時間內集中訪問，舉例100W的轉換率的活動， 會在上午1小時內完成，α係數 =請求量佔比/請求時間一天佔比= 1/(1/24)=24,
c、簡單計算的結果：
舉例平穩型：500W的PV。
((80%*500萬)/(24小時*60分*60秒*20%))/1 = 231.4個請求/秒
所以反推算PV和QPS的比例關係是43200：1的關係
PV QPS 服務器臺數
216W 100 1
432W 200 1
1080W 500 1
1728W 800 1
2160W 1000 1
舉例爆發型：50W的PV在1小時內的活動
24*（50W/(24小時*60分*60秒)）=138.9 個請求/秒
（2）邏輯瞭解：
目的：產品、開發、測試相互認識，便於後續的溝通。
方法：在邏輯瞭解時，組織產品、測試、開發做需求評審及產品實現講解會。
講解會需要了解的點：
• 瞭解整個性能測試的業務邏輯。一般需要了解請求個數，請求參數含義，請求參數可取值等。
• 瞭解服務器部署情況，主要要和線上服務器做明確隔離。不要簡單認爲所有的請求都是指向測試服務器，就認爲是隻向測試服務器打壓。主要分爲三種情況:1、測試請求會經過跳轉鏈接到線上服務器。2、測試請求的js會異步請求線上資源。3、測試服務器會經過邏輯處理後返回給客戶端，而這裏的邏輯處理可能包括到線上服務器處理或查詢數據。
• 瞭解本次性能測試的測試目標QPS及推斷方法。
• 瞭解本次打壓的請求間和參數間比例關係，這樣便於後續寫腳本時能夠儘量模擬線上用戶行爲。
（3）測試方案：
主要用來評估本次性能測試的排期。並以郵件通知到各方。
發送時機：開發實現講解之後，用例設計之前。
你的測試對象及環境，測試初步計劃，測試關注指標和預期等重要內容
（4）環境搭建：
1)測試服務器的搭建的搭建。測試環境可以有開發來搭建。原則上測試服務器配置不能高於線上服務器的配置，且測試服務器部署的服務要儘量接近線上服務器，比如說線上服務器上運行了3個服務，峯值時會佔用30%的cpu，那麼測試服務器也要運行同樣類似，且打壓時cpu最高只能打到70%。這樣得出的結果才具有指導意義。
2)打壓環境的搭建：主要指linux打壓機的部署。具體部署方法就不在此贅述了，具體可以參照：http://www.51testing.com/html/13/n-3715213.html
3)如果沒有條件來搭建測試服務器，可否直接用線上的？
• 如果線上的服務器之前打過壓力，可以直接用線上的壓力指標來衡量是否滿足本次需求。
• 如果之前沒有打過壓力，則在確認線上使用負載均衡的前提下，保證多臺服務器中有一臺掛掉後，其他服務器可以做到負載均衡壓力，使線上用戶不受影響時。可以對其中一臺進行打壓，在打壓時需挑選線上用戶非高峯時間段進行，且密切關注打壓服務器情況，一旦掛掉，迅速啓動起來。
（5）數據準備：
主要指性能測試有效數據的準備。請注意是有效數據？
舉例：加入你手動寫完腳本後，跑一下腳本，發現服務器返回沒有報錯。都是200的response。這是否就說明是有效的打壓呢？未必！應該回放腳本時，通過抓包工具抓包看下，對比真正使用場景中返回的response。看下內容格式是否一致。如果你的打壓腳本返回的是空的200請求或者僅僅有關鍵字，但是內容都是空的，而真正場景返回的是大小爲15K的json。這說明你的打壓場景是有問題的。
如果出現問題：應該和開發溝通原因，最後讓打壓請求返回正確的數據。
準備測試機的查看權限。服務器log位置及信息。主要信息包括服務器響應時間，出錯log標示，具體客戶端請求信息。
（6）腳本開發：
根據上面獲取到的邏輯和數據進行腳本開發。視個人習慣，可以使用錄製方式和手動寫腳本。但是需要注意一點，在保證儘量模擬用戶行爲的前提下，儘量使腳本簡單。如if語句和for循環。這類語句在高併發下，本身就可能導致壓力機性能問題。
（7）打壓過程：
打壓過程並不是放那裏不管，通過linux系統提供的命令，需要時刻關注被測服務器的性能指標，結合LoadRunner場景的曲線來動態判斷是否存在瓶頸。LoadRunner場景曲線主要關注HPS、TPS、responsetime。服務端主要監控cpu、內存、磁盤IO、網絡IO。然後從這幾方面再層層深入查找問題。另外，值得強調的是，打壓過程不僅需要關注被測服務器的指標，也需要關注打壓agent的性能指標是否正常。比如說如果併發數一直上不去，可能是打壓機本上連接數受限導致的。也可能是打壓機自己出口帶寬滿了導致的。
（8）問題定位&修改優化&迴歸：
問題定位是一個比較考驗個人綜合技術能力的地方。也是整個性能測試的核心所在。需要強調的是，不是看到某個參數遇到問題了，就直接可以斷定服務區的瓶頸就在這個地方。比如：
• 大量的頁調入請求導致內存隊列的擁塞
• 網卡的大吞吐量可能導致更多的CPU開銷
• 大量的CPU開銷又會嘗試更多的內存使用請求
• 大量來自內存的磁盤寫請求可能導致更多的CPU以及IO問題
具體是哪個部分的問題，需要再根據具體的邏輯實現和推斷來逐步縮小範圍。主要的過程可以參考一下步驟層層深入。服務器硬件瓶頸-〉網絡瓶頸（對局域網，可以不考慮）-〉服務器操作系統瓶頸（參數配置）-〉中間件瓶頸（參數配置，數據庫，web服務器等）-〉應用瓶頸（SQL語句、數據庫設計、業務邏輯、算法等）注：以上過程並不是每個分析中都需要的，要根據測試目的和要求來確定分析的深度。對一些要求低的，我們分析到應用系統在將來大的負載壓力（併發用戶數、數據量）下，系統的硬件瓶頸在哪兒就夠了。