Ⅰ 如何測試伺服器的穩定性
伺服器穩定性是最重要的，如果在穩定性方面不能夠保證業務運行的需要，在高的性能也是無用的。
正規的伺服器廠商都會對產品驚醒不同溫度和濕度下的運行穩定性測試。重點要考慮的是冗餘功能，如：數據冗餘、網卡榮譽、電源冗餘、風扇冗餘等。
一些測試方法主要分以下幾種：
壓力測試：已知系統高峰期使用人數，驗證各事務在最大並發數(通過高峰期人數換算)下事務響應時間能夠達到客戶要求。系統各性能指標在這種壓力下是否還在正常數值之內。系統是否會因這樣的壓力導致不良反應(如：宕機、應用異常中止等)。
Ramp Up 增量設計：如並發用戶為75人，系統注冊用戶為1500人，以5%-7%作為並發用戶參考值。一般以每15s載入5人的方式進行增壓設計，該數值主要參考測試加壓機性能，建議Run幾次。以事務通過率與錯誤率衡量實際載入方式。
Ramp Up增量設計目標： 尋找已增量方式加壓系統性能瓶頸位置，抓住出現的性能拐點時機，一般常用參考Hits點擊率與吞吐量、CPU、內存使用情況綜合判斷。模擬高峰期使用人數，如早晨的登錄，下班後的退出，工資發送時的消息系統等。
另一種極限模擬方式，可視為在峰值壓力情況下同時點擊事務操作的系統極限操作指標。加壓方式不變，在各腳本事務點中設置同集合點名稱(如：lr_rendzvous("same");)在場景設計中，使用事務點集合策略。以同時達到集合點百分率為標准，同時釋放所有正在Run的Vuser。
穩定性測試：已知系統高峰期使用人數、各事務操作頻率等。設計綜合測試場景，測試時將每個場景按照一定人數比率一起運行，模擬用戶使用數年的情況。並監控在測試中，系統各性能指標在這種壓力下是否能保持正常數值。事務響應時間是否會出現波動或隨測試時間增漲而增加。系統是否會在測試期間內發生如宕機、應用中止等異常情況。
根據上述測試中，各事務條件下出現性能拐點的位置，已確定穩定性測試並發用戶人數。仍然根據實際測試伺服器(加壓機、應用伺服器、數據伺服器三方性能)，估算最終並發用戶人數。
場景設計思想：
從穩定性測試場景的設計意義，應分多種情況考慮：
針對同一個場景為例，以下以公文附件上傳為例簡要分析場景設計思想：
1)場景一：已壓力測試環境下性能拐點的並發用戶為設計測試場景，目的驗證極限壓力情況下測試伺服器各性能指標。
2)場景二：根據壓力測試環境中CPU、內存等指標選取伺服器所能承受最大壓力的50%來確定並發用戶數。
測試方法：採用1)Ramp Up-Load all Vusers simultaneously
2)Duration-Run Indefinitely
3)在Sechele-勾選Initalize all Vusers before Run
容錯性測試：通過模擬一些非正常情況(如：伺服器突然斷電、網路時斷時續、伺服器硬碟空間不足等)，驗證系統在發生這些情況時是否能夠有自動處理機制以保障系統的正常運行或恢復運行措施。如有HA(自動容災系統)，還可以專門針對這些自動保護系統進行另外的測試。驗證其能否有效觸發保護措施。
問題排除性測試：通過原有案例或經驗判斷，針對系統中曾經發生問題或懷疑存在隱患的模塊進行驗證測試。驗證這些模塊是否還會發生同樣的性能問題。如：上傳附件模塊的內存泄露問題、地址本模塊優化、開啟Tivoli性能監控對OA系統性能的影響等等。
測評測試是用於獲取系統的關鍵性能指標點，而進行的相關測試。主要是針對預先沒有明確的預期測試結果，而是要通過測試獲取在特定壓力場景下的性能指標(如：事務響應時間、最大並發用戶數等)。
評測事務交易時間：為獲取某事務在特定壓力下的響應時間而進行的測試活動。通過模擬已知客戶高峰期的各壓力值或預期所能承受的壓力值，獲取事務在這種壓力下的響應時間。
評測事務最大並發用戶數：為獲取某事務在特定系統環境下所能承受的最大並發用戶數而進行的測試活動。通過模擬真實環境或直接採用真實環境，評測在這種環境下事務所能承受的最大並發用戶數。判定標准閾值需預先定義(如響應時間，CPU佔用率，內存佔用率，已出現點擊率峰值，已出現吞吐量峰值等)。
評測系統最大並發用戶數：為獲取整個系統所能夠承受的最大並發用戶數而進行的的測試活動。通過預先分析項目各主要模塊的使用比率和頻率，定義各事務在綜合場景中所佔的比率，以比率方式分配各事務並發用戶數。模擬真實環境或直接採用真實環境，評測在這種環境下系統所能承受的最大並發用戶數。判定標准閥值預先定義(如響應時間，CPU佔用率，內存佔用率，已出現點擊率峰值，已出現吞吐量峰值等)。取值標准以木桶法則為准(並發數最小的事務為整個系統的並發數)。
評測不同資料庫數據量對性能的影響：針對不同資料庫數據量的測試，將測試結果進行對比，分析發現資料庫中各表的數據量對事務性能的影響。得以預先判斷系統長時間運行後，或某些模塊客戶要求數據量較大時可能存在的隱患。
問題定位測試在通過以上測試或用戶實際操作已經發現系統中的性能問題或懷疑已存在性能問題。需通過響應的測試場景重現問題或定義問題。如有可能，可以直接找出引起性能問題所在的代碼或模塊。
該類測試主要還是通過測試出問題的腳本場景，並可以增加發現和檢測的工具，如開啟Tivoli性能監控、開啟HeapDump輸出、Linux資源監控命令等。並在場景運行過程中輔以手工測試。
Ⅱ 怎麼進行性能測試
問題一：性能測試應該做哪些准備 環境搭建：這個根據實際規劃，我在企業內做過的性能測試搭建的環境都是和用戶上線使用的實際環境一樣的。
數據准備：個人感覺是整個工作里第二耗時的，需要真實模擬用戶數據，這個不是單單的創建幾個帳號就完事的，每個用戶基本都會有不太一樣的配置，實際操作的時候部署數據的腳本都寫到手軟。
腳本編譯：選擇性能工具編譯性能腳本，你需要跑什麼業務流程就編譯什麼樣的腳本。
腳本執行：用規劃好的用戶數執行腳本，這個一般持續很長時間，時間太短不足以暴露伺服器等的性能瓶頸，性能測試中最耗時的就是這個步驟。
收集日誌：在執行腳本完成後收集到的能客觀反應系統性能的日誌、報表文件，比如LR的報告、資料庫的AWR日誌等等。
分析結果：分析收集到的日誌、報表，找出性能瓶頸或是得出性能指標結果。這個一般需要對資料庫或者底層非常了解的專業人士來分析，一般測試人員只需要提供收集到的報告就差不多了。
生成報告：將上面所有的性能測試活動整理總結，輸出測試報告。
問題二：如何做好性能測試？ 你好，首先很欣賞你的這種態度。我在TestBird 招聘新人的時候，也有很多小朋友覺得自己有多了解工具運用，有多熟練步驟過程，自我感覺很不錯。
其實，我卻想說，性能測試的重點不在性能測試工具的學習上。
當然，你也通過分析系統的壓力點、LR錄制腳本，設置用戶，做壓力，分析結果，整理測試報告。完成了性能測試的整個過程。那麼我說這個性能測試報告是有效的，但它不一定是有用的。
為什麼呢？因為在性能測試報告中，在你所在的環境中，你是測出了這樣的效果。並未摻假，全部真實的記錄。
為什麼說它不一定是有用悶握的，你了解系統架構么？知道資料庫、中間件、前端程序的運行方式和處理機制么？了解網路協議么？了解操作系統么？熟悉開發系統的語言么，如java JVM的內在機理知道么？這些都是系統運行的一部分，都在影響著系統的性能。如果不了解這些，你如何做出有價值的有參考意義的性能測試。
所以，學會這些性能測試工具很好，但是這僅僅是第一步。性能結果只是一些數據而已，知道你在做什麼，為什麼要做這些，做完後能給出有價值的東西，才是後面要慢慢修煉的。
問題三：移動客戶端的性能測試如何做？ 。就當練習了。。大家看了不要枝罩清噴我。。現在很多測試人員做移動端測試，可能主要還是關注功能和自動化測試。性能測試可能大多是按照每個人的體驗來做報告，是不是比較快，或者比較慢。當然也不乏有很多的測試人員會回復我說，性能測試都是伺服器的，移動端根本就不需要性能測試。我實在覺得可笑。 不過我畢竟一直在創業公司，而且就我一個人，所以了解可能有限，我這里就說下我之前碰見的，所知道的，目的只是拋磚引玉。 另外，我這里也不去說什麼MAT，instruments了，這種固有查找內存的工具大家自己google吧。 客戶端的性能從系統層面，電量消耗，網路流量，內存泄漏等都是被關注，或者說用戶最最關注的點。 實例一，3rd 應用的性能測試。應用本身的響應時間可以通過call 應用intent來查看，設備純環境，設備低內存等各種情況下進行同樣猛前此數的call，進行對比。或者與同行業同性質的應用進行對比測試。我相信很快就能夠有結論了。除了應用本身，還需要對於應用本身某些特別的功能進行響應測試。比如測試一個list，測試的方法為onkeydown之後查看這個list.index（0）是否高亮，是否正常的界面跳轉了，那麼分別進行計時（精確ms）。同樣的，我們在空list以及有幾百條list的情況進行這樣的case test，那麼就會有一個性能的結果出來。 實例二，假設你測試微薄客戶端，那麼你肯定是需要進行一個list上下滑動的性能測試。我們需要使用腳本語言shell或者python去call server api來仿造數據反饋到移動設備上，否則你不可能自己手動去發幾百條weibo然後再測試。測試的時候需要關注兩個問題，一個是list在各種情況下是否滑動流暢，一個是當list中有很多的圖片的時候圖片load的速度也是一個很大的測試點。這個load可以直接檢查imageview什麼時候load出來pic，什麼時候顯示在界面上，計算時間。這里其實很多應用是webview，或者數據是存在伺服器端的，這個時候無論是平時的測試還是壓力，還是性能，數據的修改，其實還是多使用腳本ping api比較好，能夠很好的去輔助達到性能測試的效果。 實例三，比如要測試一個優酷的視頻軟體，那麼視頻的播放的時候，首先保證網路的情況下，各種解析度各種碼率的視頻接入時間是需要關注。然後在播放，也就是和網路不停的通信的同時，那麼需要通過tcp mp和wireshark工具來檢查網路訪問是否正確，視頻的卡頓，視頻的花屏等除了硬體兼容之外，可以通過抓包來判斷其性能。如果丟包率高那麼自然視頻卡，體驗不好，性能也就不會好。 其實以上只是一些很基礎，現在很多公司也已經在這個基礎上改良測試了。不過也是一些思路，讓更多的企業和測試關注移動客戶端的性能。不要一提到性能腦中只有LR等這些Server測試。
問題四：為什麼要進行性能測試? 原因有三：
川. 開發者的水平各有不同，有的寫出來的東西性能高，有的低，所以需要統一測試一下。
2. 編程工具本身也有性能問題，用這樣的工具開發出來的軟體也要確認一下是否達到了需求所要求的性能指標，比如響應時間應該控制在多少秒以內。
3. 性能測試，強度測試都是為了測試系統的穩定性，穩定性好，軟體的質量就好，買的錢就多。
問題五：如何進行Web服務的性能測試 貼一篇我們內部的文章：
隨著瀏覽器功能的不斷完善，用戶量不斷的攀升，涉及到web服務的功能在不斷的增加，對於我們測試來說，我們不僅要保證服務端功能的正確性，也要驗證服務端程序的性能是否符合要求。那麼性能測試都要做些什麼呢？我們該怎樣進行性能測試呢？
性能測試一般會圍繞以下這些問題而進行：
1. 什麼情況下需要做性能測試？
2. 什麼時候做性能測試？
3. 做性能測試需要准備哪些內容？
4. 什麼樣的性能指標是符合要求的？
5. 性能測試需要收集的數據有哪些？
6. 怎樣收集這些數據？
7. 如何分析收集到的數據？
8. 如何給出性能測試報告？
性能測試的執行過程及要做的事兒主要包含以下內容：
1. 測試評估階段
在這個階段，我們要評估被測的產品是否要進行性能測試，並且對目前的伺服器環境進行粗估，服務的性能是否滿足條件。
首先要明確只要涉及到准備上線的服務端產品，就需要進行性能測試。其次如果產品需求中明確提到了性能指標，那也必須要做性能測試。
測試人員在進行性能測試前，需要根據當前的收集到的各種信息，預先做性能的評估，收集的內容主要包括帶寬、請求包大小、並發用戶數和當前web服務的帶寬等
2. 測試准備階段
在這個階段，我們要了解以下內容：
a. 伺服器的架構是什麼樣的，例如：web伺服器是什麼？是如何配置的？資料庫用的是什麼？服務用的是什麼語言編寫的？；
b. 服務端功能的內部邏輯實現；
c. 服務端與資料庫是如何交互的，例如：資料庫的表結構是什麼樣的？服務端功能是怎樣操作資料庫的？
d. 服務端與客戶端之間是如何進行交互的，即介面定義；
通過收集以上信息，測試人員整理出伺服器端各模塊之間的交互圖，客戶端與服務端之間的交互圖以及服務端內部功能邏輯實現的流程圖。
e. 該服務上線後的用戶量預估是多少，如果無法評估出用戶量，那麼可以通過設計測試執行的場景得出這個值；
f. 上線要部署到多少台機器上，每台機器的負載均衡是如何設計的，每台機器的配置什麼樣的，網路環境是什麼樣的。
g. 了解測試環境與線上環境的不同，例如網路環境、硬體配置等
h. 制定測試執行的策略，是需要驗證需求中的指標能否達到，還是評估系統的最大處理能力。
i. 溝通上線的指標
通過收集以上信息，確定性能測試用例該如何設計，如何設計性能測試用例執行的場景，以及上線指標的評估。
3. 測試設計階段
根據測試人員通過之前整理的交互圖和流程圖，設計相應的性能測試用例。性能測試用例主要分為預期目標用戶測試，用戶並發測試，疲勞強度與大數量測試，網路性能測試，伺服器性能測試，具體編寫的測試用例要更具實際情況進行裁減。
用例編寫的步驟大致分為：
a. 通過腳本模擬單一用戶是如何使用這個web服務的。這里模擬的可以是用戶使用web服務的某一個動作或某幾個動作，某一個功能或幾個功能，也可以是使用web服務的整個過程。
b. 根據客戶端的實際情況和伺服器端的策略，通過將腳本中可變的數據進行參數化，來模擬多個用戶的操作。
c. 驗證參數化後腳本功能的正確性。
d. 添加檢查點
e. 設計腳本執行的策略，如每個功能的執行次數，各個功能的執行順序等
4. 測試執行階段
根據客戶端的產品行為設計web服務的測試執行場景及測試執行的過程，即測試執行期間發生的事兒。通過監控程序收集web服務的性能數據和web服務所在系統的性能數據。
在測試執行過程中，還要不斷的關注以下內容：
a. web服務的連接速度如何？
b. 每秒的點擊數如何？
c. Web服務能允許多少個用戶同時在線？
d. 如果超過了這......>>
問題六：網站性能測試主要有哪幾種方法? 我知道的性能測試主要有：壓力測試，負載測試，容量測試，發性能測試，兼容性測試（不同的操作系統和不同的瀏覽器）。測的時候應用在客戶端的性能、應用在網路上的性能和應用在伺服器端的性能都要進行測試的。
希望能幫到你。
問題七：怎麼才能做性能測試工程師？ 性能測試實際上確實需要些功底兒，但是也並不是非得一兩年之後才去做。
我給你列幾條性能測試工作中的建議，你可以自己溫習一下，然後去面試，具體的經驗需要實際的工作才能得到，然而你扎實的基礎知識才識支撐你走下去的動力。
1，最直接也是最表面的建議，適用於面試：Loadrunner, HttpWatch, Dynatrace, TeamQuest, JMeter(可選), Wily(可選), HTML/HTTP, Webservice, Mainframe, DB. 這些東西足夠學很久很久的了，所以說需要幾年的工夫，但是沒必要每一樣都學太深，了解即可，經驗日後會積累到的。
2，相對比較深層的建議：性能測試最關鍵之處不是工具的選擇，而是對整個性能參數的理解，所以比較貼近於概念，比如說什麼是TPS, Response Time, Connection浮 per Second....還有就是什麼是CPU Utilization, FreeMem, Disk IO, Paging.... 工具也無非都是通過日積月累形成的客戶端，所以抓到本質才是關鍵。
不在這里長篇大論了，呵呵，加油！
問題八：性能測試應該怎麼做 需求分析 － 測試設計 － 測試執行 － 結果分析
問題九：APP如何做性能測試 目前市面上有很多家做安全加密的平台都有做安全檢測，但是大部分需要付費，如果說只是個小項目的話花錢去做的話成本太高，也不建議去做
你可以了解下愛內測這個平台，專門做測試的，有安全檢測、兼容測試、插件評估等，雖然這個平台也是付費的，但是他有免費的版本提供，個人覺得安全檢測免費版本已經足夠強大了，自動化生成測試報告，提供精準的檢測數據
希望可以幫助到你
問題十：服務端怎麼做性能測試 使用LR對資料庫進行性能測試，實際上有多種辦法，包括通過現有的資料庫協議進行CS模式的先錄制後執行的模式，以及通過socket方式向伺服器發包方式的測試方式。這些是常規書籍上介紹的比較簡單上手的測試方法，但是不具備通用性，受已有協議或socket編程方式的限制，所以需要更為通用的測試方法。
用Java user的協議進行所有資料庫性能的測試工作：
Java user 不需要錄制，把所有的操作通過java語言進行實現，通過lr調用java的class進行加壓批量操作，這樣可以不關心被測系統是哪個資料庫，只要能夠通過jdbc進行訪問，就能實現性能測試。
一、測試環境准備
1. 被測伺服器准備，根據測試目的，搭建需要的資料庫伺服器，確保資料庫能夠正常訪問，正常操作；
2. Java代碼的准備，無論使用哪種IDE，只要能夠編寫訪問資料庫的class就可以，形式可以是j2se，也可以是j2ee，因為在操作時只使用class的部分方法，所以j2ee就可以了；
3. LR的腳本調試，把java的class導入到腳本調試模式，根據需要添加事務以及其他操作。
二、編寫資料庫訪問
1. 使用myeclipse，創建web project，創建如下圖的包目錄：
Java文件中包含各種訪問資料庫的方法。
需要注意的是，class中的方法必須是public static，否則LR中無法調用。由於創建的是j2ee程序，所以不用main函數，在web中就可以進行功能驗證。
確認class中的方法編寫完成，創建一個web.jsp文件，如下：
導入class
聲明類，並實例化，直接調用剛才編寫的3個方法，因為這3個方法是直接對資料庫進行操作，不需要實參，也沒有返回值，所以直接實現即可。
此時啟動web服務，在瀏覽器中輸入jsp的地址，直接刷新頁面，就可以調用這3個方法，如果正確，就會對相應的表進行操作，如果不正確，則需要修改相應的代碼。
2. LR腳本准備：
LR腳本實際上就是對訪問代碼的調用，關鍵在於需要根據測試場景劃分不同的腳本布局。
例如：在myEclipse里，我們只編寫了一個class，其中包含三個方法，如果在執行性能測試時，這三個方法相互獨立，互不幹涉，則最簡單的劃分方法是，創建三個java user，每個java user中包含一個方法，做三份腳本，場景執行時分別進行調用。如果三個方法之間有相互關系，則需要根據實際情況，把有關聯的方法放在一起，具體情況可按實際靈活分配。
因為已經將class文件進行編譯發布了，所以可以在「java2postgres\WebRoot\WEB-INF\classes\\lr\test」目錄中找到對應的class文件，
復制這個文件，找到LR的目錄：HP\LoadRunner\classes\\lr\test\ 如果沒有文件夾，按相同的內容創建。
在LR腳本中進行引包操作：
將需要執行的java類以及方法，放在action中，可根據實際測試情況和所需要驗證的內容，具體調試代碼。
在這里可以像編寫普通LR腳本一樣，添加事務或 *** 點等內容。
由於是通過JDBC對資料庫進行訪問，因此要在java user中載入jdbc驅動。
運行時設置中，增加jdbc驅動，需要注意的是java user使用的本地jdk，需要至多1.6版......>>
Ⅲ 伺服器硬體測試教程
一般情況下，我們可能想測試一下伺服器上的文件（用戶上傳的或者後台寫入的）是否可以被外網訪問到，以進一步測試文件下載等功能。
我原本想嘗試從伺服器的任意目錄訪問文件，但是經過數次的嘗試，網上教的通過修改Tomcat路徑映射和自定義XML來進行文件映射都不能成功訪問到目標文件。
最後查到，把文件放在Tomcat的ROOT目錄下，就可以用伺服器域名+「/」+「文件名（帶後綴）」直接訪問到文件，親測成功，。
Ⅳ 怎麼判斷伺服器的性能
Windows伺服器中自帶的性能監控工具叫做Performance Monitor,
在開始-運行中輸入『perfmon』，然後回車即可運行。Performance
Monitor本身也是一個進程，運行起來也要佔用一定的系統資源。所以你看到的資源的使用量應該比實際的要稍微高一點。這個工具在幫助管理員判斷系統性能瓶頸時非常有用。舉個列子來說，今天有個用戶抱怨說他們項目組的伺服器（這是一台虛擬機）運行起來非常慢，但也不知道具體問題出在什麼地方。任務管理器里顯示CPU和內存的使用量都不算高，但伺服器的相應就是非常慢。打開Performance
Monitor，讓其運行一段時間後（因為參考平均值會比較准確），發現average disk
queue的值比較高，這就說明物理伺服器的硬碟負荷太重，I/O操作的速度跟不上系統的要求。關掉虛擬機，將其轉移到另一台硬碟負載比較小的主機上，再打開虛擬機。問題就解決了！
這里我簡單列舉幾個常用參數的參考值，需要更多的信息你可以google一把。
CPU:
% Processor Time：表示CPU的使用率，如果值大於80表示CPU的處理調度能力偏低。
硬碟：
% Disk Time：表示硬碟的I/O操作的頻率（繁忙時間），如果值大於80表示硬碟I/O調度能力偏低。
Average Disk Queue
Length：表示硬碟I/O操作等待隊列的長度，如果值大於2表示硬碟I/O調度能力偏低。
內存
Pages/Sec：表示系統對虛擬內存每秒鍾的訪問次數，如果值大於20表示有內存方面的問題。（有可能是物理內存偏低，也有可能是虛擬內存沒有配置正確。一般情況下虛擬內存應為物理內存的1.5-2倍）
Committed Bytes and Available Bytes：Committed
Bytes表示虛擬內存的大小，Available Bytes表示剩餘可用內存的大小。正常情況下，Available
Bytes減少，pages（頁面數）應該增加，提供頁面交換。如果Available
Bytes的值很小表示物理內存偏低。當關閉一些應用以後，Committed Bytes應該減少，Available
Bytes應該增加。因為關閉的進程釋放了之前佔用的內存資源。如果相應的值沒有發生變化，那麼該進程就可能造成了內存泄漏。
Cache Bytes：表示系統緩存的大小。如果值大於4M表示物理內存偏低。