高影響力、省力的跨瀏覽器測試

跨瀏覽器測試既費時又費力。 然而，開發者天生就是懶惰的：堅持 DRY 原則，編寫腳本來自動化我們必須手動完成的事情，利用第三方庫； 懶惰使我們成為優秀的開發人員。

“正確”進行跨瀏覽器測試的傳統方法是在您的受眾使用的所有主要瀏覽器中進行測試，然後逐漸轉向舊的或更晦澀的瀏覽器，以便說您已經測試過它們。 或者，如果時間和資源很短，可以測試一小部分 ad hoc 瀏覽器，並希望沒有錯誤可以讓您對應用程序的完整性充滿信心。 第一種方法體現了“良好”的發展，但效率低下，而第二種方法體現了懶惰但不可靠。

關於 SmashingMag 的進一步閱讀：

• Noah 向移動可用性測試的過渡
• 應用程序、遊戲和移動網絡測試自動化的基礎知識
• 如何創建自己的前端網站測試計劃
• 世界上最好的開放設備實驗室在哪裡？

在接下來的 15 分鐘內，我希望通過描述一種測試策略來節省您數小時的浪費精力，該策略不僅勞動強度小，而且更有效地捕捉錯誤。 我想記錄一個現實的測試策略，而不是簡單地“測試所有的東西！”，利用我作為 BBC 視覺新聞測試開發人員的經驗。

語境

順便說一句，值得指出的是，我們在團隊中所做的不僅僅是手動測試。 跨瀏覽器測試不能替代單元測試（Jasmine/QUnit）、功能測試（Cucumber）以及在適當情況下的自動化視覺回歸測試（Wraith）。 事實上，從長遠來看，自動化測試更便宜，並且當您的應用程序達到一定大小時是必不可少的。

然而，一些錯誤只在某些瀏覽器中表現出來，測試自動化還沒有可靠地進入跨瀏覽器測試的領域。 在 iPhone 4 上查看時，計算機如何知道您的自動滾動事件剛剛遮住了一半的標題？ 它怎麼知道這是個問題？ 在人工智能發展到計算機能夠理解你所構建的東西並欣賞你試圖展示的敘事和藝術性之前，總是需要手動測試。 作為必須手動執行的事情，我們有責任讓跨瀏覽器測試過程盡可能高效。

你的目標是什麼？

在盲目地進行跨瀏覽器測試之前，先決定你希望從中得到什麼。 跨瀏覽器測試可以概括為有兩個主要目標：

1. 發現錯誤這需要嘗試破壞您的應用程序以找到要修復的錯誤。
2. 健全性檢查這涉及驗證您的大多數觀眾是否獲得了預期的體驗。

我想讓你從這篇文章中得到的第一件事是這兩個目標是相互衝突的。

一方面，我知道我可以通過在 Chrome（桌面）、Chrome（Android）和 Safari（iOS 9）中進行測試來驗證近 50% 的英國觀眾的體驗。 另一方面，如果我的目標是找到錯誤，那麼我會想把我的網絡應用程序扔到我們必須積極支持的最有問題的瀏覽器上：在我們的例子中，IE8 和原生 Android 瀏覽器 2。

這兩種瀏覽器的用戶在我們的受眾中所佔的比例越來越小（目前約為 1.5%），如果我們的目標是進行完整性檢查，那麼在這些瀏覽器中進行測試會浪費我們的時間。 但是，如果您想看看設計精良的應用程序在丟給不起眼的渲染引擎時會變得多麼糟糕，那麼它們是可以測試的絕佳瀏覽器。

可以理解的是，傳統的測試策略更加強調在流行的瀏覽器中進行測試。 然而，不成比例的錯誤只存在於比較模糊的瀏覽器中，在傳統的測試模型下，這些錯誤直到測試結束才會被發現。 然後，您將面臨兩難境地……

當您在長尾測試階段後期發現錯誤時，您會怎麼做？

1. 忽略錯誤。
2. 修復錯誤並希望你沒有破壞任何東西。
3. 修復錯誤並在所有以前測試過的瀏覽器中重新測試。

在理想情況下，最後一種選擇是最好的選擇，因為它是真正確信所有瀏覽器仍按預期工作的唯一方法。 但是，它的效率也非常低——而且您可能需要多次執行此操作。 它是類似於冒泡排序的手動測試。

因此，我們發現自己處於 Catch-22 的情況：為了獲得最大效率，我們希望在開始跨瀏覽器測試之前修復所有錯誤，但在開始測試之前我們無法知道存在哪些錯誤。

答案是對我們如何測試要聰明：通過增量測試來實現我們的錯誤發現和健全性檢查的目標，我喜歡稱之為三階段攻擊。

三階段攻擊

想像你身處戰區。 你知道壞人躲在城市另一邊的總部。 在你的支配下，你有一名特工、一支由久經沙場的游擊隊組成的精銳團隊和一大群輕武裝的當地民兵。 您發起三階段攻擊以奪回城市：

1. 偵察將你的間諜派往敵方總部，了解壞人可能藏身的地方、有多少人以及戰場的總體狀況。
2. 突襲將您的精銳團隊派往敵人的心臟地帶，在一次猛烈的突襲中消滅大多數壞人。
3. 清關派遣當地民兵去挑選剩餘的壞人並確保該地區的安全。

您可以將相同的軍事策略和紀律帶到您的跨瀏覽器測試中：

1. 偵察在開發機器上的流行瀏覽器中進行探索性測試。 了解錯誤可能隱藏的位置。 修復遇到的任何錯誤。
2. Raid在少數有問題的瀏覽器上手動測試可能會顯示最多的錯誤。 修復遇到的任何錯誤。
3. Clearance Sanity 檢查您的受眾中最流行的瀏覽器是否已被清除以獲得預期的體驗。

無論您是在戰場上還是在進行設備測試，這些階段都以最少的時間開始，並隨著操作變得更加穩定而增長。 你能做的偵察只有這麼多——你應該能夠在很短的時間內發現一些錯誤。 突襲更加激烈和耗時，但提供了非常有價值的結果並顯著穩定了戰場。 通關階段是所有階段中最費力的階段，您仍然需要保持警惕，以防一個未發現的壞人不知從何而來並給您造成傷害 - 但這是能夠自信地聲稱戰場是必要的步驟現在安全了。

我們三階段攻擊的前兩個步驟實現了我們的第一個目標：漏洞發現。 當您確信您的應用程序是健壯的時，您將希望進入攻擊的第三階段，在與大多數觀眾的瀏覽行為相匹配的最少數量的瀏覽器中進行測試，實現第二個目標：健全性檢查。 然後，您可以以量化支持的信心說您的應用程序適用於 X% 的受眾。

設置：了解你的敵人

不要輕易參戰。 在開始測試之前，您需要了解用戶如何訪問您的內容。

找出您的受眾統計數據（來自 Google Analytics 或您使用的任何工具）並以您可以閱讀和理解的格式在電子表格中獲取數據。 您將希望能夠查看每種瀏覽器和操作系統組合以及佔總市場份額的相關百分比。

瀏覽器使用統計數據只有在可以輕鬆使用時才有用：您不希望看到一長串令人生畏的瀏覽器/操作系統/設備組合列表來進行測試。 此外，測試每一種可能的組合都是徒勞的。 我們可以使用我們的 Web 開發人員知識來啟發式地整合我們的統計數據。

簡化您的瀏覽器使用統計

作為 Web 開發人員，我們並不特別關心桌面瀏覽器在哪個操作系統上運行——瀏覽器錯誤很少適用於一個操作系統而不適用於另一個操作系統——因此我們將桌面瀏覽器的統計數據合併到所有操作系統中。

我們也不特別關心有人使用的是 Firefox 40 還是 Firefox 39：版本之間的差異可以忽略不計，而且版本的更新是免費的，而且通常是自動的。 為了便於我們理解瀏覽器統計信息，我們合併了所有桌面瀏覽器的版本——IE 除外。 我們知道舊版本的 IE 既存在問題又普遍存在，因此我們需要跟踪它們的使用數據。

類似的論點適用於便攜式操作系統瀏覽器。 我們並不特別關心移動版 Chrome 或 Firefox 的版本，因為它們會定期且容易地更新——所以我們合併了這些版本。 但同樣，我們關心 IE 的不同版本，因此我們分別記錄它們的版本。

如果我們談論的是 Android，則設備的操作系統版本無關緊要。 重要的是使用的原生 Android 瀏覽器的版本，因為這是一個出了名的問題瀏覽器。 另一方面，設備運行的 iOS 版本非常相關，因為 Safari 版本本質上與操作系統相關聯。 然後還有一整套用於其他設備的原生瀏覽器：這些瀏覽器在我們的整體受眾中只佔很小的比例，以至於它們的版本號也被合併了。

最後，我們迎來了迅速普及的新一波瀏覽器：應用內瀏覽器，主要在社交媒體平台上實現。 這對我們來說仍然是一個新領域，因此我們熱衷於列出所有應用內瀏覽器平台及其各自的操作系統。

一旦我們使用我們的領域專家知識來合併相關統計數據，我們會通過刪除所有占我們受眾不到 0.05% 的瀏覽器來進一步縮小列表範圍（請根據您自己的要求隨意調整此閾值）。

桌面瀏覽器

便攜式瀏覽器

應用內瀏覽器

完成後，您的電子表格應該看起來像這樣（暫時忽略“優先級”列 - 我們稍後會談到）：

因此，現在您已經獲得了簡化的電子表格，從 Web 開發人員的角度顯示了主要瀏覽器，每個都與總市場份額百分比相關聯。 請注意，您應該更新此電子表格； 每月更新一次就足夠了。

您現在已準備好開始三階段攻擊。

1. 偵察：查找與瀏覽器無關的錯誤

早在你考慮拿出一個設備進行測試之前，做你能做的最簡單的事情：在你最喜歡的瀏覽器中打開你的網絡應用程序。 除非你是一個徹頭徹尾的受虐狂，否則這很可能是 Chrome 或 Firefox，它們都很穩定並且支持現代功能。 第一階段的目的是找到與瀏覽器無關的錯誤。

與瀏覽器無關的錯誤是與用於訪問您的應用程序的瀏覽器或硬件無關的實現錯誤。 例如，假設您的網頁上線，您開始收到一些模糊的錯誤報告，人們抱怨您的網頁在 HTC One 橫向模式下看起來很垃圾。 你浪費了很多時間來確定使用的是哪個版本的瀏覽器，使用 Android 的 USB 調試模式並蒐索 StackOverflow 尋求幫助，想知道你將如何解決這個問題。 您不知道，這個錯誤與設備無關：相反，您的頁面在某個視口寬度上看起來有問題，而這恰好是相關設備的屏幕寬度。

這是一個與瀏覽器無關的錯誤的示例，它錯誤地將自己表現為特定於瀏覽器或特定於設備的錯誤。 你被引導了一條漫長而浪費的道路，錯誤報告充當噪音，混淆了問題的根本原因。 幫自己一個忙，從一開始就抓住這種錯誤，用更少的努力和更多的遠見。

通過在我們甚至開始跨瀏覽器測試之前修復與瀏覽器無關的錯誤，我們應該面臨更少的錯誤。 我喜歡稱之為融化的冰山效應。 我們正在融化隱藏在地表下的蟲子，使我們免於在海洋中墜毀和溺水——我們甚至沒有意識到我們正在這樣做。

以下是您可以在開發瀏覽器中執行以發現與瀏覽器無關的錯誤的簡短列表：

• 嘗試調整大小以查看響應性。 任何地方都有一個時髦的斷點嗎？
• 放大和縮小。 您的圖像精靈的背景位置是否被歪斜了？
• 查看應用程序在關閉 JavaScript 時的行為。 你還得到核心內容嗎？
• 查看關閉 CSS 後應用程序的外觀。 標記的語義仍然有意義嗎？
• 嘗試同時關閉 JavaScript 和 CSS。 您是否獲得了可接受的體驗？
• 嘗試僅使用鍵盤與應用程序交互。 是否可以導航並查看所有內容？
• 嘗試限制您的連接並查看應用程序的加載速度。 頁面加載量有多大？

在進入第 2 階段之前，您需要修復遇到的錯誤。 如果我們不修復與瀏覽器無關的錯誤，我們只會在以後報告大量錯誤的瀏覽器特定錯誤。

偷懶。 修復與瀏覽器無關的錯誤。 然後我們可以進入攻擊的第二階段。

2. Raid：首先在高風險瀏覽器中測試

當我們修復錯誤時，我們必須小心我們的修復不會引入更多錯誤。 調整我們的 CSS 以修復 Safari 中的填充可能會破壞 Firefox 中的填充。 優化那部分 JavaScript 以在 Chrome 中更流暢地運行可能會在 IE 中完全破壞它。 我們所做的每一次改變都會帶來風險。

為了真正確信新更改沒有破壞我們已經測試過的任何瀏覽器的體驗，我們必須返回並再次在相同的瀏覽器中進行測試。 因此，為了最大程度地減少重複工作，我們需要明智地了解我們的測試方式。

漏洞分佈統計分析

考慮下表，其中十字圖標表示瀏覽器存在錯誤。

假設我們要按風險升序測試我們的內容：低風險瀏覽器、中風險瀏覽器、高風險瀏覽器。 如果它可以幫助您將其可視化，這些瀏覽器可能會分別映射到 Google Chrome、IE 9 和 IE 6。

首先測試低風險瀏覽器 (Chrome)，我們會發現並修復錯誤 #2。 當我們轉移到中等風險瀏覽器時，錯誤 #2 已經修復，但我們發現了一個新錯誤：#4。 我們更改代碼以修復錯誤——但我們如何確定我們現在沒有破壞低風險瀏覽器中的某些內容？ 我們不能完全確定，所以我們必須返回並再次在該瀏覽器中進行測試，以驗證一切仍然按預期工作。

現在我們轉到高風險瀏覽器並發現錯誤 #1、#3 和 #5，需要大量返工才能修復。 一旦這些都解決了，我們該怎麼辦？ 返回並再次測試中低風險瀏覽器。 這是很多重複的工作。 我們必須總共測試我們的三個瀏覽器六次。

現在讓我們考慮如果我們按風險降序測試我們的內容會發生什麼。

馬上，我們就會在高風險瀏覽器中發現錯誤 #1、#3、#4 和 #5。 在修復了這些錯誤之後，我們將直接進入中等風險瀏覽器並發現錯誤 #2。 和以前一樣，此修復可能間接破壞了某些內容，因此有必要返回高風險瀏覽器並重新測試。 最後，我們在低風險瀏覽器中進行測試，沒有發現新的錯誤。 在這種情況下，我們總共在四個不同的場合測試了我們的三個瀏覽器，這大大減少了有效發現和修復相同數量的錯誤以及驗證相同數量瀏覽器的行為所需的時間.

開發人員可能會面臨首先在最流行的瀏覽器中進行測試的壓力，然後在我們的測試結束時一直使用不太廣泛使用的瀏覽器。 但是，流行的瀏覽器很可能是低風險瀏覽器。

你知道你必須支持給定的高風險瀏覽器，所以從一開始就讓那個瀏覽器不礙事。 不要浪費精力測試不太可能產生錯誤的瀏覽器，因為當您切換到產生更多錯誤的瀏覽器時，您只需返回並再次查看那些低風險瀏覽器。

修復不良瀏覽器中的錯誤使您的代碼在良好瀏覽器中更具彈性

通常，您會發現這些有問題的瀏覽器中出現的錯誤是您的不良代碼的意外結果。 您可能笨拙地將 div 設置為看起來像一個按鈕，或者在觸發某些任意行為之前侵入了 setTimeout； 這兩個問題都存在更好的解決方案。 通過修復作為不良代碼症狀的錯誤，您很可能在看到其他瀏覽器中的錯誤之前就已經修復了它們。 再次出現融化的冰山效應。

通過檢查功能支持，而不是假設瀏覽器支持某些東西，您正在修復 IE8 中的那個痛苦的錯誤，但您也使您的代碼對其他惡劣環境更加健壯。 通過為 Opera Mini 提供該圖像後備，您鼓勵使用漸進增強，並且作為副產品，您正在改進您的產品，即使對於那些減少芥末的瀏覽器​​用戶也是如此。 例如，移動設備可能會失去其 3G 連接，而僅下載了一半的應用程序資產：用戶現在獲得了他們以前無法獲得的有意義的體驗。

但請注意：如果您不小心，修復晦澀的瀏覽器中的錯誤可能會使您的代碼變得更糟。 例如，抵制嗅探用戶代理字符串以有條件地向特定瀏覽器提供內容的誘惑。 這可能會修復錯誤，但這是一種完全不可持續的做法。 不要為了支持笨拙的瀏覽器而犧牲好代碼的完整性。

識別有問題的瀏覽器

那麼什麼是高危瀏覽器呢？ 答案有點模糊，取決於您的應用程序使用的瀏覽器功能。 如果您的 JavaScript 使用indexOf ，它可能會在 IE 8 中中斷。如果您的應用程序使用position: fixed ，您需要在 iOS 7 上的 Safari 中檢查它。

我可以使用是一種寶貴的資源，也是一個很好的起點，但這是再次來自經驗和開發人員直覺的領域之一。 如果您定期推出 Web 應用程序，您將知道哪些瀏覽器會一次又一次地標記問題，並且您可以改進您的測試策略以適應這種情況。

您在有問題的瀏覽器中發現的錯誤的有用之處在於它們經常會傳播。 如果 IE9 中存在錯誤，則該錯誤很可能也存在於 IE8 中。 如果某些東西在 iOS 7 上的 Safari 上看起來很時髦，那麼它在 iOS 6 上可能看起來更加明顯。注意到這裡的模式了嗎？ 較舊的瀏覽器往往是有問題的瀏覽器。 這應該可以幫助您列出一個很好的有問題的瀏覽器列表。

話雖如此，請使用使用統計信息來備份這些內容。 例如，IE 6 是一個非常有問題的瀏覽器，但我們不會費心對其進行測試，因為它的總市場份額太低。 花費在修復 IE6 特定 bug 上的時間對於少數需要改善體驗的用戶來說是不值得的。

在 raid 階段，您並不總是想要測試舊版瀏覽器。 例如，如果您有一個帶有圖像回退的實驗性 3D WebGL 畫布項目，那麼舊的瀏覽器只會獲得回退圖像，因此我們不太可能發現很多錯誤。 我們想要做的是根據手頭的應用程序改變我們對有問題的瀏覽器的選擇。 在這種情況下，IE9 可能是一個很好的測試瀏覽器，因為它是第一個支持畫布的 IE 版本。

如果您的應用程序使用 CSS3 功能（例如漸變或邊框半徑），現代代理瀏覽器（例如​​ Opera Mini）也可能是一個不錯的 raid 測試選擇。 一個常見的錯誤是在不受支持的漸變上呈現白色文本，從而導致無法辨認的白底白字文本。

在選擇有問題的瀏覽器時，請使用您的直覺並嘗試搶先發現錯誤可能隱藏的位置。

使有問題的瀏覽器多樣化

瀏覽器和瀏覽器版本只是等式的一部分：硬件也是一個重要的考慮因素。 您需要在各種屏幕尺寸和不同像素密度上測試您的應用程序，並嘗試在縱向和橫向模式之間切換。

將相關的瀏覽器組合在一起可能很誘人，因為可以感覺到工作成本的折扣。 如果您已經打開 VirtualBox 來測試 IE8，那麼現在似乎也是在 IE9、IE10 和 IE11 中進行測試的好時機。 但是，如果您正處於測試 Web 應用程序的早期階段，您將希望與這種誘惑作鬥爭，而是選擇三到四個彼此明顯不同的瀏覽器-硬件組合，以獲得盡可能多的覆蓋範圍盡可能多的錯誤空間。

儘管這些可能因項目而異，但以下是我目前選擇的有問題的瀏覽器：

• Windows XP VM 上的 IE 8；
• 中端 Android 平板電腦上的原生 Android Browser 2；
• 運行 iOS 6 的 iPhone 4 上的 Safari；
• Opera mini（只有在沒有 JavaScript 的情況下才真正值得測試的內容，例如 datapics）。

偷懶。 通過將您的應用程序扔到最有問題的受支持瀏覽器和設備上，盡可能多地發現錯誤。 修復這些錯誤後，您就可以進入攻擊的最後階段。

3. 清關：健全性檢查

您現在已經在您必須支持的最嚴苛的瀏覽器中測試了您的應用程序，希望能夠捕捉到大多數錯誤。 但是您的應用程序還沒有完全沒有錯誤。 我經常驚訝於即使是最新版本的 Chrome 和 Firefox 在呈現相同內容時也會有多麼不同。 你還需要做更多的測試。

這是舊的 80:20 規則。 形像地說，在測試了 20% 的瀏覽器之後，您已經修復了 80% 的錯誤。 現在你要做的是通過測試不同的 20% 的瀏覽器來驗證 80% 的觀眾的體驗。

優先考慮瀏覽器

現在簡單而明顯的方法是切換回“傳統的”跨瀏覽器測試，按市場份額的降序處理每個瀏覽器。 如果 Chrome 桌面恰好是您的受眾瀏覽器份額的最高比例，其次是 iOS 8 上的 Safari，其次是 IE11，那麼按此順序進行測試是有意義的，對吧？

這是一個基本公平的系統，如果您的資源已經捉襟見肘，我不想讓這一步過於復雜。 然而，事實是，並非所有瀏覽器都是平等的。 在我的團隊中，我們根據決策樹對瀏覽器進行分組，該決策樹考慮了瀏覽器的使用、升級的難易程度以及瀏覽器是否為操作系統默認設置。

到目前為止，您的電子表格應該有一個瀏覽器列和一個市場份額列； 您現在需要第三列，指定瀏覽器屬於哪個優先級。 說實話，這個優先級工作應該在發動三階段攻擊之前完成，但為了本文的目的，在這裡描述它更有意義，因為直到清除階段才真正需要優先級。

這是我們的決策樹：

我們設計了決策樹，以便 P1 瀏覽器覆蓋大約 70% 的受眾。 P1 和 P2 瀏覽器加起來覆蓋了大約 90% 的受眾。 最後，P1、P2 和 P3 瀏覽器為我們提供了幾乎完整的受眾覆蓋。 我們的目標是在所有 P1 瀏覽器中進行測試，然後是 P2，然後是 P3，按市場份額的降序排列。

正如您在本文前面的電子表格中所見，我們只有少數 P1 瀏覽器。 事實上，我們可以如此快速地驗證超過 70% 的觀眾的體驗，這意味著如果代碼庫發生變化，我們沒有理由不在這些瀏覽器中重新測試。 隨著我們向下移動到 P2 和 P3 瀏覽器，我們必須花費越來越多的精力來驗證不斷減少的受眾規模的體驗，因此我們必須為較低優先級的瀏覽器設置更現實的測試理想。 作為指導：

• P1 。 在簽署應用程序之前，我們必須對這些瀏覽器進行完整性檢查。 如果我們對代碼進行小的更改，那麼我們應該再次在這些瀏覽器中進行完整性檢查。
• P2 。 在簽署應用程序之前，我們應該對這些瀏覽器進行完整性檢查。 如果我們對代碼進行較大的更改，那麼我們應該再次在這些瀏覽器中進行完整性檢查。
• P3 。 我們應該對這些瀏覽器進行一次完整性檢查，但前提是我們有時間。

不要忘記使您的硬件多樣化的必要性。 如果您能夠在遵循此列表的同時在多種不同的屏幕尺寸和具有不同硬件功能的設備上進行測試，那麼請這樣做。

總結：三相攻擊

一旦你努力了解你的敵人（簡化你的觀眾統計數據並將瀏覽器分組為優先級），你就可以分三個步驟進行攻擊：

1. 偵察：在您最喜歡的瀏覽器上進行探索性測試，以發現與瀏覽器無關的錯誤。
2. Raid ：在各種硬件上測試您最有問題的受支持瀏覽器，以發現大多數錯誤。
3. 許可：驗證您的應用程序在最廣泛使用和具有戰略意義的瀏覽器上的體驗，以量化支持您的應用程序工作的信心說。