前幾天回國轉了一圈，做了兩家企業質量管理培訓，一次上海測試沙龍，和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。

原文鏈接：http://blogs.msdn.com/b/billliu/archive/2012/08/20/amazon.aspx