piaocl
關鍵字：效能測試，web測試
摘要：
隨著網路世界的迅猛發展，**的效能變得日益重要，效能不好的**將被使用者所拋棄。所以效能是使用者對軟體系統是否滿意的乙個重要方面。本文將對什麼是效能，如何測試效能等方面進行論述。
那麼效能是什麼呢，效能是特定功能占用的時間和資源。他可以是功能的開銷或者是同步執行功能的數目。web效能測試就是模擬大量使用者操作給**造成壓力，並評測web系統在不同負載和不同配置下能否達到已經定義的標準。效能測試更加關注分析和消除與軟體結構中相關聯的效能瓶頸。
效能是每個軟體系統必須考慮的指標，在效能測試中我們通常注意以下四方面資料:一.
負載資料 二.資料流量
三..軟體本身消耗資源情況 四.系統使用情況。由於效能測試的特殊性，一般情況下都是利用特殊的測試工具（如loadrunner,testmanager，act等）模擬多使用者操作，對需要評測的系統造成壓力。找出系統的瓶頸，並提交給開發人員進行修正。所以效能測試的目的是找出系統效能瓶頸並糾正需要糾正的問題。
制定web效能測試的策略可以遵循對系統中最重要的模組，經常使用的模組，系統開銷最大的地方（**最複雜的部分），對使用者來說最重要的部分進行測試。我們從整體的角度分析一下效能可能出現問題的地方，作為web程式不管是兩層，還是多層系統架構的程式。系統都是通過http協議（
超文字傳輸協議（hypertemx transfer protocol, http）是乙個「請求-回應」的應用協議，這個協議支援一套固定的方法如get, post, put, delete等）來傳輸資料，傳送命令。中間的過程大致為客戶端（瀏覽器）傳送資料操作請求給伺服器，伺服器接收命令請求後進行處理，然後把結果返回給客戶端，客戶端處理響應結果。這個過程中客戶端傳送請求進行資料處理的過程一般不是系統的效能瓶頸，這個時候一般是大量使用者同時操作，傳送資料請求才是系統的瓶頸。系統的伺服器硬體資源最有可能是軟體系統的瓶頸。我們需要調整軟體和環境（最優化響應時間和資源），確認應用和系統可以處理的高負載和壓力條件。而這個時候系統硬體中最可能的是cpu造成的瓶頸。系統中其他硬體資源所造成的瓶頸，我們可以替換相應的硬體資源，進行調整。而系統中另乙個瓶頸可能是伺服器把處理資料傳送給客戶端，這個過程硬體資源就不可能是效能的限制因素，最有可能是頻寬的原因。
其實效能的問題大多數情況下是由於軟體體系結構或設計不合理造成的,而不是編碼引起的。如果在效能測試中發現
cpu佔用率居高不下，記憶體占用異常，經常報錯的情況
問題的時候，排除上邊分析的原因外，應及時
提交情況彙總給開發人員，讓開發人員察看**中出錯環節是否有死迴圈等邏輯錯誤 ，檢查應用部署後所使用的資料連線驅動是否有誤或者**未及時更新，檢視資料庫查詢或者其他語句是否有異常，中斷測試，只執行響應時間最長的頁面並驗證結果。分析系統可能的效能瓶頸。
我們需要在測試中注意不同的頻寬條件對測試結果所造成的結果，所以應該在效能測試前要制定系統效能標準，這樣才能合理分析測試結果。把不同頻寬的測試結果進行分析量化，找到測試系統瓶頸。
一般效能測試中最常見的基本型別為基準測試，配置測試，負載測試，壓力測試，我們知道在軟體測試的過程中，不同階段，不同型別所進行的效能測試關注測試目標是不同的，不同軟體架構也決定了效能測試存在差異。這樣就要對所進行的測試型別有一定的了解，才能更好的進行效能測試工作。下邊是各種測試型別的具體概念：
基準測試——把新伺服器或者未知伺服器的效能和已知的參考標準進行比較
配置測試——確認伺服器在不同的配置下效能的可接受性。（操作條件不變）
負載測試——確認伺服器在不同的負載條件下效能的可接受性。（操作條件不變）
壓力測試——確認伺服器在異常或者極限的條件時效能的可接受性，例如，減少資源或大數量的使用者。
競爭測試——確認伺服器可以處理多個客戶對同乙個資源的請求競爭
通過系統基準測試提供的一定條件下伺服器如何處理資料的基線,作為評估其他效能指標的參考資料起點。進行配置測試則是測試系統配置在不同的機器上能否正常執行。用配置測試來確保系統在多個平台上正常執行。而負載測試用來測試在不同負載條件下客戶端或者伺服器端的響應時間。幫助測試人員計算在限定時間內伺服器響應處理的請求的最大數量的事務數。壓力測試則是在極限條件下執行系統的過程，檢查什麼條件下伺服器或者客戶端崩潰。競爭測試則是在一台或者多台pc上作業系統功能來模擬實際環境。
而對於乙個開發中的web系統進行效能測試，就要根據開發目標和使用者需求在體系結構的迭代過程中，不斷調整測試目標，對系統效能有個很好的評估。那麼如何才能成功的進行效能測試呢，我覺得進行效能測試前應有乙個測試計畫，這樣才能保證效能測試有序的進行。下邊的圖例給出了效能測試的一般步驟：
圖1-1 效能測試步驟
n評估系統：在這個階段，主要是明確確定系統期望目標，包括：確定系統功能，確定使用者活動，確定系統架構，確定可接受的極限，驗證可接受的極限，確定系統風險等。
開發測試資源：進行效能測試的資源，主要覆蓋三種活動：開發風險減低計畫，開發測試策略，開發自動化指令碼。 n
執行基準測試：利用基線對比將來的測試結果對系統評估負載，壓力，競爭測試結果中的相關效能。主要通過壓力場景驗證自動化測試指令碼的正確性。在測試週期早期中標示可見的效能指標。效能工程包括個體指令碼基線，建立初始化基準。
n分析測試結果：對結果進行分析是為了決定是否對系統繼續進行測試，是否結果達到了期望值。這個階段包含評估結果，確定是否是可接受的極限，確定是否繼續進行測試，確定需求調整。
n預定測試：強制驗證系統效能，這些測試是必須執行的即使效能和需求都沒有調整的情況下。它包含執行使用者體驗測試，執行穩定性測試，執行產品確認測試等活動。
n結束測試：實際工作中由於軟體架構和其他資源限制，軟體無法繼續優化，此時建議將測試資源轉移，測試其他方面，避免測試資源浪費。
通過上邊一系列闡述，大家對web效能測試的目的方法應該有了一定了解。實際工作中千差萬別，需要大家具體問題具體分析，才能做好效能測試。
參考文獻： 1．
performance_engineering_strategy_template
2．測試指南
>- john wiley & sons
web效能測試分析 工具篇
是乙個可以用於分析.net程式行為的工具。可用其分析垃圾 器堆正在發生的事情，例如什麼方法分配了什麼型別的物件？另外，還提供了呼叫圖 call graph 功能用於顯示哪個方法呼叫了哪個方法 是個很不錯的分析工具 profiling tool 可以分析windows form和asp.net 它能夠...
web效能測試分析 工具篇
是乙個可以用於分析.net程式行為的工具。可用其分析垃圾 器堆正在發生的事情，例如什麼方法分配了什麼型別的物件？另外，還提供了呼叫圖 call graph 功能用於顯示哪個方法呼叫了哪個方法 是個很不錯的分析工具 profiling tool 可以分析windows form和asp.net 它能夠...
效能測試之效能優化篇
系統上線必會經歷測試階段，功能測試我們可以按照產品的設計原型去執行一條條測試用例來覆蓋產品功能點。但是在功能測試之外，如果乙個使用者介面層服務，我們還需要知道服務的效能指標以了解並評估這個服務在實際的生產環境中可以應對多大壓力，我們可以根據這個資料情況根據不用的場景時間去對應的增加機器節點或進行重構...