淘寶網每年的雙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里面。但是改變之后，得到的性能結果可能大不相同。這些都是否改變了我們以往的看法。
Scott Barber（性能測試方面的專家）在他的一篇文章里討論了這個話題。
“Macro- and Micro-tests, macro strategies and micro-plans, macro-level application usage and micro-level usage implementation details, macro-level result summaries for executives and micro-level test results for developers... it sounds like a day in the life of a performance tester to me.”
摘自他為Software Test & Performance雜志寫的一個系列文章，叫做Peak Performance，其中的2006年9月的一期，文章名是 Macro to Micro And Back Again Macro to Micro And Back Again，嗯，很好的詮釋。
亞里士多德說世上的道理不是被講一遍兩遍而是成千上萬遍，是的，因為Weinberg也講了一遍，就在上面提到的那本書里面。請原諒我再次引用他的話，粉絲嘛。“Although it's necessary to have an overview of the problem, the big picture often turns on one critical detail.”
critical detail, 對，就是這個term。其實不光是這里說的測試，工作和生活中的很多事情都是一樣，不是要不要關心細節，而是它是否critical。
那么，怎么區分一個細節是不是critical或者怎樣找到critical的detail呢？
嗯...，這是個好問題，不過不好意思這個不是這里要討論的范疇。
所以，你還認為性能測試只是學習如何使用性能工具么？它需要一個長期的個技術的積累，我們的路還很長。也許，我講的不夠本質，但性能測試這個領域，看到太多的新手在整天問工具的使用，學會了工具的使用就大言“我會（精通）性能測試！”。太多的公司叫新手的做性能測試，環境神馬的也不提供，你找個工具對軟件加壓一下吧！哎~！這未免是太貶低“軟件性能測試”了。
本文參考：
基於用戶體驗的性能測試http://www.cnblogs.com/pent/archive/2007/07/02/802167.html
關於性能測試的三個觀念http://blog.csdn.net/superqa/article/details/6067448