淘寶網每年的雙11 活動都是對其服務器性能的挑戰。因為那天的活動所有商品半價，在那一天購物的用戶量劇增。做淘寶網的高層更多的關心在線用戶數，用戶交易量，總交易金額 等，做為一名技術人員，我們可以更關心當天系統的吞吐量、每秒鐘點擊率以及系統資源的消耗情況等。
基于用戶體驗的性能測試
但對于一個用戶來說，他可以不關心上面這些，大約有一部分的消費者會因為網站過于技術化或者性能問題而選擇了離開。換言之，如果你的網站速度太慢客戶就會離去。這是所有的互聯網用 戶都熟知的道理。這時你的第一想法不是“哎呀，不知道站點的吞吐量怎樣”，而是“簡直太慢了！我可沒有時間在這里等，到別處去吧”。現在想想，人們離開你 的站點是否因為性能問題？所以，在做性能測試的時候除關注吞吐量、點擊率這些參數外，我們更需要站在用戶的角度來測試實際的性能感受。如果你經過測試聲稱 網站可以承受更多的用戶同時訪問，但實際的用戶體驗性非常差，那么做你的性能測試又有什么意義呢？
現在市場 上有大量的書討論如何設計良好的性能，還有更多的書把重點放在如何使得站點更加直觀、生動和易于炒作上。關于速度的好處也討論過，但如何真正并優化系統來 提高用戶體驗呢？那就是直接的用戶體驗測試了。有兩點方法可以做一這點。一是可以把站點直接投入到能夠進行數據采集和系統調優的生產環境中，并祈禱你的網 站不會太慢或崩潰。另一個種明智的選擇是模擬真實的用戶活動，進行重復的測試和調優，最后再投入到生產環境。
“明確”的性能需求
當測試人員進行性能測試工作時，真正讓他們感到困難的不是測試工具如何使用，也不是如何對測試數據進行分析與系統調優（對于一個經驗豐富有性能工程師來說，這真的不難）。讓他們感到困惑的是如何得到準確的量化的需求，比如：
A、網站可以支撐多少在線用戶數
B、網站可以支持多少用戶同時交易
C、電子郵件系統每秒種可以處理多少封郵件
D、可以支持多少人同時瀏覽網頁
類似于這樣的數據會出現客戶對系統的性能需求中，好吧，有了這些需求，我就開始性能工作了，這些需求真的很明確么？
我們來看下面的例子，一個購買汽車的用戶想知道：
這輛汽車開100公里的耗油是多少升。（對，就是他坐在里面試駕的那輛）
如果你是一個嚴謹的汽車銷售，不會馬上會說這輛車每公理的耗油是多少。而是在大腦中快速的列出的汽車駕駛環境：
1、車上坐幾個人？
2、車上帶多重的物品
3、路況如何，是高速還是擁擠的市區？
4、天氣如何，溫度如何，要開空調碼？
5、駕駛時間是白天還是晚上（如果是晚上要開車燈）？
6、駕駛習慣是怎樣的？
....................................
其實我們在做性能測試做了很多假設。你唯一能做的就是繼續向客戶確認更明確的需求，很多時候其實客戶也無法給出精確的需求。這就是時候你就要多參考常規的情況下，參考同類產品，或盡量引導用戶去明確具體的需求，盡量與客戶達到統一的共識。
“假設”的測試環境 現在是不是覺得性能測試有太多的前置條件，它他們或大或小的影響著測試的結果。
關于這些前置條件，或者我們稱之為假設（assumption），我把一些做法歸納為三個階段。
一：做了假設卻不知道自己做了假設
比如前面提到的那個耗油的問題，有人的做法是我就開100公里看看，得出來是多少就是多少，比如9L。然后就告訴別人這個車的100公里耗油是9L。
問題是這樣的結果對你是OK，因為你有切身的的體驗，知道遇到的狀況，可是測試的報告是要給別人，甚至你都無法直接面對或者溝通的人參考。這就 會很容易誤導別人，即便這不是你的本意，而且你自已也確定你是真實的記錄了結果。這里的問題在于你并不清楚自己所做的假設，因為我們一直在做這樣的假設。
二：做過多的假設
“當路面平坦，無任何紅綠燈，風速5km/h只有一名70kg的乘客，時速穩定在70km/h，良好駕駛習慣，....的情況下，耗油是7.1L/100km。”
這樣可能很嚴謹，但是對你的報告的讀者而言，這樣的數據有多大意義，因為他們沒有你這么幸運，有這么良好的環境。
三：做必要和合理的假設
生活有時候是需要一些妥協和折衷，如果這些折衷是必要的和合理的。因為跳出來看，我們的測試需要提供有價值的信息，所以為了這樣有價值的信息，做出必要和合理的假設是可以接受的。
好吧，也許這不是你想要的答案，但它是我目前給自己的解釋和安慰。
性能測試環境需要在嚴格獨立監控下管理，盡量保持與真實生產環境的一致性能。保持一致性應該注意哪些方面，等搜索蟲師的《性能測試知多少---測試環境搭建》。
“精確”的測試數據
對于一個嚴謹的測試員，我們的測試結果的描述也相當精確，如：用戶每個用戶的訪問時間為2.8729秒，10分鐘系統處理請求8634個。我以前一直認為，只要我把測試環境描述的很詳細，我的測試結果就是精確的。
實際上功能測試很容易得到測試結果，而性能測試很難得到精確的量化結果，我買了一輛汽車，開車去上班，去時車的各個功能非常正常，回來的時候車 的功能也非常正常。將過我的上下班測試，這個車的功能沒有問題。再來看耗油情況，我去時上耗油3.29升，回來時耗油3.42升，同樣的一條路，同樣的人 開同樣的車，那么是不一樣的耗油結果？如果我再試一遍，可能情況還會有變化。所以，我們很難得到精確的數據，但是這絲毫不影響我們測試結果的參考價值。
“宏觀/圍觀”的性能測試
這也是一個有趣的對立。在做性能測試，特別是整個產品的性能測試的時候，我們看到的是產品的核心功能和主要的大的功能模塊，比如數據庫、web 服務器、核心的daemon等等。在腦海里，我們有一個架構圖，哪怕你沒有把它畫出來。所以有時候，我們會想，性能測試對于產品的視角是宏觀的，看大的組 件，而不是具體的細節的東西。果真是如此嗎？看看下面的例子：
1、把daemon的log級別改為debug （log_level從2改到5）之后，性能下降了差不多一半。
2、關掉一個cache選項
3、打開keepalive選項
4、打開DNS反向查詢
.....
上面都是些細枝末節的設置，一個配置項而已，藏在DB的某張表或者某個ini里面。但是改變之后，得到的性能結果可能大不相同。這些都是否改變了我們以往的看法。