Joe Moreno在1998年至2007年期間就職于蘋果公司，是蘋果在線商店的一名開發(fā)人員。通過此文，也可對蘋果公司的一些產(chǎn)品開發(fā)細(xì)節(jié)有所了解。以下是全文。
　　當(dāng)我還在蘋果在線商店工作的時(shí)候，我們從來沒有對在線網(wǎng)站做過負(fù)載測試。我們也不覺得需要這么做。然而，當(dāng)每次史蒂夫·喬布斯在演示某個(gè)幻燈片過程中切換到在線商店時(shí)，會(huì)走下臺(tái)來等待，這是非常有趣的經(jīng)歷。作為事后檢查的一部分，每次在線商店重新上線時(shí)，我們都會(huì)問自己服務(wù)器的瓶頸在哪里：是CPU、網(wǎng)絡(luò)帶寬、磁盤I/O還是內(nèi)存？雖然準(zhǔn)確預(yù)測整個(gè)系統(tǒng)在實(shí)際環(huán)境中的行為非常困難，幸運(yùn)的是我們有一整套的測試策略來確保在重新啟動(dòng)之前有足夠的測試。 
 

作者：Joe Moreno

負(fù)載測試 / Load Testing
　　許多公司用負(fù)載測試來試驗(yàn)他們的web應(yīng)用程序能夠支持怎樣的負(fù)載。一個(gè)最平常用到的，但是錯(cuò)誤的方式是把web站點(diǎn)上線然后啟動(dòng)負(fù)載測試。這種方式的問題在于，它不會(huì)告訴你web站點(diǎn)從在線狀態(tài)到不能提供服務(wù)這個(gè)過程中是如何運(yùn)行的。當(dāng)一個(gè)web站點(diǎn)在使用狀態(tài)時(shí)宕機(jī)然后重新啟動(dòng)，這時(shí)web站點(diǎn)表現(xiàn)出的行為，一定與負(fù)載測試狀態(tài)下有很大的區(qū)別。例如，我們發(fā)現(xiàn)在iTunes商店（iTunesStore）第一次啟動(dòng)時(shí)，一個(gè)被信任的WebObjects組件不是線程安全的，而這個(gè)問題只有在該對象處于重負(fù)荷情況下才會(huì)出現(xiàn)。
初生牛犢 / Cutting My Teeth
　　當(dāng)我第一次加入蘋果在線商店開發(fā)小組時(shí)，我和一位經(jīng)驗(yàn)豐富的軟件工程師搭檔，他教會(huì)我如何快速地熟悉代碼庫，構(gòu)建流程以及單元測試和組件測試。由于在線商店已經(jīng)上線了，我們只有在對新代碼進(jìn)行測試以及搜集數(shù)據(jù)之后才能發(fā)布。
　　我的第一項(xiàng)任務(wù)是和搭檔一起實(shí)現(xiàn)一個(gè)在網(wǎng)絡(luò)上用特性表形式搜集產(chǎn)品信息的簡單web服務(wù)。一般這樣的簡單web服務(wù)程序只需要一到兩天，而我們倆在師傅的一步步指導(dǎo)下花了一整個(gè)禮拜，通過結(jié)對編程方式完成了整個(gè)流程。（雖然我們采用結(jié)對編程，但是我們使用的是Agile/Scrum，而不是極限編程。每個(gè)開發(fā)小組可以在保證進(jìn)度的前提下使用任何他們達(dá)成共識(shí)的開發(fā)技術(shù)。我服務(wù)的團(tuán)隊(duì)碰巧有幾個(gè)經(jīng)過訓(xùn)練的scrum大師，他們得到了管理團(tuán)隊(duì)的支持。）
　　在實(shí)際開始編寫產(chǎn)品代碼之前，我們需要編寫單元測試。所有的軟件工程師都被要求先為他們的API編寫單元測試，這個(gè)一個(gè)很值得學(xué)習(xí)的規(guī)范。（編注：測試在敏捷當(dāng)中非常重要，參考這篇《敏捷方法中測試人員的價(jià)值》。）接下來，我們在Eclipse/WOLips上使用WebObjects/Java編寫代碼，與此同時(shí)我們?yōu)閼?yīng)用程序設(shè)下關(guān)鍵的斷點(diǎn)，然后在調(diào)試模式下運(yùn)行，這樣我們就可以單步調(diào)試代碼。我見到了有太多在別處工作的軟件工程師，他們不斷地編碼然，就像他們在不斷地往墻上扔?xùn)|西，然后看看到底會(huì)有什么會(huì)粘在墻上（像碰運(yùn)氣一樣）。
　　在我們檢入我們代碼的同時(shí)，軟件倉庫會(huì)自動(dòng)構(gòu)建所有的應(yīng)用程序，然后對它們運(yùn)行單元測試。如果你的代碼讓這次構(gòu)建失敗，開發(fā)小組的每個(gè)人，包括一到兩位項(xiàng)目經(jīng)理會(huì)受到郵件通知——你就是構(gòu)建失敗的罪魁禍?zhǔn)住?
令牌 / Token
　　我們有一段非常特殊的軟件代碼，一次只能由一個(gè)軟件工程師檢出（check out）、編寫（work on）、然后檢入（checkin）。你只有在得到一個(gè)物理令牌時(shí)才能夠接觸到這段代碼。在我們這里，這個(gè)令牌就是一個(gè)DarthTater玩偶，它放在你的工作的格子間或者書架上最顯眼的地方。
搜集度量數(shù)據(jù)/ Gathering Metrics
　　一旦我們的服務(wù)編碼完成，沒有錯(cuò)誤，并且被檢入到代碼倉庫后，我們開始組件測試并搜集新代碼的度量數(shù)據(jù)。這是另外一個(gè)在新手團(tuán)隊(duì)里被忽略的步驟。我懷疑“搜集度量數(shù)據(jù)”這個(gè)步驟甚至都沒有被包含在Joel測試中，因?yàn)镴oelSpolsky的產(chǎn)品是一個(gè)桌面應(yīng)用程序而不是一個(gè)需要重負(fù)載測試的web程序（或者，也許這個(gè)被隱含在“你有測試工程師嗎？”這個(gè)步驟里）
　　甚至在我們考慮將代碼放到實(shí)時(shí)代碼分支之前，我們就已經(jīng)對代碼進(jìn)行了數(shù)百萬次的請求測試。在蘋果公司，我們有一個(gè)非常復(fù)雜的緩存算法，根據(jù)我們設(shè)定的目標(biāo)，它可以保存我們需要的任意數(shù)目的記錄。我們是否需要五百個(gè)或是五萬個(gè)產(chǎn)品的請求記錄緩存呢？在一次冷啟動(dòng)開始之后，我們是否需要對指定的產(chǎn)品用緩存來“熱身”呢？在沒有任何的請求命中時(shí)，我們需要等多久才把一個(gè)產(chǎn)品從緩存中移除并釋放內(nèi)存呢？
　　附注一點(diǎn)，我們的緩存通常是一個(gè)哈希表。哈希表的優(yōu)點(diǎn)在于它的大O表示法運(yùn)行時(shí)間是常量O(1)。當(dāng)你在一個(gè)面試中被問道“什么事最快的查找函數(shù)”時(shí)，千萬不要說“一個(gè)B樹二叉樹”。完美的哈希表通常會(huì)輕松勝出。
調(diào)整并完成 / Tweaking and Done
　　我們會(huì)不斷調(diào)整代碼直到我們得到可接受的度量數(shù)據(jù)。我們的測量數(shù)據(jù)會(huì)對緩存內(nèi)存消耗多少以及滿足每個(gè)服務(wù)請求/響應(yīng)的時(shí)間長短進(jìn)行度量。根據(jù)我們的需求，我們會(huì)努力達(dá)到99.7%的服務(wù)請求在35毫秒之內(nèi)返回，95%的請求在10毫秒之內(nèi)返回，沒有單個(gè)請求超過50毫秒的響應(yīng)時(shí)間。
　　這些測試在一個(gè)非常接近產(chǎn)品環(huán)境的實(shí)時(shí)數(shù)據(jù)庫的拷貝中運(yùn)行。這不能完美地指出web應(yīng)用程序一旦在實(shí)際環(huán)境中會(huì)如何執(zhí)行。但是將它變成一個(gè)設(shè)定期望的很好的辦法，這不會(huì)需要很久時(shí)間。
　　在我們“疾跑”（Sprint）結(jié)束的時(shí)候，所有這些度量數(shù)據(jù)都會(huì)作為敏捷定義“完成”時(shí)演示的一部分。這時(shí)代碼已經(jīng)準(zhǔn)備就緒可以被檢入質(zhì)量保證的代碼分支，在代碼發(fā)布上線之前還會(huì)進(jìn)行功能測試。
編注：
　　1. 大O表示法：用來描述算法的時(shí)間復(fù)雜度，O(1)的時(shí)間復(fù)雜度最低
　　2. 疾跑（Sprint）：是scrum開發(fā)方法的一個(gè)最基本開發(fā)單元