系列原創：效能測試新手誤區假設有這樣乙個小論壇，效能測試人員得到的需求是「支援併發50人，響應時間要在3秒以內」，效能測試人員a和b同時開始進行效能測試（各做各的）。
只考慮發帖這個操作，a設計的測試場景是50人併發發帖，得到的測試結果是平均完成時間是5秒。於是他提出了這個問題，認為系統沒有達到效能期望，需要開發人員進行優化。
兩個人得到了不同的測試結果，完全相反的測試結論，誰做錯了？
或許這個例子太極端，絕對併發和平均分布的訪問壓力當然是截然不同的，那我們再來看個更真實的例子。
a認為，每個使用者的操作，一般間隔30s比較合適，於是他在指令碼中的每兩個事務之間加上了30秒的等待（思考時間）。
b想了想自己看論壇時的情景，好像平均每次滑鼠點選要間隔1分鐘，於是他在指令碼中的每兩個事務之間加上了1分鐘的等待。
他們都認為自己的測試場景比較接近實際情況，可惜測試結果又是不同的，很顯然a場景的壓力是b的兩倍。那誰錯了呢？或者有人說是需求不明確導致的，那麼你需要什麼樣的需求呢？
看看我隨手在網上（51testing）找的提問吧，和上面的內容如出一轍。一定有很多的效能測試人員每天接到的就是這種需求，又這樣就開展了測試，結果可想而知。
這裡我想問幾個問題，希望各位看完了上面的小例子後想一想：
如果有另乙個人和你測同樣的系統，你們的測試結果會一致麼？
如果不一致，那麼誰是正確的？
如何證明測試結果是有效的？
效能測試中非常重要的一塊內容就是模擬預期的壓力，測試系統執行在此壓力下，使用者的體驗是什麼樣的。
那麼壓力是什麼？壓力是伺服器在不斷的處理事情、甚至是同時處理很多事情。壓力是伺服器直接處理的「事情」，而不是遠在網路另一端的使用者。
下圖中，每乙個顏色的線段代表一種操作。在任意乙個時刻，伺服器都知道它有10個事務需要處理，這10個事務也是有10個使用者產生的。但它不知道的是，整個時間段內的所有事務，是由多少個使用者與系統互動而產生的。
這句話好像有點繞，我再試著更形象的解釋一下。時刻1，10個當前事務是由10個使用者發起的。時刻2，依然是10個正在進行的事務，但可能是完全不同的10個人發起的。在這段時間內，伺服器每乙個時刻都在處理10個事務，但是參與了這個互動過程（對伺服器產生壓力）的人可能會達到上百個，也可能只有最開始的10個。
那麼，對於伺服器來說，壓力是什麼呢？顯然只是每時刻這10個同時處理的事務，而到底是有10個人還是1000個人，區別不大（暫不考慮session等問題）。
下面再從使用者的視角來看看。實際的情況中，不可能出現很多使用者同一時刻開始進行操作的場景，而是有一定的時間順序的。正如下圖所示，在這個時間段內，一共有23個使用者進行了操作。
但是伺服器能看到這些使用者麼？它知道的只是某乙個時間點上，有多少個正在執行的事務。大家可以數一下，此圖中任意時刻的併發事務依然是10個。
其實這兩個圖描述的本來就是同乙個場景，只不過觀察者的視角不同罷了。
那麼大家想想，在效能需求中最常見到的「併發使用者」到底是指的什麼呢？
再回到相對併發這個概念上來，它與伺服器的壓力到底是什麼關係呢？如果你理解了前面的所有內容，那麼就會知道這兩者其實沒有直接聯絡（當然了，同乙個測試用例中，肯定是使用者數越多壓力越大）。也就是說，你得到的這種效能需求，是無法知道伺服器到底要承受多大壓力的。
那麼如何開展效能測試？
既然我們知道了所謂的壓力其實是從伺服器視角來講的，伺服器要處理的事務才是壓力，那麼我們就從這出發，來探尋一下效能測試需要的資訊。依然用之前的小論壇為例，我們需要測試活躍使用者為500人時，系統的效能是否能還能提供良好的使用者感受。
假設現在的活躍使用者有50個人（或者通過另乙個類似的系統來推算也行），平均每天總的發帖量是50條、瀏覽帖子500次，也就是每人每天發乙個帖子、瀏覽十個帖子（為了方便講解，假設論壇只有這兩個基本功能）。那麼我們就可以推算，活躍使用者達到500時，每天的業務量也會成比例的增長，也就是平均每天會產生500個新帖子、瀏覽帖子5000次。
進一步分析資料，又發現。使用者使用論壇的時間段非常集中，基本集中在中午11點到1點和晚上18點到20點。也就是說每天的這些業務，實際是分布在4個小時中完成的，如下圖（隨便找了個圖意思一下，數不一致）。
那我們的測試場景，就是要用500個使用者在4小時內完成「每人發乙個帖子、瀏覽十個帖子」的工作量。
注意上面的兩處，「平均每天……」、「分布在4個小時……」。敏感的測試人員應該能發現，這個場景測的是平均壓力，也就是乙個系統最平常一天的使用壓力，我喜歡稱之為日常壓力。
顯然，除了日常壓力，系統還會有壓力更大的使用場景，比如某天發生了一件重要的事情，那麼使用者就會更加熱烈的進行討論。這個壓力，我習慣叫做高峰期壓力，需要專門設計乙個測試場景。
這個場景，需要哪些資料呢，我們依然可以從現有的資料進行分析。比如上面提到的是「平均每天總的發帖量……」，那麼這次我們就要查到過去最高一日的業務量。「分布在4個小時」也需要進行相應的修改，比如查查歷史分布圖是否有更為集中的分布，或者用更簡單通用的80-20原則，80%的工作在20%的時間內完成。根據這些資料可以再做適當的調整，設計出高峰期的測試場景。
需要注意高峰期壓力和峰值壓力的區別，高峰期壓力是指系統正常的、預期內壓力的乙個高峰。而峰值壓力是指那些不在正常預期內的壓力，可能幾年才出現一次。
這裡只是舉了個最簡單的例子，實際工作遠比這複雜的多。需要哪些資料、如何獲取，很可能要取得這些資料就要花費很大的功夫。這其實就涉及到了乙個很重要的內容，使用者模型和壓力模型的建立，以後會有專門的文章進行講述。
為什麼要花這麼大的精力來收集這些資訊呢？是因為只有通過這些有效的資料，才能準確的去模擬使用者場景，準確的模擬壓力，獲取到更加真實的使用者體驗。只有這樣，「不同的測試人員，測出相同的結果」才會有可能實現，而且結果都是準確有效的。
最後通過幾個小問題來總結回顧一下：
你真的理解「併發使用者」的意義麼？
什麼是使用者視角和伺服器視角？
什麼是壓力？
如何模擬預期壓力？
效能測試新手誤區（一）
系列原創 效能測試新手誤區 有過一些效能測試經驗的人很容易進入此狀態，他們已經熟悉了效能測試的基本流程，能夠比較熟練的使用測試工具開展工作。我大概從事效能測試一年左右時遇到了這個問題，那時我覺得效能測試的過程沒有太多挑戰，遇到的每乙個系統，彷彿都可以用同樣的流程完成。半天時間填寫測試方案，一天時間來...
效能測試新手誤區（六） 效能監控
資料庫 或中介軟體 非常慢了，如何監控它的效能 你想得到什麼效能指標？就是 內部的效能指標 收到效能測試人員這樣的問題後，通常會發生上面的對話。我的觀點是，準確的說出你想要做什麼，比你會不會做更重要。那麼對於效能測試人員來說，效能監控 這門必修課，該從何下手呢？如果我給你乙個黑盒子，告訴你裡面是一部...
效能測試報告模板 效能測試新手誤區
推薦閱讀 1 效能測試學習筆記 場景設計 2 效能測試的重要意義 3 效能分析流程及方法 4 應用系統效能調優之效能分析 效能測試新手誤區 效能測試新手誤區 找不到測試點，不知為何而測 有過一些效能測試經驗的人很容易進入此狀態，他們已經熟悉了效能測試的基本流程，能夠比較熟練的使用測試工具開展工作。我...