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