當(dāng)我還在蘋果在線商店工作的時候，我們從來沒有對在線網(wǎng)站做過負(fù)載測試。我們也不覺得需要這么做。然而，當(dāng)每次史蒂夫·喬布斯在演示某個幻燈片過程中切換到在線商店時，會走下臺來等待，這是非常有趣的經(jīng)歷。作為事后檢查的一部分，每次在線商店重新上線時，我們都會問自己服務(wù)器的瓶頸在哪里：是CPU、網(wǎng)絡(luò)帶寬、磁盤I/O還是內(nèi)存？雖然準(zhǔn)確預(yù)測整個系統(tǒng)在實際環(huán)境中的行為非常困難，幸運的是我們有一整套的測試策略來確保在重新啟動之前有足夠的測試。

　　負(fù)載測試 / Load Testing

　　許多公司用負(fù)載測試來試驗他們的web應(yīng)用程序能夠支持怎樣的負(fù)載。一個最平常用到的，但是錯誤的方式是把web站點上線然后啟動負(fù)載測試。這種方式的問題在于，它不會告訴你web站點從在線狀態(tài)到不能提供服務(wù)這個過程中是如何運行的。當(dāng)一個web站點在使用狀態(tài)時宕機然后重新啟動，這時web站點表現(xiàn)出的行為，一定與負(fù)載測試狀態(tài)下有很大的區(qū)別。例如，我們發(fā)現(xiàn)在iTunes商店（iTunes Store）第一次啟動時，一個被信任的WebObjects組件不是線程安全的，而這個問題只有在該對象處于重負(fù)荷情況下才會出現(xiàn)。

　　初生牛犢 / Cutting My Teeth

　　當(dāng)我第一次加入蘋果在線商店開發(fā)小組時，我和一位經(jīng)驗豐富的軟件工程師搭檔，他教會我如何快速地熟悉代碼庫，構(gòu)建流程以及單元測試和組件測試。由于在線商店已經(jīng)上線了，我們只有在對新代碼進(jìn)行測試以及搜集數(shù)據(jù)之后才能發(fā)布。

　　我的第一項任務(wù)是和搭檔一起實現(xiàn)一個在網(wǎng)絡(luò)上用特性表形式搜集產(chǎn)品信息的簡單web服務(wù)。一般這樣的簡單web服務(wù)程序只需要一到兩天，而我們倆在師傅的一步步指導(dǎo)下花了一整個禮拜，通過結(jié)對編程方式完成了整個流程。（雖然我們采用結(jié)對編程，但是我們使用的是Agile/Scrum，而不是極限編程。每個開發(fā)小組可以在保證進(jìn)度的前提下使用任何他們達(dá)成共識的開發(fā)技術(shù)。我服務(wù)的團隊碰巧有幾個經(jīng)過訓(xùn)練的scrum大師，他們得到了管理團隊的支持。）

　　在實際開始編寫產(chǎn)品代碼之前，我們需要編寫單元測試。所有的軟件工程師都被要求先為他們的API編寫單元測試，這個一個很值得學(xué)習(xí)的規(guī)范。接下來，我們在Eclipse/WOLips上使用WebObjects/Java編寫代碼，與此同時，我們?yōu)?a href=/pingce/yingyong/ target=_blank class=infotextkey>應(yīng)用程序設(shè)下關(guān)鍵的斷點，然后在調(diào)試模式下運行，這樣我們就可以單步調(diào)試代碼。我見到了有太多在別處工作的軟件工程師，他們不斷地編碼然，就像他們在不斷地往墻上扔?xùn)|西，然后看看到底會有什么會粘在墻上（像碰運氣一樣）。

　　在我們簽入我們代碼的同時，軟件倉庫會自動構(gòu)建所有的應(yīng)用程序，然后對它們運行單元測試。如果你的代碼讓這次構(gòu)建失敗，開發(fā)小組的每個人，包括一到兩位項目經(jīng)理會受到郵件通知——你就是構(gòu)建失敗的罪魁禍?zhǔn)住?/p>

　　令牌 / Token

　　我們有一段非常特殊的軟件代碼，一次只能由一個軟件工程師簽出（check out）、編寫（work on）、然后簽入（check in）。你只有在得到一個物理令牌時才能夠接觸到這段代碼。在我們這里，這個令牌就是一個Darth Tater玩偶，它放在你工作的格子間或者書架上最顯眼的地方。

　　搜集度量數(shù)據(jù) / Gathering Metrics

　　一旦我們的服務(wù)編碼完成，沒有錯誤，并且被簽入到代碼倉庫后，我們開始組件測試并搜集新代碼的度量數(shù)據(jù)。這是另外一個在新手團隊里被忽略的步驟。我懷疑搜集度量數(shù)據(jù)這個步驟甚至都沒有被包含在Joel測試中，因為Joel Spolsky的產(chǎn)品是一個桌面應(yīng)用程序而不是一個需要重負(fù)載測試的web程序（或者，也許這個被隱含在“你有測試工程師嗎？”這個步驟里）

　　甚至在我們考慮將代碼放到實時代碼分支之前，我們就已經(jīng)對代碼進(jìn)行了數(shù)百萬次的請求測試。在蘋果公司，我們有一個非常復(fù)雜的緩存算法，根據(jù)我們設(shè)定的目標(biāo)，它可以保存我們需要的任意數(shù)目的記錄。我們是否需要五百個或是五萬個產(chǎn)品的請求記錄緩存呢？在一次冷啟動開始之后，我們是否需要對指定的產(chǎn)品用緩存來熱身呢？在沒有任何的請求命中時，我們需要等多久才把一個產(chǎn)品從緩存中移除并釋放內(nèi)存呢？

　　附注一點，我們的緩存通常是一個哈希表。哈希表的優(yōu)點在于它的大O表示法運行時間是常量O(1)。當(dāng)你在一個面試中被問道什么事最快的查找函數(shù)時，千萬不要說一個B樹二叉樹。完美的哈希表通常會輕松勝出。

　　調(diào)整并完成 / Tweaking and Done

　　我們會不斷調(diào)整代碼直到我們得到可接受的度量數(shù)據(jù)。我們的測量數(shù)據(jù)會對緩存內(nèi)存消耗多少以及滿足每個服務(wù)請求/響應(yīng)的時間長短進(jìn)行度量。根據(jù)我們的需求，我們會努力達(dá)到99.7%的服務(wù)請求在35毫秒之內(nèi)返回，95%的請求在10毫秒之內(nèi)返回，沒有單個請求超過50毫秒的響應(yīng)時間。

　　這些測試在一個非常接近產(chǎn)品環(huán)境的實時數(shù)據(jù)庫的拷貝中運行。這不能完美地指出web應(yīng)用程序一旦在實際環(huán)境中會如何執(zhí)行。但是將它變成一個設(shè)定期望的很好的辦法，這不會需要很久時間。

　　在我們疾跑（Sprint）結(jié)束的時候，所有這些度量數(shù)據(jù)都會作為敏捷定義完成時演示的一部分。這時代碼已經(jīng)準(zhǔn)備就緒可以被簽入質(zhì)量保證的代碼分支，在代碼發(fā)布上線之前還會進(jìn)行功能測試。

　　編注：

　　1. 大O表示法：用來描述算法的時間復(fù)雜度，O(1)的時間復(fù)雜度最低。

　　2. 疾跑（Sprint）：是scrum開發(fā)方法的一個最基本開發(fā)單元。

it知識庫：我在蘋果公司學(xué)到的編程技巧，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。