來源：Bill Liu 的部落格（@billliu_seattle）
前幾天回國轉了一圈，做了兩家企業質量管理培訓，一次上海測試沙龍，和chinatest兩次演講。收穫頗多，以後慢慢分享。回來後發現我的軟體質量實踐系列文章距離上一次發表已經有很長一段時間了。我想還是先把它寫完，再寫別的文章吧。那麼今天我們看看網際網路公司的另外一個大哥大是如何做質量控制的――Amazon.
Amazon是一個很傳奇的公司，它1995年的時候以一個網上書店起家，在短短的十幾年裡成為全球最大的線上購物公司。更為甚者，他在2005推出的AWS雲端計算服務更是被業界公認為雲端計算的鼻祖，也是現在全球最大最成功的雲端計算服務提供商。我一直堅信成功的產品一定是由成功的質量控制做保障的，採取什麼樣的測試策略只有兩個決定因素。一是企業文化，二是產品特點。在分析Amazon的測試策略之前，我們先看看它的企業文化。
業界關於amazon企業文化和成功要素有很多，我覺得實際上最為核心的只有一個，就是他們的“low margin, large volume”理念。就是通過單個商品的低利潤和巨大的銷售量來最終提高公司利潤和公司業務向前發展。工程團隊的理念就是要保障企業文化得以順利實施，所以Amazon的工程團隊的理念就是如何保障公司“low margin, large volume”的企業文化。Amazon工程團隊有以下特點：
●獨立的團隊：在Amazon，負責產品功能模組的每個團隊相對獨立。他們對該模組的所有功能，效能，開發，質量，上線，維護等從頭到尾的絕對負責。我們在Google中也可以明顯看的這一特徵.
●敏捷的團隊：為了保障團隊的敏捷，Amazon採用“2個比薩餅”的原則來看控制一個團隊的大小。也就是2個比薩餅就可以吃飽（5－7個人）的大小。團隊內部和團隊之間儘量減少工作的交接，一方面減少因為交接照成的不必要延遲，另一方面避免互相推卸責任。Amazon是最早採用敏捷開發（scrum）的公司之一，他們現在絕大多說產品組都是用scrum，據說有超過400多個CSM.
●面向服務的產品體系架構。在01年的時候，Amazon隨著它的產品線迅速擴大，業務邏輯越來越複雜，現有的產品體系架構極大地限制了整個公司的高速發展。他們重新設計了基於面向服務的，鬆耦合體系架構，使得各個模組獨立開發，修改和維護。所以Amazon可以在不犧牲質量的同時，快速推出新產品新服務。
很遺憾的是Amazon很少公開談論他們的質量管理流程和策略，不過通過有限的資料，還是不難看出他們的質量管理的策略：
●開發對質量負責：因為每個團隊對模組完全負責，並且要做到敏捷。Amazon要求開發對質量負責：從設計，寫程式碼開始一直到程式碼上線。開發做測試不僅可以儘快地發現bug，而且可以避免過分依賴測試人來提高質量，更為重要的優點是開發在設計是會考慮程式碼的可測試性 （因為他們自己要測試，肯定想方設法使得測試更為容易些），從而使得模組容易測試，容易維護，鬆耦合，最終極大提高模組質量。因為開發做了大量的測試，Amazon專職測試工程師也比較稀少（據說對開發的比例是1:7左右）。測試的主要職責是負責複雜使用者環境下的測試，以及開發測試工具，流程和基礎設施。而且很多產品組把一部分功能測試外包，所以即使Amazon的測試工程師不多，但是整個產品的測試工作卻沒有一點減少。
●自動化測試：這裡我就不在多說了，和microsoft, google一樣，他們開發了大量的測試工具和流程基礎設施來提高測試效率。開發專注於寫程式碼和測試，不用在搭建環境，部署，執行測試用例，和反饋上浪費時間。除了測試自動化外，他們也開發了一整套用以產品上線，維護和監控的工具和流程。只有這樣，開發才有可能既要寫程式碼，又要對程式碼質量從頭到尾負責。
●資料驅動的決策流程：和google一樣，Amazon全方位監控它的應用服務的執行狀態，從每個API呼叫時間，到使用者使用產品的每一步驟。根據對這些資料的分析和挖掘，開發團隊決定如何提高產品質量。
如果大家熟悉Google的軟體質量實踐應該可以發現，Amazon和google在軟體質量控制的理念和實踐有非常的相似之處。有所不同的是，google的很多專案以實驗性為目的，最初沒有任何專職測試。只有等到專案真的被重視後，測試才開始介入。做為網際網路產品的兩個大哥大，他們的測試方式或許可以代表著網際網路產品的測試發展方向吧。下一次我們介紹最後一個公司的測試策略－facebook。
【本系列文章】：