伺服器穩定性是最重要的，如果在穩定性方面不能夠保證業務執行的需要，再高的效能也是無用的。正規的伺服器廠商都會對產品進行不同溫度和溼度下的執行穩定性測試。重點要考慮的是冗餘功能，如：資料冗餘、網路卡冗餘、電源冗餘、風扇冗餘等。

一些伺服器穩定性測試方法主要為以下幾種：

壓力測試：

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

Ramp Up 增量設計：

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

Ramp Up增量設計目標：

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

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

穩定性測試：

已知系統高峰期使用人數、各事務操作頻率等。設計綜合測試場景，測試時將每個場景按照一定人數比例一起執行，模擬使用者使用數年的情況。並監控在測試中，系統各效能指標在這種壓力下是否能保持正常數值。事務響應時間是否會出現波動或隨測試時間增長而增加。系統是否會在測試期間內發生如當機、應用中止等異常情況。

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

還可以對伺服器進行以下方式測試，驗證伺服器在各種特殊情況下是否有自動處理機制：

1、容錯性測試

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

2、問題排除性測試

透過原有案例或經驗判斷，針對系統中曾經發生問題或懷疑存在隱患的模組進行驗證測試，驗證這些模組是否還會發生同樣的效能問題。如：上傳附件模組的記憶體洩露問題、地址本模組最佳化、開啟Tivoli效能監控對OA系統效能的影響等等。

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

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

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

評測系統最大併發使用者數：為獲取整個系統所能夠承受的最大併發使用者數而進行的的測試活動。透過預先分析專案各主要模組的使用比率和頻率，定義各事務在綜合場景中所佔的比例，以比例方式分配各事務併發使用者數。模擬真實環境或直接採用真實環境，評測在這種環境下系統所能承受的最大併發使用者數。判定標準閥值預先定義(如響應間，CPU佔用率，記憶體佔用率，已出現點選率峰值，已出現吞吐量峰值等)。取值標準以木桶法則為準(併發數最小的事務為整個系統的併發數)。

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

透過以上測試或使用者實際操作已經發現系統中的效能問題或懷疑已存在效能問題，需透過響應的測試場景重現問題或定義問題。如有可能，可以直接找出引起效能問題所在的程式碼或模組。該類測試主要還是透過測試出問題的指令碼場景，並可以增加發現和檢測的工具，如開啟Tivoli效能監控、開啟HeapDump輸出、Linux資源監控命令等，並在場景執行過程中輔以手工測試。

軟體測試中伺服器穩定性測試幾種方法