Telemetry（項(xiàng)目主頁）是 Google 為 Chromium 項(xiàng)目所編寫的一套性能測(cè)試自動(dòng)化框架。
關(guān)于 Chromium 的可測(cè)性設(shè)計(jì)的效果，筆者可以給一個(gè)簡(jiǎn)單的數(shù)據(jù)：
由于筆者在工作中也從事瀏覽器相關(guān)的測(cè)試工作，以工作中的 Android 平臺(tái)內(nèi)核渲染性能測(cè)試為例：
剛開始的時(shí)候，由于不了解 Chromium 在可測(cè)試性設(shè)計(jì)上的內(nèi)容（可視作沒有作可測(cè)試性設(shè)計(jì)），由于在線頁面的渲染測(cè)試的數(shù)據(jù)波動(dòng)性較大，為了獲得穩(wěn)定的性能數(shù)據(jù)，一輪測(cè)試需要耗時(shí) 4 小時(shí)；
使用了 Chromium 的 Telemetry 平臺(tái)之后（可視為已經(jīng)完成了可測(cè)試性設(shè)計(jì)），相同規(guī)模的測(cè)試在 Telemetry 耗時(shí)僅 0.5 小時(shí)。
上面的數(shù)據(jù)是筆者在工作中實(shí)際統(tǒng)計(jì)的數(shù)據(jù)，那么 Chromium 以及 Telemetry 究竟在可測(cè)試性做了哪些工作，可以使得測(cè)試效率有接近 8 倍的提升呢？ 這就是本文接下來要嘗試分析的內(nèi)容。
可測(cè)試性設(shè)計(jì)包含哪些內(nèi)容
由于可測(cè)試性設(shè)計(jì)是一個(gè)相當(dāng)務(wù)虛，又相當(dāng)有效的話題。所以我們有必要在正式展開這個(gè)話題之前看看，軟件的可測(cè)試性設(shè)計(jì)包含哪些方面的內(nèi)容：
PS: 下述內(nèi)容整理自 《軟件可測(cè)試性設(shè)計(jì)》 一文，為了便于理解，修改了部分用詞：
- 1.可操作性：“運(yùn)行得越穩(wěn)定，被測(cè)試的效率越高。”
- 2.可觀察性：“你所看見的就是你所測(cè)試的。”
- 3.可控制性：“對(duì)軟件的控制越好，測(cè)試越能夠被自動(dòng)執(zhí)行與優(yōu)化。”
- 4.可分解性：“通過控制測(cè)試范圍，能夠更快地分解問題，執(zhí)行更靈巧的再測(cè)試。”
- 5.簡(jiǎn)單性：“需要測(cè)試的內(nèi)容越少，測(cè)試的速度越快。”
- 6.低變更性：“改變?cè)缴伲瑢?duì)測(cè)試的破壞越小。”
- 7.易理解性：“得到的信息越多，進(jìn)行的測(cè)試越靈巧。”
其實(shí)上述 7 個(gè)方面都十分重要。但是由于 Chromium 以及背后的 webkit 以及 blink 是事實(shí)上的行業(yè)標(biāo)準(zhǔn)。因此，在以下 3 個(gè)方面所做的工作是顯而易見的：
- 可操作性：“運(yùn)行得越穩(wěn)定，被測(cè)試的效率越高。”
- 低變更性：“改變?cè)缴伲瑢?duì)測(cè)試的破壞越小。”
- 易理解性：“得到的信息越多，進(jìn)行的測(cè)試越靈巧。”
因此，我們需要重點(diǎn)關(guān)注的就是 Chromium 以及 Telemetry 在剩下的幾個(gè)方面為可測(cè)試性做了哪些工作：
- 可觀察性：“你所看見的就是你所測(cè)試的。”
- 可控制性：“對(duì)軟件的控制越好，測(cè)試越能夠被自動(dòng)執(zhí)行與優(yōu)化。”
- 可分解性：“通過控制測(cè)試范圍，能夠更快地分解問題，執(zhí)行更靈巧的再測(cè)試。”
- 簡(jiǎn)單性：“需要測(cè)試的內(nèi)容越少，測(cè)試的速度越快。”
Chromium 以及 Telemetry 為可測(cè)試性做了哪些工作？
那么，Chromium 團(tuán)隊(duì)在上述這幾個(gè)方面是怎么做的呢？我們接下來一一拆解。
可觀察性——The Trace Event Profiling Tool (about:tracing)
眾所周知，測(cè)試是要以數(shù)據(jù)來說話的。因此，可測(cè)試性設(shè)計(jì)中尤為重要的就是被測(cè)對(duì)象能夠具備良好的可觀察性。對(duì)于 Chromium 項(xiàng)目而言，其可觀察性的能力主要由 The Trace Event Profiling Tool (about:tracing) 工具來提供。為了方便，下面均簡(jiǎn)稱 Tracing 工具。
關(guān)于 Tracing 工具，我們先給出 Google 對(duì)于這個(gè)工具的定義：
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.
對(duì)于 Tracing 工具的具體能力，簡(jiǎn)要來說就是，它記錄了 Chromium 中各進(jìn)程以及各線程中每個(gè)方法的活動(dòng)情況，既包含由 C++ 實(shí)現(xiàn)的內(nèi)核調(diào)用情況，也包含由 JavaScript 實(shí)現(xiàn)的頁面調(diào)用情況。
此外，Tracing 提供了一個(gè)很重要的能力——支持自定義加入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)方法》中給出了一個(gè)它所推薦的自動(dòng)化驗(yàn)收測(cè)試的層次：
- 驗(yàn)收條件：支持以“假如／當(dāng)／那么”的形式將驗(yàn)收條件寫入測(cè)試中
- 測(cè)試實(shí)現(xiàn)層：代碼使用領(lǐng)域語言，不引用UI元素
- 應(yīng)用程序驅(qū)動(dòng)層：理解如何與應(yīng)用程序進(jìn)行交互，來執(zhí)行一系列動(dòng)作，并返回結(jié)果
而要實(shí)現(xiàn)這種具備高可維護(hù)性特征的設(shè)計(jì)，對(duì)應(yīng)用程序驅(qū)動(dòng)層要求很高。特別是類似 Telemetry 這樣要求在 GUI 層面上執(zhí)行測(cè)試，一般而言應(yīng)用程序驅(qū)動(dòng)層的實(shí)現(xiàn)代價(jià)很大。
再次引用《持續(xù)交付——發(fā)布可靠軟件的系統(tǒng)方法》的原話：
假如應(yīng)用程序設(shè)計(jì)得比較好，GUI 層僅是清晰定義用于數(shù)據(jù)展現(xiàn)的代碼，不包括任何業(yè)務(wù)邏輯。在這種情況下，繞過界面，基于界面下的代碼進(jìn)行測(cè)試的風(fēng)險(xiǎn)會(huì)相對(duì)小一些。將可測(cè)試性銘記于心，寫出來的應(yīng)用程序就會(huì)有一個(gè) API，使 GUI 和測(cè)試用具（test harness）都可以用它來驅(qū)動(dòng)應(yīng)用程序。
Chromium 項(xiàng)目也實(shí)現(xiàn)了這么一個(gè) API，就是 Remote Debugging Protocol。
簡(jiǎn)單來說，Remote Debugging Protocol 就是用來與瀏覽器頁面交互和調(diào)試的協(xié)議通道。它采用 websocket 來與頁面建立通信通道，由發(fā)送給頁面的 commands 和它所產(chǎn)生的 events 組成。chrome 的開發(fā)者工具是這個(gè)協(xié)議主要的使用者，第三方開發(fā)者也可以調(diào)用這個(gè)協(xié)議來與頁面交互調(diào)試。
Remote Debugging Protocol 分為不同的功能模塊域：
上述模塊幾乎涵蓋瀏覽器的所有操作，由于 Remote Debugging Protocol 調(diào)用瀏覽器的方式完成操作與 UI 操作實(shí)現(xiàn)原理一致。因此對(duì)于驅(qū)動(dòng)層的實(shí)現(xiàn)幫助極大。
也正是通過 Remote Debugging Protocol， Telemetry 可以更精確的操控 Chromium，而不受系統(tǒng)輸入系統(tǒng)的影響。而這對(duì)于 GUI 性能測(cè)試而言意義重大，也是文章開頭所舉例子中的測(cè)試效率提升的關(guān)鍵所在。
可分解性——Run Chromium with flags
一個(gè)使用的功能肯定是由許許多多的功能模塊組成的，但是在測(cè)試的過程我們需要擁有靈活的能力去操作這些功能模塊，以便于我們更加靈活的設(shè)計(jì)我們的測(cè)試方案。
舉個(gè)簡(jiǎn)單的例子，Chromium 同時(shí)具備軟件渲染（software rasterization）以及硬件渲染（GPU rasterization）的能力，而且默認(rèn)使用硬件渲染（GPU rasterization）。當(dāng)我們需要重點(diǎn)關(guān)注軟件渲染（software rasterization）的性能時(shí)。我們需要 Chromium 具備一種便于我們更改這種默認(rèn)設(shè)置，以便單獨(dú)針對(duì)該模塊實(shí)現(xiàn)測(cè)試。
于是 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è)計(jì)，Telemetry 才功能通過傳入不同的啟動(dòng)參數(shù)的方式實(shí)現(xiàn)不同的測(cè)試需求。我們不敢相信，如果這些特殊功能的測(cè)試都需要開發(fā)單獨(dú)打包才能實(shí)現(xiàn)的話，這是怎樣一種坑爹的場(chǎng)景。
簡(jiǎn)單性——產(chǎn)品簡(jiǎn)單才是一切的核心
最后一點(diǎn)，其實(shí)說起來應(yīng)該也不完全時(shí)可測(cè)試性設(shè)計(jì)所需要關(guān)注的內(nèi)容。當(dāng)一個(gè)產(chǎn)品本身很復(fù)雜時(shí)，是不可能從根本上設(shè)計(jì)出一種簡(jiǎn)單的測(cè)試方案的。因此，要想測(cè)試變得優(yōu)雅，首先產(chǎn)品必須得優(yōu)雅。
至于 Chromium 項(xiàng)目為我們展示的就是這種優(yōu)雅，幾乎只提供核心能力：頁面瀏覽。
得益于產(chǎn)品的定位，Telemetry 才可以僅關(guān)注“瀏覽頁面時(shí)“的性能數(shù)據(jù)。從而逐步封裝，給出這樣的框架下面框架設(shè)計(jì)。
我們不妨設(shè)想一下，如果 Chromium 包含諸如軟件管理，系統(tǒng)清理，新聞推送等其他功能時(shí)，Telemetry 能否給出上述的測(cè)試框架設(shè)計(jì)？
我們可以從 Google 身上學(xué)到的
所實(shí)話，上述工作大部分都屬于 SDET（Software Development Engineer in Test） 的職責(zé)范疇，如果所在公司的相關(guān)崗位只有 STE（Software Test Engineer） 的話，那么這個(gè) STE 在上述事情參與程度可能不會(huì)太多。
但是，無論如何，明白“如何讓產(chǎn)品變得優(yōu)雅，讓測(cè)試變得優(yōu)雅”是非常重要的事情。況且夢(mèng)想還是要有的，萬一實(shí)現(xiàn)了呢。
