谷歌是如何測試即時頁面的

　　看了一篇關于前端關于兼容性的文章，覺得信息量很大，翻譯來分享給大家，原文地址

　　谷歌的Instant Pages(即時頁面)是一個非?？岬募铀儆脩羲阉鞯姆绞?，當谷歌發現用戶想點擊哪個搜索結果之前，會在后臺先預加載這個頁面，當用戶點擊這個頁面的時候會立即渲染呈現，這將為用戶節約5秒的時間，當你知道每天搜索量非常龐大，特別是當你知道其他搜索優化都是亞秒級別的時候，5秒的效果將會非常顯著。

　　即時頁面的測試問題也很有趣。這個功能需要客戶端和服務端相互調用完成，我們需要在一個看不見的后臺預加載和渲染網頁，我們要確保這些在后臺預加載的頁面在渲染出來后沒有問題

　　最初的想法是叫開發人員通過瀏覽一些他們打開的網頁去測試，但是相對于龐大的互聯網頁數量這種測試是不可度量的，并且這種方式重復執行的成本很高，此外你不知道預期的頁面應該是什么樣，寫selenium的自動化代碼驗證成千上萬的網站也會無休止的執行下去，畢竟產品發布時間是第一位的。我們的解決辦法是通過自動化的代碼來對比兩種頁面，一種是使用了即時頁面功能的頁面，一種是沒有使用即時頁面功能的頁面

　　我們是如何對比兩個結果的呢?特別是當頁面上的內容或者廣告不斷變化，我們根本不知道內容或者廣告下一刻會變成什么樣子的話，我們又該如何對比呢?我們可以使用緩存的辦法，但是用這種方法測試畢竟與真實的情況不一樣，并且需要花費一定的時間去創建這種緩存的機制，還要花精力去解決每種緩存頁面創建和更新的定時策略不統一的問題。我們最終采用了利用DOM的辦法來對比網頁。我們逐個像素地掃描網頁，我們主要關注在每個像素點上DOM中哪個元素是可見的，而不是關注每個像素點的color/RGB的值。然后我們對這些緊密的像素點的匹配結果做一個簡單的度量就可以了。這種測試方法是是由我們所謂的“質量機器人”產生的，這些機器人會生成分數0〜100%的分數，100%意味著所有的測量值是相同的。

　　當我們執行這些測試的時候，發現絕大部分(大約95%)的比較正如我們所期望的那樣是幾乎相同的。對于其中不相同的每對頁面，我們建立了一個網頁，以圖片和高亮的方式顯示兩個頁面間的差異。這能使開發人員更簡易、快速、直觀地驗證渲染過程中頁面上的內容或其他非結構上引起的差異。任何時候這些自動化測試都是可度量的、可重復的，可量化的，開發人員可以不通過我們進行測試，這是多美好的一件事情呀!

　　這種測試是怎么建立起來的呢?就像在谷歌測試中的許多東西一樣，是人們之間聊天談起了這個東西，這種聊天可以使自己正在實現的工作可以幫助其他工程師。這是自下而上的，而非自上而下。 TEJAS Shah主要從事通過質量機器人解決chrome和其他瀏覽器的兼容性(更多的是在以后的文章中)的工作。當他去即時頁面開發人員的辦公樓參觀的時候，他和這些開發人員開始聊了起來，他們贊同用他的機器人可能會幫他們一些忙。他然后在接下來的幾個星期把它與即時頁面的測試連在了一起，最后跟這個團隊共享了這個成果。

　　而現在質量機器人的更多應用開始浮出水面。如果我們保持瀏覽器不變，僅僅修改應用程序的版本會怎么樣呢?這些機器人能夠幫助驗證Web應用程序的一個獨立的功能而不用再重新編寫和維護自定義的驗證腳本嗎?敬請關注..

原文轉自：http://www.anti-gravitydesign.com