① 如何對Web應用程序進行負載測試
定義測試策略 到目前為止，您肯定參加過這樣的會議，客戶倚靠在寬大的會議桌上，問您：「這個系統能處理上千個用戶嗎？」傳統的負載測試方法要求您編寫腳本並執行測試，以試圖給出此問題的精確答案。對於這種測試，您需要定義「處理」的含義以及 1000 名典型用戶在站點活動時的情形。您需要定義測試用例以代表各種用戶活動：例如，購買股票或注冊新的帳戶。接下來，您必須估計用戶在這些測試用例上的分布。對以下數據進行假設，即模擬真實用戶與應用程序交互時，需要多長的思考時間（或等待時間）。因此，負載測試期間活動的可從某個方面大致反映出同樣數量的真實用戶在站點活動時的情形。 這種方法有幾個不足之處。首先，其結果不會比您做的假設更好。顯然，不正確的假設將使結果出現偏差。 其次，估計真實用戶需要大量客戶端硬體。如果對每名虛擬用戶給定需要的處理能力和內存量，則典型的客戶端計算機可以處理大約 200 名虛擬用戶。因此，對 2000 名用戶並發處理級別的測試需要 10 台客戶端計算機 — 這是一筆重大投資。測試使用 HTTPS 的站點將需要多得多的客戶端硬體。 最終，此方法難以向您的開發團隊提供以操作為導向的信息。當某處出現故障時，常常難以再現該問題。 作為備選方案，我們建議您圍繞以下這些關鍵問題設計測試用例： �6�1 系統瓶頸在哪裡？系統能同步處理多少個並發請求？ �6�1 在響應時間變得不可接受之前，一台機器能處理多少名不同步的超級用戶？ �6�1 添加額外的硬體時，結果是線形增長的嗎？ �6�1 有任何穩定性問題會妨礙站點運行於生產環境中嗎？ 此方法將使用開發團隊（此開發團隊參與可能出現問題的領域）提供的附加信息。請關注這些領域。對於上一個示例，其瓶頸可能出在定單提交領域。從這里您可以派生出更具體的問題，例如「提交流程可以同時處理多少個請求？」攻擊這些特定領域是最快且成本最小的方法，用來向開發團隊提供以操作為導向的信息，以便他們能改進系統。在使用這種方法的同時，我們推薦您記住遵循以下建議。 關注負載測試正如我們已提到的那樣，首先要做的是構建導致潛在瓶頸和穩定性問題的腳本。這種「數據第一，假設第二」的方法使您能夠從應用程序收集原始數據，然後根據假設確定更高級別的結果。不用擔心為識別低風險站點的腳本編寫問題。例如，為站點的幫助領域或只讀文檔領域編寫腳本不大可能出現系統瓶頸。 同步請求使用同步請求攻擊瓶頸。此處的這個主意是模擬最壞的情況：即，站點上的用戶精確地在同一時間攻擊瓶頸。通過使用戶同步，您可以重復進行此測試。如果不同步結果，則難以再現故障情況。可以使用同步點做到這一點，同步點是大多數較健壯（成本也較高）的測試工具中提供的一項功能。同步點迫使每名虛擬用戶一直等到剩餘的用戶到達腳本中定義的點後，才能開始下一請求。它允許您精確並重復地確定站點的潛在瓶頸區域能處理的並發用戶數。例如，下限可以是 7 名並發同步用戶。 創建循環測試用例腳本使測試用例循環。在另一種方法中，每次測試用例迭代前後，站點應處於相同狀態。這允許您長時間地重復運行測試用例。 使用超級用戶最後，使用我們所稱的超級用戶。正如前面所提到的，超級用戶運行時思考時間設置為零。請記住，思考時間假設是用於常規測試中，以使虛擬用戶模擬真實用戶。但是，如果將虛擬用戶思考時間減半，則伺服器的實際負載將加倍。在另一種方法中，伺服器真正關心的與負載有關的變數是每秒的請求數。虛擬用戶的數量及其思考時間結合起來生成該負載。 讓我們進行一些數學運算以使此概念更清晰。下面的公式計算訪問站點的真實用戶生成的負載（請求數/秒）： 例如，某個站點有 100 名並發用戶，假設下載時間為 10 秒，思考時間為 30 秒，則每秒將生成 2.5 頁。如果我們假設每頁 3 個請求，則在 Web 伺服器上將轉化為每秒 7.5 個請求。 以超級用戶運行測試時，觀察每秒請求數，並與剛剛計算的值比較。根據我們的經驗，真實用戶數與超級用戶數的比例通常約為 15:1。對於同一個示例，這意味著 (100/15) 名超級用戶將生成與 100 名普通用戶相同的負載。再舉一個例子，假設在 10 名超級用戶之後響應時間變得不可接受。請注意轉換回真實用戶數的該點每秒請求數。現在您可以進行任何希望的思考時間假設，甚至可以更改它而無需重新運行測試。在幾天的測試之後，您將能根據直覺從超級用戶數轉換成真實用戶數。此方法允許您保持用戶數可控，減少所需的客戶端硬體數量，並包含負載測試軟體的成本。 這些超級用戶測試用例對於多機測試很有用。要測試站點的可伸縮性，可添加第二台 Web 伺服器和一個負載平衡器，並重復超級用戶測試。理想情況下，在看見相同的相應次數之前，您將能加倍超級用戶數量。 要回答穩定性問題，可運行測試，以在延長的時間段內維持合理數量的並發且未同步超級用戶。我們在上一個項目中熬了很多個通宵，甚至 24 小時晝夜不停，但持續時間與應用程序有關。我們稱之為「內置」測試。一旦您已採取步驟識別並潛在地解決了找到的瓶頸，則重復同步點測試，看下限是否有所增長。然後用所支持的新的並發用戶數重新運行「內置」測試。以努力提高此數字為目標重復該循環，直到達到質量條。 但是有多少用戶呢？ 盡管此方法向開發團隊提供了有價值的信息，但它使得您更難於回答會議室的問題。不過，您可以近似地估計答案。例如，假設站點的最壞情況瓶頸顯示，每台計算機多於 20 名超級用戶的情況下，響應時間超過 10 秒。根據您從我們建議的公式計算的結果，近似地估計有 300 名真實用戶（20 名超級用戶 × 15 名真實用戶）。此時，您可以做出與常規用例中相同的假設。通常情況下，有百分之多少的用戶正在使用站點的此領域？假設預期 50% 的用戶正在使用此領域，而其他領域，例如文檔或資料庫讀取，用戶比例則沒有這么大。這意味著具有一台 Web 伺服器的系統將處理大約 600 名用戶。 到目前為止，我們已討論了在能明確地指向站點的一個瓶頸領域的情況下該如何做，但如果影響性能的領域不止一個時您又應如何做呢？答案是創建單獨查看各個領域的測試腳本。首先孤立地運行這些腳本，然後一起運行。再比較結果，看站點的一個領域對另一個領域的影響有多大。
② 如何使用websocket壓力並發測試工具
apache自帶的ab.exe 可以
如果沒有理解錯誤，websocket是依託於web server，
比如IIS，Apache.所以性能測試也是針對他們提供的socket模型進行.
③ Web壓力測試常用的工具有哪些
可以使用以下幾種常用工具：
- bullbench
- jmeter
- webbench
- tcp
祝樓主早日找到合適工具
④ Web 壓力測試有什麼低成本的方法
loadrunner搞起~~~~~~~~~~~~~如果熟悉協議，還有些免費發包工具可以自己定製報文流程。
⑤ 如何利用VS2013 做Web性能測試和負載測試67
定義測試策略 到目前為止，您肯定參加過這樣的會議，客戶倚靠在寬大的會議桌上，問您：「這個系統能處理上千個用戶嗎？」傳統的負載測試方法要求您編寫腳本並執行測試，以試圖給出此問題的精確答案。對於這種測試，您需要定義「處理」的含義以及 100...
⑥ 怎樣正確做 Web 應用的壓力測試
關於工具的選擇
其實工具並不是最重要的，那麼多的測試工具，HP的是LoadRunner、IBM的是Rational Performance Tester、Apache有Jmeter（免費開源）、還有Borland的SilkPerformer，這些都是可以的。有人提到了Apache的AB，AB不是說不行的，但既然問題是"正確的壓力測試"，那麼還是選擇一個那些容易支撐起復雜業務的性能場景的工具吧。
什麼樣的工具能夠在腳本中讓你模擬業務場景中一個用戶的行為？什麼樣的工具能夠在場景中讓你模擬業務場景中一群用戶的行為？什麼樣的工具能夠讓你模擬用戶所處於的使用環境？什麼樣的工具能夠讓你比較方便、快捷的通過它的性能圖表了解Web應用的大致性能表現？答案肯定不會是那些對某個URL不斷施壓的那些工具。
關於場景的設計過程
過半數的性能測試人員並不了解自己執行的性能測試場景代表的是用戶生產環境中什麼樣的場景。事實很難正確的說清楚「性能測試」、「負載測試」、「壓力測試」、「可靠性測試」、「配置測試」、「疲勞測試」這些測試的概念。
任何一個場景的設計都必須首先明確一些相關的性能指標，這些指標的閾值一旦被超出，那麼場景一般是不必繼續執行的。
關於性能指標我們可以幾個角度來看：
首先是用戶視角的性能指標，一般來說這些指標包括了測試事務的平均響應時間、最大響應時間、90%事務的響應時間、事務響應時間標准差，我們通過著一些指標來判斷用戶實際獲得的性能體驗如何。然後是運維視角指標，點擊率、吞吐量、處理能力、各種硬體資源佔用、運維通過這些指標來了解目前應用的處理能力，通過業務增長了解何時需要進行擴容，還有開發視角的指標，鎖競爭。具體要考慮的視角由項目干係人、關鍵角色定義。
採用的指標確定好以後，再開始為這些指標定義閾值，例如事務的響應時間，也許用戶認為請求在2秒以內得到響應是滿意的，5秒以內響應是一般，超出8秒則會感覺太慢，超出10秒會超出了可容忍的上限，那麼對於這一項指標來說，它的閾值可以是：
<2秒響應，優秀
<5秒響應，良好
<8秒響應，較差
>10秒響應，超出可容忍上線
關於用戶性能體驗的指標一般會劃分為4個級別。硬體指標至少也會劃分2個級別。
系統在任何時候都應該為用戶提供優秀的響應體驗嗎？並不總是，在2倍的峰值負載中，我認為良好、甚至較差的響應體驗也是可接受的。那是不是說在正常的峰值負載中，各項指標表現不在優秀范圍內就是不理想呢？也不一定，要看正常的峰值負載持續時間長短是否合理。
場景的設計不合理最終將可能導致我們面對一堆性能缺陷無法確定處理的優先順序。
場景設計中，重點考慮的問題：
腳本測試數據符合典型用戶的數據差異（測試帳號差異、操作數據差異、提交表單參數差異等）
腳本操作次序符合典型用戶的操作差異（思考時間、業務間間隔等）；
腳本執行符合典型用戶的使用環境（瀏覽器緩存模擬、帶寬模擬等）；
測試環境的業務基礎數據必須合理（0年到N年的基礎數據）；
測試場景所產生的負載必須合理（代表峰值的負載？代表1.5倍峰值的負載？代表促銷活動的負載？）。
一般都是使用工具，可以模擬多用戶 同時/非同步地進行比較好的工具，要錢的有loadrunner ，不要錢的有JMeter 。這2種工具都能自動生成圖形報告。這樣你就能判斷出伺服器的瓶頸在哪裡。是需要增加內存還是提高處理器性能，或者增加硬碟。
⑦ 如何正確的做WEB端的壓力測試
1、對要測試的系統進行分析，明確需要對哪一塊做壓力測試。比如：淘寶網站雙十一期間，秒殺跟支付，此模式用戶操作中佔比比較大
再比如：游戲，登錄--開始戰斗--結束戰斗這種混合模式在用戶操作中佔比較大
那麼就可以針對這種佔比比較大的模式進行壓力測試
2、明確了要測試的點後，如何對這些測試點進行施壓呢？
第一種方式可以通過寫腳本產生壓力機器人對伺服器進行發包收包操作；
第二種方式就是藉助一些壓力測試工具如:J
⑧ web壓力測試 要測試哪些方面
web壓力測試通過產生真實壓力來發現問題需要關注以下方面：
1、對要測試的系統進行分析，明確需要對哪一塊做壓力測試。比如：淘寶網站雙十一期間，秒殺跟支付，此模式用戶操作中佔比比較大
再比如：游戲，登錄--開始戰斗--結束戰斗這種混合模式在用戶操作中佔比較大
那麼就可以針對這種佔比比較大的模式進行壓力測試
2、明確了要測試的點後，如何對這些測試點進行施壓呢？
第一種方式可以通過寫腳本產生壓力機器人對伺服器進行發包收包操作；
第二種方式就是藉助一些壓力測試工具如:JMeter或LoadRunner
3、如何對這些測試點進行正確的施壓呢？
那麼就需要用壓力測試工具或者其它方法來錄制腳本，模擬用戶的操作
4、對測試點該施加多大的壓力比較合適？該施加多少的數據才能找出系統的瓶頸？
那麼就需要明確壓力測試所限制的數量，即用戶並發量，這里分3種情況來明確：
1）根據上級的明確規定數量，來設定最確大值，然後根據情況往上或往下增減
2）上級未規定，由自己判斷，從1開始慢慢遞增。如：1，5，10，20等等
3）若做過壓力測試，則可以根據上次的壓力測試結果為基數進行測試
5、測試完之後，如何通過這些數據來定位性能問題呢？
雖然通過這些測試結果我們可以得到TPS(吞吐量)，平均響應時間等這些數據，可判斷出伺服器是否存在問題，但卻不能定位問題。
⑨ 關於Web系統的壓力測試
壓力測試沒有一個固定的數值，一般憑經驗或客戶要求。
壓力測試不達標一般是2種情況。
1.程序出現異常，大量數據的讀寫可能會出現代碼或資料庫的異常。根據異常的不同修改就是了。
2.效率低下。就是程序不會有問題就是執行時間太長了，這個需要改善就麻煩了，一般從SQL語句上節省資料庫訪問次數，再就是從邏輯上避免多重循環等方法解決。
-------------------------------------------
大公司的話一般設有專門的測試人員，現在這個領域還沒有專門的書籍或標准，基本都時憑借經驗。