3.5 Exchange TiP v2——將TiP遷移到Windows Azure云端
雖然第一個版本的服務毫無疑問地已經為公司帶來了收益，并且是度量和改進在線服務的主要工具，但是我們有一個大膽的計劃，那就是處理當前服務存在的問題，并使它具有更大的價值。第一個版本中最需要處理的3個問題是：
將執行移到公司網絡之外，來處理雷德蒙德地區的代理防火墻問題。
將測試執行的頻率增加到5分鐘一次或者更少時間。
將覆蓋擴展到所有的數據庫可用性組（Database Availability Group, DAG）和郵箱數據庫。
我們考慮了幾種方法來解決上述這些問題，如表3-4所示。
雖然我們還想維持現有測試執行用具的簡單易操作性，但很顯然的是，沒有任何潛在可用的環境能夠支持它。同時，與用具相關的所有報告、失效調查和工作流對于復合結果并不是非常有效，這使我們得出了一個結論：必須為測試更換執行夾具（harness）。最后我們決定將TiP基礎設施移到具有平臺優勢的Windows Azure上面的運行。最值得驕傲的是，因為我們設計測試架構的方式，所以移動到另一個平臺的時候不需要修改（事實上，我們只需要簡單地將測試移到新的夾具，而不需要重新編譯）。
表3-4 TiP框架潛在執行環境中的決策矩陣
將TiP框架從測試實驗室移到產品中，正是采用了TiP中將測試基礎設施從實驗室移到數據中心的思想。在這種情況下，我們進駐云端并構建了一個可擴展的、靈活的TiP服務。
圖3-5中的框架以插圖的形式說明了現在是如何執行產品測試的。通過使用Windows Azure，我們不僅具有了覆蓋現有標度單位的能力，還具有了對之前無法預期的新場景進行模擬的功能（比如，在提交給客戶之前，即便沒有成千上萬的用戶，仍然可以對數百個用戶并發地使用產品進行模擬）。隨著時間的推移，這個框架當然會不斷演進來滿足日益增長的需求。
圖3-5 Exchange TiP第二個版本的系統拓撲結構
3.6 我們的心得
TiP測試使我們可以找出數據中心上線過程中引入的問題和有時在產品中客戶還沒發現的問題。隨著時間的推移，還可以讓我們找出潛在問題、性能和總體功能表現的非常有趣的發展趨勢。
3.6.1 合作方服務相關的問題
對TiP測試至關重要的一個組成部分就是：找出我們所依賴的并在其上進行構建的與合作方服務相關的問題。我們的服務，與幾乎所有其他云端服務一樣，依賴于許多特定領域相關的不同服務。例如，我們依賴Windows Live ID來提供專門的身份驗證層。又如，命名空間管理和提供是依賴于在線域名服務的。在找出上面這些通過別的方面無法捕獲的依賴問題方面，我們的測試是非常有幫助的。
3.6.2 云端監視的挑戰性
Exchange作為服務很獨特的一個方面是它的目標客戶是IT專業人員，他們在升級到新的服務時總是非常謹慎，而且很多大客戶都定制了一些寫在Exchange頂層的產品。此外，有一些客戶在混合模式下運行，而另一個客戶僅僅只在公司的Exchange Servers中運行，也有一些是在云端運行的。在處理單個云端中版本的一些值得注意的、更持久的變化方面，標準監控解決方案設計得并不是很好。TiP測試在流經系統時，其版本和配置變化使我們能更好地在異構的云端測量和保證質量。這些挑戰對于很多云端服務來說是非典型的，如Bing、Facebook、Twitter, 更多的是使用同構的和松耦合的服務架構來獲取連續的部署模型。
盡管如此，我們的服務是分層的，且依賴于比Exchange團隊更快速的發布周期。網絡本身就是隨著新的Firmware版本和訪問控制列表（Access Control List, ACL）的改變而不斷更新的一個層。當那些層發生災難性的改變時，由監控服務（如Gomez 和Keynote）提供的黑盒方法會向運營中心發出警報，但是對于間歇型或邊緣情況卻不會發出警報。TiP使我們可以在這些依賴問題變成災難性問題之前深入分析并捕獲它們。在某些情況下，我們甚至可以在合作方服務升級過程中捕獲問題，這樣就可以提醒他們將這些變更進行回滾。
3.6.3 在線TiP測試所發現的一些問題
以下是通過TiP測試在產品中找到問題的一些樣例：
都柏林（愛爾蘭共和國的首都）的服務提供的一個隊列掛起了，但是監控器并沒有檢測到。
檢測到服務提供的延遲。
TiP檢測到了Hotmail運行中斷，Exchange團隊可以暫停并等待Hotmail的修復。
Live ID運行中斷影響了Exchange Cloud的客戶；Live ID的運營需要進一步加強。
TellMe, 一個可以將電話在我們的系統和手機交換器（Quest/Verizon負責的地上通信線和T-Mobile的移動電話）之間轉換的VoIP網關系統，需要對最終用戶連接場景的運行中斷進行監控。TiP是找出集成試點測試中所使用的電話號碼故障的唯一方法。
也常用TiP測試來鑒定發生隨時間不斷流逝的間歇失效的根本原因（隨著時間流逝出現故障的百分比，而不僅僅只是在單個事故中出現故障）。
3.6.4 聚集處理結果中的“噪聲”
我們學到了很多關于對一個實時服務如何執行測試的知識。學到的第一點就是，這種自動化的運行并不簡單。例如，因為是在公司防火墻后面運行的，所以只好按照雷德蒙德的代理服務器的路線來發送請求。這些代理服務器并非旨在擁有這種用途，所以導致了有時會出現請求丟失、主機查找失敗和其他奇怪的網絡故障等。這很快導致了第二種實現方法的出現，即在產品系統中運行自動化測試時，重要的不是個體的通過或者失敗的結果，而是隨著時間推移，這些結果的聚集體。聚集可以幫助識別一個問題是持久中斷問題還是僅僅只是一次網絡故障，因此可以將噪聲級減少到足夠低，這能對服務安全性進行更精確的提高。同時還可以幫助預測未來的發展趨勢，而只通過簡單地適時看一看統計結果是無法做到這些的。
【小竅門】
對細節過程進行監控是非常重要的，但留意總體趨勢也同樣重要。
當你注意到測試一個小時運行一次的時候，上述最后一點（關于噪聲消減）就變得十分重要。這一頻率受到測試執行框架上的內置假設的影響，即關于測試通過之后怎么配置（比如，假設每一個測試運行執行都必須出現在一個新部署的機器上）和關于測試本身是如何執行的。我們發現那些假設因為很多原因存在一些漏洞。
它們一個小時運行一次的另外一個原因是擔心消耗太多的生產力。我們發現一個服務必須要留出一些額外的設備來支持實時網站監控、使用過程中的高峰和低谷、拒絕服務攻擊和成長。如果以一個增長的頻率，比如每5分鐘一次，在每個產品簇中運行一個自動化功能測試集合來對服務的邊緣進行檢測，那么運行的這項服務的時間就太密集了，需要增加設備。但事實上，對許多IT組織來說，采購和安置專用硬件的成本太高，以至于他們覺得準備額外設備留作備用是很不可思議的。然而，隨著轉移到進行云計算并具有了對電腦和存儲資源的動態增長能力，很多組織都能負擔得起通過一些合理的額外設備構建一個服務以用于在線測試。
3.6.5 易犯的錯誤
我們得到的一個教訓就是，測試自動化比由外到內的基本監控更完整，并且由于這些測試的質量不錯，團隊很快就想將TiP系統作為一個加強的監控解決方案。但問題是，我們不可能對頻率為1小時的測試進行適時的反應，因為收集足夠的樣本來分析一個問題是否真的需要花費的太長時間。另一種辦法是在測試中實施重試邏輯（retry logic），這樣有可能進一步降低通過率并有可能因為瞬態問題而給你提供假陽性的結果（例如，因節流機制而引起發送信息失敗）。
我們得到的第二個教訓是，當處理橫向擴展的產品系統時，如果沒有一個類似的自動化測試橫向驗證策略，就有可能導致一種虛假的安全感。在最初的實施過程中，我們為每一個規模化單元的每個人創建了單個郵箱賬戶集合，問題是，規模化單元還有進一步的粒度分割，因為它們是由多服務器、可用組織和其他最初未說明的資源組成的。事實上，這意味著每個站點只能覆蓋一個可用的組織或者郵箱數據庫。這會導致事故不被基礎設施所捕獲的情形，因為規模化單元受到影響的那部分并不是我們所覆蓋的那部分。
除了作為回歸測試的金絲雀之外，TiP測試像我們的系統一樣，應該將其當作更健壯的持續改進項目（continuous improvement project，CIP）中的一員來對待。與大多數CIP一樣，高層管理人員的參與和帶動是成功的關鍵。管理人員與團隊的同心協力將保證工程團隊獲得支持以改善產品服務、彌補TiP和整個監控解決方案中其他元素（單服務器并且由外到內）的空缺。
3.7 總結
在線測試在這個快節奏的在線服務領域中是很有必要的，測試實驗室中的自動化測試應該擴展到產品中去，因為沒有哪一個服務是封閉的孤島，持續執行那些貫穿和驗證主要端到端（end-to-end）場景的測試用例，這將會增強簡單的單服務器（SCOM）或由外而內（Gomez or Keynote）可用性監控。持續回歸測試具有類似監視器的作用，可以針對服務運行中斷向產品服務團隊發出警報，而且該方法對于早期鑒定非用戶影響的間歇性bug特別有用。
雖然本案例研究是基于Exchange的，但測試自動化的趨勢，尤其是豐富自動化場景，在微軟服務團隊中發展非常迅速。同時，在產品云端運行這些解決方案的趨勢也越來越受到關注。我們期待通過自動化測試來加強監視作用的這類活動會，在整個微軟延續下去。
【小竅門】
在云端進行測試可能是你將來工作的一部分，從本章作者的這些經歷中學習知識吧！
3.8 致謝
感謝Keith Stobie 和Andy Tischaefer的同行審校，并感謝Karen Johnston對本章進行審稿。
（連載完）
相關鏈接：
自動化測試最佳實踐 連載一
自動化測試最佳實踐 連載二
自動化測試最佳實踐 連載三
自動化測試最佳實踐 連載四
自動化測試最佳實踐 連載五
自動化測試最佳實踐 連載六
自動化測試最佳實踐 連載七