併發測試的方法

併發有4種測試方法。主要的差異點就是在併發測試的時候，是否會有連線的拆除。簡單總結如下：

方法1：用新建來測試併發——只有在拆除階段的時候，會有連線的拆除。

方法2：用併發的方式來測試併發，邊建立邊拆除——在達到期望的併發值後，開始有連線的拆除和新建。

方法3：用併發的方式來測試併發，從一開始就邊建立邊拆除——在達到期望併發值的過程中，就有連線的拆除和建立。

方法4：用併發的方式來測試併發，只建立不拆除——測試至始至終都不拆除

併發測試方法2：用併發的方式來測試併發，邊拆邊建立

測試場景（該方法適合於測試最好值）

場景1：驗證系統是否可以達到指定數值的的併發值。

場景2：在不知道系統併發的情況下，測試系統最大的併發值。

在這種測試模型下，會不斷的拆除會話和拆除會話，但是在每一秒來看，系統依然可以保持到一個設定的併發值。因此，在這種情況下，儀表上顯示的，累積的併發值（attempted值）會遠遠超過我們設定的併發值。此時對DUT來說，會測試到會話表的新建和拆除。

要點

如何配置load？Load的單位選擇conections或者simusers<由於新建=併發/時間，所以load裡爬坡階段的斜率，就等於此時的新建。為了避免併發測試受到新建測試的影響，所以此時斜率應該小於系統的新建值（建議在換句話說，要先測新建，再測併發）

測試用例3：驗證系統是否可以達到100w的併發

假設系統的新建為3000，需要驗證系統的併發是否可以達到100w。Load的設定如下圖所示：

特別注意，系統此時的新建值要低於系統的最大新建值（一定要“低於”，如果“等於”，也會在T2這段時間，也就是邊建邊拆的時候，出現失敗，詳細的說明可以參考下面的測試結果分析部分）

假設此時系統的新建為 3000 connections/sec

T1 = 100w/3000 = 333。3（寫334）

T2 希望的併發可以保持的時間（假設為120s）

本例設定T3 = T1

在aciton中，設定think time = T1，即 334s

特別說明：

設定think time = T1，效果是使得系統在達到希望測試的併發目標的時候（100w），沒有連線拆除。達到併發後，在T2這個時間段裡，是有連線的拆除和新建的

擴充套件說明：如果此時，設定think time = T1+T2，這時和本文描述的第一種測試方法，即“用新建的方式來測試併發”，效果是一樣的。

測試結果分析：

擴充套件說明

從方法1和方法2的結果對比中，已經可以看出，不同的效能測試方法，對系統的壓力的差異了。這點在效能測試設計中，和外測中需要特別注意。

例如本例的例子。假設系統的新建能力就只有3000，那麼在測試的過程中，特別在T2這一階段就很容易出現大量失敗。

測試用例4：測試系統可以達到多大的併發

測試系統可以達到的最大併發，和用例1的差異就是在最大負載的差異。

第一輪測試

一般會測試兩輪。第一輪的測試目的是找到一個性能的“預定值”：

先測試新建

根據系統的記憶體（可以知道一個流表佔用的記憶體大小，也可以知道用於流表的記憶體塊有多大），預估併發的最大值。

建立一個新的load。此時需要使用到stair階段：

總高度H= H1+H2 =預估系統最大的併發值 x （ 1 + 20%） 其中20%也是為經驗值。

H1= H x 80%

H2 = H x 40%

爬坡時間 T1 = H1 / 新建值 （這個新建值需要低於最大新建值，為了不讓新建影響併發，建議低於1/10）

每個階梯（h1）的爬坡斜率和H1部分的爬坡斜率一致。

設定think time = T1的時間

執行這個配置，注意觀察出現失敗的點（此時可以重點關注http transactions per second）。然後將出現失敗前的點，作為系統的最大併發值。

第二輪測試

以第一輪測試得到的最大併發值，進行測試，確認系統能夠穩定在該值。此時的測試方法和併發測試用例1的測試方法一致，不再贅述。

文章源於網路，不做任何商業用途~