『壹』 怎樣測試伺服器壓力
下載並安裝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網站已經打不開了，提示過多用戶連接。
『貳』 對網站進行測試和評估的工作內容～
一個網站的建成，是各個部門分工協作的結果。設計師進行網站頁面的設計，程序進行代碼的編寫。在網站的架構完成之後，還有一項非常重要的工作，那就是網站測試。
主要測試內容：
1、伺服器穩定性、安全性。
望站伺服器的穩定和安全一直都是最頭疼的事情，所以我們應該走到麻煩的前面，首先把預想到的麻煩排除掉。
Web伺服器搭建完成上線在即，其能夠承載多大的訪問量，響應速度、容錯能力等性能指標，所有這些是管理人員最想知道也最為擔心的。如何才能知曉這一切呢?通過工具進行Web壓力測試是個好方法。通過它可以有效地測試Web伺服器的運行狀態和響應時間等性能指標。
2、程序及資料庫測試。
每個程序都有自己相對應的功能，資料庫則是數據集中的地方，尤其重要。
資料庫開發既然在軟體開發的比重逐步提高，隨之而來的問題也突出。我們以前往往重視對代碼的測試工作，隨著流程技術的日益完善，軟體質量得到了大幅度的提高，但資料庫方面的測試仍然處於空白。我們從來沒有真正將資料庫作為一個獨立的系統進行測試，而是通過對代碼的測試工作間接對資料庫進行一定的測試。隨著資料庫開發的日益升溫，資料庫測試也需要獨立出來進行符合自身特點的測試工作。
在進行性能測試的時候，一定要注意環境的一致，包括：操作系統、應用軟體的版本以及硬體的配置等，而且在進行資料庫方面的測試的時候一定要注意資料庫的記錄數、配置等要一致，只有在相同條件下進行測試，才可以對結果進行比較。
3、網頁兼容性測試，如瀏覽器、顯示器。
網頁打開多了 不會出現死頁的情況，當然也有顯示器的解析度和瀏覽器的版本問題存在。
使用不同的瀏覽器訪問同一個網站，或者頁面的時候，在一種瀏覽器下顯示正常，在另一種下就亂了。這是因為不同的瀏覽器對於網站CSS的解釋不同。
常見的瀏覽器兼容性問題，主要表現在如下兩方面;
1.頁面顯示
頁面顯示的美觀性是Web應用程序中重要需求，不同瀏覽器上呈現給用戶的同一個Web頁面可能顯示的不一樣。這些差異性主要表現在對於頁面元素的位置、大小、外觀。如果在某款瀏覽器上顯示不美觀，就會成為一個問題，需要修改。
2)功能問題
Web軟體中的功能性問題主要是不同瀏覽器對腳本的執行不一致，功能性問題極大的限制了用戶對Web界面元素的使用。這類問題通常很難被發現，比如某個按鈕可能顯示正確但實際它是無法使用的，這個則需要用戶真正的去使用它才能被發現。
4、鏈接及表單設計
鏈接測試可分為三個方面：
1.測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面;
2.測試所鏈接的頁面是否存在;
3.保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的URL地址才能訪問。
表單測試，如用戶注冊、登陸、信息提交等，我們必須測試提交操作的完整性，以校驗提交給伺服器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了默認值，還要檢驗默認值的正確性。如果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字元，測試時可以跳過這些字元，看系統是否會報錯。
當然，網站測試還有很多方面的內容，諸如連接速度測試、負載測試、壓力測試、介面測試、安全測試等等，相關文章可以在企贏001進行了解。網站測試需要用到各種測試工具，以及寫一份合格的網站測試報告，這都是我們需要了解的。
二、性能測試
（1）連接速度測試。用戶連接到電子商務網的速度與上網方式有關，他們或許是電話撥號，或是寬頻上網
（2）負載測試。負載測試是在某一負載級別下，檢測電子商務系統的實際性能。
也就是能允許多少個用戶同時在線！可以通過相應的軟體在一台客戶機上模擬多個用戶來測試負載。
（3）壓力測試。壓力測試是測試系統的限制和故障恢復能力，也就是測試電子商務系統會不會崩潰
三、安全性測試
它需要對電子商務的客戶伺服器應用程序、數據、伺服器、網路、防火牆等進行測試用相對應的軟體進行測試
上面的測試是針對電子商務的，在電子商務書上找到的，那個測試一般普通的網站就是兩方面。
基本測試
包括色彩的搭配，連接的正確性，導航的方便和正確，CSS應用的統一性
2.技術測試
網站的安全性（伺服器安全，腳本安全），可能有的漏洞測試，攻擊性測試，錯誤性測試。
網站的評估主要對以下方面：網站界面,產品展示,在線支付,在線客服,線下產品配送。更重要的是目標消費者可以很方便快捷的找到該網站,從而進行電子商務活動.讓客戶找到該電子商務網站。是否網站有一個搜索引擎!或是把自己的網站添加到一些大的分類目錄上。再就是讓目標客戶記得你網站的名字(最終效果--品牌效果)並直接進去個好的電子商務網站是看它是否經過搜索引擎優化了。
『叄』 如何做壓力測試
一個壓力測試的流程：
1、明確測試目標
2、制定測試計劃
3、實施測試，收集參數
4、分析測試結果
5、給出優化方案
一 、明確測試目標：如果是客戶的需求，那需要向客戶確認，有清楚的性能指標參數，測試時就是保證系統達到該指標並能良好運轉，即壓力測試。如果是自己的系統需要有一個評估，那就需要完整的得到該系統的幾個臨界點，拿到完整的性能曲線，從而來分析部署情況，即為性能測試。不管是哪個，知道了需求，才能制定計劃。
性能測試的目標是發現重大的系統瓶頸。你可以想像一個系統由一系列的瓶頸組成；發現並改善一個瓶頸往往會在其他地方產生一個新的瓶頸。例如，我曾為一運行微軟Windows CE的器件部門工作。我們發現的第一大性能問題體現在某一具體硬體環境下的內存管理中。我們把問題分離出來，改善了內存分配的效率。爾後再次運行我們的測試，又找到了一個新的瓶頸，這次體現在網路吞吐量上（throughput）。解決了這個問題後，我們接著又為下一個瓶頸改善而工作，然後再下一個，直到整個系統都達到了性能目標。要記住的是：關鍵在於要盡早訂立性能目標，否則你可能不知道什麼時候該停止性能測試。
二、制定測試計劃：確定使用什麼工具，著重哪些參數，設置線程數，方法執行次數，執行時間，是否多個介面同時進行測試等等。
三、實施測試，收集參數：選一個施壓工具，來向部署好的服務發起高並發請求，同時關注和收集性能參數。這個是我們花費時間最多的地方。通常該階段需要反復執行，來得到想要的數據。通常來說，我們可以使用JMeter LR AB 自己寫多線程等各種方式，之後介紹一下JMeter。
四、分析測試結果：即根據上一節的參數介紹來進行參數分析。
五、給出優化方案：如果是代碼邏輯耗費cpu，就優化演算法；如果是redis等資料庫耗時，就增加節點，減少讀取，讀寫分離，使用內存等；如果是外在條件限制，則與外部們溝通問題，共同優化等等。
『肆』 如何用loadrunner做簡單網站的壓力測試
用loadrunner做簡單網站的壓力測試的方法
使用LoadRunner完成測試一般分為四個步驟：
1、VvitrualUserGenerator創建腳本。
創建腳本，選擇協議，錄制腳本， 編輯腳本，檢查修改腳本是否有誤。
2、中央控制器（Controller）來調度虛擬用戶。
創建Scenario，選擇腳本，設置機器虛擬用戶數，設置Schele，如果模擬多機測試，設置IpSpoofer。
『伍』 如何對伺服器進行壓力測試
壓力測試工具很多，可以使用阿里雲PTS進行壓測。
壓測流程
『陸』 游戲上線前伺服器壓力測試應該怎麼做
對於游戲後台性能，評測標准不只單單是TPS（每秒處理多少個XX請求），因為當你的游戲伺服器上線後，不存在一群玩家只發XX請求的壓力場景。所以，游戲後台受到的現網請求壓力永遠是多場景混合的，在這樣的壓力下，後台能支撐多少人同時在線，才是一個游戲壓測者需要得到的有價值的測試結論。
要得到可支撐的"最大同時在線人數"，主要做好2件事：
1、設計你的類現網壓力模型
在現網真實壓力里，不論壓力大小如何變化，現網環境如何變化，一個游戲類型和玩法設計定型後，永遠有2個壓力宏觀數據保持不變：a. 各介面的壓力比例不變， b.玩家平均每分鍾操作頻率不變。因此，壓力測試目標就轉變成了如何模擬符合ab數據的壓力。
對於a，首先從同類型游戲或者本游戲內測階段，日誌插樁，收集各個介面的調用比例；然後，將介面比例轉化為場景比例，如同時會有個2%完結登陸、15%玩家戰斗、20%玩家拉取好友列表、10%玩家賭博（一個手游場景例子）。
對於b，同樣在內測階段收集玩家平均操作頻率。
此時有了a和b，就可以構造出一分鍾內玩家同時在線的真實壓力模型了。
2、用壓測工具構造出符合壓力模型的壓力
這個可以自己寫，也可以使用現成的壓測工具。現在市面上的壓測工具很多，但很多都是專注於TPS這個參數，不符合游戲行業壓測的關注點，同時在線人數。
『柒』 如何用Jmeter做壓力測試
如何用Jmeter做壓力測試
Jmeter是一個性能測試工具，同loadrunner類似，他功能較多，我們常用的功能是用jmeter模擬多瀏覽器對網站做壓力測試。
下載jmeter地址 ：http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi
我們一般的網站，在進入業務功能前先需登錄，然後才能訪問業務功能。下面介紹如何用jmeter登錄系統再對主業務做壓力測試。
1. 運行jmeter
2. 左邊樹將出現測試計劃、工作台兩根節點。
3. 選擇測試計劃，按右鍵－》添加－》threads（users）線程組
線程組能設置以多少個線程並發做壓力測試。
在」循環次數」設置不選擇永遠，循環次數設置1。
4. 現在先介紹如何設置登錄http請求，選擇線程組，右鍵――添加――》sampler－―》http 請求。
http請求即模仿瀏覽器的訪問。
在「伺服器名稱或ip」設置127.0.0.1，埠號設置:8080，「方法」設置post，路徑設置網站登錄的地址，如「/exam/operatorAction」。
登錄需傳入用戶、密碼。在「同請求一起發送參數」列表中添加參數。參數值根據web應用設置。如login_user=0001;login_password=1;actFlag=login
5. 登錄成功後，網站一般將跳入主頁面。在jmap中可做判斷，判斷是否登錄後按預想進入主頁面（此步驟也可不設）。選擇4中的「http請求「，右鍵――》添加――》斷言――》響應斷言。「Apply to」設置Main smaple only；「要測試的響應欄位」設置「url樣本」；「模式匹配規則」設置「包括」，「要測試的模式」增加頁面跳轉到的主頁面，如：「studentMain.jsp」
6. 一般網站登錄後，在tomcat中生成了session，之後訪問其他頁面將無需再次登錄，前提是瀏覽器需支持cookie。在jmap中也同樣，如要繼續訪問其他頁面，還需做下面關鍵的設置。
選擇「線程組」――》右鍵――》添加――》配置元件――》Http cookie管理器。加了此步驟後，http請求將具備cookie功能，即登錄成功後訪問其他頁面將不會跳轉到登錄頁面重新登錄。
7. 對目標頁面反復壓力測試。
7.1 如何使被測頁面反復訪問達到測壓效果。選「線程組」―》右鍵――》邏輯控制器――》循環控制器。循環次數中選擇「永遠」。
7.2 選擇剛加的「循環控制器」，右鍵――》添加――》sampler－―》http 請求，按4步驟設置ip、埠，http請求方法為「get」，路徑為被壓力測試的url，如：「exam/business/studentExam.action.StudentExamAction?action=goIntoMockExam」。
按上面的設置後，已完成配置，可做壓力測試。只需點菜單「運行」――》啟動，即運行壓力測試。
8. jmeter提供了許多壓力結果查看工具。是壓力測試時非常好的分析工具。下面幾種查看工具可有選擇的添加。
8.1 察看結果樹。他記錄每次請求發送數據、響應返回數據。選擇「線程組」――》右鍵――》添加――》察看結果樹。
8.2 用表格查看結果。可查看每次請求的響應時間等。選擇「線程組」――》右鍵――》添加――》用表格查看結果。
8.3 Summary Report。可查看平均響應時間、最長響應時間等。
『捌』 如何正確的做WEB端的壓力測試
1、對要測試的系統進行分析，明確需要對哪一塊做壓力測試。比如：淘寶網站雙十一期間，秒殺跟支付，此模式用戶操作中佔比比較大
再比如：游戲，登錄--開始戰斗--結束戰斗這種混合模式在用戶操作中佔比較大
那麼就可以針對這種佔比比較大的模式進行壓力測試
2、明確了要測試的點後，如何對這些測試點進行施壓呢？
第一種方式可以通過寫腳本產生壓力機器人對伺服器進行發包收包操作；
第二種方式就是藉助一些壓力測試工具如:J
『玖』 怎樣正確做 Web 應用的壓力測試
一個完整的壓力測試需要關注三個方面：如何正確產生壓力、如何定位瓶頸、如何預估系統的承載能力
(1) 首先說一下如何產生壓力，產生壓力的方法有很多，通常可以寫腳本產生壓力機器人對伺服器進行發包和收包操作，也可以使用現有的工具(像jmeter、LoadRunner這些），所以說產生壓力其實並不難，難點在於產生的壓力是不是真實地反映了實際用戶的操作場景。舉個例子來說，對游戲來說單純的並發登陸場景在整個線上環境中的佔比可能並不大(新開服等特殊情況除外)，相反「登陸-開始戰斗-結束戰斗」、不同用戶執行不同動作這種「混合模式」佔了更大的比重。所以如何從實際環境中提煉出具體的場景比重，並且把這種比重轉化成實際壓力是一個重要的關注點。
(2) 產生壓力之後，通常我們可以拿到TPS、響應時延等性能數據，那麼如何定位性能問題呢？TPS、響應時延只能告訴你伺服器是否存在問題，但不能幫助你定位問題。這些表面背後是整個後台處理邏輯綜合作用的結果，這時候可以先關注系統的CPU、內存、IO、網路，對比在tps、時延達到瓶頸時這些系統數據的情況，確定性能問題是系統哪一部分造成的，然後再回到代碼的邏輯中逐個優化這些點。
(3) 當伺服器的整體性能就可以相對穩定下來，這時候就需要對自己伺服器的承載能力有一個預估，通過產生真實壓力、對比系統數據，大致可以對單套系統的處理能力有個真實的評價，然後結合業務規模配置伺服器數量。