系列原創：性能測試新手誤區
經常會見到新人提出這樣的性能問題：
“100用戶時，A操作響應時間達到了XX秒，請修改”
“場景運行2個小時后，系統沒有響應了”
面對這樣的問題，開發人員一定會覺得很無助，他們甚至不知道問題是什么。
即使從測試人員的角度來看，這也算不上是一個合格的問題。甚至是不是真正的問題，都要暫時打上問號。
那么一個合格的性能問題應該是什么樣呢？
首先要證明這是一個問題
開發人員面對測試提出的問題時，第一反應很容易是“我的程序沒有問題，是你的使用不正確”，想必大多數測試人員都有過這種感受吧。手工功能測試尚是如此，更不用說性能測試了，因為性能測試的核心在於“模擬”二字，模擬大量用戶、模擬大數據量……這必然要引入很多測試工具、測試代碼。那么工具使用的是否正確、代碼編寫是否可靠、模擬的用戶和數據是否真實，都可能直接影響到測試結果。由於測試而引入的問題，有經驗的性能測試人員一定有所經歷，一些可能會留下很深的印象。因為這種問題的后果往好了說是耗時耗力、最后證明測試不當，往壞了說可能會誤認為系統存在問題、做出了不該有的改變。
那么如何才能證明測試過程沒有問題，有問題的是被測系統呢？簡單的說，是要把測試過程公開化，把測試的方法、測試的具體場景、測試代碼的實現、測試環境等等拿出來讓開發人員、業務人員等評審和確認，讓相關人理解具體的測試過程，讓大家知道你到底在做什么。這是一個說起來容易，實際中很難做好的工作，只有靠制訂測試過程的詳細規范才能從源頭去主動的改善這一過程。否則，靠你的嘴皮子去和開發人員理論吧。
好問題要描述清晰
100個用戶，是指絕對並發操作么？還是什么樣的場景？
是只測這一個A操作？還是有多個操作在同時進行？
如果有多個操作，是只有這一個操作變慢？還是普遍變慢？
測試環境是什么樣的？測試數據量是多少？
這又回到了上面那個“測試過程公開化”的范疇了。也許開發人員理解了詳細的測試場景后，會告訴你，這個場景在業務中是不可能的，或者測試數據量是不合理的。
好問題要有盡量深入的定位
只是描述清晰還不夠，要明白什么是表面現象，什么才是問題。
問題是需要定位才能發現的。
“100個用戶操作時，A事務的響應時間過長”，這只是一個場景的運行結果，只是一個現象，問題是什么呢？
響應慢是慢在哪？是中間件還是數據庫？這是最基本的分層定位。
是服務器達到了硬件瓶頸么？如果硬件或操作系統上沒有瓶頸，那么瓶頸在哪？
是不是由於一些基本配置問題導致了排隊呢？比如中間件的HTTP線程數和數據庫的連接數。
如果基本配置沒有問題，那么再深入一些，是內部的哪些資源產生了爭用和等待么？
是哪些SQL引起了數據庫內部資源的爭用呢？應用程序上又是哪個方法在占用資源呢？
……
定位的越深入，需要的技術能力也就越高。
好問題應該用最簡單的手段復現
比如上面的100個用戶，導致了數據庫的一張表的爭用，因此產生了大量鎖等待現象，最終導致了外部的A響應時間過長。但是通過之前的分析和定位，我們發現也許引發問題的那些SQL語句，只來自100用戶中的10個特殊類型的用戶。那么這個問題就完全可以簡化成用10個用戶去復現，其他90個用戶都是干擾。這樣問題被簡化了，開發人員也就更容易理解問題，對於測試的復測也更加方便。
不過還是要記住，最終的用戶場景模擬才是決定性的驗證。
最后再總結一下，性能問題到底應該如何提呢？其實只有一個標准，那就是能讓開發理解問題、找到根本原因並進行修正的就夠了（假設開發人員無所不能）。再進一步深入的分析，可能是為了減輕開發的一些負擔，也可能是為了鍛煉自己的能力，這就不是每個測試人員都會去做的了。