Web網站壓力測試教程

Web服務處於分散式運算的核心位置，它們之間的互動通常很難測試。分布式開發、大型的開發人員團隊以及對代碼日益組件化的期望都有可能使 Web 服務的開發變得越來越容易隱藏錯誤。這些類型的錯誤極難檢測出來。壓力測試是檢測這類代碼錯誤的一種有效方法，但是只有在壓力系統設計得比較有效情況下才能發揮作用。本文將讓您深入瞭解一下這種壓力系統的基本要求。

測試方法

傳統的測試方法包括某種形式的簡單單元測試，通常由開發人員執行。設計這些測試需要瞭解軟體的內部知識，並且這些測試幾乎總是針對產品的非常小的、特定的部分。這些類型的測試非常適合與其他程式碼群組件極少互動，甚至沒有互動的簡單 Web 服務。

功能驗證(Functional Verification) 也是一種測試過程，在這個過程中，對產品原始碼瞭解有限的設計者進行測試以確認產品或服務的核心功能。設計這種測試是為了證明這個核心功能符合某個規範。舉個例子，我的線上拍賣顯示的是輸入的正確出價嗎? 我的保險經紀人系統找到最便宜的報價了嗎?如果這些測試失敗，通常就意味著檢測到了產品的一個基本問題(這個問題通常是可以直接修複)。這種測試也是適合簡單的 Web 服務，使您可以檢查服務是否能夠正確執行它的各個功能。

系統測試(System Test) 通常是在功能驗證階段完成，驗證了核心功能後進行。它傾向於把整個系統作為一個整體來尋找問題 — 弄清 Web 服務作為系統的一部分怎樣運作，以及 Web 服務相互之間如何互動。由於系統測試是在開發生命週期快結束時才進行，所以通常不能給它分配足夠的時間來完成。又因為緊張的發行排程以及開發的各個重要階段的後移，系統測試階段經常被忽略，並且一些通常都可以發現的、少見的錯誤都不能被檢測到。即使發現了這種錯誤，這時也來不及確定錯誤的原因並設法修複它們了。因此，在尋找代碼錯誤時，必需把系統測試應用設計得儘可能高效。系統測試通常由三部分組成，它們是：

效能(Performance)： 這涉及到確定相關的產品統計資料的過程。例如：每秒有多少條訊息?一個服務可同時接受多少個使用者?

案例(Scenario)： 這是重新建立客戶所需的確切配置的過程。因此在案例中發現的任何問題都可以在客戶使用該產品之前被檢測出來。

壓力(或稱工作負載平衡)： 它與另兩個部分不同，因為它被設計為通過應用很大的工作負載來使軟體超負荷運轉。如果壓力測試通過對產品保持高強度的使用(但不超過效能統計數字確定的限制)能有效地執行，那麼它就經常能夠發現許多隱形錯誤，而這些錯誤用上面提到的任何其他技術都是發現不了的(這些錯誤也經常是最難修複的)。

從檢測代碼錯誤這方面來說，可以證明這三個系統測試組件中效率最高的是壓力測試部分。但由於這個過程經常跟系統的其他要素或功能測試混淆在一起，所以這個過程涉及到的方法還沒有被正確著手處理或實現。