服務器穩定性測試方法

服務器穩定性是最重要的，若是在穩定性方面不可以保證業務運行的須要，在高的性能也是無用的。

正規的服務器廠商都會對產品驚醒不一樣溫度和溼度下的運行穩定性測試。重點要考慮的是冗餘功能，如：數據冗餘、網卡榮譽、電源冗餘、風扇冗餘等。

一些測試方法主要分如下幾種：

壓力測試：已知系統高峯期使用人數，驗證各事務在最大併發數（經過高峯期人數換算）下事務響應時間可以達到客戶要求。系統各性能指標在這種壓力下是否還在正常數值以內。系統是否會因這樣的壓力致使不良反應（如：宕機、應用異常停止等）。

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)在Sechedule-勾選Initalize all Vusers before Run

容錯性測試：經過模擬一些非正常狀況（如：服務器忽然斷電、網絡時斷時續、服務器硬盤空間不足等），驗證系統在發生這些狀況時是否可以有自動處理機制以保障系統的正常運行或恢復運行措施。若有HA（自動容災系統），還能夠專門針對這些自動保護系統進行另外的測試。驗證其可否有效觸發保護措施。

問題排除性測試：經過原有案例或經驗判斷，針對系統中曾經發生問題或懷疑存在隱患的模塊進行驗證測試。驗證這些模塊是否還會發生一樣的性能問題。如：上傳附件模塊的內存泄露問題、地址本模塊優化、開啓Tivoli性能監控對OA系統性能的影響等等。

測評測試是用於獲取系統的關鍵性能指標點，而進行的相關測試。主要是針對預先沒有明確的預期測試結果，而是要經過測試獲取在特定壓力場景下的性能指標（如：事務響應時間、最大併發用戶數等）。

評測事務交易時間：爲獲取某事務在特定壓力下的響應時間而進行的測試活動。經過模擬已知客戶高峯期的各壓力值或預期所能承受的壓力值，獲取事務在這種壓力下的響應時間。

評測事務最大併發用戶數：爲獲取某事務在特定系統環境下所能承受的最大併發用戶數而進行的測試活動。經過模擬真實環境或直接採用真實環境，評測在這種環境下事務所能承受的最大併發用戶數。斷定標準閾值需預先定義（如響應時間，CPU佔用率，內存佔用率，已出現點擊率峯值，已出現吞吐量峯值等）。

評測系統最大併發用戶數：爲獲取整個系統所可以承受的最大併發用戶數而進行的的測試活動。經過預先分析項目各主要模塊的使用比率和頻率，定義各事務在綜合場景中所佔的比率，以比率方式分配各事務併發用戶數。

模擬真實環境或直接採用真實環境，評測在這種環境下系統所能承受的最大併發用戶數。斷定標準閥值預先定義（如響應時間，CPU佔用率，內存佔用率，已出現點擊率峯值，已出現吞吐量峯值等）。取值標準以木桶法則爲準（併發數最小的事務爲整個系統的併發數）。

評測不一樣數據庫數據量對性能的影響：針對不一樣數據庫數據量的測試，將測試結果進行對比，分析發現數據庫中各表的數據量對事務性能的影響。得以預先判斷系統長時間運行後，或某些模塊客戶要求數據量較大時可能存在的隱患。

問題定位測試在經過以上測試或用戶實際操做已經發現系統中的性能問題或懷疑已存在性能問題。需經過響應的測試場景重現問題或定義問題。若有可能，能夠直接找出引發性能問題所在的代碼或模塊。

該類測試主要仍是經過測試出問題的腳本場景，並能夠增長髮現和檢測的工具，如開啓Tivoli性能監控、開啓HeapDump輸出、Linux資源監控命令等。並在場景運行過程當中輔以手工測試。