最近和幾個同事一起組織了一門ETP（Engineer Training Program）的課程，叫做Advanced Performance
Testing。叫Advanced不是因為多么高深，而是因為這是一個多次的系列課程，而且里面結合了大量的實例和實踐的經驗，不希望只是泛泛的介紹。當然，這樣叫還是會覺得有些大言不慚的，畢竟做
性能測試久了，知道深淺。
最近在Weinberg（對，還是他，可見我讀書多么慢）的《becoming a technical leader》書中看到一段話，提到他對于培訓的一點心得，他對于成功與否的判斷標準是受眾在其后對于這個領域的關注度是提高了還是下降了。我也希望在我 們這個系列的課程結束之后，大家對于這一塊有了更多的認識和了解，也愿意去更深入的學習和實踐。總之，希望會有一些幫助。
昨晚上完第一次overview的課后坐地鐵回家，碰到一位來上課的同事，他對于我在課上提到的和性能測試相關的幾個觀念有一些印象。看來，簡潔的歸納 是有助于傳播的，可能比一堆的checklist更容易讓人記住和獲取一些新的想法。這里也整理一下發出來供大家參考。
1. 精確和模糊
這是困擾很多性能測試人員的一個問題。因為基本上性能測試都需要得到一個精確的量化的結果，比如：
a. 系統可以支持10，000個并發連接
b. 每秒鐘可以處理80封電子郵件
c. 可以支持3000人同時瀏覽網頁
......
類似的數據可能出現在需求中，也可能出現在測試的結果里面。使得我們認為，相比功能測試或者穩定性測試而言，性能測試是一種要求精確的測試。
但是，真的是這樣嗎？ 試著回答下面這個問題：
一輛汽車開100公里需要多少汽油？
直覺上你會說不同的車不一樣，對，這是好的開始，那好，就確定是某一臺確定的車，不僅是型號，就是門口的某一臺。
嗯，怎么樣？開始犯難了吧，特別是如果你是一個嚴謹的人。因為你的大腦開始快速列出下列條件：
1. 坐幾個人，帶多重的物品？
2. 路況如何，是高速還是擁擠的市區？
3. 天氣如何，溫度如何，要開空調嗎？
4. 駕駛習慣是怎樣的？
......
還有很多，越有經驗的人可以列出越多，想想F1調整一下尾翼的角度就可以改變下壓力之類的事情。天哪，我要開一個長長的清單。
到現在，你還覺得性能測試是一個精確的測試嗎？也許問題出在有太多的前置條件，它們或大或小的影響著測試的結果。
所以呢，我們應該怎么辦？這是對很多新參與性能測試的人來說最難的問題，而不是那些看起來復雜的工具。大家常會問：我怎么知道該用什么樣的sample？
關于這些前置條件，或者我們稱之為假設（assumption），我把一些做法歸為三個階段。
Stage 1：做了假設卻不知道自己做了假設
比如前面提到的那個油耗的問題，有人的做法是我就開100公里看看，得出來是多少就是多少，比如9L。然后我就告訴別人這個車的100公里油耗就是9L。
問題是這樣的結果對你是OK，因為你有切身的體驗，知道遇到的狀況，可是測試的報告是要給別人，甚至你都無法直接面對或者溝通的人參考。這就會很容易誤 導別人，即便這不是你的本意，而且你自己也確定你是真實的記錄了結果。這里的問題在于你并不清楚自己所做的假設，因為我們一直在做這樣的假設。
Stage 2：做了過多的假設
“當路面平坦，無任何紅綠燈，風速5km/h， 只有一名70kg的乘客，時速穩定在70km/h， 良好駕駛習慣，... ，的情況下， 油耗是7.1 L/100 km.”
這樣可能很嚴謹，但是對你的報告的讀者而言，這樣的數據有多大意義，因為他們沒有你那么幸運，有這么良好的環境。
Stage 3：做必要和合理的假設。
生活有時候是需要一些妥協和折衷，如果這些折衷是必要的和合理的。因為跳出來看，我們的測試需要提供有價值的信息，所以為了這樣有價值的信息，做出必要的和合理的假設是可以接受的。
好吧，也許這不是你想要的答案，但它是我目前給自己的解釋，和安慰。
2. 宏觀和微觀
這也是一個有趣的對立。在做性能測試，特別是整個產品的性能測試的時候，我們看到的是產品的核心功 能和主要的大的功能模塊，比如數據庫、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呢？
嗯...，這是個好問題，不過不好意思這個不是這里要討論的范疇。
3. 項目和任務
性能測試本身肯定是一個任務，無論對于被安排去做這個的人，或者安排的人。但是它有時候也像一個項目，對于去做這件事情的人。為什么呢？
首先你需要和很多的人打交道。
產品經理或者客戶：獲取需求，設定目標。
QA manager/lead：討論resource和schedule。包括需要的機器，環境，軟件，還有整個計劃。
開發人員：查找問題和調優等。
功能測試的owner： 性能測試人員可能不是什么功能都很懂。
Admin：Lab，網絡，DB等等
其次，它是一個周期很長，跨度很大的工作。特別是對于一個比較大的產品而言。你需要準備詳細的測試設計，包括目標、范圍、可能的方法，以及上面 提到的資源和時間計劃；然后邀請很多人來評審這個計劃；接下來要準備工具、環境和測試數據。然后是執行，記錄分析結果。如果有問題還要反復的調整和 regression。最后要整理報告，回答疑問。
說它是一個項目一來是因為上面的原因導致工作的復雜性，還有一些原因是因為性能測試帶有評測的性質，因為你是在試圖去度量、衡量或者評價一個東 西，而且帶有比較絕對的結果。這樣導致性能測試不可避免的要引入一些權威性的問題，盡管你并不一定期望這樣。這使得很多的東西就像一個其他項目一樣，有期 望管理和良好的外部溝通和協調的需要。所以有時候，更愿意把它作為一個小的項目來看待，這樣或許可以做得更全面。