過程分析

實時分析（密切觀察（watchful waiting））

通過工具，可以發現如下信息：

1. 每個事務的響應時間，並且能夠以圖表和圖形兩種方式展現；（不僅包括完整的事務，也包括事務的任何組成部分）；
2. 能夠監控每個腳本所分配的用戶數以及測試全過程中所分配的用戶總數；（可以實時觀察用戶負載增長和事務吞吐量增長時，應用程序的反應）；
3. 監控所有負載生成器，以便能夠檢查負載生成器是否過載；
4. 需要監控與任何已經作為性能測試一部分的服務器、應用服務器以及網絡KPI所有相關數據（需要其他工具配合）；
5. 有一個能夠配置性能測試閥值的圖形界面和發生錯誤時的指示器；
6. 一個顯示測試執行過程中所發生錯誤信息的圖形界面。

測試後分析

性能測試結束後，測試工具可以存儲性能測試結果供測試後分析。

性能測試輸出的類型

統計入門

平均數和中位數

平均數及一系列數字的算術平均值。
中位數是一組數據的中間值；比如1,2,2,2,3,9————算術平均數為3.17，中位數為2。

中位數更能體現“平均數”。

標準方差和正態分佈

標準方差反映所有數據與這組數據平均值之間的平均偏離度；較高的標準方差意味著最終用戶的體驗不夠穩定；性能測試的目標應該使標準方差的值較小。

Nth百分比

統計學中的Nth百分比用於定義測試結果的採樣比例；比如：40th百分比意味著選取在40%及小於40%的一組結果。

響應時間分佈

關注響應時間的分佈，如：平均值、中位值、P90值、標準方差等。

響應時間測量

應用程序或服務器每個事務的響應時間通常是性能測試的重點關注指標。

響應時間：指的是客戶端向服務器發起請求到客戶端接收到響應所花費的時間

思考時間：所有消耗在客戶端的時間，代表最終用戶和應用程序之間交互的正常延時與停頓

性能測試工具一般都工作在中間層，也就是說工作在表現層之下。

通常衡量響應時間不應該包括思考時間，關注的是從客戶端請求到服務器完全返回響應所花費的時間（某些工具可以區分思考時間和響應時間）。

隨著負載用戶的增加，響應時間也會相應增加，但是增加幅度不一定同步。

添加事務中的“檢查點”的響應時間，有助於提高響應時間的分析粒度，並且可以將相對較差的時間與特定事務的行為進行關聯。

所有事務中的最差性能“檢查點”排序圖，有助於分析事務中突出的問題所在。

吞吐量和容量

事務吞吐量：強調對於某個事務的處理有多快。
容量：強調在某個時間段內能夠處理多少事務。

吞吐量的降低是Web服務器層或應用服務器層達到容量極限的標誌。

監控關鍵性能指標

遠程監控：Windows註冊表、基於Web的企業管理系統、簡單網絡管理協議、JMX技術、Rstatd（傳統的基於RPC的監控工具）；
客戶端需要關注：CPU 使用率、內存使用率、頁使用率、I/O（磁盤和網絡）、磁盤可用空間。

服務器關鍵性能指標

最關注的兩個指標：CPU 使用率、可用內存大小。

網絡關鍵性能指標

接收和發送字節的網絡流量。

負載生成器性能

負載生成器自己在性能測試過程中超負荷，會導致性能測試無法表現真實的行為，同時產生的結果不可信。

負載生成器需要監控的典型指標：

• CPU 使用率
• 可用內存
• 頁使用率
• I/O（磁盤和網絡）
• 磁盤可用空間

根本原因分析

在進行分析之前，調整測試數據的時間範圍，去掉加載和退出的時間，以確保測試結果的準確性。

保證分析的測試數據是一段穩定狀態。

可擴展性和響應時間

良好的可擴展性和響應時間的模型就是隨著虛擬用戶和事務吞吐量的增加，平均響應時間平穩增長，但增長值處於可接受的範圍內；反之，伴隨著虛擬用戶負載的增加，響應時間隨之增加，而且增加趨勢不平穩，或者變得不穩定，標準方差遠高於平均值。

深入挖掘

找到問題的原因，需要結合服務器和網絡KPI一起分析原因。

應用服務器內部

當一般級別應用服務器的監控不能提供更多的信息，我們需要找出具體的哪些組件的調用產生的問題。

尋找“拐點”

拐點：性能測試過程中在一定的吞吐量或一定數量的活動用戶下，性能測試圖中的一些或者說有事務的響應時間曲線有一個急劇的上升或下降趨勢。

錯誤處理

檢查所有性能測試過程中所發生的錯誤時非常重要的，因為這些錯誤可能表示應用程序的部分模塊已經達到了性能極限。

基準數據

一個成功的性能測試項目最後的輸出，將是一個基準性能數據，該基準性能數據可能在系統部署後的應用監控中用到。

分析報告檢查列表

測試前的準備工作

1. 確保您已經配置了合適的服務器、應用服務器和網絡KPI；
2. 確保您已經決定執行最後的混合性能測試；
3. 確保負載生成器可以訪問你的應用程序；
4. 假如您的性能測試工具能夠自動為性能目標設置閥值，並且把它作為性能測試體系的一部分（基於目標的性能測試場景）；
5. 性能測試工具把事務響應時間、當前虛擬用戶數、服務器和網絡KPI指標自動關聯；設置KPI閥值的標準，定義是否測試通過；
6. 如果使用第三方監控工具，在執行測試前，確保這些工具進行了正確的配置；
7. 把第三方工具輸出的數據整合到你的性能測試工具中。

測試執行過程中的工作

1. 實時檢查負載生成是否過載；
2. 確保每次的測試執行都形成文檔，保存下來：

• 性能測試執行文件的名稱，測試執行的日期和時間；
• 對測試組成部分進行一個簡要描述；
• 當前執行的測試對應的測試結果文件名；
• 與性能測試以及相關事務對應的所有輸入數據文件名稱；
• 對測試過程中所發生的任何問題的簡要記錄。

• 突發錯誤（應用程序構架某些地方已經達到了它的極限；假如你的測試是由數據驅動的，可能你的測試數據不夠使用；還有可能與特定的活動用戶數量有關；）；
• 事務吞吐量突然下降；
• 系統可用內存洩露問題；
• 來自網管的緊急電話（生產系統崩潰）。

測試完成後的工作

1. 一旦性能測試完成後，無論什麼後果，都要確保您為每次測試收集了所有相關數據（第三方監控工具特別注意）；
2. 將所有測試資源（腳本、輸入數據文件、測試結果等）備份到一個獨立的文件夾是一個好的習慣，因為你不知道什麼時候需要進行迴歸測試；
3. 編寫測試報告的時候，確保測試結果與性能目標對應，這些性能目標是在預測試的需求獲取階段設定的.

參考文檔

• 《應用程序性能測試的藝術》

閱讀更多 叨叨軟件測試 的文章

關鍵字: 性能 中位數 KPI