文章出處：Developworks 作者：Chris Wilkinson 發佈時間：2005-10-19
Web 服務處於分佈式計算的核心位置，它們之間的交互通常很難測試。分佈式開發、大型的開發者團隊以及對代碼日益組件化的期望都有可能使 Web 服務的開發變得越來越容易隱藏錯誤。這些類型的錯誤極難檢測出來。壓力測試是檢測這類代碼錯誤的一種有效方法，但是只有在壓力系統設計得比較有效的情況下 才能發揮作用。本文將讓您深入瞭解一下這種壓力系統的基本要求。
傳統的測試方法包括某種形式的簡單單元測試，通常由開發人員執行。設計這些測試需要了解軟件的內部知識，並且這些測試幾乎總是針對產品的非常小的、特定的部分。這些類型的測試非常適合與其他代碼組件極少交互，甚至沒有交互的簡單 Web 服務。
功能驗證（Functional Verification）也 是一種測試過程，在這個過程中，對產品源代碼瞭解有限的設計者進行測試以確認產品或服務的核心功能。設計這種測試是爲了證明這個核心功能符合某個規範。舉 個例子，我的在線拍賣顯示的是輸入的正確出價嗎？ 我的保險經紀人系統找到最便宜的報價了嗎？如果這些測試失敗，通常就意味着檢測到了產品的一個基本問題（這個問題通常是可以直接修復）。這種測試也是適合 簡單的 Web 服務，使您可以檢查服務是否能夠正確執行它的各個功能。
系統測試（System Test）通常是在功能驗 證階段完成，驗證了核心功能後進行。它傾向於把整個系統作爲一個整體來查找問題 — 弄清 Web 服務作爲系統的一部分怎樣運作，以及 Web 服務相互之間如何交互。由於系統測試是在開發生命週期快結束時才進行，所以通常不能給它分配足夠的時間來完成。又因爲緊張的發行日程安排以及開發的各個重 要階段的後移，系統測試階段經常被忽略，並且一些通常都可以發現的、少見的錯誤都不能被檢測到。即使發現了這種錯誤，這時也來不及確定錯誤的原因並設法修 復它們了。因此，在查找代碼錯誤時，必需把系統測試應用設計得儘可能高效。系統測試通常由三部分組成，它們是：
1. 性能（Performance）：這涉及到確定相關的產品統計數據的過程。例如：每秒有多少條消息？一個服務可同時接受多少個用戶？
2. 案例（Scenario）：這是重新創建客戶所需的確切配置的過程。因此在案例中發現的任何問題都可以在客戶使用該產品之前被檢測出來。
3. 壓力（或稱工作負載平衡）：它 與另兩個部分不同，因爲它被設計爲通過應用很大的工作負載來使軟件超負荷運轉。如果壓力測試通過對產品保持高強度的使用（但不超過性能統計數字確定的限 制）能有效地執行，那麼它就經常能夠發現許多隱蔽的錯誤，而這些錯誤用上面提到的任何其他技術都是發現不了的（這些錯誤也經常是最難修復的）。
從檢測代碼錯誤這方面來說，可以證明這三個系統測試組件中效率最高的是壓力測試部分。但由於這個過程經常跟系統的其他要素或功能測試混淆在一起，所以這個過程涉及到的方法還沒有被正確着手處理或實現。
使用壓力測試，您有希望找到很多種用其他測試方法更難發現的錯誤。有兩種錯誤類型是：
1. 內存泄漏（Memory leak）：一種極難檢測的現象。內存泄漏經常發生在已發行的產品中，原因很簡單，很難設計測試 用例來檢測它們。使用簡單的功能測試，幾乎發現不了內存泄漏問題，因爲在產品完成之前測試沒對產品進行足夠多的使用。內存泄漏通常要求操作要重複非常多的 次數以使內存消耗達到能引起注意的程度。儘管與其它編程語言（如 C/C++）相比，Java 程序更難引入內存泄漏錯誤，但只要程序仍保持着對對象的引用，該對象仍有可能被實例化並且它佔用的內存永遠不會被釋放。
2. 併發與同步（Concurrency and Synchronization）：壓 力測試在查找併發性問題上非常出衆，這是因爲在任何一個測試生命週期中，它都應用了許多不同的代碼路徑和定時條件。一般的規則是，壓力測試運行的時間越 長，涉及並應用的代碼路徑組合和定時條件就越多。當然，這也的確使得這些問題很難再現（錯誤可以在 5 分鐘或 5 天后發生）。死鎖、線程泄漏以及任何一般的同步問題通常只能在壓力測試階段被檢測出來。這些類型的問題很難通過執行單元測試來發現。開發人員不會一直考慮 他或她的代碼將與其他地方的代碼（在執行單元測試時這些代碼可能還沒寫出來）進行交互。
有許多聲稱能夠對 產品進行壓力測試的可用工具目前正在開發中。被廣泛應用的是針對 Web 服務的那些工具。然而，這些工具中有許多隻是簡單的 HTML/SOAP 生成器，它們模擬許多客戶機連接，並因此對 Web 服務器生成高負載（這對於查找 Web 服務器的問題很有用，但對於查找 Web 服務的問題就沒那麼有用了）。這些工具對基本的壓力測試比較有用，但它們經常是僅僅擴展功能驗證階段來重複地執行相同的功能任務。如果足夠的時間和資源可 用，就可以通過創建定製構建的壓力測試系統來實現更有效的測試。由於壓力系統的設計者通常對要測試的產品和 Web 服務有更多的瞭解，所以他們將能夠確保壓力系統可以用於哪些具體的代碼區域。
設計試圖對 Web 服務進行壓力測試的壓力測試系統時，要讓它們以某種特定的方式運行代碼。這些風格超越了功能驗證，目的是要弄清楚被測試的 Web 服務是不是不僅能做我們認爲它能做的事，而且在被施加了某些高強度壓力的情況下仍然繼續正常運行。壓力測試必須對 Web 服務應用四個基本條件。許多已建立的壓力系統應用了這些條件。有效的壓力測試系統將應用以下這些關鍵條件：
1. 重複（Repetition）：或 許最明顯的且最容易理解的壓力條件就是測試的重複。換句話說，測試的重複就是一遍又一遍地執行某個操作或功能，比如重複調用一個 Web 服務。功能驗證測試可以用來被弄清楚一個操作能否正常執行。而壓力測試將確定一個操作能否正常執行，並且能否繼續在每次執行時都正常。這對於推斷一個產品 是否適用於某種生產情況至關重要。客戶通常會重複使用產品，因此壓力測試應該在客戶之前發現代碼錯誤。許多最簡單的壓力系統只實現這一個條件，但簡單地擴 展功能驗證測試來多次重複並不能構成一個有效的壓力測試。當與下面的一些原則結合起來使用時，重複就可以發現許多隱蔽的代碼錯誤。
2. 併發（Concurrency）：並 發是同時執行多個操作的行爲。換句話說，就是在同一時間執行多個測試，例如在同一個服務器上同時調用許多 Web 服務。這個原則不一定適用於所有的產品（比如無狀態服務），但是多數軟件都具有某個併發行爲或多線程行爲元素，這一點只能通過執行多個代碼示例才能測出 來。功能測試或單元測試幾乎不會與任何併發設計結合。壓力系統必須超越功能測試，要同時遍歷多條代碼路徑。至於怎麼做到這一點取決於具體的產品。例如，一 個 Web 服務壓力測試需要一次模擬多個客戶機。Web 服務（或者任何多線程代碼）通常會訪問多個線程實例間的一些共享數據。因額外方面的編程而增加的複雜性通常意味着代碼會具有許多因併發引起的錯誤。由於引 入併發性意味着一個線程中的代碼有可能被其他線程中的代碼中斷，所以錯誤只在一個指令集以特定的順序（例如以特定的定時條件）執行時纔會被發現。把這個原 則與重複原則結合在一起，您可以應用許多代碼路徑和定時條件。
3. 量級（Magnitude）：壓 力系統應該應用於產品的另一個條件考慮到了每個操作中的負載量。壓力測試可以重複執行一個操作，但是操作自身也要儘量給產品增加負擔。例如，一個 Web 服務允許客戶機輸入一條消息，您可以通過模擬輸入超長消息的客戶機來使這個單獨的操作進行高強度的使用。換句話說就是，您增加了這個操作的量級。這個量級 總是特定於應用的，但是可以通過查找產品的可被用戶計量和修改的值來確定它 — 例如，數據的大小、延遲的長度、資金數量的轉移、輸入速度以及輸入的變化等等。單獨的高強度操作自身可能發現不了代碼錯誤（或者僅能發現功能上的缺陷）， 但與其他壓力原則結合在一起時，您將可以增加發現問題的機會。
4. 隨機變化：最後一點，任何壓力系統都多多 少少具有一些隨機性。如果您隨機使用前面的壓力原則中介紹的無數變化形式，您就能夠在每次測試運行時應用許多不同的代碼路徑。下面是幾個關於怎樣在測試生 命週期內改變測試的示例。使用重複時，在重新啓動或重新連接服務之前，您可以改變重複操作間的時間間隔、重複的次數，或者也可以改變被重複的 Web 服務的順序。使用併發，您可以改變一起執行的 Web 服務、同一時間運行的 Web 服務數目，或者也可以改變關於是運行許多不同的服務還是運行許多同樣的實例的決定。量級或許是最容易更改的 — 每次重複測試時都可以更改應用程序中出現的變量（例如，發送各種大小的消息或數字輸入值）。如果測試完全隨機的話，因爲很難一致地重現壓力下的錯誤，所以 一些系統使用基於一個固定隨機種子的隨機變化。這樣，用同一個種子，重現錯誤的機會就會更大。
一個壓力測試通常會結合上述的所 有原則，並且在允許的範圍內儘可能長時間地運行。測試被允許的執行時間越長，就可以遍歷越多的代碼路徑，並且發現的錯誤也越多。當然，一旦找到錯誤就必須 診斷並修復它。由於一個代碼錯誤可以在壓力測試運行多日以後自己顯示出來，所以系統必須保證當出現錯誤時所有可用的調試信息都被生成 — 否則可能就必須花費同樣多的時間來重現這個錯誤。
測試是軟件開發過程中至關重要 的部分，並且一個重要的、經常被曲解或忽略的部分是壓力測試。遵循上面詳細說明的原則，您就可以設計並實現有效的壓力測試系統，用來查找一些與您的代碼相 關的、比較隱蔽的問題。無論是利用預先寫好的工具，還是創建一個完全專用的壓力系統，壓力測試都是用於查找 Web 服務（或其他任何程序）問題的本質方法，並能最終提高您的軟件產品質量。
- 閱讀 Alan Booth 和 Andrew Citron 發表在 developerWorks 上的文章，“Stress testing your software without stressing your testers”。 （2001 年 2 月）
- 您可以在 Software Testing Institute 上找到一些面向軟件測試人員的資源鏈接。
- Software Testing and Quality Engineering Magazine 上有許多有用的文章。
您還可以在軟件測試和資源中心找到許多有用的鏈接。
