性能測試新手誤區（一）：找不到測試點，不知為何而測
性能測試新手誤區（二）：為什么我模擬的百萬測試數據是無效的？
性能測試新手誤區（三）：用戶數與壓力
性能測試新手誤區（四）：一切來自錄制
經常會見到新人提出這樣的性能問題：
“100用戶時，A操作響應時間達到了XX秒，請修改。”
面對這樣的問題，開發人員一定會覺得很無助，他們甚至不知道問題是什么。
即使從測試人員的角度來看，這也算不上是一個合格的問題。
那么一個好的性能問題應該是什么樣呢？
好問題要描述清晰
100個用戶，是指絕對并發操作么？還是什么樣的場景？
是只測這一個A操作？還是有多個操作在同時進行？
如果有多個操作，是只有這一個操作變慢？還是普遍變慢？
測試環境是什么樣的？測試數據量是多少？
也許開發人員理解了詳細的測試場景后，會告訴你，這個場景在業務中是不可能的，或者測試數據量是不合理的。
好問題要有盡量準確的定位
只是描述清晰還不夠，要明白什么是表面現象，什么才是問題。
問題是需要定位才能發現的。
“100個用戶操作時，A事務的響應時間過長”，這只是一個現象，問題是什么呢？
響應慢是慢在哪？是中間件還是數據庫？這是最基本的分層定位。
是服務器達到了硬件瓶頸么？如果硬件或操作系統上沒有瓶頸，那么瓶頸在哪？
是不是由于一些基本配置問題導致了排隊呢？比如中間件的HTTP線程數和數據庫的連接數。
如果基本配置沒有問題，那么再深入一些，是內部的哪些資源產生了爭用和等待么？
是哪些SQL引起了數據庫內部資源的爭用呢？應用程序上又是哪個方法在占用資源呢？
……
定位的越深入，需要的技術能力也就越高。
好問題應該用最簡單的手段復現
比如上面的100個用戶，導致了數據庫的一張表的爭用，因此產生了大量鎖等待現象，最終導致了外部的A響應時間過長。但是通過之前的分析和定位，我們發現也許引發問題的那些SQL語句，只來自100用戶中的10個特殊類型的用戶。那么這個問題就完全可以簡化成用10個用戶去復現，其他90個用戶都是干擾。這樣問題被簡化了，開發人員也就更容易理解問題，對于測試的復測也更加方便。
不過還是要記住，最終的用戶場景模擬才是決定性的驗證。
最后再總結一下，性能問題到底應該如何提呢？其實只有一個標準，那就是能讓開發理解問題、找到根本原因并進行修正的就夠了（假設開發人員無所不能）。再進一步深入的分析，可能是為了減輕開發的一些負擔，也可能是為了鍛煉自己的能力，這就不是每個測試人員都會去做的了。