經常會見到新人提出這樣的效能問題：
「100使用者時，a操作響應時間達到了xx秒，請修改」
「場景執行2個小時後，系統沒有響應了」
面對這樣的問題，開發人員一定會覺得很無助，他們甚至不知道問題是什麼。
即使從測試人員的角度來看，這也算不上是乙個合格的問題。甚至是不是真正的問題，都要暫時打上問號。
那麼乙個合格的效能問題應該是什麼樣呢？
開發人員面對測試提出的問題時，第一反應很容易是「我的程式沒有問題，是你的使用不正確」，想必大多數測試人員都有過這種感受吧。手工功能測試尚是如此，更不用說效能測試了，因為效能測試的核心在於「模擬」二字，模擬大量使用者、模擬大資料量……這必然要引入很多測試工具、測試**。那麼工具使用的是否正確、**編寫是否可靠、模擬的使用者和資料是否真實，都可能直接影響到測試結果。由於測試而引入的問題，有經驗的效能測試人員一定有所經歷，一些可能會留下很深的印象。因為這種問題的後果往好了說是耗時耗力、最後證明測試不當，往壞了說可能會誤認為系統存在問題、做出了不該有的改變。
那麼如何才能證明測試過程沒有問題，有問題的是被測系統呢？簡單的說，是要把測試過程公開化，把測試的方法、測試的具體場景、測試**的實現、測試環境等等拿出來讓開發人員、業務人員等評審和確認，讓相關人理解具體的測試過程，讓大家知道你到底在做什麼。這是乙個說起來容易，實際中很難做好的工作，只有靠制訂測試過程的詳細規範才能從源頭去主動的改善這一過程。否則，靠你的嘴皮子去和開發人員理論吧。
100個使用者，是指絕對併發操作麼？還是什麼樣的場景？
是只測這乙個a操作？還是有多個操作在同時進行？
如果有多個操作，是只有這乙個操作變慢？還是普遍變慢？
測試環境是什麼樣的？測試資料量是多少？
這又回到了上面那個「測試過程公開化」的範疇了。也許開發人員理解了詳細的測試場景後，會告訴你，這個場景在業務中是不可能的，或者測試資料量是不合理的。
只是描述清晰還不夠，要明白什麼是表面現象，什麼才是問題。
問題是需要定位才能發現的。
「100個使用者操作時，a事務的響應時間過長」，這只是乙個場景的執行結果，只是乙個現象，問題是什麼呢？
響應慢是慢在哪？是中介軟體還是資料庫？這是最基本的分層定位。
是伺服器達到了硬體瓶頸麼？如果硬體或作業系統上沒有瓶頸，那麼瓶頸在哪？
是不是由於一些基本配置問題導致了排隊呢？比如中介軟體的http執行緒數和資料庫的連線數。
如果基本配置沒有問題，那麼再深入一些，是內部的哪些資源產生了爭用和等待麼？
是哪些sql引起了資料庫內部資源的爭用呢？應用程式上又是哪個方法在占用資源呢？
……定位的越深入，需要的技術能力也就越高。
比如上面的100個使用者，導致了資料庫的一張表的爭用，因此產生了大量鎖等待現象，最終導致了外部的a響應時間過長。但是通過之前的分析和定位，我們發現也許引發問題的那些sql語句，只來自100使用者中的10個特殊型別的使用者。那麼這個問題就完全可以簡化成用10個使用者去復現，其他90個使用者都是干擾。這樣問題被簡化了，開發人員也就更容易理解問題，對於測試的複測也更加方便。
不過還是要記住，最終的使用者場景模擬才是決定性的驗證。
最後再總結一下，效能問題到底應該如何提呢？其實只有乙個標準，那就是能讓開發理解問題、找到根本原因並進行修正的就夠了（假設開發人員無所不能）。再進一步深入的分析，可能是為了減輕開發的一些負擔，也可能是為了鍛鍊自己的能力，這就不是每個測試人員都會去做的了。
效能測試新手誤區（一）
系列原創 效能測試新手誤區 有過一些效能測試經驗的人很容易進入此狀態，他們已經熟悉了效能測試的基本流程，能夠比較熟練的使用測試工具開展工作。我大概從事效能測試一年左右時遇到了這個問題，那時我覺得效能測試的過程沒有太多挑戰，遇到的每乙個系統，彷彿都可以用同樣的流程完成。半天時間填寫測試方案，一天時間來...
效能測試新手誤區（六） 效能監控
資料庫 或中介軟體 非常慢了，如何監控它的效能 你想得到什麼效能指標？就是 內部的效能指標 收到效能測試人員這樣的問題後，通常會發生上面的對話。我的觀點是，準確的說出你想要做什麼，比你會不會做更重要。那麼對於效能測試人員來說，效能監控 這門必修課，該從何下手呢？如果我給你乙個黑盒子，告訴你裡面是一部...
效能測試報告模板 效能測試新手誤區
推薦閱讀 1 效能測試學習筆記 場景設計 2 效能測試的重要意義 3 效能分析流程及方法 4 應用系統效能調優之效能分析 效能測試新手誤區 效能測試新手誤區 找不到測試點，不知為何而測 有過一些效能測試經驗的人很容易進入此狀態，他們已經熟悉了效能測試的基本流程，能夠比較熟練的使用測試工具開展工作。我...