轉自http://www.testroad.net/bbs/dispbbs.asp?boardid=16&id=1187&move=next
同樣的項目、同樣的性能需求，讓不同的測試人員來測，會是相同的結果麼？
假設有這樣一個小論壇，性能測試人員得到的需求是“支持併發50人，響應時間要在3秒以內”，性能測試人員A和B同時開始進行性能測試（各做各的）。
只考慮發帖這個操作，A設計的測試場景是50人併發發帖，得到的測試結果是平均完成時間是5秒。於是他提出了這個問題，認爲系統沒有達到性能期望，需要開發人員進行優化。
B設計的測試場景是，50個人在線，並且在5分鐘內每人發一個帖子，也就是1分鐘內有10個人發帖子，最後得到的測試結果是平均完成時間2秒。於是他的結論是系統通過性能測試，可以滿足上線的壓力。
兩個人得到了不同的測試結果，完全相反的測試結論，誰做錯了？
或許這個例子太極端，絕對併發和平均分佈的訪問壓力當然是截然不同的，那我們再來看個更真實的例子。
還是一個小論壇，需求是“100人在線時，頁面響應時間要小於3秒”。A和B又同時開工了，這時他們都成長了，經驗更加豐富了，也知道了要設計出更符合實際的測試場景。假設他們都確認了用戶的操作流程爲“登錄-進入子論壇-（瀏覽列表-瀏覽帖子）×10-發帖”，即每個用戶看10個帖子、發一個帖子。於是他們都錄製出了同樣的測試腳本。
A認爲，每個用戶的操作，一般間隔30s比較合適，於是他在腳本中的每兩個事務之間加上了30秒的等待（思考時間）。
B想了想自己看論壇時的情景，好像平均每次鼠標點擊要間隔1分鐘，於是他在腳本中的每兩個事務之間加上了1分鐘的等待。
他們都認爲自己的測試場景比較接近實際情況，可惜測試結果又是不同的，很顯然A場景的壓力是B的兩倍。那誰錯了呢？或者有人說是需求不明確導致的，那麼你需要什麼樣的需求呢？
看看我隨手在網上（51testing）找的提問吧，和上面的內容如出一轍。一定有很多的性能測試人員每天接到的就是這種需求，又這樣就開展了測試，結果可想而知。
這裏我想問幾個問題，希望各位看完了上面的小例子後想一想：
如果有另一個人和你測同樣的系統，你們的測試結果會一致麼？
如果不一致，那麼誰是正確的？
如何證明測試結果是有效的？
如果你有了一些疑惑，對之前的測試結果少了一些自信，那麼請繼續。
服務器視角 vs. 用戶視角
性能測試中非常重要的一塊內容就是模擬預期的壓力，測試系統運行在此壓力下，用戶的體驗是什麼樣的。
那麼壓力是什麼？壓力是服務器在不斷的處理事情、甚至是同時處理很多事情。壓力是服務器直接處理的“事情”，而不是遠在網絡另一端的用戶。
下圖中，每一個顏色的線段代表一種操作。在任意一個時刻，服務器都知道它有10個事務需要處理，這10個事務也是有10個用戶產生的。但它不知道的是，整個時間段內的所有事務，是由多少個用戶與系統交互而產生的。
這句話好像有點繞，我再試着更形象的解釋一下。時刻1，10個當前事務是由10個用戶發起的。時刻2，依然是10個正在進行的事務，但可能是完全不同的10個人發起的。在這段時間內，服務器每一個時刻都在處理10個事務，但是參與了這個交互過程（對服務器產生壓力）的人可能會達到上百個，也可能只有最開始的10個。
那麼，對於服務器來說，壓力是什麼呢？顯然只是每時刻這10個同時處理的事務，而到底是有10個人還是1000個人，區別不大（暫不考慮session等問題）。
下面再從用戶的視角來看看。實際的情況中，不可能出現很多用戶同一時刻開始進行操作的場景，而是有一定的時間順序的。正如下圖所示，在這個時間段內，一共有23個用戶進行了操作。
但是服務器能看到這些用戶麼？它知道的只是某一個時間點上，有多少個正在執行的事務。大家可以數一下，此圖中任意時刻的併發事務依然是10個。
其實這兩個圖描述的本來就是同一個場景，只不過觀察者的視角不同罷了。
那麼大家想想，在性能需求中最常見到的“併發用戶”到底是指的什麼呢？
併發用戶
很多使用“併發用戶”這個詞的人，並沒有從服務器視角進行考慮。他們想的是坐在電腦前使用這個系統、對系統產生壓力的人的個數。基於這個原因，我很少使用這個容易讓人誤解的詞彙，而是進行了更細的劃分。主要有這麼幾個：系統用戶數（註冊用戶數）、在線用戶數（相對併發用戶數）、絕對併發用戶數。
上面幾個例子中所說的“併發用戶”，實際就是在線用戶數。其實我更喜歡叫做相對併發用戶數，因爲這個詞更容易讓人感受到“壓力”。相對併發用戶數指的是，在一個時間段內，與服務器進行了交互、對服務器產生了壓力的用戶的數量。這個時間段，可以是一天，也可以是一個小時。而需求人員必須要描述的，也正是這個內容。
而絕對併發用戶，主要是針對某一個操作進行測試，即多個用戶同一時刻發起相同請求。可以用來驗證是否存在併發邏輯上的處理問題，如線程不安全、死鎖等問題；也可提供一些性能上的參考信息，比如1個用戶需要1秒，而10個用戶併發卻需要30秒，那很可能就會有問題，需要進行關注，因爲10個用戶請求排隊處理也應該只需要10秒啊。但這種絕對併發的測試，同實際壓力下的用戶體驗關係不大。
再回到相對併發這個概念上來，它與服務器的壓力到底是什麼關係呢？如果你理解了前面的所有內容，那麼就會知道這兩者其實沒有直接聯繫（當然了，同一個測試用例中，肯定是用戶數越多壓力越大）。也就是說，你得到的這種性能需求，是無法知道服務器到底要承受多大壓力的。
那麼如何開展性能測試？
如何模擬壓力
既然我們知道了所謂的壓力其實是從服務器視角來講的，服務器要處理的事務纔是壓力，那麼我們就從這出發，來探尋一下性能測試需要的信息。依然用之前的小論壇爲例，我們需要測試活躍用戶爲500人時，系統的性能是否能還能提供良好的用戶感受。
假設現在的活躍用戶有50個人（或者通過另一個類似的系統來推算也行），平均每天總的發帖量是50條、瀏覽帖子500次，也就是每人每天發一個帖子、瀏覽十個帖子（爲了方便講解，假設論壇只有這兩個基本功能）。那麼我們就可以推算，活躍用戶達到500時，每天的業務量也會成比例的增長，也就是平均每天會產生500個新帖子、瀏覽帖子5000次。
進一步分析數據，又發現。用戶使用論壇的時間段非常集中，基本集中在中午11點到1點和晚上18點到20點。也就是說每天的這些業務，實際是分佈在4個小時中完成的。
那我們的測試場景，就是要用500個用戶在4小時內完成“每人發一個帖子、瀏覽十個帖子”的工作量。
注意上面的兩處，“平均每天……”、“分佈在4個小時……”。敏感的測試人員應該能發現，這個場景測的是平均壓力，也就是一個系統最平常一天的使用壓力，我喜歡稱之爲日常壓力。
顯然，除了日常壓力，系統還會有壓力更大的使用場景，比如某天發生了一件重要的事情，那麼用戶就會更加熱烈的進行討論。這個壓力，我習慣叫做高峯期壓力，需要專門設計一個測試場景。
這個場景，需要哪些數據呢，我們依然可以從現有的數據進行分析。比如上面提到的是“平均每天總的發帖量……”，那麼這次我們就要查到過去最高一日的業務量。“分佈在4個小時”也需要進行相應的修改，比如查查歷史分佈圖是否有更爲集中的分佈，或者用更簡單通用的80-20原則，80%的工作在20%的時間內完成。根據這些數據可以再做適當的調整，設計出高峯期的測試場景。
實際工作中可能還需要更多的測試場景，比如峯值壓力場景。什麼是峯值壓力呢，比如一個銀行網站，可能會由於發佈一條重磅消息使訪問量驟增，這個突發的壓力也是性能測試人員需要考慮的。
需要注意高峯期壓力和峯值壓力的區別，高峯期壓力是指系統正常的、預期內壓力的一個高峯。而峯值壓力是指那些不在正常預期內的壓力，可能幾年纔出現一次。
這裏只是舉了個最簡單的例子，實際工作遠比這複雜的多。需要哪些數據、如何獲取，很可能要取得這些數據就要花費很大的功夫。這其實就涉及到了一個很重要的內容，用戶模型和壓力模型的建立，以後會有專門的文章進行講述。
爲什麼要花這麼大的精力來收集這些信息呢？是因爲只有通過這些有效的數據，才能準確的去模擬用戶場景，準確的模擬壓力，獲取到更加真實的用戶體驗。只有這樣，“不同的測試人員，測出相同的結果”纔會有可能實現，而且結果都是準確有效的。
要點回顧
● 最後通過幾個小問題來總結回顧一下：
● 你真的理解“併發用戶”的意義麼？
● 什麼是用戶視角和服務器視角？
● 什麼是壓力？
● 如何模擬預期壓力？