Telemetry（項目主頁）是 Google 為 Chromium 項目所編寫的一套性能測試自動化框架。
關(guān)于 Chromium 的可測性設(shè)計的效果，筆者可以給一個簡單的數(shù)據(jù)：
由于筆者在工作中也從事瀏覽器相關(guān)的測試工作呻率，以工作中的 Android 平臺內(nèi)核渲染性能測試為例：
剛開始的時候，由于不了解 Chromium 在可測試性設(shè)計上的內(nèi)容（可視作沒有作可測試性設(shè)計）苛蒲，由于在線頁面的渲染測試的數(shù)據(jù)波動性較大笋颤，為了獲得穩(wěn)定的性能數(shù)據(jù)，一輪測試需要耗時 4 小時都毒；
使用了 Chromium 的 Telemetry 平臺之后（可視為已經(jīng)完成了可測試性設(shè)計）色罚，相同規(guī)模的測試在 Telemetry 耗時僅 0.5 小時。
上面的數(shù)據(jù)是筆者在工作中實際統(tǒng)計的數(shù)據(jù)账劲，那么 Chromium 以及 Telemetry 究竟在可測試性做了哪些工作保屯，可以使得測試效率有接近 8 倍的提升呢？ 這就是本文接下來要嘗試分析的內(nèi)容涤垫。
可測試性設(shè)計包含哪些內(nèi)容
由于可測試性設(shè)計是一個相當(dāng)務(wù)虛姑尺，又相當(dāng)有效的話題。所以我們有必要在正式展開這個話題之前看看蝠猬，軟件的可測試性設(shè)計包含哪些方面的內(nèi)容：
PS: 下述內(nèi)容整理自 《軟件可測試性設(shè)計》 一文切蟋，為了便于理解，修改了部分用詞：
- 1.可操作性：“運行得越穩(wěn)定榆芦，被測試的效率越高柄粹。”
- 2.可觀察性：“你所看見的就是你所測試的匆绣∽び遥”
- 3.可控制性：“對軟件的控制越好，測試越能夠被自動執(zhí)行與優(yōu)化崎淳】柏玻”
- 4.可分解性：“通過控制測試范圍，能夠更快地分解問題拣凹，執(zhí)行更靈巧的再測試森爽。”
- 5.簡單性：“需要測試的內(nèi)容越少嚣镜，測試的速度越快爬迟。”
- 6.低變更性：“改變越少菊匿，對測試的破壞越小付呕〖聘＃”
- 7.易理解性：“得到的信息越多，進行的測試越靈巧徽职“羲眩”
其實上述 7 個方面都十分重要。但是由于 Chromium 以及背后的 webkit 以及 blink 是事實上的行業(yè)標(biāo)準(zhǔn)活箕。因此力麸，在以下 3 個方面所做的工作是顯而易見的：
- 可操作性：“運行得越穩(wěn)定，被測試的效率越高育韩】寺欤”
- 低變更性：“改變越少，對測試的破壞越小筋讨“０龋”
- 易理解性：“得到的信息越多，進行的測試越靈巧悉罕〕辔荩”
因此，我們需要重點關(guān)注的就是 Chromium 以及 Telemetry 在剩下的幾個方面為可測試性做了哪些工作：
- 可觀察性：“你所看見的就是你所測試的壁袄±嘣纾”
- 可控制性：“對軟件的控制越好，測試越能夠被自動執(zhí)行與優(yōu)化嗜逻∩В”
- 可分解性：“通過控制測試范圍，能夠更快地分解問題栈顷，執(zhí)行更靈巧的再測試逆日。”
- 簡單性：“需要測試的內(nèi)容越少萄凤，測試的速度越快室抽。”
Chromium 以及 Telemetry 為可測試性做了哪些工作靡努？
那么坪圾，Chromium 團隊在上述這幾個方面是怎么做的呢？我們接下來一一拆解颤难。
可觀察性——The Trace Event Profiling Tool (about:tracing)
眾所周知神年，測試是要以數(shù)據(jù)來說話的。因此行嗤，可測試性設(shè)計中尤為重要的就是被測對象能夠具備良好的可觀察性。對于 Chromium 項目而言垛耳，其可觀察性的能力主要由 The Trace Event Profiling Tool (about:tracing) 工具來提供栅屏。為了方便飘千，下面均簡稱 Tracing 工具。
關(guān)于 Tracing 工具栈雳，我們先給出 Google 對于這個工具的定義：
When diagnosing performance problems it can be valuable to see what Chrome is doing "under the hood." One way to get a more detailed view into what's going on is to use the about:tracing tool.
對于 Tracing 工具的具體能力护奈，簡要來說就是，它記錄了 Chromium 中各進程以及各線程中每個方法的活動情況哥纫，既包含由 C++ 實現(xiàn)的內(nèi)核調(diào)用情況霉旗，也包含由 JavaScript 實現(xiàn)的頁面調(diào)用情況。
此外蛀骇，Tracing 提供了一個很重要的能力——支持自定義加入Tracing厌秒。具體可以參考：Adding Traces to Chromium/WebKit/Javascript。
正是如此擅憔，Telemetry 所用的基礎(chǔ)數(shù)據(jù)主要來源于 Tracing鸵闪，相較于我們從系統(tǒng)或者其他三方APP獲取數(shù)據(jù)，Tracing的數(shù)據(jù)無疑可以包含更多的細(xì)節(jié)而且可信度更高暑诸。
可控制性——Remote Debugging Protocol
《持續(xù)交付——發(fā)布可靠軟件的系統(tǒng)方法》中給出了一個它所推薦的自動化驗收測試的層次：
- 驗收條件：支持以“假如／當(dāng)／那么”的形式將驗收條件寫入測試中
- 測試實現(xiàn)層：代碼使用領(lǐng)域語言蚌讼，不引用UI元素
- 應(yīng)用程序驅(qū)動層：理解如何與應(yīng)用程序進行交互，來執(zhí)行一系列動作个榕，并返回結(jié)果
而要實現(xiàn)這種具備高可維護性特征的設(shè)計篡石，對應(yīng)用程序驅(qū)動層要求很高。特別是類似 Telemetry 這樣要求在 GUI 層面上執(zhí)行測試西采，一般而言應(yīng)用程序驅(qū)動層的實現(xiàn)代價很大夏志。
再次引用《持續(xù)交付——發(fā)布可靠軟件的系統(tǒng)方法》的原話：
假如應(yīng)用程序設(shè)計得比較好，GUI 層僅是清晰定義用于數(shù)據(jù)展現(xiàn)的代碼苛让，不包括任何業(yè)務(wù)邏輯沟蔑。在這種情況下，繞過界面狱杰，基于界面下的代碼進行測試的風(fēng)險會相對小一些瘦材。將可測試性銘記于心，寫出來的應(yīng)用程序就會有一個 API仿畸，使 GUI 和測試用具（test harness）都可以用它來驅(qū)動應(yīng)用程序食棕。
Chromium 項目也實現(xiàn)了這么一個 API，就是 Remote Debugging Protocol错沽。
簡單來說簿晓，Remote Debugging Protocol 就是用來與瀏覽器頁面交互和調(diào)試的協(xié)議通道。它采用 websocket 來與頁面建立通信通道千埃，由發(fā)送給頁面的 commands 和它所產(chǎn)生的 events 組成憔儿。chrome 的開發(fā)者工具是這個協(xié)議主要的使用者，第三方開發(fā)者也可以調(diào)用這個協(xié)議來與頁面交互調(diào)試放可。
Remote Debugging Protocol 分為不同的功能模塊域：
上述模塊幾乎涵蓋瀏覽器的所有操作谒臼，由于 Remote Debugging Protocol 調(diào)用瀏覽器的方式完成操作與 UI 操作實現(xiàn)原理一致朝刊。因此對于驅(qū)動層的實現(xiàn)幫助極大。
也正是通過 Remote Debugging Protocol蜈缤， Telemetry 可以更精確的操控 Chromium拾氓，而不受系統(tǒng)輸入系統(tǒng)的影響。而這對于 GUI 性能測試而言意義重大底哥，也是文章開頭所舉例子中的測試效率提升的關(guān)鍵所在咙鞍。
可分解性——Run Chromium with flags
一個使用的功能肯定是由許許多多的功能模塊組成的，但是在測試的過程我們需要擁有靈活的能力去操作這些功能模塊趾徽，以便于我們更加靈活的設(shè)計我們的測試方案续滋。
舉個簡單的例子，Chromium 同時具備軟件渲染（software rasterization）以及硬件渲染（GPU rasterization）的能力附较，而且默認(rèn)使用硬件渲染（GPU rasterization）吃粒。當(dāng)我們需要重點關(guān)注軟件渲染（software rasterization）的性能時。我們需要 Chromium 具備一種便于我們更改這種默認(rèn)設(shè)置拒课，以便單獨針對該模塊實現(xiàn)測試徐勃。
于是 Chromium 為我們開放了 Run Chromium with flags 的能力。
There are command line flags (or "switches") that Chromium (and Chrome) accept in order to enable particular features or modify otherwise default functionality.
Current switches may be found at http://peter.sh/examples/?/chromium-switches.html
得益于 Run Chromium with flags 所提供的可分解性設(shè)計早像，Telemetry 才功能通過傳入不同的啟動參數(shù)的方式實現(xiàn)不同的測試需求僻肖。我們不敢相信，如果這些特殊功能的測試都需要開發(fā)單獨打包才能實現(xiàn)的話卢鹦，這是怎樣一種坑爹的場景臀脏。
簡單性——產(chǎn)品簡單才是一切的核心
最后一點，其實說起來應(yīng)該也不完全時可測試性設(shè)計所需要關(guān)注的內(nèi)容冀自。當(dāng)一個產(chǎn)品本身很復(fù)雜時揉稚，是不可能從根本上設(shè)計出一種簡單的測試方案的。因此熬粗，要想測試變得優(yōu)雅搀玖，首先產(chǎn)品必須得優(yōu)雅。
至于 Chromium 項目為我們展示的就是這種優(yōu)雅驻呐，幾乎只提供核心能力：頁面瀏覽灌诅。
得益于產(chǎn)品的定位，Telemetry 才可以僅關(guān)注“瀏覽頁面時“的性能數(shù)據(jù)含末。從而逐步封裝猜拾，給出這樣的框架下面框架設(shè)計。
我們不妨設(shè)想一下佣盒，如果 Chromium 包含諸如軟件管理挎袜，系統(tǒng)清理，新聞推送等其他功能時，Telemetry 能否給出上述的測試框架設(shè)計宋雏？
我們可以從 Google 身上學(xué)到的
所實話芜飘，上述工作大部分都屬于 SDET（Software Development Engineer in Test） 的職責(zé)范疇务豺，如果所在公司的相關(guān)崗位只有 STE（Software Test Engineer） 的話磨总，那么這個 STE 在上述事情參與程度可能不會太多。
但是笼沥，無論如何蚪燕，明白“如何讓產(chǎn)品變得優(yōu)雅，讓測試變得優(yōu)雅”是非常重要的事情奔浅。況且夢想還是要有的馆纳，萬一實現(xiàn)了呢。
