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