跟著 Google 學測試自動化——淺談 Telemetry 的測試框架設計
Telemetry（專案主頁）是 Google 為 Chromium 專案所編寫的一套效能測試自動化框架。
從測試架構上以及實際使用中，Telemetry 均表現出極強的易用性和擴充套件性，本文試圖探討的就是 Telemetry 的框架是如何設計以及為啥這樣設計的。
Telemetry 體現的出的易用性以及擴充套件性
為了體現 Telemetry 的易用性和擴充套件性，首先我們得先來看看 Telemetry 的用法：
$ telemetry/run_benchmark --browser=canary smoothness.top_25以上命令將會讓 Telemetry 在名為 canary 的瀏覽器上執行一段已經預定義好的 Benchmark。而且從所執行的 Benchmark 的命名上我們可以看出，該Benchmark 的效能指標集合為 smoothness，站點集合為 top_25。
易用性
由於以上命令已經非常接近業務側的描述語言，因此使用者無需關注於實現細節，就能很好的使用 Telemetry 完成相關測試。也正是由於這種特性，Telmetry 除了監控 Chromium 和 Chrome 專案的核心效能， 也可以被用作評估 Web 服務的效能。
擴充套件性
Telemetry 已經提供了100+ 項 Benchmark，基本涵蓋效能測試的基本需求。但是如果想對其進行擴充套件也是及其方便的，僅需三步：
- Step 1. 在 page_sets 資料夾中依樣畫葫蘆的新建一個 your_new_pageset.py 檔案，新增上你所需的測試的站點。
- Step 2. 在 measurements 資料夾中新建一個 your_new_measurement.py 檔案，從預定義好的 metrics 中選擇你所需的指標，依樣畫葫蘆的新增進去。
- Step 3. 新增一個 benchmark，指明其 pageset 為 your_new_pageset，其 measurement 為 your_new_measurement 即可。
也即是說在 Telemetry 具備自動檢測變更並載入配置的能力。這將大大降低維護工作的成本。
Telemetry 是如何設計的
“事要知其所以然”,我們既然知道的 Telemetry 框架具有易用性強且擴張性強的特點，就應該費一點功夫弄清其框架的是如何設計和實現的。
當然框架設計這個命題有點大，因此我們重點從以下幾個方向來進行分析：
測試物件：
基於Chromium 和 Chrome 核心的所有瀏覽器，在 瀏覽頁面時
的效能資料。技術手段：
被測物件驅動：以 Chrome DevTools 的 Remote Debugging Protocol 為主，輔助以平臺相關的控制命令
效能資料來源：以 Inspector timeline and traces 為主，輔助以平臺相關的效能資料測試理念：
Telemetry 最小的可測試物件稱為一個基準（Benchmark）。測試所需的配置都被寫入到每個基準（Benchmark）中，來保證在不同機器上測試時的一致性。
而一個基準（Benchmark）可以包含有多個測試（Page Test），而這具有由頁面集合（ Page Set）和測量（ Measurement）組成，其中：
- 頁面集合（ Page Set）定義了測試（Page Test）集合中將會分別測試哪些頁面
- 測量（ Measurement）定義了在一次測試（Page Test）中將會測試哪些指標（Metrics）
測試框架設計方案
下圖是筆者根據原始碼結合自身理解所畫 Telemetry 測試框架的架構圖：
這個設計方案中有幾個明顯的特點需要指出：
頁面集合（ Page Set）和測量（ Measurement）是 Telemetry 中最為重要的核心元件。兩者幾乎完全解耦，因此理論上可以做到任意組合以形成新的基準（Benchmark）；
頁面集合（ Page Set）不僅定義好了頁面的URL，而且同時定義了對頁面的測試相關操作（Page Action）。因此在測試某些特殊站點（如需要登入賬號的站點）時，可以依賴統一的對外封裝介面，很方便的進行特殊的內部控制。
測量（ Measurement）僅僅決定用哪些指標（Metrics）以及怎麼通過這些指標（Metrics）來表達最終的結果。
指標（Metrics）中絕大部分都是由 Telemetry 框架預定義好的。
由於 Telemetry 對測試物件的高度抽象，因此整個測試過程也能高度抽象為一個基類 Page Test，無論頁面集合（ Page Set）中測試相關操作（Page Action）以及指標（Metrics）的具體實現都可以在 Page Test 所提供的介面中得以實現。
Telemetry 提供了測試所需的各種基礎類庫，例如用於錄製回放的 wpr，用於 Android 裝置控制的 devil，用於資料分析處理的 value 等等。
Telemetry 為何要這樣設計
正所謂“沒有對比就沒有傷害”，要想領會 Telmetry 設計的優秀，就先得縷一縷常見的自動化測試框架。
常見的自動化測試基礎框架
根據文章《Choosing a test automation framework》（原文、譯文）的總結，常見的自動化測試基礎框架有如下四種方案：
1.測試指令碼模組化框架（The Test Script Modularity Framework）
特徵：
通過建立獨立的，零件化的小指令碼，並通過分級的方式將這些小指令碼組成更大的指令碼，最終來實現一個特定的測試用例。
特點：
- 結構清晰，容易實現
- 在多人團隊中，較難實現團隊分工
2.測試庫構架框架（The Test Library Architecture Framework）
特徵：
與測試指令碼模組化框架的理念相同，區別在於建立的零件並非指令碼而是各種庫函式以及函式以供上層呼叫。兩者的區別特別像”面向過程”與”面向物件”。
特點：
- 高度模組化，提升了可維護性，在多人團隊容易實現分工
- 相對而言程式碼量較高
3.關鍵字驅動或表驅動測試框架（The Keyword-Driven or Table-Driven Testing Framework）
特徵：
該框架的特點是，發明了一套獨立於應用程式的”語言”。其中的每個測試項，其測試步驟（或方法）以及測試資料都被寫在詳細指引裡了。
特點：
- 用例可讀性強，用例可維護性強
- 實現框架的抽象程度高，難度大
4.資料驅動測試框架（The Data-Driven Testing Framework）
特徵：
該框架與關鍵字驅動或表驅動測試框架的區別是，只有測試資料包含在資料檔案中。
優缺點：
- 只需要非常少的程式碼就可以產生大量的測試用例
- 僅適用於測試場景可以高度抽象的情況
Telemetry 架構設計分析
上述四種框架是各有優缺點的基礎架構，在實際工程中最常見框架是上述技術的組合，抽取它們的優點，剔除其弱點。而 Telmetry 很明顯也就是綜合運用上述基礎框架模型而形成的。
那麼，為什麼 Telemetry 要這樣設計呢？我們可以簡單討論一下。
Q1: 為啥 Telemetry 沒有采用關鍵字驅動或表驅動測試框架（The Keyword-Driven or Table-Driven Testing Framework）？
A1: 因為 Telemetry 框架提供的是一種 Benchmark 型的測試。因此，需要的是一種可以在不同機器上保持測試一致性的能力，而非靈活定製化的能力。而且實現關鍵字驅動或表驅動的代價很高，所以沒有必要。但是為了保障其易用性，Telemetry 依然在呼叫命令上下了比較大的功夫，可以讓使用者直接從語義上明確當前測試的具體配置。
Q2: Telemetry 是如何使用測試庫構架框架（The Test Library Architecture Framework）以及測試指令碼模組化框架（The Test Script Modularity Framework）的？
A2: 由於 Telemetry 工程量較大，為了方便多人協作開發，整體上 Telemetry 是採用測試庫構架框架（The Test Library Architecture Framework）來設計的。但在具體的模組內部，也有采用測試指令碼模組化框架（The Test Script Modularity Framework）。
Q3: 簡單分析一下 Telemetry 中資料驅動測試框架（The Data-Driven Testing Framework）的應用？
A3: 雖然前面提到靈活定製化的需求對於 Telemetry 而言並不那麼重要，但是在 Page Set 中需要維護大量的站點，並可能存在更新維護的需求。目前，Telemetry 在 Page Set 內部簡單實現了一種類似資料驅動測試框架（The Data-Driven Testing Framework）的方式，方便我們從 List 中批量匯入被測站點。但筆者認為從方便更新維護的角度考慮，需要針對 Page Set 設計一個可以支援從外部匯入資料驅動測試的機制。
我們可以從 Google 身上學到的
由於筆者在工作中也從事瀏覽器相關的測試工作，因此對比了 Telemetry 與自己開發的測試框架之後，可以總結了如下一些可以從 Telemetry 中學習的要點：
高度抽象核心場景並實現充分解耦
Telemetry 在 Page Set 和 Measurement 上的充分解耦是該專案成功的關鍵，而解耦的基礎在於能夠抽象出其測試場景是“測試 瀏覽頁面時 的效能資料”。特別是將 Page Action 納入 Page Set 一併管理，而非將其歸屬於所謂的測試步驟中（筆者自己寫的指令碼就是這麼做的！囧！），很有借鑑意義。
實現上以測試庫構架框架（The Test Library Architecture Framework）為主
只要提供的不是 script，而是 framework ，理論上都應遵循這個設計。
注重工具的使用者體驗
本質上來講，關鍵字驅動或表驅動測試框架（The Keyword-Driven or Table-Driven Testing Framework）的本質就是為了降低使用者使用成本，從而提升使用者體驗。因此，我們的指令碼在使用上一定得做到“看上去就知道是給人用的”。
除非測試頻率高且變更快（對比 Chromium 的效能測試），不然暫時可以不用考慮關鍵字驅動或表驅動測試框架（The Keyword-Driven or Table-Driven Testing Framework）
實現成本太高了，這對後期設計其他的框架應該極具參考意義。