對Web服務進行壓力測試(2)

　　設計試圖對 Web 服務進行壓力測試的壓力測試系統時，要讓它們以某種特定的方式運行代碼。這些風格超越了功能驗證，目的是要弄清楚被測試的 Web 服務是不是不僅能做我們認為它能做的事，而且在被施加了某些高強度壓力的情況下仍然繼續正常運行。壓力測試必須對 Web 服務應用四個基本條件。許多已建立的壓力系統應用了這些條件。有效的壓力測試系統將應用以下這些關鍵條件:

　　重復(Repetition): 或許最明顯的且最容易理解的壓力條件就是測試的重復。換句話說，測試的重復就是一遍又一遍地執行某個操作或功能，比如重復調用一個 Web 服務。功能驗證測試可以用來被弄清楚一個操作能否正常執行。而壓力測試將確定一個操作能否正常執行，并且能否繼續在每次執行時都正常。這對于推斷一個產品 是否適用于某種生產情況至關重要?？蛻敉ǔ貜褪褂卯a品，因此壓力測試應該在客戶之前發現代碼錯誤。許多最簡單的壓力系統只實現這一個條件，但簡單地擴展功能驗證測試來多次重復并不能構成一個有效的壓力測試。當與下面的一些原則結合起來使用時，重復就可以發現許多隱蔽的代碼錯誤。

　　并發(Concurrency): 并 發是同時執行多個操作的行為。換句話說，就是在同一時間執行多個測試，例如在同一個服務器上同時調用許多 Web 服務。這個原則不一定適用于所有的產品(比如無狀態服務)，但是多數軟件都具有某個并發行為或多線程行為元素，這一點只能通過執行多個代碼示例才能測出 來。功能測試或單元測試幾乎不會與任何并發設計結合。壓力系統必須超越功能測試，要同時遍歷多條代碼路徑。至于怎么做到這一點取決于具體的產品。例如，一個 Web 服務壓力測試需要一次模擬多個客戶機。Web 服務(或者任何多線程代碼)通常會訪問多個線程實例間的一些共享數據。因額外方面的編程而增加的復雜性通常意味著代碼會具有許多因并發引起的錯誤。由于引入并發性意味著一個線程中的代碼有可能被其他線程中的代碼中斷，所以錯誤只在一個指令集以特定的順序(例如以特定的定時條件)執行時才會被發現。把這個原 則與重復原則結合在一起，您可以應用許多代碼路徑和定時條件。

　　量級(Magnitude): 壓力系統應該應用于產品的另一個條件考慮到了每個操作中的負載量。壓力測試可以重復執行一個操作，但是操作自身也要盡量給產品增加負擔。例如，一個 Web 服務允許客戶機輸入一條消息，您可以通過模擬輸入超長消息的客戶機來使這個單獨的操作進行高強度的使用。換句話說就是，您增加了這個操作的量級。這個量級 總是特定于應用的，但是可以通過查找產品的可被用戶計量和修改的值來確定它。例如，數據的大小、延遲的長度、資金數量的轉移、輸入速度以及輸入的變化等等。單獨的高強度操作自身可能發現不了代碼錯誤(或者僅能發現功能上的缺陷)， 但與其他壓力原則結合在一起時，您將可以增加發現問題的機會。

　　隨機變化: 最后一點，任何壓力系統都多多少少具有一些隨機性。如果您隨機使用前面的壓力原則中介紹的無數變化形式，您就能夠在每次測試運行時應用許多不同的代碼路徑。下面是幾個關于怎樣在測試生 命周期內改變測試的示例。使用重復時，在重新啟動或重新連接服務之前，您可以改變重復操作間的時間間隔、重復的次數，或者也可以改變被重復的 Web 服務的順序。使用并發，您可以改變一起執行的 Web 服務、同一時間運行的 Web 服務數目，或者也可以改變關于是運行許多不同的服務還是運行許多同樣的實例的決定。量級或許是最容易更改的 — 每次重復測試時都可以更改應用程序中出現的變量(例如，發送各種大小的消息或數字輸入值)。如果測試完全隨機的話，因為很難一致地重現壓力下的錯誤，所以一些系統使用基于一個固定隨機種子的隨機變化。這樣，用同一個種子，重現錯誤的機會就會更大。

　　一個壓力測試通常會結合上述的所 有原則，并且在允許的范圍內盡可能長時間地運行。測試被允許的執行時間越長，就可以遍歷越多的代碼路徑，并且發現的錯誤也越多。當然，一旦找到錯誤就必須診斷并修復它。由于一個代碼錯誤可以在壓力測試運行多日以后自己顯示出來，所以系統必須保證當出現錯誤時所有可用的調試信息都被生成，否則可能就必須花費同樣多的時間來重現這個錯誤。

　　結束語

　　測試是軟件開發過程中至關重要的部分，并且一個重要的、經常被曲解或忽略的部分是壓力測試。遵循上面詳細說明的原則，您就可以設計并實現有效的壓力測試系統，用來查找一些與您的代碼相關的、比較隱蔽的問題。無論是利用預先寫好的工具，還是創建一個完全專用的壓力系統，壓力測試都是用于查找 Web 服務(或其他任何程序)問題的本質方法，并能最終提高您的軟件產品質量。

原文轉自：http://www.anti-gravitydesign.com