❶ php web伺服器。網站上線在即，請問如何測試伺服器壓力呢比如如何知道這個網站到底能同時承受
利用一些軟體吧，可用來進行 Web 壓力測試的工具有很多，比如微軟的 Web Application Stress、Linux下的 siege、功能全面的 Web-CT 等等，這些都是非常優秀的 Web 壓力測試工具。
一、 Siege
一款開源的壓力測試工具，可以根據配置對一個WEB站點進行多用戶的並發訪問，記錄每個用戶所有請求過程的相應時間，並在一定數量的並發訪問下重復進行。
官方：http://www.joedog.org/
1. 下載源碼
請自行google例如:
wget http://soft.vpser.net/test/siege/siege-2.67.tar.gz
2. 解壓、編譯和安裝
tar -zxf siege-2.67.tar.gz cd siege-2.67/ /configure make && make install
3. 運行siege
siege -c 200 -r 10 -f test.txt
-c是並發量，-r是重復次數。 url文件就是一個文本，每行都是一個url，它會從裡面隨機訪問的。
test.txt 內容:
http://blog.test.com/wp-content/uploads/2012/07/cluster6.png
http://blog.test.com/wp-content/uploads/2012/07/cluster7-150x150.png
http://blog.test.com/wp-content/uploads/2012/07/cluster7.png
http://blog.test.com/wp-content/uploads/2012/07/cluster8-150x150.png
http://blog.test.com/wp-content/uploads/2012/07/cluster9-150x150.png
4 結果說明
Lifting the server siege… done.
Transactions: 3419263 hits //完成419263次處理
Availability: 100.00 % //100.00 % 成功率
Elapsed time: 5999.69 secs //總共用時
Data transferred: 84273.91 MB //共數據傳輸84273.91 MB
Response time: 0.37 secs //相應用時1.65秒：顯示網路連接的速度
Transaction rate: 569.91 trans/sec //均每秒完成 569.91 次處理：表示伺服器後
Throughput: 14.05 MB/sec //平均每秒傳送數據
Concurrency: 213.42 //實際最高並發數
Successful transactions: 2564081 //成功處理次數
Failed transactions: 11 //失敗處理次數
Longest transaction: 29.04 //每次傳輸所花最長時間
Shortest transaction: 0.00 //每次傳輸所花最短時間
二、Webbench
webbench最多可以模擬3萬個並發連接去測試網站的負載能力，安裝使用簡單方便。
1. 下載源碼
請自行google例如:
wget http://blog.s135.com/soft/linux/webbench/webbench-1.5.tar.gz
2. 解壓、編譯和安裝
tar zxvf webbench-1.5.tar.gz cd webbench-1.5 make mkdir /usr/local/man #建立相應目錄否則導致無法正常安裝 make install
3. 運行webbench
webbench -c 100 -t 30 http://192.168.1.235/index.html
-c表示並發數，-t表示時間(秒)
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://192.168.1.235/index.html
100 clients, running 30 sec.
Speed=16084 pages/min, 152872 bytes/sec. #運行結果顯示
Requests: 8042 susceed, 0 failed.
三、Web Application Stress Tool
這是由微軟的網站測試人員開發的專門用來進行實際網站壓力測試以一套工具。透過這套功能強大的壓力測試工具，管理人員可以在網站實際上線之前先網站進行如同真實環境下的測試，以找出系統潛在的問題，對系統進行進一步的調整、設置工作。
❷ web-application-stress-tool在win8下能用嗎
一、准備工作
為了測試數據的准備性，首先需要刪除緩存和Cookies等臨時文件。啟動IE後打開「工具」菜單下的「Internet」選項命令，在打開的「Internet選項」窗口的「常規」選項卡中，單擊「Internet臨時文件」區域的「刪除Cookies」和「刪除文件」按鈕將臨時文件刪除。
二、錄制測試腳本
安裝並啟動WAS，程序運行時會打開「Create new script」對話框，即建立一個新的腳本窗口（如圖1），如果運行WAS沒有打開該窗口可以單擊WAS主程序窗口工具欄上第一個按鈕「New Script」即可。
因為是初次使用，所以在新建腳本窗口上單擊「Record」按鈕打開創建向導對話框「Browser Recorder-Step 1 of 2」，其中三個選項的作用是選擇要記錄的內容，分別為Request（請求）、Cookies（網上信息塊）以及Host headers（主機標題），可根據需要選擇（圖2），然後單擊「Next」即會打開「Browser Recorder-Step 2 of 2」窗口，單擊「Finish」按鈕。這樣WAS會自動啟用，並且會打開一個瀏覽器窗口，此時我們就可以在瀏覽器的地址欄中輸入要測試的網站網址。隨著要測試的網站內容的不斷顯示，在WAS主界面的「Recording」選項卡中的信息會實時更新（如圖3）。
當瀏覽器的狀態欄顯示為「完成」時，我們就可以返回WAS窗口，單擊「Stop Recording」按鈕返回腳本窗口。
三、測試設置
為了使測試更加准確，更加接按真實效果，需要對錄制的測試腳本進行一些設置。
去除靜態干擾
由於網頁是由圖片、文字以及其它動態源碼組成的，而一般的靜態內容消耗的帶寬並不是很大，因此我們可以將其排除在外。在腳本中選中指向圖像、文字以及其它靜態文件項目前的灰色按鈕，然後單擊工具欄上的「Delete」按鈕將其刪除（圖4）。
設置並發數
然後在單擊「New Recorded Script」下的「Settings」標簽，其中「Concurrent Connections」是設置並發連接數的，其下面的「Stress level (threads)」和 「Stress multiplier(sockets perthread)」 分別設置對目標伺服器的壓力及負載程度的，其中Level是客戶端所產生的線程數目，一個線程可以產生多個Socket並發請求，因此將兩者的數值相乘，所獲得的數字就是客戶端同時連接的並發數（圖5）。
時間設置
時間設置包括「Test Run Time」（測試運行時間）和「Request Delay」（停止響應）以及「Suspend」（掛起時間）三項。其中測試運行時間是以日、小時、分鍾和秒來設定的，建議該項時間不宜太短，如果設置的並發數較多，那麼時間應該按比較增長，以便產生足夠多的請求；而停止時間是指連接時超出這個時間即作超時處理；在掛起時間處部分為Warmup和Cooldown兩項，一般可以設置為兩三分鍾為宜，這樣做的目的是避免測試開始和結束時數據的變形，影響測試的准確性。
指定帶寬瓶頸
「Bandwith」是指定帶寬瓶頸的，即選擇訪問該網站大多數用戶所使用的帶寬。例如訪問該網站的絕大部分用戶是撥號，那麼可以選擇56K。
四、開始測試
做好基本的設置工作後，就可以在左側選中新建的腳本「New Recorded Script」項，然後單擊工具欄上的「Run Script」按鈕，或者打開「Scripts」菜單下的「Run」命令，這樣就開始測試了。測試過程中會以進度條的方式實時顯示，待進度條結束我們即可進行測試結果分析了。
五、數據分析
現在我們就可以打開測試報告來查看測試結果了。單擊「View」菜單，選擇「Reports」，在打開的窗口左側會按時間顯示所有測試報告。根據時間選擇本次測試報告，在窗口右側即可查看具體內容。
在測試報告中最重要的部分就是「Socket Errors」部分和「Result Codes」部分。其中Socket Errors部分共分為Connect、Send 、Recv和Timeouts。其中Connect表示客戶端不能與伺服器取得連接的次數；Send表示客戶端不能正確發送數據到伺服器的次數；Recv表示客戶端不能正確從伺服器接次的次數；Timeouts表示超時的線程數目。由此我們可以如果這四個數值都比較小，甚至為0則說明我們的伺服器是經得起考驗的；如果數值居高不下，甚至接近設置的並發數，那麼則要好好的檢查你的伺服器了（圖6）。
另外在「Result Codes」部分，如果Code列表下的數值都為200，那麼表示所有請求都經伺服器成功返回，如果數值出現400或大於400，例如404，那麼則需要在左側找到「Page Data」節點，查看具體的錯誤項目，然後作出改正了。
其實要完整的反映出一個網站在伺服器上的運行情況，需要不斷增減其並發數，並且進行多次測試，才能了解伺服器所能承受的限度，然後才可以在IIS中設置允許連接的最大數目，從而保證網站正常運行。
WAS 的負載使用說明（二）
測試腳本的准備
1、在測試客戶端機器上啟動Web Application Stress Tool，在彈出的「建立新腳本」對話框中選擇「Record」按鈕；
2、在「Record」參數設置第一步中，所有的checkbox都不用選擇
到 第二步時直接點擊「finish」,過幾秒鍾會彈出一個IE窗口，在此窗口中訪問測試數據生成頁面（http://192.168.1.4: 8086/Apply/test），依次點擊5個測試用例連接，然後返回Web Application Stress Tool，停止Record；
3、將一些沒用的記錄刪去（比如：/Apply/test/index.htm）,只留下如下圖所示的五條記錄：
在Server輸入框中輸入伺服器的IP，埠號不用輸入。改一下腳本名字，比如改為Joinwork Test;
4、5個測試用例在實際使用環境中被訪問的概率是不一樣的。我們可以在Page Groups中定義幾個Page Group來模擬這種訪問分布：
在上圖中我們定義了5個Group，分別對應：查詢可啟動流程列表、啟動流程、查詢個人待辦工作任務、顯示任務執行表單和執行任務，它們被點擊的次數比率為：1 : 1 : 5 : 5 : 4。
回到腳本主頁面，分別將5條記錄的Group改為剛才建立的Page Group。這樣在運行腳本的時候就會按Group定義的比率來產生點擊了；
5、下面設置測試並發用戶數和測試時間長度。 到 如下圖的Settings頁面，通過Stress Level (threads)和Stress mulitiplters來設置並發用戶數，Test RUn Time來設置測試時長。因為我們要做性能壓力測試，不要設置延時時間（Request Delay）。可以在實際測試時間之前，設置一段warm up運行時間，這段時間的數據是不會記錄到最後的報告里的；其他設置可以保持預設值不變；
測試運行
一切准備完成後，回到腳本主頁面，然後點擊工具條上的「Run Script」按鈕就開始測試了；
測試報告查看
測試運行結束後，我們就可以通過點擊工具條上的」Reports」按鈕查看測試報告了；
測試報告里比較重要的數據是：每秒處理的請求數（Requests per Second）和每個頁面的平均響應時間。
上面兩張圖的數據是筆者直接使用Joinwork開發版的預設配置（JBoss 3.2.2和JBoss自帶的資料庫Hsql），一台主頻1.5M HZ（奔騰移動）、內存725M的筆記本作伺服器，一台主頻2.0M HZ的台式機作客戶端，測試的數據。
數據顯示在100並發用戶數下，每秒可處理89.26個請求，其中響應時間最長的頁面是任務執行，平均響應時間是1.66秒。
Web Application Stress Tool也可以採集伺服器的CPU利用率等伺服器端數據，有興趣的話可以查看幫助文件。
Web Application Stress 是Microsoft免費提供的一款軟體專門對WEB服務進行壓力測試用的工具軟體。我經常會需要測試一些伺服器的運行狀態和響應時間什麼的，比如在網路中新加了一台防火牆做好設置以後，它的改動對於網路中應用層的服務影響怎麼樣，客戶會不會明顯感覺到IE 打開站點的速度明顯減慢等等，尤其是在防火牆工作在透明代理模式下加上了一些對於應用服務的內容限制以後，設置前後速度上的改變都是非常重要參考數據的，我需要知道到底速度的影響有多大是否可以忽略不計。
部分數據解析
下面我們用其進行一次簡單的壓力測試。
1. 打開主程序，點擊」Record」按鈕
2. 選擇」Record Delay between request」
3. 然後」next」，再」finish」4
4. 接下來會彈出一個瀏覽器，輸入所要測試的WEB伺服器地址，隨便瀏覽一些頁面，然後將其關閉，返回到Web Application Stress中
5. 點擊」stop recording」按鈕。點擊」Settings」，就可以進入設置界面，填入一些參數。在此例中，threads我填入了50，run time我填入了2分鍾，其它默認。然後選擇」Scripts」菜單項中的」Run」，對伺服器進行壓力測試，等待2分鍾。
6.結束後，選擇」Window」下的」Reports」，可以看到類似於下面的壓力測試結果（我已經將其簡化了）。
============================================================
Number of test clients: 1
Number of hits: 6121
Requests per Second: 51.01
Socket Statistics
————————————————————
Socket Connects: 6163
Total Bytes Sent (in KB): 1750.10
Bytes Sent Rate (in KB/s): 14.58
Total Bytes Recv (in KB): 29227.62
Bytes Recv Rate (in KB/s): 243.55
Socket Errors
————————————————————
Connect: 0
Send: 0
Recv: 0
Timeouts: 0
RDS Results
————————————————————
Successful Queries: 0
下面對其進行簡單解釋。測試時間內，虛擬的用戶點擊頁面6121次，平均每秒51個請求，Socket連接數6163，其中沒有連接、發送、接收、超時錯誤。從這個壓力測試報告來看，伺服器對於50個用戶同時操作，應該沒有任何問題。需要特別說明的是，這個只是簡化的部分結果。
這只是一個簡單的示例，Web Application Stress的功能遠不止於此，還需要在實踐中總結才是。
❸ 怎樣測試伺服器壓力
下載並安裝WAST；
1．設置並行連接數；
2．設置持續時間；
3．其餘設置；
註：所有以上的選項可以根據自己的需要進行設置。
設置完成後就可以進行壓力測試。測試的步驟如下：
第一步，點擊工具欄上的「New Script」按鈕，在打開的面板中點擊「Nanual」按鈕創建一個新的測試項目。在打開的窗口中對它進行設置，在主選項中的Server中填寫要測試的伺服器的IP地址。這里我們填寫192.168.1.20。在下方選擇測試的Web連接方式，這里的方式Verb選擇get。Path選擇要測試的Web頁面路徑，這里填寫/Index.asp即動網的首頁文件，WAST可以設置更多的Path。
第二步，在「Settings」功能設置中將Stress Level （Threads）線程數設置為1000。然後點工具中的灰色三角按鈕即可進行測試。測試過程中我們可以從伺服器的任務管理器中看到CPU使用率已經達到100%，損耗率達到最大。在CMD窗口中使用命令netstat -an，可以看到客戶端的IP地址在伺服器上的80埠進行了非常多的連接，而且Web網站已經打不開了，提示過多用戶連接。
❹ 怎樣正確做 Web 應用的壓力測試
1. "簡單"的應用,可以用apache自帶的工具ab測試. 也可以試試http_load;
2. 一般給一個大概的性能評測報告,評估需要多少伺服器. 多點餘量無妨;
3. 注意記錄好各種數據. 在什麼時候需要增加伺服器更多的是考驗運維的能力.
❺ 如何對Web伺服器做壓力測試
開發腳本向伺服器發送請求啊
❻ 如何對Web伺服器做壓力測試
apache壓力測試
ab -n 1000 -c 1000 http://test.com/index.php
❼ Web測試的主要內容和測試方法有哪些
測試分類：
1、界面測試
1）給用戶的整體感：舒適感；憑感覺能找到想要找的信息；設計風格是否一致
2）各控制項的功能
2、功能測試
1）刪除/增加某一項：是否對其他項造成影響，這些影響是否都正確
2）列表默認值檢查
3）檢查按鈕功能是否正確：新建、編輯、刪除、關閉、返回、保存、導入、上一頁、下一頁、頁面跳轉、重置（常見錯誤）
4）字元串長度檢查：超出長度
5）字元類型檢查
6）標點符號檢查：空格、各種引號、Enter鍵
7）特殊字元：常見%、「、」
8）中文字元：是否亂碼
9）檢查信息完整：查看信息，查看所填信息是否完整更新；更新信息，更新信息與添加信息是否一致
10）信息重復：需唯一信息處，比如重復的名字或ID、重名是否區分大小寫、加空格
11）檢查刪除功能：不選擇任何信息，按Delete，看如何處理；選擇一個或多個進行刪除；多頁選、翻頁選刪除；刪除是否有提示
12）檢查添加和修改是否一致：添加必填項，修改也該必填；添加為什麼類型，修改也該什麼類型
13）檢查修改重名：修改時把不能重名的項改為已存在的內容
14）重復提交表單：一條已經成功提交的記錄，返回後再提交
15）檢查多次使用返回鍵：返回到原來頁面，重復多次
16）搜索檢查：存在或不存在內容，看搜索結果是否正確；多個搜索條件，同時輸入合理和不合理條件；特殊字元
17）輸入信息的位置
18）上傳下載文件檢查：功能是否實現，
上傳：上傳文件是否能打開、格式要求、系統是否有解釋信息、將不能上傳的文件格式修改後綴為可上傳的文件格式；
下載：下載是否能打開、保存、格式要求
19）必填項檢查：必填項未填寫；是否有提示，如加*；對必填項提示返回後，焦點是否自動定位到必填項
20）快捷鍵檢查：是否支持快捷鍵Ctrl+C、Ctrl+V、backspace；對不允許做輸入的欄位（如：下拉選項），對快捷方式是否也做了限制
21）Enter鍵檢查：輸入結束後按Enter鍵，系統如何處理
22）刷新鍵檢查：按瀏覽器刷新鍵如何處理
23）回退鍵檢查：按瀏覽器回退鍵如何處理
24）空格檢查：輸入項輸入一個或多個空格
25）輸入法半形全形檢查：比如，浮點型，輸入全形小數點「。」或「. 」，如4. 5；全形空格
26）密碼檢查：輸入加密方式的極限字元；密碼盡可能長
27）用戶檢查：不同種類管理員用戶的不同許可權，是否可以互相刪除、管理、編輯；一般用戶的許可權；注銷功能，老用戶注銷再注冊，是否為新用戶
28）系統數據檢查：數據隨業務過程、狀態的變化保持正確，不能因為某個過程出現垃圾數據，也不能因為某個過程而丟失數據。
29）系統可恢復性檢查：以各種方式把系統搞癱，測試系統是否可以迅速恢復
30）確認提示檢查：系統更新、刪除操作：是否有提示、取消操作；提示是否准確；事前、事後提示
31）數據注入檢查：對資料庫注入，特殊字元，對SQL語句進行破壞
32）時間日期檢查：時間、日期、時間驗證：日期范圍是否符合實際業務；對於不符合實際業務的日期是否有限制
33）多瀏覽器驗證
3、性能測試
1）壓力測試：實際破壞一個Web應用系統，測試系統的反應，測試系統的限制和故障恢復能力
2）負載測試：在某一負載級別上的性能，包括某個時刻同時訪問Web的用戶數量、在線數據處理的數量
3）強度測試：測試對象在性能行為異常或極端條件下（如資源減少或用戶過多）的可接受性，以此驗證系統軟硬體水平
4）資料庫容量測試：通過存儲過程往資料庫表中插入一定數量的數據，看是否能及時顯示
5）預期指標的性能測試：在需求分析和設計階段會提出一些性能指標，對於預先確定的性能要求要首先進行測試
6）獨立業務性能測試：對核心業務模塊做用戶並發測試，包括同一時刻進行完全一樣的操作、同一時刻使用完全一樣的功能
7）組合業務性能測試：模擬多用戶的不同操作，最接近實際用戶使用情況，按用戶實際的實際使用人數比例來模擬各個模塊的組合並發情況
8）疲勞強度性能測試：系統穩定運行情況下，以一定負載壓力來長時間運行系統的測試
9）網路性能測試：准確展示帶寬、延遲、負載、埠的變化是如何影響用戶的相應時間的
10）大數據量性能測試：實時大數據量，模擬用戶工作時的實時大數據量；極限狀態下的測試，系統使用一段時間，積累一段數據量時能否正常運行，以及對前面兩種進行結合
11）伺服器性能測試：在進行用戶並發性能測試、疲勞強度、大數據量性能測試時，完成對伺服器性能的監控，並進行評估
12）一些特殊的測試：配置測試、內存泄漏的一些特殊測試
4、可用性測試(介面測試）
1）整體界面測試
2）多媒體測試
3）導航測試
5、客戶端兼容性
平台測試：windows；unix；macintosh；linux
瀏覽器測試：不同廠商的瀏覽器對Java、Javascript、ActiveX、plug-ins或不同的HTML的規格
不同的支持；框架和層次結構在不同瀏覽器也不同的顯示
6、安全性
安全性測試要求：
1）能夠對密碼試探工具進行防範
2）能夠防範對Cookie攻擊的常用手段
3）敏感數據保證不用明文傳輸
4）能防範通過文件名猜測和查看html文件內容獲取重要信息
5）能保證在網站收到工具後在給定時間內恢復，重要數據丟失不超過1小時
web的性能測試工具：
隨著Web2.0技術的迅速發展，許多公司都開發了一些基於Web的網站服務，通常在設計開發Web應用系統的時候很難模擬出大量用戶同時訪問系統的實際情況。
因此，當Web網站遇到訪問高峰時，容易發生伺服器響應速度變慢甚至服務中斷。
為了避免這種情況，需要一種能夠真實模擬大量用戶訪問Web應用系統的性能測試工具進行壓力測試，來測試靜態HTML頁面的響應時間，甚至測試動態網頁（包括ASP、PHP、JSP等）的響應時間，為伺服器的性能優化和調整提供數據依據。
1、企業級自動化測試工具WinRunner
MercuryInteractive公司的WinRunner是一種企業級的功能測試工具，用於檢測應用程序是否能夠達到預期的功能及正常運行。
2、工業標准級負載測試工具Loadrunner
LoadRunner是一種預測系統行為和性能的負載測試工具
3、全球測試管理系統testdirector
TestDirector是業界第一個基於Web的測試管理系統，它可以在您公司內部或外部進行全球范圍內測試的管理。
4、功能測試工具RationalRobot
IBMRationalRobot是業界最頂尖的功能測試工具，它甚至可以在測試人員學習高級腳本技術之前幫助其進行成功的測試。
它集成在測試人員的桌面IBMRationalTestManager上，在這里測試人員可以計劃、組織、執行、管理和報告所有測試活動，包括手動測試報告。
這種測試和管理的雙重功能是自動化測試的理想開始。
5、單元測試工具xUnit系列
目前的最流行的單元測試工具是xUnit系列框架，常用的根據語言不同分為JUnit（java），CppUnit（C++），DUnit（Delphi），NUnit（.net），PhpUnit（Php）等等。
該測試框架的第一個和最傑出的應用就是由ErichGamma（《設計模式》的作者）和KentBeck（XP（ExtremeProgramming）的創始人）提供的開放源代碼的JUnit.
6、功能測試工具SilkTest
BorlandSilkTest2006屬於軟體功能測試工具，是Borland公司所提出軟體質量管理解決方案的套件之一。
這個工具採用精靈設定與自動化執行測試，無論是程序設計新手或資深的專家都能快速建立功能測試，並分析功能錯誤。
7、性能測試工具WAS
是由微軟的網站測試人員所開發，專門用來進行實際網站壓力測試的一套工具。
透過這套功能強大的壓力測試工具，您可以使用少量的Client端計算機模擬大量用戶上線對網站服務所可能造成的影響。
8、自動化白盒測試工具Jtest
Jtest是parasoft公司推出的一款針對java語言的自動化白盒測試工具，它通過自動實現java的單元測試和代碼標准校驗，來提高代碼的可靠性。
parasoft同時出品的還有C++test，是一款C/C++白盒測試工具。
9、功能和性能測試的工具JMeter
JMeter是Apache組織的開放源代碼項目，它是功能和性能測試的工具，100%的用java實現。
10、性能測試和分析工具WEBLOAD
webload是RadView公司推出的一個性能測試和分析工具，它讓web應用程序開發者自動執行壓力測試；webload通過模擬真實用戶的操作，生成壓力負載來測試web的性能。
(7)web伺服器壓力測試報告擴展閱讀：
漏洞測試
企業網站做的越來越復雜、功能越來越強。不過這些都不是憑空而來的，是通過代碼堆積起來的。如果這個代碼只供企業內部使用，那麼不會帶來多大的安全隱患。
但是如果放在互聯網上使用的話，則這些為實現特定功能的代碼就有可能成為攻擊者的目標。
天眼舉一個簡單的例子。在網頁中可以嵌入SQL代碼。而攻擊者就可以利用這些SQL代碼來發動攻擊，來獲取管理員的密碼等等破壞性的動作。
有時候訪問某些網站還需要有某些特定的控制項。用戶在安裝這些控制項時，其實就有可能在安裝一個木馬（這可能訪問者與被訪問者都沒有意識到）。
為此在為網站某個特定功能編寫代碼時，就要主動出擊。從編碼的設計到編寫、到測試，都需要認識到是否存在著安全的漏洞。
天眼在日常過程中，在這方面對於員工提出了很高的要求。各個員工必須對自己所開發的功能負責。
已知的病毒、木馬不能夠在所開發的插件中有機可乘。通過這層層把關，就可以提高代碼編寫的安全性。
❽ 怎樣正確做 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種工具都能自動生成圖形報告。這樣你就能判斷出伺服器的瓶頸在哪裡。是需要增加內存還是提高處理器性能，或者增加硬碟。