軟件性能測試中考慮時間Thinking Time的計算 軟件測試
我們講了設置考慮時間是為了保證測試環境和生產環境盡量一致，今天我們講一下考慮時間的計算方法，以及考慮時間是如何讓測試環境更符合生產環境。
我們還是引用上次那個例子：測試一個論壇系統的兩個業務，A查看帖子、B回復帖子，假設每天會員查看帖子的總數(PV)是回復帖子的2倍，也就是A:B=2:1，因此我們的性能測試也要符合這一比例，如果我們測出的結果是5:1，那么測試結果就沒有意義了。
這里我們要先講一個容易混淆的概念。是不是性能測試中的考慮時間等于用戶實際使用中的“考慮的時間”呢。答案是不。我們不能根據用戶實際的考慮時間來設置性能測試的考慮時間，而要經過計算才能得到正確的考慮時間。
一般我們會先錄制編寫A、B的測試腳本，這時要把腳本中的考慮時間全部刪除，因為錄制時產生的考慮時間不能直接作為正式性能測試的考慮時間。腳本制作好以后我們開始進行計算，(當然也可以先計算再做腳本)。
剛才我們的要求是A:B=2:1，我們還要確定具體的數字，比如我們經過分析發現，論壇系統A業務每小時的(PV)數量大約是10k，B業務是5k，而且對用戶來說，頁面的響應時間最多不能超過5秒。好，這就是我們測試的一個基準。注意，這些數據在計算前就需要確定下來，我們可以從類似的系統中采集數據，也可以根據用戶的數量進行估算，這些工作可以和產品經理討論溝通，達成一致。
確定了這些數據基準以后，我們開始計算。這里先講一個公式：
并發數 / (響應時間+考慮時間) = 總業務數 / 總時間
先看等式右邊，這在上一篇曾經出現過：總業務數 / 總時間 = 系統吞吐量。
比如A業務每小時是10k，那么系統處理A的吞吐量就是：10k / 3600s = 2.78次/s。也就是說系統每秒鐘會處理2.78次A業務，同理，系統會處理1.39次B業務，注意，系統是在一秒內同時完成了2.78次A業務和1.39次B業務，因此我們測試時不能把A和B分開來測。
再看一下等式的左邊，并發數指的是性能測試時，同時運行某一腳本的個數。我們先來算A業務的，由于用戶對響應時間要求的上限是5秒，我們就確定(響應時間+考慮時間) =5秒，這樣把5秒帶入公式：
并發數 = 2.78 × 5 = 13.89
因此我們需要按照A腳本14路，B腳本7路這樣的壓力來測試�？墒�，考慮時間不是還沒有算出來么?
講到這里，就需要明確一個定義了：我們要設置考慮時間，最終的目的是要保證：(響應時間+考慮時間) 是一個定值!
如果(響應時間+考慮時間)會不停的變化，那么這個等式就無法成立，這樣就會出現測試結果的偏差。這里最主要的問題是，響應時間是不受我們控制的，響應時間如果變小，那么測出的吞吐量就會變大，從而影響到其他的業務。
那我們怎么做才能保證(響應+考慮)是一個定值呢?最完美的方法是在測試腳本中設置，首先在腳本開始的時候定義一個計時器，等腳本執行完后，統計一下經過的時間，如果不到5秒，就sleep一直到5秒，然后再結束當前腳本。如果超過5秒，就說明系統已經不合格了。
最簡單的方法，是人為的指定一個考慮時間，來讓(響應+考慮)=5秒。這樣的測試結果就沒那么精確了，而且可能需要執行很多次腳本，才能實現這個要求。比如我們先設考慮時間為2秒，執行發現響應時間是1秒，加起來是3秒，于是我們調整考慮時間為4秒。隨著考慮時間的調整，響應時間也會跟著變，呵呵，需要耐心。
到此為止，對于考慮時間的說明已經講完了。只要我們能保證(響應+考慮)是一個定值，就能有效的控制各個業務的測試比例，從而使我們的測試環境更符合要求。最后要說一下，這種算法是針對于評估系統的吞吐量，并不適用于壓力測試或者是強度測試。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
