如何有效的進行伺服器穩定性測試？

伺服器穩定性是最重要的，如果在穩定性方面不能夠保證業務運作的需要，再高的性能也是無用的。

正規的伺服器廠商都會對産品進行不同溫度和濕度下的運作穩定性測試。重點要考慮的是備援功能，如：資料備援、網卡備援、電源備援、風扇備援等。

測試方法主要分以下幾種：

1、壓力測試

已知系統高峰期使用人數，驗證各事務在最大并發數(通過高峰期人數換算)下事務響應時間能夠達到客戶要求。系統各性能名額在這種壓力下是否還在正常數值之内。系統是否會因這樣的壓力導緻不良反應(如：當機、應用異常中止等)。

2、Ramp Up 增量設計

如并發使用者為75人，系統注冊使用者為1500人，以5％－7％作為并發使用者參考值。一般以每15s加載5人的方式進行增壓設計，該數值主要參考測試加壓機性能，建議Run幾次。以事務通過率與錯誤率衡量實際加載方式。

Ramp Up增量設計目标： 尋找已增量方式加壓系統性能瓶頸位置，抓住出現的性能拐點時機，一般常用參考Hits點選率與吞吐量、CPU、記憶體使用情況綜合判斷。模拟高峰期使用人數，如早晨的登入，下班後的退出，工資發送時的消息系統等。

另一種極限模拟方式，可視為在峰值壓力情況下同時點選事務操作的系統極限操作名額。加壓方式不變，在各腳本事務點中設定同集合點名稱 (如：lr_rendzvous(“same”);)在場景設計中，使用事務點集合政策。以同時達到集合點百分率為标準，同時釋放所有正在Run的 Vuser。

3、穩定性測試

已知系統高峰期使用人數、各事務操作頻率等。設計綜合測試場景，測試時将每個場景按照一定人數比率一起運作，模拟使用者使用數年的情況。并監控在測試中，系統各性能名額在這種壓力下是否能保持正常數值。事務響應時間是否會出現波動或随測試時間增漲而增加。系統是否會在測試期間内發生如當機、應用中止等異常情況。

根據上述測試中，各事務條件下出現性能拐點的位置，已确定穩定性測試并發使用者人數。仍然根據實際測試伺服器(加壓機、應用伺服器、資料伺服器三方性能)，估算最終并發使用者人數。

場景設計思想：從穩定性測試場景的設計意義，應分多種情況考慮。針對同一個場景為例，以下以公文附件上傳為例簡要分析場景設計思想：

1)場景一：已壓力測試環境下性能拐點的并發使用者為設計測試場景，目的驗證極限壓力情況下測試伺服器各性能名額。

2)場景二：根據壓力測試環境中CPU、記憶體等名額選取伺服器所能承受最大壓力的50%來确定并發使用者數。

測試方法：

①Ramp Up-Load all Vusers simultaneously

②Duration-Run Indefinitely

③在Sechedule-勾選Initalize all Vusers before Run

4、容錯性測試

通過模拟一些非正常情況(如：伺服器突然斷電、網絡時斷時續、伺服器硬碟空間不足等)，驗證系統在發生這些情況時是否能夠有自動處理機 制以保障系統的正常運作或恢複運作措施。如有HA(自動容災系統)，還可以專門針對這些自動保護系統進行另外的測試。驗證其能否有效觸發保護措施。

問題排除性測試：通過原有案例或經驗判斷，針對系統中曾經發生問題或懷疑存在隐患的子產品進行驗證測試。驗證這些子產品是否還會發生同樣的性能問題。如：上傳附件子產品的記憶體洩露問題、位址本子產品優化、開啟Tivoli性能監控對OA系統性能的影響等等。

測評測試是用于擷取系統的關鍵性能名額點，而進行的相關測試。主要是針對預先沒有明确的預期測試結果，而是要通過測試擷取在特定壓力場景下的性能名額(如：事務響應時間、最大并發使用者數等)。

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

評測事務最大并發使用者數：為擷取某事務在特定系統環境下所能承受的最大并發使用者數而進行的測試活動。通過模拟真實環境或直接采用真實環境，評測在這 種環境下事務所能承受的最大并發使用者數。判定标準門檻值需預先定義(如響應時間，CPU占用率，記憶體占用率，已出現點選率峰值，已出現吞吐量峰值等)。

評測系統最大并發使用者數：為擷取整個系統所能夠承受的最大并發使用者數而進行的的測試活動。通過預先分析項目各主要子產品的使用比率和頻率，定義各事務 在綜合場景中所占的比率，以比率方式配置設定各事務并發使用者數。

模拟真實環境或直接采用真實環境，評測在這種環境下系統所能承受的最大并發使用者數。判定标準閥 值預先定義(如響應時間，CPU占用率，記憶體占用率，已出現點選率峰值，已出現吞吐量峰值等)。取值标準以木桶法則為準(并發數最小的事務為整個系統的并 發數)。

評測不同資料庫資料量對性能的影響：針對不同資料庫資料量的測試，将測試結果進行對比，分析發現資料庫中各表的資料量對事務性能的影響。得以預先判斷系統長時間運作後，或某些子產品客戶要求資料量較大時可能存在的隐患。

問題定位測試在通過以上測試或使用者實際操作已經發現系統中的性能問題或懷疑已存在性能問題。需通過響應的測試場景重制問題或定義問題。如有可能，可以直接找出引起性能問題所在的代碼或子產品。

5、總結

該類測試主要還是通過測試出問題的腳本場景，并可以增加發現和檢測的工具，如開啟Tivoli性能監控、開啟HeapDump輸出、Linux資源監控指令等。并在場景運作過程中輔以手工測試。

文章來源：網絡 版權歸原作者所有

上文内容不用于商業目的，如涉及知識産權問題，請權利人聯系小編，我們将立即處理