Telemetry（項目主頁）是 Google 為 Chromium 項目所編寫的一套性能測試自動化框架饲握。

從測試架構上以及實際使用中，Telemetry 均表現出極強的易用性和擴展性捐康，本文試圖探討的就是 Telemetry 的框架是如何設計以及為啥這樣設計的赂毯。

Telemetry 體現的出的易用性以及擴展性

為了體現 Telemetry 的易用性和擴展性懂算，首先我們得先來看看 Telemetry 的用法：

這是 Telemetry 官方文檔給出的 Telemetry 的一種基礎用法（引用至自 Telemetry: Run Benchmarks Locally）：

$ telemetry/run_benchmark --browser=canary smoothness.top_25

以上命令將會讓 Telemetry 在名為 canary 的瀏覽器上執(zhí)行一段已經預定義好的 Benchmark策严。而且從所執(zhí)行的 Benchmark 的命名上我們可以看出，該Benchmark 的性能指標集合為 smoothness凑保，站點集合為 top_25冈爹。

• 易用性

  由于以上命令已經非常接近業(yè)務側的描述語言，因此使用者無需關注于實現細節(jié)欧引，就能很好的使用 Telemetry 完成相關測試频伤。也正是由于這種特性，Telmetry 除了監(jiān)控 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 測試框架的架構圖：

  Test Automation Framework of Telemetry

  這個設計方案中有幾個明顯的特點需要指出：

  1. 頁面集合（ Page Set）和測量（ Measurement）是 Telemetry 中最為重要的核心組件辕宏。兩者幾乎完全解耦畜晰，因此理論上可以做到任意組合以形成新的基準（Benchmark）；

  2. 頁面集合（ Page Set）不僅定義好了頁面的URL瑞筐，而且同時定義了對頁面的測試相關操作（Page Action）凄鼻。因此在測試某些特殊站點（如需要登錄賬號的站點）時，可以依賴統一的對外封裝接口聚假，很方便的進行特殊的內部控制块蚌。

  3. 測量（ Measurement）僅僅決定用哪些指標（Metrics）以及怎么通過這些指標（Metrics）來表達最終的結果。

  4. 指標（Metrics）中絕大部分都是由 Telemetry 框架預定義好的膘格。

  5. 由于 Telemetry 對測試對象的高度抽象峭范，因此整個測試過程也能高度抽象為一個基類 Page Test，無論頁面集合（ Page Set）中測試相關操作（Page Action）以及指標（Metrics）的具體實現都可以在 Page Test 所提供的接口中得以實現瘪贱。

  6. Telemetry 提供了測試所需的各種基礎類庫纱控，例如用于錄制回放的 wpr辆毡，用于 Android 設備控制的 devil，用于數據分析處理的 value 等等甜害。

Telemetry 為何要這樣設計

正所謂“沒有對比就沒有傷害”舶掖，要想領會 Telmetry 設計的優(yōu)秀，就先得縷一縷常見的自動化測試框架唾那。

常見的自動化測試基礎框架

根據文章《Choosing a test automation framework》（原文访锻、譯文）的總結，常見的自動化測試基礎框架有如下四種方案：

• 1.測試腳本模塊化框架（The Test Script Modularity Framework）

  Example:The Test Script Modularity Framework

  特征：

  通過創(chuàng)建獨立的闹获，零件化的小腳本期犬，并通過分級的方式將這些小腳本組成更大的腳本，最終來實現一個特定的測試用例避诽。

  特點：

  • 結構清晰龟虎，容易實現
  • 在多人團隊中，較難實現團隊分工

• 2.測試庫構架框架（The Test Library Architecture Framework）

  Example:The Test Library Architecture Framework

  特征：

  與測試腳本模塊化框架的理念相同沙庐，區(qū)別在于創(chuàng)建的零件并非腳本而是各種庫函數以及函數以供上層調用鲤妥。兩者的區(qū)別特別像"面向過程"與"面向對象"。

  特點：

  • 高度模塊化拱雏，提升了可維護性棉安，在多人團隊容易實現分工
  • 相對而言代碼量較高

• 3.關鍵字驅動或表驅動測試框架（The Keyword-Driven or Table-Driven Testing Framework）

  Example:The Keyword-Driven or Table-Driven Testing Framework

  特征：

  該框架的特點是，發(fā)明了一套獨立于應用程序的"語言"铸抑。其中的每個測試項贡耽，其測試步驟（或方法）以及測試數據都被寫在詳細指引里了。

  特點：

  • 用例可讀性強鹊汛，用例可維護性強
  • 實現框架的抽象程度高蒲赂，難度大

• 4.數據驅動測試框架（The Data-Driven Testing Framework）

  Example:The Data-Driven Testing Framework

  特征：

  該框架與關鍵字驅動或表驅動測試框架的區(qū)別是，只有測試數據包含在數據文件中刁憋。

  優(yōu)缺點：

  • 只需要非常少的代碼就可以產生大量的測試用例
  • 僅適用于測試場景可以高度抽象的情況

Telemetry 架構設計分析

上述四種框架是各有優(yōu)缺點的基礎架構滥嘴，在實際工程中最常見框架是上述技術的組合，抽取它們的優(yōu)點至耻，剔除其弱點若皱。而 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 工程量較大足绅，為了方便多人協作開發(fā)，整體上 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 與自己開發(fā)的測試框架之后勋乾，可以總結了如下一些可以從 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）

  實現成本太高了帝洪，這對后期設計其他的框架應該極具參考意義似舵。