為什麼壓力測試會耗費我們如此多的時間
我遇到很多客戶做過壓力測試 – 有大規模的，也有小規模的 – 有用開源工具的，也有用商業軟體的。 壓力測試本身變得越來越容易，越來越可以支付的起——因為出現了很多很好用的壓力測試工具。還有一些公司提供線上壓力測試服務。儘管做壓力測試越來越容 易、越來越有效率、而能花很小的代價產生很大的壓強，但是我的所有客戶都遇到了同樣一個問題：壓力測試並不會報告是什麼導致了問題。它只會報告這有了問 題，例如：查詢頁面在併發50個使用者使用時變慢下來，但它不會顯示什麼導致了變慢。捕獲到的效能統計資料例如CPU和記憶體使用量只是強調了潛在的問題區 域，但並不會指出實際的根源在應用程式的什麼地方。
標準的壓力測試報告只提供黑盒檢視（Black-Box View）
當分析下面的壓力測試報告時我們只能發現在我們的應用程式的壓力達到某個“點選數/秒”臨界點時問題出現了。
壓力測試結果
我們會發現伺服器的CPU很可能跟問題有關，因為它的使用率隨著我們產生壓強的增多迅速升高，但我們停下來分析問題時，它的使用率也下來了。如果你 把這個報告呈給你們的工程師，他們很可能會驚訝他們的應用程式為什麼如此的不經壓，但他們也沒法告訴你是否是應用程式出了什麼問題（以及問題在哪）或者是 當前版本的應用程式根本就承受不起這麼大的壓力。
過多的測試迭代在拖累我們
所以可以看出來，我們從壓力測試工具上獲得的標準測試報告並不能幫助我們分析出問題的根源在哪裡。那通常我們是怎麼最終找出問題的呢？下面的圖例顯示的就是我從我的客戶那裡看到的典型的測試周期。
需要反覆迭代測試才能定位產生效能問題的根源
每次測試之後他們都和工程師一起坐下來討論測試的結果。工程師們試圖重現報告中被重點顯示的問題。通常這些問題只有在有相當壓力的情況下才會出現， 根本就沒法在工程師的本地安裝了debugger工具或profiling工具的機器上重現。可行的辦法就是要改進在測試中捕獲到的各種資料詳細程度。對 捕捉資訊的改進可以包括收集額外的有用的效能資料，例如CPU，記憶體，I/O，記憶體回收事件，資料庫統計，… 報告應用程式特殊資料，例如n號訂單被處理了，處理佇列的長度，處於活動狀態的使用者會話的數量，… 或者擴充套件應用程式輸出的日誌，讓它跟蹤記錄效能資訊，例如函式的呼叫次數，執行了哪些SQL語句，…
當改進完成了之後，測試會再進行一次。如果你很幸運，你會在第一次改進後獲得你想要的資料結果。但據我所觀察的結果是通常要好幾輪改進之後你才能得 到能夠讓你分析出問題出在哪裡並且能夠用來修正程式的報告資訊。這些額外的測試迭代會耗費測試者以及開發人員的大量時間。如果你有獨立的測試團隊或者你外 包了測試，那你或需要額外的開銷來應付這些迭代測試。
目標：花最少的時間做更多的測試
理想的目標是去除所有的額外開銷，就現狀來講包括在壓力測試中改進和分析捕獲到的資料的工作量。美國Novell公司就有一個精彩的例子來展示在他們的分散式敏捷開發團隊裡改進壓力測試過程的。你可以在公佈的學習案例中瞭解更詳細的資訊。
測試中的應用效能管理 可以讓你去使壓力測試的功效發揮到極致。下圖展示了一個真實的壓力測試過程是怎樣的：
通過應用效能管理避免測試迭代
Yes we can! 讓壓力測試充分發揮其能力
.這篇部落格只是簡單的談到了我在客戶哪裡遇到的問題的皮毛 – 請檢視 Case Study we did with Novell ，其中講到了Novell公司如何讓他們的測試吞吐量提高2-3倍的。過多的測試迭代和對應用的黑盒測試檢視妨礙了我們讓壓力測試發揮更大的功效，應用效能管理可以幫助我們使這個過程更高效。有興趣的話你可以下載完整版的How to Transform the Load Testing Process ，它裡面討論了更詳細的我們所說的問題，同時向我們展示瞭如何花最少的時間做更多的測試。關鍵的要素就是讓我們對應用程式內部視覺化，能夠自動的捕捉資料和分析資料。
.歡迎您對這個問題的反饋。(外刊IT評論 )
:)