第3章 移動到云端：TiP的演化——在線的持續回歸測試
Ken Johnston
Felix Deschamps
來自微軟公司的Ken Johnston和 Felix Deschamps講述了他們是如何通過在云端實施自動化測試，從而將基于產品的自動化測試變更為基于服務的自動化測試的。微軟的郵件服務產品Microsoft Exchange Server中絕大多數的測試已經實施自動化了，而且其中大量的自動化是可以重用的。大多數測試人員對于“在線測試”（Testing in Production, TiP）這個概念還比較陌生，但是這一章解釋了為什么進行持續監測是必要且有益的，同時為那些也正在考慮這么做的人提供了一些非常有用的小竅門。案例發生在美國，經歷了3年多的時間，毫無疑問，使用到了微軟公司的一些工具，如表3-1所示。
表3-1 案例研究特征
3.1 本案例研究的背景
你會將一個價值十億美元的業務作為賭注放在云端嗎？
Exchange 2007的發布對我們團隊來說是非常令人振奮的。在剛推出這款產品的時候，我們已經成功地對產品架構進行重新設計，以使它能在本地的.Net平臺上運行，從而轉化到通過“角色”（role）來支持服務器管理，把64位機器作為目標平臺，采用Windows PowerShell作為自動化服務器管理的工具箱。我們已經做好了迎接下一個挑戰的準備！
那時，微軟的總架構師Ray Ozzie正準備構建微軟云計算未來的發展藍圖。我們都很清楚，云計算將會越來越重要，而正好Exchange產品也在尋求這種百年一遇的重大商機。通過云計算，我們可以在為客戶降低成本的同時，給他們提供更好的服務，同時，我們也可以將Exchange產品中的業務發展壯大。
實施云計算這一舉措也為我們引入了更多的問題。我們如何構建一組特性來吸引IT專業人員升級到Wave 14 （發布名稱為Microsoft Exchange Server 2010）版本，同時又能以某一服務作為目標呢？我們又該如何對產品架構重新進行設計，以使它能夠在運行遍布全球的服務前提下實現規模經濟效益呢？何況現在我們不僅僅需要構建所需的軟件，而且還要構建數據中心，這從何做起？
我們進入到完整的原型和發現模式。我們學習了很多新的web服務概念，以便通過冗余將服務進行縱向和橫向擴展：
我們需要對多租戶進行架構設計，這樣單個服務實例就能服務于多個客戶組織（租戶）。
我們將為了滿足某個功能的一組邏輯上的機器確定為不同的單元（有時稱為小群組），這樣有利于規劃所獲取的單元。
服務必須是遍布全球的，以支持業務連續性規劃（Business Continuance Planning，BCP），并通過區域市場減少延遲。
我們學習了如何使服務成為一種業務，以及為什么必須對固定資產費（Capital Expenditure, CAPEX，如購買新的服務器開銷等）、運營費用（Operational Expenditure，OPEX，比如給經營服務的員工發放工資等）以及總銷貨成本（Cost Of Goods Sold，COGS）進行管理。懂得了服務器并不是像變魔法似的出現在數據中心，恰恰相反，我們必須提前一年就擬定采購計劃，同時，對整個數據中心的空間大小、供電和網絡配置也要進行安排。對于那些曾經從事過一段時間的服務工作的人來說，這聽起來都是些基本的知識，但是我們想讓整個團隊的人員都清楚這些服務理念，并真正懂得我們將服務業務實施云策略的意義。
受到以上學習過程的啟發，我們決定使用以下的一組原理來推動Wave 14的發布：
復用和擴展現有的基礎設施。
Exchange將保留一個代碼庫。
我們的團隊是一個整體，不會分裂為服務工程團隊和服務運營團隊兩個獨立的團隊。
3.2 將測試移到云端
作為專業的測試團隊，我們很容易厘清該如何同時地測試一臺服務器和一項服務。但是如何將現有的自動化測試豐富的資產應用到服務空間？最終的答案是：在線測試（Testing in Production, TiP），在當時看來這是我們之前決不會做的事情。我們的起點是一些現有的工具和資產，如表3-2所示。
表3-2 Exchange產品測試的現有工具和資產
① 用于描述軟件公司使用自己的產品這種情況。
因為Exchange是世界上功能最復雜的產品之一，所以我們已經建了一個龐大的工程流水線來開發和測試我們的產品。其中僅測試實驗室就有大約5000臺機器用于運行日常的測試和預檢入（pre-check-in）的測試。在這些機器模擬測試場景（如具有多級動態目錄的網站、不同的故障轉移配置、多角色配置等）的復雜拓撲結構中，我們每周對Exchange的80 000次自動部署進行相關測試。到2007年年末，我們已經編寫了將近70 000個自動化測試用例來對產品進行驗證，我們每天都運行這些自動化測試用例，且每次提交代碼之前必須運行其中的某些測試用例。我們使用Microsoft Visual Studio作為我們自動化測試工具的開發環境，大部分是使用C#語言進行開發的，但也有少部分是使用JavaScript和C++語言進行開發。
與大多數微軟的產品研發團隊一樣，我們要吃自己的狗食。在很多文章和博客上都談到“如何把產品當狗食來吃”的概念。在這里，指整個Exchange團隊將他們的郵箱裝在團隊的dog food（beta版）環境中或者基于云端的dog food環境中，為了增加復雜性，我們讓兩個dog food環境無縫地協同工作，即便每兩周都要升級到最新版本，也是如此。
這一級別的自動化允許我們建立單一的主代碼分支，并使之在多個產品單元之間具有一致的文件版本。這是通過維護一定數量的編譯錯誤（構建過程中斷）和最小范圍的回歸來完成的。在dog food中有了自己的郵箱，可以允許我們很快地找出被測試忽略的功能問題，并能增強對正在構建的產品性能的自信心。因為我們正轉向基于服務的自動化，所以繼續獲得這種自信是非常重要的。我們采用的新工具和模型如表3-3所示。
表3-3 新的工具和模型
我們的每一個新工具和過程都吸取了推出Exchange Server產品時的經驗。對于我們來說，解決如何與別的服務進行集成，以及如何在產品數據中心進行傳統的測試活動，是一個新的轉折點。
3.2.1 TiP測試策略的目標
我們設定的TiP測試策略目標是：
積極主動地發現產品線所存在的問題；
積極測試服務dog food；
驗證新的產品上線；
確認配置變更或升級不會導致任何中斷；
通過我們的附屬服務進行合作方注銷測試，如Windows Live ID；
衡量并幫助提高現有的系統中心運行管理器（system center operations manager，SCOM）監控方案；
發現潛在的缺陷；
工程團隊可以使用這些測試來了解產品試驗。
有了適當的目標之后，就要將它們作為測試——尤其是TiP測試的指導原則，并保證它們與整個Exchange項目的目標是一致的。我們最終選中了一組專注于效率和重用的原則。效率原則是指在復雜度最低的環境中用最快的速度找出正確的bug集合，OneBox是最主要的資產。另外，我們還選擇將許多OneBox測試環境搭建在數據中心。使用以上方法時，會出現很多因數據中心網絡和安全設置所產生的額外bug。重用變得至關重要，因為它意味著將現有的資產和過程擴展到數據中心和產品中，用于更快地產生好的測試結果。
3.2.2 指導原則
我們使用以下原則來指導我們的開發：
沒有獨立的團隊，現有功能的測試團隊都要參與。
產品中同樣的代碼庫意味著我們應該嘗試著復用整個產品和測試資產（自動化測試、測試裝置、測試工具和流程），但是現在就在產品線上。
在實驗室完成功能測試，意味著我們要在產品線上做進一步的測試，通過扮演客戶的角色來驗證用戶體驗。一些TiP方法利用可測試性特性深入到在線網站的堆棧中去，但是在最初實施時，我們堅持使用模擬終端用戶進行黑盒測試的方法。
對測試場景的設計應該考慮其測試的廣度，而非深度（即盡可能多地描述測試場景的覆蓋面，同時測試場景的執行盡可能地快）
【真知灼見】
明確自己的目標，并為自動化測試設計可以實現的指導原則。
3.3 如何實施TiP
第一步是讓測試經理也支持這些指導原則，然后再與團隊的資深成員緊密合作，并根據所有主要功能區對原則進行評審。這一過程保證了我們之間沒有隔閡，并且能夠很好地在不同領域利用測試人員的專業技術知識。這個虛擬團隊定義了40多個場景，這些場景代表了視為最重要的功能的寬度。
【真知灼見】
避免白費力氣做重復的工作；盡可能地復用現有的自動化測試件。
第二步是決定如何將上面的40多個場景在整個產品系統中具體實施。如前所述，我們要盡可能地重用已有的資產，所以我們集中精力盡快定義和開發出所需的測試。最初實施時，我們決定使用現有的測試執行框架來運行測試，那樣的話，就可以重用現有的測試報告工具、機器管理等，這也使得我們可以利用現有的自動化測試庫。
我們的第一次實施的具體結構見圖3-1。每小時執行引擎都會自動部署一臺新機器，并安裝相應的客戶庫、工具和測試，也安裝一個“云定義”文件，該文件以一種通用方法描述了目標環境。測試本身并不知道目標環境的任何信息，通過這種抽象的方法我們可以指向某個數據中心、某個邏輯單元或者某臺特定的機器（實際上現在是在預檢入工作流中完成的）。
【小竅門】
另一種級別的抽象：將測試從機器和它們所運行的環境中分離出來。
圖3-1是TiP系統拓撲結構的第一個版本，具有如下特點：
1）部署一臺自動化測試主機，在特定的數據中心運行測試。
2）將測試結果發送到Focus測試執行（Focus Test Execution, FTE）服務器上，它將對測試結果進行處理（Focus是工具的名稱）。
3）結果將保存到一個公用數據庫上。
4）在運行過程中，TiP診斷服務周期性地對結果進行收集。
5）收集的結果會返回給數據庫。
6）遇到問題時，產品bug會自動顯示出來。
7）診斷服務給管理區發送一個請求信息，包含分頁調度和報警信號的邏輯信息。
8）請求信息被發送到SCOM根管理系統（Root Management System，RMS）進行處理。SCOM的警報解除了，同時啟動相應的響應處理機制。
圖3-1 Exchange TiP第一個版本的系統拓撲結構
最初，在將服務提供（為用戶注冊和新建郵箱）給新用戶之前，我們通過測試來驗證服務的新部署。后來我們發現，盡管如此，與傳統的以軟件為中心的世界中我們只需保證軟件質量不同的是，我們現在所經營的服務是一直變化的。不僅配置（域名系統（Domain Name System, DNS）、補丁、新的租戶等）經常發生變化，更新的變化也很多，這意味著隨著時間的增長，可能會遇到沒有測試過或預料到的更新或者小的配置變動。根據我們的經驗，即便是對產品來說安全的改變也可能會使服務中斷。這也是為什么我們決定采用連續運行測試的方式，而不僅僅只是在進行部署的時候運行一次。
TiP具有一點類似產品服務監控器的作用；然而，相比于傳統的輕量級服務監控，我們所運行的測試集更深入，端到端（end-to-end）場景魯棒性更強。同樣，TiP測試就變成了煤礦中的金絲雀，能對潛在用戶面臨問題提供更早的警報。過去是使用其他構建在Microsoft System Center頂端的基于代理的監控解決方案，然而，這些代理只是停留在單機器層面。TiP測試作為最終用戶來運行，并且當它們使用性能降低的時候，會發出警告。
【真知灼見】
不要僅僅通過一種途徑來實施自動化，盡可能使用多種有用的方法。不同方法之間可以互補并且往往比單獨使用一個方法更有效。
作為我們整個決策的一部分，我們決定停止使用第三方服務，像Gomez和Keynote。雖然在整個決策中非常重要，這種類型的監控關注的主要是一些比較片面的場景（比如登錄）的服務可用性。與此同時，TiP場景的寬度比其他測試要小（高級測試只有40個測試用例，而實驗室運行的端到端的場景中有70 000多個測試），所以比一般服務的深度肯定是要大些。
通過使用自己的基礎設施，例如，我們可以很容易地給手機的ActiveSync協議添加新的驗證信息，這在傳統的黑盒監控環境中是很難做到的，因為協議具有復雜性。另一方面是敏捷度，根據產品環境和測試本身，在數據中心我們可以進行更改并對更改作出快速回應。因此，正如只關注單機器的SCOM監控基礎設施一樣，這些TiP測試對外部黑盒測試是一種補充，而不是取代它。
3.4 每月服務評審記分卡樣例
每個月都會對總體的服務質量（Quality of Service, QoS）進行一次評審，同時，根據上個月的結果進行有針對性的改進也是要進行評審的。這種評審有利于持續改進總體服務，并幫助改進TiP套件。這種每月的評審是由經理發起的，并且他每個月都參與其中，推動問答(Q&A)環節的進行。這也是他每個月深入實況網站并對其進行改進的一次機會。經理的支持和帶動作用對任何一個類似這樣的項目都是至關重要的，而我們從一開始就很幸運。圖3-2所示是一個記分卡的例子。
圖3-2 調整記分卡中的事故和調整情況
3.4.1 閱讀記分卡
當你看到TiP記分卡時，提出的第一個最典型的問題就是：怎么閱讀記分卡？這是一個很好的問題。
首先需要注意的是，圖3-2中所示的記分卡只是每月進行評審的幻燈片中的某一頁。首先將每月的數據放到一個很大的Excel數據表格中，然后高級管理層和其他團隊將Excel中的每項數據放到一頁幻燈片中進行評審。
圖3-3顯示了將記分卡按不同的區域進行分解后的情況。區域1提供了指向Excel表格中具體行的標記。因為幻燈片中空間有限，所以只顯示了最近3個月的數據，但事實上，Excel電子表格包含的不僅僅只是這3個月的數據。在評審過程中，每個人都有這個Excel電子表格的一份副本，并通過在自己的筆記本電腦上進行評審來對幻燈片的內容進行更新。
區域2是細分（drill-down）后的區域的名字。在給出的例子中該區域的名稱是“事故及調整情況”。
區域3是從Excel表格報表中拉出的數據。包括度量的名稱以及最近3個月的數據。在圖3-3所示的樣例中，數據根據事故數量和服務組件，按月顯示。當整個Exchange 云端服務的某個組件發生了一次故障，并需要人工干預來進行解決，則稱為一次事故（incident）。通過最近3個月的數據，即便在已經達到每月目標的前提下，還可以幫助我們確認服務的發展趨勢是好是壞。
圖3-3 事故記分卡區域中的事故和調整
區域4是整個記分卡最重要的部分。在每個月評審之前還有一個預評審，是由負責改進該區域服務的工程師進行的。在遇到事故和調整的情況下，測試、開發和運營團隊中的成員都會派代表參與預評審。他們分析數據，找出異常值和負面走向線。風險區域和關注區域分別用綠色和紅色的圓點標記。在圖3-2中，黑色的實心圓點代表紅色，或者是PPT幻燈片中應關注的區域。有時候他們知道某一個度量的趨勢走向不好的具體原因，但是更多的時候，他們只能進行猜測。此時就要依靠虛擬小組的成員來找出負面走向度量和異常值的根本原因。上述調查的結果就是圖3-3中記分卡區域4的內容。通常，如果造成負面走向的根本原因是已知的，那么區域4中的內容就是一些總結性的建議補救方法。
【真知灼見】
對報表進行裁剪，使它僅提供你所需要的有用信息。
3.4.2 對事故和調整報表的處理
根據事故和調整記分卡，可以分析各個方面引起的事故。引起事故的原因包括SCOM服務器級別的監控器、TiP服務級別的監控器，以及與第三方監控一起運行的一些監控器，旨在保證我們與全球市場都有聯系。影響我們減少用戶方面bug的能力的兩個主要因素是：一是監控過程中遺漏的真正問題的數量和嚴重性，另一個是等待時間(Time To Engage, TTE)。在整個行業和微軟公司內部都有很多計算TTE的公式。對于Exchange來說，TTE是指從產品事故開始到找到合適的工程師（開發人員或測試人員）著手修復該故障所花費的時間（以分鐘計算）。一般來說，不管是在業務時間還是之外，導致TTE很慢的最典型的原因是監控器遺漏。這兩個度量緊密相關，并且是每個月關注的重點之一。它們中只要有一個出現問題，我們就要考慮需要更新哪個監控方案（SCOM、TiP，或第三方監控），有時候會給這3種監控方案都增加監控器。
TiP功能可用性記分卡用來提供粒子級別上服務可用性指標。可用性是通過以下公式來計算的：
通過為每個特性運行TiP，我們可以發現非客戶影響的小的服務中斷的發生，如ActiveSync中斷。子服務中這種短暫的中斷可能并不會對客戶產生影響，但是卻代表了服務的風險和退化。間歇失效或者（掛起）隊列，與服務提供一樣，通常都是可以在這個記分卡上顯示出來的，但是并不是在關注調整的那張記分卡上（見圖3-4）。
圖3-4 TiP 功能可用性記分卡
【真知灼見】
經常利用自動化測試生成的信息來監控服務的發展、尋求進一步提高、保持自動化優勢的前景，這是非常重要的。
（未完待續...）
相關鏈接：
自動化測試最佳實踐 連載一
自動化測試最佳實踐 連載二
自動化測試最佳實踐 連載三
自動化測試最佳實踐 連載四
自動化測試最佳實踐 連載五
自動化測試最佳實踐 連載六