服務器性能測試功能詳解

併發測試

併發測試方法經過模擬用戶併發訪問，測試多用戶併發訪問同一個應用、同一個模塊或者數據記錄時是否存在隱藏的併發問題，如內存泄漏、線程鎖、資源爭用問題。

特色：

•主要目的是發現系統中可能隱藏的併發訪問時的問題
•主要關注系統可能存在的併發問題，例如系統中的內存泄漏、線程鎖和資源爭用方面的問題。
•這種性能測試方法能夠在開發的各個階段使用須要相關的測試工具的配合和支持
•也就是說，這種測試關注點是多個用戶同時（併發）對一個模塊或操做進行加壓。

場景測試

場景測試就是基於場景的軟件測試。

什麼是場景？

場景就是假設的故事，用來幫助人們理解一個複雜的問題或者系統。

一個完美的場景測試有幾個特徵：

1. 基於一個用戶怎麼使用軟件的故事，包括用戶的動機
2. 故事具備感染力，有影響力的干係人會促使這個場景測試失敗的程序獲得修復
3. 故事要可信，不只在真實的世界中可能發生，並且將極可能發生。
4. 故事包含對軟件的複雜的使用，或者複雜的環境或者一套複雜的數據
5. 測試結果容易評估

爲何使用場景測試？

1. 學習產品
2. 將需求文檔和測試聯繫起來
3. 暴露產品卻吸納
4. 探索程序的專業用法
5. 將需求相關的問題引出到檯面上

建立好場景的12個方法建立好場景的12個方法：

1. 寫出系統中對象的生命歷程。
2. 列出可能的用戶，分析他們的興趣和目標
3. 考慮惡意用戶，他們可能怎麼攻擊你的程序
4. 列出系統事件，系統怎麼處理這些事件？
5. 列出特殊事件，系統怎麼容納這些事件？
6. 列出收益並建立端到端的任務來檢查他們。
7. 與用戶面談，找出老系統中他們最不滿意的地方。
8. 與用戶一塊兒工做，觀察他們怎麼工做，作什麼。
9. 閱讀相似的系統會作什麼。
10. 研究對這個系統之前版本和競爭對手的抱怨。
11. 建立一個模擬業務，認真對待這個模擬業務並處理相關的數據。。
12. 試着把競爭對手和之前版本的真實數據轉換到新的系統。

場景測試的風險

1. 在早期，不穩定的代碼上，場景測試的效果不如其餘方式，由於場景測試比較複雜，包含許多特性，一旦第一個特性出錯，就會阻礙其餘特性的測試。
2. 場景測試不是爲了所有覆蓋整個程序。
3. 場景測試常常發現的是設計問題，而不是代碼問題，代碼問題更適合由其餘的測試來發現。

負載測試

經過測試系統在資源超負荷狀況下的表現，以發現設計上的錯誤或驗證系統的負載能力。

特色：

•主要目的是找到系統中所存在的性能問題
•須要在給定的測試環境下進行，一般也須要考慮被測試系統的業務壓力和典型場景、使得測試結果具備業務上的意義。
•通常用來了解系統的性能容量，或是配合性能調優來使用。

接口測試

接口測試是測試系統組件間接口的一種測試。

接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。

接口測試通常會用於多系統間交互開發，或者擁有多個子系統的應用系統開發的測試。接口測試適用於爲其餘系統提供服務的底層框架系統和中心服務系統，主要測試這些系統對外部提供的接口，驗證其正確性和穩定性。接口測試一樣適用於一個上層系統中的服務層接口，越往上層，其測試的難度越大。接口測試在淘寶的應用是一個自下而上的發展過程。

接口測試實施在多系統多平臺的構架下，有着極爲高效的成本收益比，接口測試天生爲搞複雜性的平臺帶來高效的缺陷監測和質量監督能力。平臺越複雜，系統越龐大，接口測試的效果越明顯。

接口測試的目的是測試接口，尤爲是那些與系統相關聯的外部接口，測試的重點是要檢查數據的交換，傳遞和控制管理過程，還包括處理的次數。外部接口測試通常是做爲系統測試來看待的。

容量測試

經過性能測試，若是找到了系統的極限或苛刻的環境中系統的性能表現，在必定的程度上，就完成了負載測試和容量測試。

容量能夠看做系統性能指標中一個特定環境下的一個特定性能指標，即設定的界限或極限值。

容量測試的目的是經過測試預先分析出反映軟件系統應用特徵的某項指標的極限值（如最大併發用戶數、數據庫記錄數等），系統在其極限狀態下沒有出現任何軟件故障或還能保持主要功能正常運行。容量測試還將肯定測試對象在給定時間內可以持續處理的最大負載或工做量。

軟件容量的測試能讓軟件開發商或用戶瞭解該軟件系統的承載能力或提供服務的能力，如某個電子商務網站所能承受的、同時進行交易或結算的在線用戶數。知道了系統的實際容量，如是不能知足設計要求，就應該尋求新的技術解決方案，以提升系統的容量。有了對軟件負載的準確預測，不只能對軟件系統在實際使用中的性能情況充滿信心，同時也能夠幫助用戶經濟地規劃應用系統，優化系統的部署。

性能調優

指爲軟件提供較佳的性能，用於處理系統響應速度太慢等。

現象

通常觀測性能問題的現象有：
• Ÿ 系統響應速度太慢。
• Ÿ 每秒所完成的系統輸出/入低於預期。
• Ÿ 相同的環境，但每秒鐘所完成的批操做較先前少。
• Ÿ 系統資源（如CPU、內存、硬盤或網絡等）長時間處於耗盡的狀態。

性能調優，首先是要肯定性能調優的目標是什麼，定義性能目標一般有這樣幾個指標：

一、最大併發數

二、Quality of Service 服務的質量，在軟件系統方面咱們認爲主要表如今請求的出錯率，系統的load等。

三、最長響應時間 對於任何請求所能承受的最大響應時間。

四、TPS 每秒須要支持的最大事務數，最典型的指標是：「某頁面最高須要支撐每秒7000次的訪問次數」。
例如一個web系統，須要定義出來的目標是：
併發目標：最高支撐200併發；
QoS：出錯率須控制在萬分之一，系統的load最高只能到達10；
TPS：每秒完成7000次請求的處理；
最大響應時間：最長容許的響應時間爲5秒。
至於請求的平均響應時間這些就不在性能調優目標中定義，由於要達到TPS的要求，響應時間是必需要達到一個級別的，並且響應時間隨着高併發是會出現劣化的。
也能夠把性能指標定到更爲細節，例如某個方法的TPS在100併發時須要達到多少。

嘗試列出系統中各個組件合理的性能消耗，能夠幫助你理清整個系統訪問中，各個組件所佔的性能消耗比例，哪些部分有能夠調整的空間。另外，再搭配調整該部分的成本有多高，讓你瞭解調整的優先級，並對系統的極限有更佳的認識。

可靠性測試（穩定性測試）

在給系統加載必定業務壓力的狀況下，使系統運行一段時間，以此檢測系統是否穩定。

特色：

•這種性能測試方法的主要目的是驗證是否支持長期穩定的運行。
•這種性能測試方法須要在壓力下持續一段時間的運行。（2~3天）
•測試過程當中須要關注系統的運行情況。
•也就是說，這種測試的關注點是「穩定」，不須要給系統太大的壓力，只要系統可以長期處於一個穩定的狀態。

壓力測試（強度測試）

l模擬實際應用的軟硬件環境及用戶使用過程的系統負荷，長時間或超大負荷地運行測試軟件，來測試被測系統的性能、可靠性、穩定性等。

特色：

•主要目的是檢查系統處於壓力性能下時，應用的表現。•通常經過模擬負載等方法，使得系統的資源使用達到較高的水平。•通常用於測試系統的穩定性。•讓系統處在很大強度的壓力之下，看系統是否穩定，哪裏會出問題。