我遇到很多客戶做過壓力測試 ? 有大規(guī)模的，也有小規(guī)模的 ? 有用開源工具的，也有用商業(yè)軟件的。 壓力測試本身變得越來越容易，越來越可以支付的起??因為出現(xiàn)了很多很好用的壓力測試工具。還有一些公司提供在線壓力測試服務。盡管做壓力測試越來越容易、越來越有效率、而能花很小的代價產生很大的壓強，但是我的所有客戶都遇到了同樣一個問題：壓力測試并不會報告是什么導致了問題。它只會報告這有了問題，例如：查詢頁面在并發(fā)50個用戶使用時變慢下來，但它不會顯示什么導致了變慢。捕獲到的性能統(tǒng)計數(shù)據(jù)例如CPU和內存使用量只是強調了潛在的問題區(qū)域，但并不會指出實際的根源在應用程序的什么地方。

　　標準的壓力測試報告只提供黑盒視圖（Black-Box View）

　　當分析下面的壓力測試報告時我們只能發(fā)現(xiàn)在我們的應用程序的壓力達到某個“點擊數(shù)/秒”臨界點時問題出現(xiàn)了。

　　壓力測試結果

　　我們會發(fā)現(xiàn)服務器的CPU很可能跟問題有關，因為它的使用率隨著我們產生壓強的增多迅速升高，但我們停下來分析問題時，它的使用率也下來了。如果你把這個報告呈給你們的工程師，他們很可能會驚訝他們的應用程序為什么如此的不經壓，但他們也沒法告訴你是否是應用程序出了什么問題（以及問題在哪）或者是當前版本的應用程序根本承受不起這么大的壓力。

　　過多的測試迭代在拖累我們

　　所以可以看出來，我們從壓力測試工具上獲得的標準測試報告并不能幫助我們分析出問題的根源在哪里。那通常我們是怎么終找出問題的呢？下面的圖例顯示的是我從我的客戶那里看到的典型的測試周期。

　　需要反復迭代測試才能定位產生效能問題的根源

　　每次測試之后他們都和工程師一起坐下來討論測試的結果。工程師們試圖重現(xiàn)報告中被重點顯示的問題。通常這些問題只有在有相當壓力的情況下才會出現(xiàn)，根本沒法在工程師的本地安裝了debugger工具或profiling工具的機器上重現(xiàn)？尚械霓k法是要改進在測試中捕獲到的各種數(shù)據(jù)詳細程度。對捕捉信息的改進可以包括收集額外的有用的性能數(shù)據(jù)，例如CPU，內存，I/O，內存回收事件，數(shù)據(jù)庫統(tǒng)計，… 報告應用程序特殊數(shù)據(jù)，例如n號訂單被處理了，處理隊列的長度，處于活動狀態(tài)的用戶會話的數(shù)量，… 或者擴展應用程序輸出的日志，讓它跟蹤記錄性能信息，例如函數(shù)的調用次數(shù)，執(zhí)行了哪些SQL語句，…

　　當改進完成了之后，測試會再進行一次。如果你很幸運，你會在第一次改進后獲得你想要的數(shù)據(jù)結果。但據(jù)我所觀察的結果是通常要好幾輪改進之后你才能得到能夠讓你分析出問題出在哪里并且能夠用來修正程序的報告信息。這些額外的測試迭代會耗費測試者以及開發(fā)人員的大量時間。如果你有獨立的測試團隊或者你外包了測試，那你或需要額外的開銷來應付這些迭代測試。

　　目標：花少的時間做更多的測試

　　理想的目標是去除所有的額外開銷，現(xiàn)狀來講包括在壓力測試中改進和分析捕獲到的數(shù)據(jù)的工作量。美國Novell公司有一個精彩的例子來展示在他們的分布式敏捷開發(fā)團隊里改進壓力測試過程的。你可以在公布的學習案例中了解更詳細的信息。

　　測試中的應用性能管理 可以讓你去使壓力測試的功效發(fā)揮到。下圖展示了一個真實的壓力測試過程是怎樣的：

　　通過應用性能管理避免測試迭代

　　Yes we can！ 讓壓力測試充分發(fā)揮其能力

　　這篇博客只是簡單的談到了我在客戶哪里遇到的問題的皮毛 ? 請查看Case Study we did with Novell，其中講到了Novell公司如何讓他們的測試吞吐量提高2-3倍的。過多的測試迭代和對應用的黑盒測試視圖妨礙了我們讓壓力測試發(fā)揮更大的功效，應用性能管理可以幫助我們使這個過程更高效。有興趣的話你可以下載完整版的How to Transform the Load Testing Process，它里面討論了更詳細的我們所說的問題，同時向我們展示了如何花少的時間做更多的測試。關鍵的要素是讓我們對應用程序內部可視化，能夠自動的捕捉數(shù)據(jù)和分析數(shù)據(jù)。