方案設計思路是什麼

方案設計是設計中的重要階段，它是一個極富有創造性的設計階段，同時也是一個十分複雜的問題，它涉及到設計者的知識水平、經驗、靈感和想象力等。下面小編給大家帶來方案設計思路，歡迎大家閱讀。

　　一、需求分析

1. 測試目的

爲什麼測？目的在於測試系統相關性能能否滿足業務需求。通常分以下兩種情況：

1）新項目上線

2）老項目優化

如果是老項目優化，可考慮是否存有歷史測試方案，如果有可以參考，或許可以省事很多。

2. 測試對象

要測啥？

測試對象可以歸結爲“業務功能”。測試前，需要了解我們需要測試的業務功能（不深入細節）有哪些，比如“購買商品”、“寄送快遞”。

有沒有必要測？

需求來源哪裏？，有沒有數據支撐測試這個需求的必要性？

通常，可以從以下幾個方面考慮：

1）是否核心功能，是否要求嚴格的質量

2）是否常用、高頻使用的功能

3）可能佔用系統較多資源的功能

4）使用人數多還是少

5）在線人數多還是少

3. 拆分對象

先從業務上來分，實現這個完整的功能包含哪些流程、環節

舉例：購買商品

登錄->搜索商品->提交訂單->支付訂單->退出

然後從功能實現上來看，怎麼實現這個完整功能的。通常這些業務功能操作都對應着一個或多個請求(可能能是不同類型的請求，比如http, mysql等)，我們要做的是找出這些操作對應的請求，請求之間的順序是怎麼樣的。

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，第三年 20xx0，第四年25000，那麼我們得出，以第一年爲基準，數據增長率分別爲 0.5，1，1.5，每年在上一年的基礎上，以5000的速度增長

預估3年後，數據增長率爲 3，需要測試數據量爲 （1+3）x 10000 = 40000

注意：

1、實際數據一般是沒上面舉例那麼規律的，只能大致估算數據增長率。

2、一些大數據量的性能測試除了和數據量相關，還涉及到數據分佈等，比如查詢，構造數據時需要結合實際，儘量貼近實際。

3、不同業務模塊，涉及表不一樣，數據量要求也是不一樣的，需要有區別的對待。

如果是新項目，那就比較不確定了，除非能收集相關數據。

　　二、系統分析

結合需求分析中第3點，分析系統架構。

1）請求順序、請求之間相互調用關係

2）數據流向，數據是怎麼走的，經過哪些組件、服務器等

3）預測可能存在性能瓶頸的環節（組件、服務器等）

4）明確應用類型 IO型，還是CPU消耗性、內存消耗型-> 弄清楚重點監控對象

5）關注應用是否採用多進程、多線程架構-> 多線程容易造成線程死鎖、數據庫死鎖，數據不一致等

6）是否使用集羣/是否使用負載均衡

瞭解測試環境部署和生產環境部署差異，是否按1:1的比例部署

通常建議測試時先不考慮集羣，採用單機測試，測試通過後再考慮使用集羣，這樣有個比較，比較能說明問題

參考閱讀“淺談web網站架構演變過程 ”：

　　三、業務分析

1）明確要測試的功能業務中，功能業務佔比，重要程度。

目的在於

<1>明確重點測試對象，安排測試優先級

<2>建模，混合場景中，虛擬用戶資源分配，針對不同業務功能施加不同的負載。

2）明確下“需求分析-指標分析”中相關業務功能所需基礎數據及數據量問題，因爲那塊需求分析時可能只是大致估算下，評估指標是否合理，需要認真再分析下

　　四、用例設計

1）用例設計

通常是基於場景的測試用例設計

<1>單業務功能場景

運行測試期間，所有虛擬用戶只執行同一種業務功能某個環節、操作

<2>混合業務功能場景

運行測試期間，部分虛擬用戶執行某種業務的某個環節操作，部分虛擬用戶執行該業務功能的其它環節

或者

運行測試期間，部分虛擬用戶執行某種業務功能，部分虛擬用戶執行其它業務功能

注：這裏用例沒說到多少用戶去跑，跑多久等，這裏只是把他當作相同場景用例下的的一組組測試數據了。

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>理解工具實現原理

<2>採用用異步還是同步

常識：

1．同步請求：發出一個調用請求，在沒有得到結果之前，該調用就不返回。

2.異步請求：發出一個調用請求，在沒有得到請求結果之前，該調用可立即返回。該調用請求的處理者在處理完成後通過狀態、通知和回調等來通知調用者。

<3>使用長連接還是短連接

　　七、 軟件配置

1）操作系統

內核版本、32 or 64位?

2）應用版本

應用版本要和線上保持一致，特別是中間件、組件等的版本，因爲不同版本，其性能可能不一樣

3）參數配置

<1>負載均衡、反向代理參數配置

<2>Web服務器參數配置

<3>數據庫服務器參數配置

　　八、網絡分析

1）網絡路由

通常爲了排除網絡型瓶頸，通常建議在局域網下進行測試。

通常，這裏我的分析思路是這樣的：

<1>檢查hosts文件的配置

從終端壓測機(負載生成機)開始，到請求目的服務器器，機器的hosts文件配置

通常，hosts文件位於如下：

Windows：C:WindowsSystem32driversetchosts

Unix/Linux：/etc/hosts

小常識：

1、通常域名訪問站點，首先要通過DNS域名服務器把網絡域名（形如）解析成的IP地址，然後繼續後續訪問。

2、hosts存放了域名和ip地址的映射關係，如下

性能測試方案設計思路總結

使用hosts可以加快域名解析，在進行DNS請求以前，系統會先檢查自己的hosts文件中是否有這個地址映射關係，如果有則把域名解析爲映射的IP地址，不請求網絡上的DNS服務器，如果沒有再向已知的DNS 服務器提出域名解析。也就是說hosts的請求級別比DNS高，可加快域名解析。

<2>檢查DNS配置

不同DNS，其速度和準確率是不一樣的，比如速度遠比快，如果有用到DNS（特別是壓測機），需要考慮下是否適當

<3>確保路由正確設置

2）網絡帶寬

如果沒條件在局域網下測試，可能需要估算所需大致帶寬。

如果測試時是基於UI層操作的操作，那麼得估算頁面平均大小，這個可以通過瀏覽器自帶工具查看打開單個頁面服務器返回的請求數據大小。如果是測試時是基於接口層的請求測試，可以通過工具查看服務器響應數據大小。

然後根據採集的頁面PV峯值、請求數峯值進行計算。

假設在 PV峯值、請求數峯值 = 1000，峯值時段：8:00 - 12:00，平均頁面、請求大小 20xx

帶寬 = 1000 x 80% / (20% x 4 x 3600s) x 20xxB x /1024 x 8bit ,單位MBps

注意： 這裏涉及到瀏覽器緩存等因素，估值可能不準，大致估算。

　　九、硬件配置

1) CPU

型號，頻率，核數

2) 內存

3) 磁盤

不同磁盤類型，讀寫速率不一樣

4) 網卡

不同網卡，其傳輸速率也不一樣

注意：硬件配置最好和生產環境的配置保持一致

　　十、性能監控

略

注意：

1） 這裏監控不僅僅是服務器自身性能指標監控，如cpu，還包括事務耗時監控等

2） 需要記錄測試前各個性能指標數據，方便後續測試對比

　　十一、 實施測試

略

　　十二、 結果分析

如果是性能調優，還需同上一個版本的性能測試結果對比。