當測試中所有的用戶都同時執行幾乎相同的操作時,就會發生這種現象。這將會產生非常不可靠和不精確的結果,所以必須采取一些措施防止這種情況的出現。有兩種方法可以從這種類型的結果中獲得精確的測量值。如果測試可以運行相當長的時間(有時是幾個小時,取決于用戶的操作持續的時間),最后由于隨機事件的本性使然,服務器的吞吐量會被“拉平”;蛘,可以只選取波形中兩個平息點之間的測量值。該方法的缺點是可以捕獲數據的時間非常短。
性能規劃測試
對于性能規劃類型的測試來說,其目標是找出,在特定的環境下,給定應用程序的性能可以達到何種程度。此時可重現性就不如在基準測試中那么重要了,因為測試中通常都會有隨機因子。引入隨機因子的目的是為了盡量模擬具有真實用戶負載的現實世界應用程序。通常,具體的目標是找出系統在特定的服務器響應時間下支持的當前用戶的最大數。例如,您可能想知道:如果要以5秒或更少的響應時間支持8,000個當前用戶,需要多少個服務器?要回答這個問題,需要知道系統的更多信息。
要確定系統的容量,需要考慮幾個因素。通常,服務器的用戶總數非常大(以十萬計),但是實際上,這個數字并不能說明什么。真正需要知道的是,這些用戶中有多少是并發與服務器通信的。其次要知道的是,每個用戶的“考慮時間”即請求間時間是多少。這非常重要,因為考慮時間越短,系統所能支持的并發用戶越少。例如,如果用戶的考慮時間是1秒,那么系統可能只能支持數百個這樣的并發用戶。但是,如果用戶的考慮時間是30秒,那么系統則可能支持數萬個這樣的并發用戶(假定硬件和應用程序都是相同的)。在現實世界中,通常難以確定用戶的確切考慮時間。還要注意,在現實世界中,用戶不會精確地按照間隔時間發出請求。
于是就引入了隨機性。如果知道普通用戶的考慮時間是5秒,誤差為20%,那么在設計負載測試時,就要確保請求間的時間為5×(1 +/- 20%)秒。此外,可以利用“調步”的理念向負載場景中引入更多的隨機性。它是這樣的:在一個虛擬用戶完成一整套的請求后,該用戶暫停一個設定的時間段,或者一個小的隨機時間段(例如,2×(1 +/- 25%)秒),然后再繼續執行下一套請求。將這兩種隨機化方法運用到測試中,可以提供更接近于現實世界的場景。
現在該進行實際的容量規劃測試了。接下來的問題是:如何加載用戶以模擬負載狀態?最好的方法是模擬高峰時間用戶與服務器通信的狀況。這種用戶負載狀態是在一段時間內逐步達到的嗎?如果是,應該使用ramp-up類型的測試,每隔幾秒增加x個用戶;蛘,所有用戶是在一個非常短的時間內同時與系統通信?如果是這樣,就應該使用flat類型的測試,將所有的用戶同時加載到服務器。兩種不同類型的測試會產生沒有可比性的不同測試。例如,如果進行ramp-up類型的測試,系統可以以4秒或更短的響應時間支持5,000個用戶。而執行flat測試,您會發現,對于5,000個用戶,系統的平均響應時間要大于4秒。這是由于ramp-up測試固有的不準確性使其不能顯示系統可以支持的并發用戶的精確數字。以門戶應用程序為例,隨著門戶規模的擴大和集群規模的擴大,這種不確定性就會隨之顯現。
這不是說不應該使用ramp-up測試。對于系統負載在一段比較長的時間內緩慢增加的情況,ramp-up測試效果還是不錯的。這是因為系統能夠隨著時間不斷調整。如果使用快速ramp-up測試,系統就會滯后,從而報告一個較相同用戶負載的flat測試低的響應時間。那么,什么是確定容量的最好方法?結合兩種負載類型的優點,并運行一系列的測試,就會產生最好的結果。例如,首先使用ramp-up測試確定系統可以支持的用戶范圍。確定了范圍之后,以該范圍內不同的并發用戶負載進行一系列的flat測試,更精確地確定系統的容量。
滲入測試
滲入測試是一種比較簡單的性能測試。滲入測試所需時間較長,它使用固定數目的并發用戶測試系統的總體健壯性。這些測試將會通過內存泄漏、增加的垃圾收集(GC)或系統的其他問題,顯示因長時間運行而出現的任何性能降低。測試運行的時間越久,您對系統就越了解。運行兩次測試是一個好主意——一次使用較低的用戶負載(要在系統容量之下,以便不會出現執行隊列),一次使用較高的負載(以便出現積極的執行隊列)。
測試應該運行幾天的時間,以便真正了解應用程序的長期健康狀況。要確保測試的應用程序盡可能接近現實世界的情況,用戶場景也要逼真(虛擬用戶通過應用程序導航的方式要與現實世界一致),從而測試應用程序的全部特性。確保運行了所有必需的監控工具,以便精確地監測并跟蹤問題。
峰谷測試
峰谷測試兼有容量規劃ramp-up類型測試和滲入測試的特征。其目標是確定從高負載(例如系統高峰時間的負載)恢復、轉為幾乎空閑、然后再攀升到高負載、再降低的能力。
實現這種測試的最好方法就是,進行一系列的快速ramp-up測試,繼之以一段時間的平穩狀態(取決于業務需求),然后急劇降低負載,此時可以令系統平息一下,然后再進行快速的ramp-up;反復重復這個過程。這樣可以確定以下事項:第二次高峰是否重現第一次的峰值?其后的每次高峰是等于還是大于第一次的峰值?在測試過程中,系統是否顯示了內存或GC性能降低的有關跡象?測試運行(不停地重復“峰值/空閑”周期)的時間越長,您對系統的長期健康狀況就越了解。
結束語
本文介紹了進行性能測試的幾種方法。取決于業務需求、開發周期和應用程序的生命周期,對于特定的企業,某些測試會比其他的更適合。但是,對于任何情況,在決定進行某一種測試前,都應該問自己一些基本問題。這些問題的答案將會決定哪種測試方法是最好的。
這些問題包括:
結果的可重復性需要有多高? 測試需要運行和重新運行幾次? 您處于開放周期的哪個階段? 您的業務需求是什么? 您的用戶需求是什么? 您希望生產中的系統在維護停機時間中可以持續多久? 在一個正常的業務日,預期的用戶負載是多少?將這些問題的答案與上述性能測試類型相對照,應該就可以制定出測試應用程序的總體性能的完美計劃。
文章來源于領測軟件測試網 http://www.kjueaiud.com/