|
|
|
原文作者Joe Moreno在1998年至2007年期間就職于蘋果公司，是蘋果在線商店的一名開發人員。通過此文，也可對蘋果公司的一些產品開發細節有所了解。以下是全文。當我還在蘋果在線商店工作的時候，我們從來沒有對在線網站做過負載測試。我們也不覺得需要這么做。然而，當每次史蒂夫·喬布斯在演示某個幻燈片過程中切換到在線商店時，會走下臺來等待，這是非常有趣的經歷。作為事后檢查的一部分，每次在線商店重新上線時，我們都會問自己服務器的瓶頸在哪里：是CPU、網絡帶寬、磁盤I/O還是內存？雖然準確預測整個系統在實際環境中的行為非常困難，幸運的是我們有一整套的測試策略來確保在重新啟動之前有足夠的測試。
負載測試 / Load Testing
許多公司用負載測試來試驗他們的web應用程序能夠支持怎樣的負載。一個最平常用到的，但是錯誤的方式是把web站點上線然后啟動負載測試。這種方式的問題在于，它不會告訴你web站點從在線狀態到不能提供服務這個過程中是如何運行的。當一個web站點在使用狀態時宕機然后重新啟動，這時web站點表現出的行為，一定與負載測試狀態下有很大的區別。例如，我們發現在iTunes商店（iTunes Store）第一次啟動時，一個被信任的WebObjects組件不是線程安全的，而這個問題只有在該對象處于重負荷情況下才會出現。
初生牛犢 / Cutting My Teeth
當我第一次加入蘋果在線商店開發小組時，我和一位經驗豐富的軟件工程師搭檔，他教會我如何快速地熟悉代碼庫，構建流程以及單元測試和組件測試。由于在線商店已經上線了，我們只有在對新代碼進行測試以及搜集數據之后才能發布。
我的第一項任務是和搭檔一起實現一個在網絡上用特性表形式搜集產品信息的簡單web服務。一般這樣的簡單web服務程序只需要一到兩天，而我們倆在師傅的一步步指導下花了一整個禮拜，通過結對編程方式完成了整個流程。（雖然我們采用結對編程，但是我們使用的是Agile/Scrum，而不是極限編程。每個開發小組可以在保證進度的前提下使用任何他們達成共識的開發技術。我服務的團隊碰巧有幾個經過訓練的scrum大師，他們得到了管理團隊的支持。）
在實際開始編寫產品代碼之前，我們需要編寫單元測試。所有的軟件工程師都被要求先為他們的API編寫單元測試，這個一個很值得學習的規范。（編注：測試在敏捷當中非常重要，參考這篇《敏捷方法中測試人員的價值》。）接下來，我們在 Eclipse/WOLips上使用WebObjects/Java編寫代碼，與此同時我們為應用程序設下關鍵的斷點，然后在調試模式下運行，這樣我們就可以單步調試代碼。我見到了有太多在別處工作的軟件工程師，他們不斷地編碼然，就像他們在不斷地往墻上扔東西，然后看看到底會有什么會粘在墻上（像碰運氣一樣）。
在我們檢入我們代碼的同時，軟件倉庫會自動構建所有的應用程序，然后對它們運行單元測試。如果你的代碼讓這次構建失敗，開發小組的每個人，包括一到兩位項目經理會受到郵件通知——你就是構建失敗的罪魁禍首。
令牌 / Token
我們有一段非常特殊的軟件代碼，一次只能由一個軟件工程師檢出（check out）、編寫（work on）、然后檢入（check in）。你只有在得到一個物理令牌時才能夠接觸到這段代碼。在我們這里，這個令牌就是一個Darth Tater玩偶，它放在你的工作的格子間或者書架上最顯眼的地方。
搜集度量數據 / Gathering Metrics
一旦我們的服務編碼完成，沒有錯誤，并且被檢入到代碼倉庫后，我們開始組件測試并搜集新代碼的度量數據。這是另外一個在新手團隊里被忽略的步驟。我懷疑“搜集度量數據”這個步驟甚至都沒有被包含在Joel測試中，因為Joel Spolsky的產品是一個桌面應用程序而不是一個需要重負載測試的web程序（或者，也許這個被隱含在“你有測試工程師嗎？”這個步驟里）
甚至在我們考慮將代碼放到實時代碼分支之前，我們就已經對代碼進行了數百萬次的請求測試。在蘋果公司，我們有一個非常復雜的緩存算法，根據我們設定的目標，它可以保存我們需要的任意數目的記錄。我們是否需要五百個或是五萬個產品的請求記錄緩存呢？在一次冷啟動開始之后，我們是否需要對指定的產品用緩存來“熱身”呢？在沒有任何的請求命中時，我們需要等多久才把一個產品從緩存中移除并釋放內存呢？
附注一點，我們的緩存通常是一個哈希表。哈希表的優點在于它的大O表示法運行時間是常量O(1)。當你在一個面試中被問道“什么事最快的查找函數”時，千萬不要說“一個B樹二叉樹”。完美的哈希表通常會輕松勝出。
調整并完成 / Tweaking and Done
我們會不斷調整代碼直到我們得到可接受的度量數據。我們的測量數據會對緩存內存消耗多少以及滿足每個服務請求/響應的時間長短進行度量。根據我們的需求，我們會努力達到99.7%的服務請求在35毫秒之內返回，95%的請求在10毫秒之內返回，沒有單個請求超過50毫秒的響應時間。
這些測試在一個非常接近產品環境的實時數據庫的拷貝中運行。這不能完美地指出web應用程序一旦在實際環境中會如何執行。但是將它變成一個設定期望的很好的辦法，這不會需要很久時間。
在我們“疾跑”（Sprint）結束的時候，所有這些度量數據都會作為敏捷定義“完成”時演示的一部分。這時代碼已經準備就緒可以被檢入質量保證的代碼分支，在代碼發布上線之前還會進行功能測試。
編注：
1. 大O表示法：用來描述算法的時間復雜度，O(1)的時間復雜度最低
2. 疾跑（Sprint）：是scrum開發方法的一個最基本開發單元 |
|
發表于 2011-7-11 13:22:50
收藏
頂
踩