性能測試新手誤區（五）：如何提出一個好的性能問題

　　經常會見到新人提出這樣的性能問題：

　　“100使用者時，a操作響應時間達到了xx秒，請修改。”

　　面對這樣的問題，開發人員一定會覺得很無助，他們甚至不知道問題是什麼。

　　即使從測試人員的角度來看，這也算不上是一個合格的問題。

　　那麼一個好的性能問題應該是什麼樣呢？

　　好問題要描述清晰

　　100個使用者，是指絕對并發操作麼？還是什麼樣的場景？

　　是隻測這一個a操作？還是有多個操作在同時進行？

　　如果有多個操作，是隻有這一個操作變慢？還是普遍變慢？

　　測試環境是什麼樣的？測試資料量是多少？

　　也許開發人員了解了詳細的測試場景後，會告訴你，這個場景在業務中是不可能的，或者測試資料量是不合理的。

　　好問題要有盡量準确的定位

　　隻是描述清晰還不夠，要明白什麼是表面現象，什麼才是問題。

　　問題是需要定位才能發現的。

　　“100個使用者操作時，a事務的響應時間過長”，這隻是一個現象，問題是什麼呢？

　　是不是由于一些基本配置問題導緻了排隊呢？比如中間件的http線程數和資料庫的連接配接數。

　　如果基本配置沒有問題，那麼再深入一些，是内部的哪些資源産生了争用和等待麼？

　　……

　　定位的越深入，需要的技術能力也就越高。

　　好問題應該用最簡單的手段複現

　　比如上面的100個使用者，導緻了資料庫的一張表的争用，是以産生了大量鎖等待現象，最終導緻了外部的a響應時間過長。但是通過之前的分析和定位，我們發現也許引發問題的那些sql語句，隻來自100使用者中的10個特殊類型的使用者。那麼這個問題就完全可以簡化成用10個使用者去複現，其他90個使用者都是幹擾。這樣問題被簡化了，開發人員也就更容易了解問題，對于測試的複測也更加友善。

　　不過還是要記住，最終的使用者場景模拟才是決定性的驗證。

　　最後再總結一下，性能問題到底應該如何提呢？其實隻有一個标準，那就是能讓開發了解問題、找到根本原因并進行修正的就夠了（假設開發人員無所不能）。再進一步深入的分析，可能是為了減輕開發的一些負擔，也可能是為了鍛煉自己的能力，這就不是每個測試人員都會去做的了。

====================================分割線================================

最新内容請見作者的github頁：http://qaseven.github.io/