第一步：從分析Summary的事務執行情況入手
Summary主要是判定事務的響應時間與執行情況是否合理。如果發現問題，則需要做進一步分
析。通常情況下，如果事務執行情況失敗或響應時間過長等，都需要做深入分析。
下面是查看分析概要時的一些原則：
（1）：用戶是否全部運行，最大運行併發用戶數（Maximum Running Vusers）是否與場景設計的最大運行併發用戶數一致。如果沒有，則需要打開與虛擬用戶相關的分析圖，進一步分析虛擬用戶不能正常運行的詳細原因；
（2）：事務的平均響應時間、90%事務最大響應時間用戶是否可以接受。如果事務響應時間過長，則要打開與事務相關的各類分析圖，深入地分析事務的執行情況；
（3）：查看事務是否全部通過。如果有事務失敗，則需要深入分析原因。很多時候，事務不能正常執行意味着系統出現了瓶頸；
（4）：如果一切正常，則本次測試沒有必要進行深入分析，可以進行加大壓力測試；
（5）：如果事務失敗過多，則應該降低壓力繼續進行測試，使結果分析更容易進行；
......
上面這些原則都是分析Summary的一些常見方法，大家應該靈活使用並不斷地進行總結與完善，尤其要主要結合實際情況，不能墨守成規。
查看分析概要後，接下來要查看負載生成器和待測服務器的系統資源使用情況：查看CPU的利用率和內存使用情況，尤其要注意查看是否存在內存泄露問題。這樣做是由於很多時候系統出現瓶頸的直接表現是CPU利用率過高或內存不足。應高保證負載生成器在整個測試過程中其CPU、內存、帶寬沒有出現瓶頸，否則測試結果無效。而待測試服務器，則重點分析測試過程中CPU和內存是否出現了瓶頸：CPU需要查看其利用率是否經常達到100%或平均利用率一直高居95%以上；內存需要查看是否夠用以及測試過程是否存在溢出現象（對於一些中間件服務器要查看其分配的內存是否夠用）。
第三步：查看虛擬用戶與事務的詳細執行情況。
在前兩步確定了測試場景的執行情況基本正常後，接下來就要查看虛擬用戶與事務的執行情況。對於虛擬用戶，主要查看在整個測試過程中是否運行正常，如果有較多用戶不能正常運行，則需要重新設計場景或調整用戶加載與退出方式再次進行測試。對於事務，重點關注整個過程的事務響應時間是否逐漸變長以及是否存在不能正常執行的事務。總之，對每個用戶或事務的執行細節都應該認真分析不可輕易忽略；
example1：一個性能逐步下降的服務器，需要進一步分析其性能下降的原因【可以查找是否存在內存泄露問題】；
example2：一個性能相對穩定的服務器，但是響應時間偏大，這時需要分析程序算法是否存在缺陷或服務器參數的配置是否合理。
第四步：查看錯誤發生情況。
整個測試過程中錯誤的發生情況也應該是分析的重點。下面是查看錯誤發生情況的常用準則：
（1）查看錯誤發生曲線在整個測試過程中是否是有規律變化的，如果有規律通常意味着程序在併發處理方面存在一定的缺陷。圖5-9所示的每秒缺陷數量曲線十分有規律，這是因爲服務器定期生成緩存文件導致用戶不能正常訪問而產生的錯誤；
（2）查看錯誤分類統計，作爲優化系統的參考。例如對於Web性能測試，當出現瓶頸時往往需要查看服務器的錯誤統計信息結果：如果“超時錯誤”佔到90％以上，可能需要提高硬件配置；如果較多的“內部服務器錯誤”，則可能是程序方面存在問題。
第五步：查看Web資源與細分網頁。
本步驟僅適用於Web性能測試。查看Web資源圖時，往往結合前面對虛擬用戶以及事務響應時間的分析結果，重點分析服務器的穩定性。對於網頁細分功能則遵循如下原則：首先分析從用戶發出請求到收到第一個緩衝爲止，哪些環節比較耗時；其次找出頁面哪些組成部分對用戶響應時間影響較大；當對頁面的性能問題定位後，就可以採取相關的解決方案。