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