測試你的前端程式碼：視覺化測試

發表於2017-10-25

測試 App，你從哪裡開始？在最後這個部分，第五部分，Gil Tayar 總結了他為前端測試新人寫的系列文章。最後這篇文章中，Tayar 講述了視覺化測試，以及為什麼它是測試前端程式碼的最後一步。

不久前，我一個剛剛進入精彩前端世界的朋友打電話問我該怎麼測試他的應用程式。我告訴她有太多需要學習的東西，在電話里根本說不清楚。我答應傳送一些對她前端之路有所幫助的連結。

所以我在電腦前坐下，通過 Google 搜尋相關的主題。我找到很多連結，也傳送給她了，但我對這些連結討論的深度並不滿意。我找不到一個全面的指南 —— 以新入行的前端的角度 —— 指導如何測試前端應用。我沒找到某個指南既講理論又講實踐，同時還是面向前端應用的討論。

因此，我決定寫一個。這已經是這一系列的第五部分了。你可以在下面看到其它部分：

另外，為了寫這篇文章，我寫了一個小應用 —— Calculator（計算器） —— 我要用它演示測試的不同型別。你可以在這裡看到它的原始碼。

視覺化測試

軟體測試一直是我的一大愛好。最近，我覺得沒有測試就寫不出程式碼。對我來說，有一種原始的想法，執行的目的就是為了驗證程式碼是否正確。你的意思是告訴我，在以前，每次開發者修改他們的程式碼，都需要有人手工去驗證之前正常的事情仍然正常？是這樣嗎？

因此，我寫測試。因為我喜歡演講和寫部落格，我會演講或寫關於軟體測試的內容。如果有機會進入一個對加強軟體測試有著卓越遠見的公司，寫程式碼來幫助其它人寫測試，並推廣他們的產品，我會毫不猶豫的加入。

正是如此，我最近加入了 Applitools （如果你想知道職位，是佈道師和高階架構師）。因為他們的產品，Applitools Eyes，與我寫的這個系列有著直接聯絡，我決定在這個系列中多寫一個部分 —— 一個關於“視覺化測試”的部分。

還記得我的疑惑嗎？開發者實際總是會在每次修改他們的程式碼之後執行他們的應用。嗯，到目前為止，軟體產品需要手工測試 —— 這是在應用的視覺化方面。還沒有辦法檢查應用看起來仍然是好的 —— 字型是正確的，對齊沒有問題，顏色也還在，等等。

理論上你是可以寫程式碼來進行相關的檢查。我們在第三部分了解到如何使用 Selenium Webdriver 測試 Web 應用的 UI。我們可以使用 Selenium 的 getScreenShot API 來獲得頁面的截圖，將其儲存為基準，之後每個測試都會將頁面截圖與這個基準進行比較：

測試你的前端程式碼：視覺化測試

啊哈！要是這麼簡單就好了。我嘗試過這個方案，結果遇到不少問題，最後不得不放棄這個方案。而且可笑的是我每次修改了程式碼都要執行應用。主要的問題在某些技術：瀏覽器在呈現內容的時候存在一些細微的差異 —— 造成這些差異的因素可能來源於螢幕或者 GPU，對內容進行抗鋸齒渲染的方式略有不同。沒有兩張截圖會擁有完全一樣的畫素。這些差異人眼覺察不到，也就是說，按畫素進行比較毫無意義。你需要使用影象分析技術來處理這個問題。

而且，還有其它問題，僅從我基於 Applitools 的工作就能總結出如下問題：

你不能對整個頁面截圖 —— 你只能對可以看到的部分截圖。
如果頁面中存在動畫，那就不能拿它和基礎影象進行比較。
動態資料，比如廣告，會讓事情變得複雜，難以找出與基準相比的實際差異。
頁面什麼時候才會“完全載入”？什麼時候才能對其截圖？現在在 DOM 載入完成時截圖是不夠的。要找出什麼時候才可以截圖是件非常困難的事情。

我們做得到

不過我們似乎可以編寫自動的視覺化測試。存在著無數我並不知道的工具可以更好的截圖並將之與標準影象比較。其中一些如下：

Wraith
WebdriverCSS
當然還有 Applitools Eyes
(還是其它的，但本文已經有點長了…)

這些工具可以解決全部或部分上面提到的問題。在系列的這個部分，我想向你展示如何使用 Applitools Eyes 來編寫視覺化測試。

寫一個視覺化測試

既然視覺化測試是測試的最終產品，它們應該用於端到端瀏覽器的前端測試中。所以這是我的視覺化測試。這個程式碼非常有意思，它比常規的端到端測試更小。它由三個部分組成 —— 設定瀏覽器，測試 Applitools Eyes 和測試本身。

我們再看一下 Selenium Driver 瀏覽器設定，它與第三部分的端到端測試相同：

let driver

before(async () => {

driver = new webdriver.Builder().forBrowser('chrome').build()

})

after(async () => await driver.quit())

這會開啟一個瀏覽器並等待驅動命令。不過在開始測試之前，我們需要安裝（以及拆卸）Applitools Eyes：

const {Eyes} = require('eyes.selenium')

let eyes

before(async () => {

eyes = new Eyes()

eyes.setApiKey(process.env.APPLITOOLS_APIKEY)

await eyes.open(driver, 'Calculator App', 'Tests', {width: 800, height: 600})

})

after(async () => await eyes.close())

我們建立了一些新的 Eyes（第5行），並開啟它們（第8行）—— 可愛的術語，不是嗎？不要忘了從 Applitools 獲取一個 API 的 Key，這是我們會在下一小節討論的東西，然後把它設定給 Eyes（第6行）。

現在我們已經設定好瀏覽器和 Eyes，我們可以寫測試了，這和我們的端到端測試非常像：

it('should look good', async function () {

await driver.get('http://localhost:8080')

await eyes.checkWindow('Initial Page')

const digit4Element = await driver.findElement(By.css('.digit-4'))

const digit2Element = await driver.findElement(By.css('.digit-2'))

const operatorMultiply = await driver.findElement(By.css('.operator-multiply'))

const operatorEquals = await driver.findElement(By.css('.operator-equals'))

await digit4Element.click()

await digit2Element.click()

await operatorMultiply.click()

await digit2Element.click()

await operatorEquals.click()

await eyes.checkWindow('After calculating 42 * 2 =')

})

與這個系列的前一篇文章中的端到端測試相比，你可以看到它很像，但更短。程式碼中主要的區別是對特定元素的驗證被一行簡單的程式碼代替了：

1	await eyes.checkWindow(‘’)

在端到端測試中，我們是這樣做的：

await retry(async () => {

const displayElement = await driver.findElement(By.css('.display'))

const displayText = await displayElement.getText()

expect(displayText).to.equal('0')

})

我們通過重試等待頁面“穩定”。但進行視覺化測試的時候，你不需要等待頁面可見 —— eyes.checkWindow 會幫你幹這個事情！

eyes.checkWindow 會擷取頁面影象並將之與前端測試產生的基準影象進行比較（參閱下面的小節“執行視覺化測試”）。如果比較結果是新影象與基準等價，則測試成功，否則測試失敗。

視覺化測試是端到端測試更好的工具

進行視覺化測試的巨大好處是 —— 系統處理的穩定性。而且 —— 你不是隻檢查一兩個元素 —— 你是在一次斷言中檢查整個頁面。你可能會發現一些壓根沒想去找的問題！

總的來說，看起來視覺化測試是端到端測試中唯一的斷言方法。但不幸的是，目前視覺化斷言較慢，所以你需要好好地把一些檢查特定元素的常規斷言和檢查整個頁面的視覺化斷言組合起來。

記住 —— 沒有靈丹妙藥：沒有某一個測試型別可以做所有事情！混合不同型別的測試可以更好的建立平衡，建議這樣的混合需要測試經驗。所以現在就開始測試！的確，測試需要時間和責任。但是一旦你開始測試，你就不能回頭了。

執行視覺化測試

我們怎麼才行執行視覺化測試更看到結果？

如果你沒有使用環境變數 APPLITOOLS_APIKEY 來提供一個 API Key，npm test 就會跳過視覺化測試。所以需要獲取一個 API Key 來執行測試，去 Applitools 註冊個使用者就好。你可以在你的 Applitools 賬戶介面找到 API Key。把它拷貝下來，用到測試中去（在 Linux/MacOS 中）：