為什么要在性能測試中設置考慮時間

　　考慮時間Thinking Time指的是在性能測試腳本中，事務與事務之間，會有一些短暫的停頓，就好像真實用戶在操作時，兩次操作之間需要考慮一下。比如用戶注冊的時候，在打開注冊頁面到提交注冊頁面之間，是有一段考慮時間的(用戶在填寫個人信息)。

　　下面就討論一下在性能測試實戰中，為什么要設置考慮時間。

　　先說一個概念：吞吐量，這指的是服務器系統(包括軟件和硬件)單位時間內處理業務的數量。我們現在做一個小試驗，寫一個小程序，執行一個簡單的業務，并且在程序中進行計時，計算每分鐘能執行多少次。然后當我們運行1路這個程序的時候，每分鐘能完成約6萬次。好，現在問一個問題，如果我們起2路，是不是每一路都能達到 6萬/分鐘 的吞吐量?

　　試驗發現，當運行2路的時候，兩個程序的數值都降了下來，但是它們的總和仍然是6萬次。而且不管我們起多少路，這些程序的性能總和都接近于6萬。

　　這就好像一個人1分鐘最快能吃1個饅頭，你讓他一個一個吃，他兩分鐘能吃2個，如果你讓他一手拿一個，同時吃，他兩分鐘吃不了4個，還是只能吃兩個。

　　我們不是在說“考慮時間”么，哈哈，別急，因為上面的問題必須要先說清楚。

　　如果我們需要進行性能測試的業務是一個單純的業務，就好像上面舉的那個例子一樣，那么測試腳本中就不需要設置“考慮時間”，因為不管你用什么方法測試，一個服務系統處理單一業務的吞吐量總是一個定值。

　　但是在實際環境里面，往往一個系統都是要處理多種業務，并且這些業務之間是有邏輯關系的。舉例說明，比如一個論壇系統，每天最常處理的業務有兩個：A打開帖子、B回復帖子。那么每天系統處理AB業務的總數是不是一樣的呢，答案很明顯，看帖子多，回復的少一些。假設A:B=2:1。

　　好，如果我們不設置考慮時間，起2路A的腳本，1路B的腳本進行性能測試，我們會得到什么結果呢?我們會得到這兩個業務的吞吐量，并且能算出每個小時系統完成A、B業務的總數，吞吐量 × 時間 = 總數。

　　這時我們發現，同樣時間，AB業務的處理總數卻不是2:1的關系，這是為什么呢?原因是這樣的，我們在跑AB腳本的時候，這兩組腳本都在盡全力爭奪服務器的資源，他們的并發路數雖然是2:1，但是給服務器的壓力卻不一定是2:1，可能會出現偏差，測試結果就是最好的證據。A查看帖子由于響應時間短，因此跑的次數更多，最后的比例可能是4:1。

　　那么這樣的結果有什么問題呢?？偨Y為一句話：測試環境的業務和真實環境不符，這樣測出的數據沒有價值。即使測試通過，也不能證明真實環境是ok的;或者即使測試不通過，也不能說明真實環境不ok，呵呵。

　　比如上面的例子，如果我們測出的結果是B回復帖子的吞吐量不夠，響應時間太長，那可能是因為A業務搶走了過多的，本不屬于A的資源，而引起了B的性能降低。

　　說到這里，大家應該明白了，我們設置考慮時間，是為了保證測試復合業務的時候，各個業務之間的比例關系符合我們的真實生產環境。

原文轉自：http://www.uml.org.cn/Test/200712203.asp