效能測試方案設計
透過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項效能指標進行測試，這就是效能測試。下面是效能測試方案設計，為大家提供參考。
一、需求分析
1. 測試目的
為什麼測？目的在於測試系統相關效能能否滿足業務需求。通常分以下兩種情況：
1）新專案上線
2）老專案最佳化
如果是老專案最佳化，可考慮是否存有歷史測試方案，如果有可以參考，或許可以省事很多。
2. 測試物件
要測啥？
測試物件可以歸結為“業務功能”。測試前，需要了解我們需要測試的業務功能（不深入細節）有哪些，比如“購買商品”、“寄送快遞”。
有沒有必要測？
需求來源哪裡？，有沒有資料支撐測試這個需求的必要性？
通常，可以從以下幾個方面考慮：
1）是否核心功能，是否要求嚴格的質量
2）是否常用、高頻使用的功能
3）可能佔用系統較多資源的功能
4）使用人數多還是少
5）線上人數多還是少
3. 拆分物件
先從業務上來分，實現這個完整的功能包含哪些流程、環節
舉例：購買商品
登入->搜尋商品->提交訂單->支付訂單->退出
4. 指標分析
分析效能需求指標（如“支援300人併發登入”）是否合理
有必要測試這個需求，考慮需求指標是否合理？有沒有資料支撐？
通常，支撐資料可以從以下方面考慮：
1）取樣時間段內系統使用人數
2）取樣時間段內系統線上人數
3）取樣時間段內系統(頁面)訪問量
4）取樣時間段內請求數
....
常用分析思路：
1）2/8法則
2/8法則：80%的業務量在20%的時間裡完成。這裡，業務量泛指訪問量，請求數，資料量等
2）正態分佈
3）按比例倍增
4）響應時間2-5-8原則
就是說，一般情況下，當用戶能夠在2秒以內得到響應時，會感覺系統的響應很快；當用戶在2-5秒之間得到響應時，會趕緊繫統的響應速度還可以；當用戶在5-8秒以內得到響應時，會趕緊繫統的速度很慢，但是還可以接受；而當用戶在超過8秒後仍然無法得到響應時，會感覺系統糟糕透了，或者認為系統已經失去響應。
注意：這個要根據實際情況，有些情況下時間長點也是可以接受的，好比12306
舉例：
某公司後臺監控，根據一段時間的取樣資料，分析得出日高峰時段(11:00-14:00)使用者下單請求數平均為1000，峰值為1500，根據這個計算併發請求數
時段：3個小時 -> 3 x 60 x 60 = 1080s
業務量：1500
吞吐量：1500 * 80% / (1080 * 20%) = 5.56請求數/s
假設使用者下單遵循正態分佈，那麼併發請求數峰值會肯定大於上述估算的吞吐量
注意:
1、2/8原則計算的結果並非在線併發使用者數，是系統要達到的處理能力（吞吐量）
2、如果要求更高系統性能，根據實際情況，也可以考慮1/9原則或其它更嚴格的演算法
3、以上估值只是大致的估算，不是精確值
舉例：
想了下，暫時沒想到啥好的例子，大致就說一些涉及到資料量的效能測試，比如報表統計，或者是大資料探勘，查詢等，怎麼去估算資料量？
資料生命週期：
一般來說，資料都是有一定的生命週期的，時間的選取需要結合資料週期考慮。這裡假設3年後系統性能仍然需要滿足業務需求。
資料增長率：
如果是老專案，可以考慮對應功能主表歷史資料存放情況
這裡假設按年統計，比如第一年 10000，第二年 15000，第三年 20000，第四年25000，那麼我們得出，以第一年為基準，資料增長率分別為 0.5，1，1.5，每年在上一年的基礎上，以5000的速度增長
預估3年後，資料增長率為 3，需要測試資料量為 （1+3）x 10000 = 40000
注意：
1、實際資料一般是沒上面舉例那麼規律的，只能大致估算資料增長率。
2、一些大資料量的效能測試除了和資料量相關，還涉及到資料分佈等，比如查詢，構造資料時需要結合實際，儘量貼近實際。
3、不同業務模組，涉及表不一樣，資料量要求也是不一樣的，需要有區別的對待。
如果是新專案，那就比較不確定了，除非能收集相關資料。
二、系統分析
結合需求分析中第3點，分析系統架構。從功能實現上來看，怎麼實現這個完整功能的.。通常這些業務功能操作都對應著一個或多個請求(可能能是不同型別的請求，比如http, mysql等)，我們要做的是找出這些：
1）請求順序、請求之間相互呼叫關係
2）資料流向，資料是怎麼走的，經過哪些元件、伺服器等
3）預測可能存在效能瓶頸的環節（元件、伺服器等）
4）明確應用型別 IO型，還是CPU消耗性、記憶體消耗型-> 弄清楚重點監控物件
5）關注應用是否採用多程序、多執行緒架構-> 多執行緒容易造成執行緒死鎖、資料庫死鎖，資料不一致等
6）是否使用叢集/是否使用負載均衡
瞭解測試環境部署和生產環境部署差異，是否按1:1的比例部署
通常建議測試時先不考慮叢集，採用單機測試，測試通過後再考慮使用叢集，這樣有個比較，比較能說明問題
三、業務分析
1）明確要測試的功能業務中，功能業務佔比，重要程度。
目的在於
<1>明確重點測試物件，安排測試優先順序
2）明確下“需求分析-指標分析”中相關業務功能所需基礎資料及資料量問題，因為那塊需求分析時可能只是大致估算下，評估指標是否合理，需要認真再分析下
四、用例設計
1）用例設計
通常是基於場景的測試用例設計
<1>單業務功能場景
執行測試期間，部分虛擬使用者執行某種業務的某個環節操作，部分虛擬使用者執行該業務功能的其它環節
或者
執行測試期間，部分虛擬使用者執行某種業務功能，部分虛擬使用者執行其它業務功能
注：這裡用例沒說到多少使用者去跑，跑多久等，這裡只是把他當作相同場景用例下的的一組組測試資料了。
2）事務定義
根據用例合理的定義事務，方便分析耗時（特別是混合業務功能場景測試），進而方便分析瓶頸。
比如，購買商品，我們可以把下訂單定義為一個事務，把支付也定義為一個事務。
3）場景監控物件
針對每條用例，結合“系統分析”第4）點，明確可能的壓力點（比如資料庫、WEB伺服器），需要監控的物件，比如tps，耗時，CPU，記憶體，I/O等
五、測試策略
1）先進行混合業務功能場景的測試，在考慮進行測試單業務功能場景的測試
2）負載測試 -> 壓力測試-> 穩定性測試-> 強度測試
注：如果測試穩定性，時間建議至少8小時；
3）逐步加壓
比如開始前5分鐘，20個使用者，然後每隔5分鐘，增加20個使用者。
好處：不僅比較真實的模擬現實環境，而且在效能指標比較模糊，且不知道伺服器處理能力的情況下，可以幫我們確定一個大致基準，因為通常情況下，隨著使用者數的不斷增加，伺服器壓力也會隨著增加，如果伺服器不夠強大，那麼就會出現不能及時處理請求、處理請求失敗的情況下，對應的執行結果圖形中，執行曲線也會出現對應的形態，比如從原本程一條穩定直線的情況，到突然極限下降、開始上下波動等，透過分析我們就能得出伺服器大致處理能力，供後續測試參考。
4）單點併發
比如使用集合點，單獨針對某個環節的併發測試，通常是針對某個環節的效能調優時使用。
常識：
a) 負載測試
保證系統能正常執行(通常是滿足某些系統性能指標)的前提下，讓被測物件承擔不同的工作量，以評估被測物件的最大處理能力及存在缺陷而進行的測試
b) 壓力測試
不保證系統能否正常執行的前提下，讓被測物件承擔不同工作量，以評估被測物件能提供的最大處理能力及存在缺陷而進行的測試
c) 穩定性測試
測試系統的長期穩定執行的能力。同疲勞強度測試的區別是，穩定性測試的壓力強度較小，一般趨向於客戶現場日常狀態下的壓力強度，當然在透過時間不能保證穩定性的狀態下，需要加大壓力強度來測試，此時的壓力強度則會高於正常值。
d) 強度測試
通常模擬系統在較差、異常資源配置下執行，如人為降低系統工作環境所需要的資源,如網路頻寬,系統記憶體,資料鎖等等,以評估被測物件在資源不足的情況下的工作狀態
注：疲勞強度測試是一類特殊的強度測試，主要測試系統長時間執行後的效能表現，例如7x24小時的壓力測試。
六、工具選取
1）協議分析
一般效能測試工具都是基於協議開發的，所以先要明確應用使用的協議
2）工具選取
1）型別
開源工具、收費工具、自研工具
2）分析工具
<1>理解工具實現原理
常識：
1．同步請求：發出一個呼叫請求，在沒有得到結果之前，該呼叫就不返回。
2.非同步請求：發出一個呼叫請求，在沒有得到請求結果之前，該呼叫可立即返回。該呼叫請求的處理者在處理完成後透過狀態、通知和回撥等來通知呼叫者。
<3>使用長連線還是短連線
<2>Web伺服器引數配置
八、網路分析
1）網路路由
通常為了排除網路型瓶頸，通常建議在區域網下進行測試。
通常，這裡我的分析思路是這樣的：
<1>檢查hosts檔案的配置
不同DNS，其速度和準確率是不一樣的，比如114.114.114.114速度遠比8.8.8.8快，如果有用到DNS（特別是壓測機），需要考慮下是否適當
<3>確保路由正確設定
2）網路頻寬
如果沒條件在區域網下測試，可能需要估算所需大致頻寬。
如果測試時是基於UI層操作的操作，那麼得估算頁面平均大小，這個可以透過瀏覽器自帶工具檢視開啟單個頁面伺服器返回的請求資料大小。如果是測試時是基於介面層的請求測試，可以透過工具檢視伺服器響應資料大小。
然後根據採集的頁面PV峰值、請求數峰值進行計算。
假設在 PV峰值、請求數峰值 = 1000，峰值時段：8:00 - 12:00，平均頁面、請求大小 200k
頻寬 = 1000 x 80% / (20% x 4 x 3600s) x 200KB x /1024 x 8bit ,單位MBps
注意： 這裡涉及到瀏覽器快取等因素，估值可能不準，大致估算。
九、硬體配置
1) CPU
型號，頻率，核數
2) 記憶體
3) 磁碟
不同磁碟型別，讀寫速率不一樣
4) 網絡卡
不同網絡卡，其傳輸速率也不一樣
注意：硬體配置最好和生產環境的配置保持一致。