分析壓力測試結果
這步同樣是壓力測試中很難的一步，在這一步需要做出的根據壓力測試的結果分析出系統的具體表現情況，判定系統是否能夠滿足壓力指標。
以loadrunner產生的分析結果圖而言，通常需要分析以下圖：
1、Total Transactions per Second
這張圖中顯示了系統在進行壓力測試過程的TPS的變化情況，從這張圖中我們可以看到系統的TPS的情況，通常來講，隨著用戶數的增加，TPS應該是呈一定比率的增長的，等增長到一定程度后會達到瓶頸，甚至開始下降，這也是TPS的瓶頸值了，這張圖可以幫助我們評估系統的TPS是否符合要求。
另外，在這張圖中，我們可以看到系統從什么時候開始出現出錯的transactions，從而判斷出錯率是否在可接受的范圍。
2、Transaction Response Time Under Load
這張圖非常的重要，借助這張圖我們可以分析隨著用戶數增加的情況下，系統的劣化狀況，最佳狀況當然是一條直線，但這基本是不可能的，畢竟資源是有限的，需要判斷的是劣化的程度是否為可接受范疇。
另外就是需要關注數據中90%的用戶的響應時間的狀況，如果少量用戶響應慢是可接受的話，那么有可能在之上指標不達標的情況下仍然滿足了壓力指標。
3、Unix Resources
這張系統load圖自然是非常的重要，借助這張圖大致可以判斷系統隨著用戶數的增長消耗的資源的變化情況，這對于調優以及容量規劃而言是很重要的，但還是得取決于應用本身，:)。
loadrunner還提供了其他方面很多的圖，可以根據考評的要求來自行進行分析。
尋找瓶頸并進行調優以達到目標
這步不屬于壓力測試范疇，但還是在這里稍微講講，畢竟壓力測試結束后如果系統沒達標的話就必須進行這步了。
尋找瓶頸，這自然是非常難的事了，通常系統達不到要求的狀況都會是隨著用戶的增長，響應時間劣化的過于厲害，在這樣的情況下首先得觀察系統硬件資源的變化情況，如果是硬件資源耗盡的話，需要查查為什么資源被耗盡，假設最后判斷確實需要耗費這么多的硬件資源的話，也許需要考慮增加硬件資源或是水平擴展，否則的話可能需要從軟件層面相應的優化系統了，這樣的話可以進入下一步了。
如果不是硬件資源的限制的話，得在系統中從頭到尾設置時間跟蹤filter，從而判斷響應時間劣化的原因，看看是系統中哪些步驟造成的，這個是細致活了，有可能要查非常久。
其實這里說的還是相當的簡單了，在尋找瓶頸的過程中是個非常繁瑣的過程，需要不斷的嘗試，硬件的增加、OS的調優、jvm的調優以及軟件系統本身的調優等等，這些很多時候需要的是經驗，因此某知名人士曾經說過如何尋找瓶頸和調優，其中依靠的一點就是直覺，^_^。
當然，在尋找瓶頸的過程中，可以借助os的工具、java的工具（例如gc打印、jprofiler等）來進行查找。（ps: 不過感覺很多情況下都是應用本身造成的性能瓶頸，在寫程序時稍不注意用錯一個數據結構都有可能會導致比較大的問題，所以我現在查找瓶頸的時候更多的還是先從軟件本身下手，只是軟件性能要做到提升通常來付出較大的代價，這個時候需要權衡）
調優基本上要求對硬件、OS、JDK、數據庫甚至軟件的實現方式等都要有非常深入的理解，至少要能做到判斷出瓶頸因素，然后找相應領域的專家來解決，因此要求是非常高的。
關于性能調優的知識體系這里有篇不錯的文章：www.cnblogs.com/jackei/archive/2008/06/27/1231307.html
話題太大了，寫到最后發現基本上還是有些泛泛而談了，后面會針對這里的每一步來做更為細致的實例的講述吧，不過畢竟是外行人，肯定有很多不對的地方，歡迎大家指正、拍磚。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
