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

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

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

壓力測試結果

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

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

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

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

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

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

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

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

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

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

　　Yes we can!讓壓力測試充分發揮其能力

　　這篇博客只是簡單的談到了我在客戶哪里遇到的問題的皮毛–請查看 Case Studywe did with Novell ，其中講到了Novell公司如何讓他們的測試吞吐量提高2-3倍的。過多的測試迭代和對應用的黑盒測試視圖妨礙了我們讓壓力測試發揮更大的功效，應用性能管理可以幫助我們使這個過程更高效。

　　有興趣的話你可以下載完整版的How to Transform the Load Testing Process ，它里面討論了更詳細的我們所說的問題，同時向我們展示了如何花最少的時間做更多的測試。關鍵的要素就是讓我們對應用程序內部可視化，能夠自動的捕捉數據和分析數據。