模板
教程
環境
性能
功能
管理
對Web服務進行壓力測試(1)
傳統的測試方法包括某種形式的簡單單元測試 ，通常由開發人員執行。設計這些測試需要了解軟件的內部知識，并且這些測試幾乎總是針對產品的非常小的、特定的部分。這些類型的測試非常適合與其他代碼組件極少交互，甚至沒有交互的簡單 Web 服務。
功能驗證(Functional Verification) 也 是一種測試過程，在這個過程中，對產品源代碼了解有限的設計者進行測試以確認產品或服務的核心功能。設計這種測試是為了證明這個核心功能符合某個規范。舉 個例子，我的在線拍賣顯示的是輸入的正確出價嗎? 我的保險經紀人系統找到最便宜的報價了嗎?如果這些測試失敗，通常就意味著檢測到了產品的一個基本問題(這個問題通常是可以直接修復)。這種測試也是適合 簡單的 Web 服務，使您可以檢查服務是否能夠正確執行它的各個功能。
系統測試(System Test) 通常是在功能驗 證階段完成，驗證了核心功能后進行。它傾向于把整個系統作為一個整體來查找問題 — 弄清 Web 服務作為系統的一部分怎樣運作，以及 Web 服務相互之間如何交互。由于系統測試是在開發生命周期快結束時才進行，所以通常不能給它分配足夠的時間來完成。又因為緊張的發行日程安排以及開發的各個重 要階段的后移，系統測試階段經常被忽略，并且一些通常都可以發現的、少見的錯誤都不能被檢測到。即使發現了這種錯誤，這時也來不及確定錯誤的原因并設法修 復它們了。因此，在查找代碼錯誤時，必需把系統測試應用設計得盡可能高效。系統測試通常由三部分組成，它們是:
性能(Performance): 這涉及到確定相關的產品統計數據的過程。例如:每秒有多少條消息?一個服務可同時接受多少個用戶?
案例(Scenario): 這是重新創建客戶所需的確切配置的過程。因此在案例中發現的任何問題都可以在客戶使用該產品之前被檢測出來。
壓力(或稱工作負載平衡): 它 與另兩個部分不同，因為它被設計為通過應用很大的工作負載來使軟件超負荷運轉。如果壓力測試通過對產品保持高強度的使用(但不超過性能統計數字確定的限 制)能有效地執行，那么它就經常能夠發現許多隱蔽的錯誤，而這些錯誤用上面提到的任何其他技術都是發現不了的(這些錯誤也經常是最難修復的)。
從檢測代碼錯誤這方面來說，可以證明這三個系統測試組件中效率最高的是壓力測試部分。但由于這個過程經常跟系統的其他要素或功能測試混淆在一起，所以這個過程涉及到的方法還沒有被正確著手處理或實現。
壓力下的錯誤
使用壓力測試，您有希望找到很多種用其他測試方法更難發現的錯誤。有兩種錯誤類型是:
內存泄漏(Memory leak): 一種極難檢測的現象。內存泄漏經常發生在已發行的產品中，原因很簡單，很難設計測試 用例來檢測它們。使用簡單的功能測試，幾乎發現不了內存泄漏問題，因為在產品完成之前測試沒對產品進行足夠多的使用。內存泄漏通常要求操作要重復非常多的 次數以使內存消耗達到能引起注意的程度。盡管與其它編程語言(如 C/C++)相比，Java 程序更難引入內存泄漏錯誤，但只要程序仍保持著對對象的引用，該對象仍有可能被實例化并且它占用的內存永遠不會被釋放。
并發與同步(Concurrency and Synchronization): 壓 力測試在查找并發性問題上非常出眾，這是因為在任何一個測試生命周期中，它都應用了許多不同的代碼路徑和定時條件。一般的規則是，壓力測試運行的時間越 長，涉及并應用的代碼路徑組合和定時條件就越多。當然，這也的確使得這些問題很難再現(錯誤可以在 5 分鐘或 5 天后發生)。死鎖、線程泄漏以及任何一般的同步問題通常只能在壓力測試階段被檢測出來。這些類型的問題很難通過執行單元測試來發現。開發人員不會一直考慮 他或她的代碼將與其他地方的代碼(在執行單元測試時這些代碼可能還沒寫出來)進行交互。
現有的壓力測試工具
有許多聲稱能夠對 產品進行壓力測試的可用工具目前正在開發中。被廣泛應用的是針對 Web 服務的那些工具。然而，這些工具中有許多只是簡單的 HTML/SOAP 生成器，它們模擬許多客戶機連接，并因此對 Web 服務器生成高負載(這對于查找 Web 服務器的問題很有用，但對于查找 Web 服務的問題就沒那么有用了)。這些工具對基本的壓力測試比較有用，但它們經常是僅僅擴展功能驗證階段來重復地執行相同的功能任務。如果足夠的時間和資源可 用，就可以通過創建定制構建的壓力測試系統來實現更有效的測試。由于壓力系統的設計者通常對要測試的產品和 Web 服務有更多的了解，所以他們將能夠確保壓力系統可以用于哪些具體的代碼區域。
原文轉自：http://www.anti-gravitydesign.com
