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

　　負(fù)載測(cè)試 / Load Testing

　　許多公司用負(fù)載測(cè)試來試驗(yàn)他們的web應(yīng)用程序能夠支持怎樣的負(fù)載。一個(gè)最平常用到的，但是錯(cuò)誤的方式是把web站點(diǎn)上線然后啟動(dòng)負(fù)載測(cè)試。這種方式的問題在于，它不會(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ù)載測(cè)試狀態(tài)下有很大的區(qū)別。例如，我們發(fā)現(xiàn)在iTunes商店（iTunes Store）第一次啟動(dòng)時(shí)，一個(gè)被信任的WebObjects組件不是線程安全的，而這個(gè)問題只有在該對(duì)象處于重負(fù)荷情況下才會(huì)出現(xiàn)。

　　初生牛犢 / Cutting My Teeth

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

　　我的第一項(xiàng)任務(wù)是和搭檔一起實(shí)現(xiàn)一個(gè)在網(wǎng)絡(luò)上用特性表形式搜集產(chǎn)品信息的簡(jiǎn)單web服務(wù)。一般這樣的簡(jiǎn)單web服務(wù)程序只需要一到兩天，而我們倆在師傅的一步步指導(dǎo)下花了一整個(gè)禮拜，通過結(jié)對(duì)編程方式完成了整個(gè)流程。（雖然我們采用結(jié)對(duì)編程，但是我們使用的是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)品代碼之前，我們需要編寫單元測(cè)試。所有的軟件工程師都被要求先為他們的API編寫單元測(cè)試，這個(gè)一個(gè)很值得學(xué)習(xí)的規(guī)范。接下來，我們?cè)贓clipse/WOLips上使用WebObjects/Java編寫代碼，與此同時(shí)，我們?yōu)?a href=/pingce/yingyong/ target=_blank class=infotextkey>應(yīng)用程序設(shè)下關(guān)鍵的斷點(diǎn)，然后在調(diào)試模式下運(yùn)行，這樣我們就可以單步調(diào)試代碼。我見到了有太多在別處工作的軟件工程師，他們不斷地編碼然，就像他們?cè)诓粩嗟赝鶋ι先訓(xùn)|西，然后看看到底會(huì)有什么會(huì)粘在墻上（像碰運(yùn)氣一樣）。

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

　　令牌 / Token

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

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

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

　　甚至在我們考慮將代碼放到實(shí)時(shí)代碼分支之前，我們就已經(jīng)對(duì)代碼進(jìn)行了數(shù)百萬次的請(qǐng)求測(cè)試。在蘋果公司，我們有一個(gè)非常復(fù)雜的緩存算法，根據(jù)我們?cè)O(shè)定的目標(biāo)，它可以保存我們需要的任意數(shù)目的記錄。我們是否需要五百個(gè)或是五萬個(gè)產(chǎn)品的請(qǐng)求記錄緩存呢？在一次冷啟動(dòng)開始之后，我們是否需要對(duì)指定的產(chǎn)品用緩存來熱身呢？在沒有任何的請(qǐng)求命中時(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ù)。我們的測(cè)量數(shù)據(jù)會(huì)對(duì)緩存內(nèi)存消耗多少以及滿足每個(gè)服務(wù)請(qǐng)求/響應(yīng)的時(shí)間長(zhǎng)短進(jìn)行度量。根據(jù)我們的需求，我們會(huì)努力達(dá)到99.7%的服務(wù)請(qǐng)求在35毫秒之內(nèi)返回，95%的請(qǐng)求在10毫秒之內(nèi)返回，沒有單個(gè)請(qǐng)求超過50毫秒的響應(yīng)時(shí)間。

　　這些測(cè)試在一個(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)行功能測(cè)試。

　　編注：

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

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

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

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