跨瀏覽器測試簡介
本文概述了跨瀏覽器測試：什麼是跨瀏覽器測試，一些常見問題，以及一些除錯/故障排除方法。
| 預備知識 | 熟悉核心 HTML、CSS 和 JavaScript 語言。 |
|---|---|
| 目標 | 瞭解跨瀏覽器測試中涉及的高階概念。 |
什麼是跨瀏覽器測試？
跨瀏覽器測試是確保網站在各種瀏覽器和裝置上都能正常執行的做法。Web 開發者應該考慮：
- 不同的瀏覽器，包括一些不支援所有最新 JS/CSS 功能的稍舊的瀏覽器。
- 從桌上型電腦和筆記型電腦到平板電腦和智慧手機，再到智慧電視的各種裝置，它們具有不同的硬體功能。
- 殘疾人，他們可能依賴螢幕閱讀器等輔助技術，或者只使用鍵盤。
請記住，你不是你的使用者 — 僅僅因為你的網站在你的 MacBook Pro 或高階 Galaxy Nexus 上執行良好，並不意味著它對所有使用者都適用！
注意：讓所有人都用上 Web 討論了不同的瀏覽器、它們的市場份額以及相關的跨瀏覽器相容性問題。
網站應該能在不同的瀏覽器和裝置上以及殘疾人（例如，螢幕閱讀器友好）中訪問。網站不必在所有瀏覽器和裝置上提供完全相同的體驗，只要核心功能能夠以某種方式訪問即可。例如，現代瀏覽器可能擁有一些動畫、3D 和閃亮的東西，而舊瀏覽器可能只顯示具有相同資訊的平面圖形。
此外，網站不可能在所有瀏覽器和裝置上都執行，因此 Web 開發者應該與網站所有者就程式碼將執行的瀏覽器和裝置範圍達成一致。
為什麼會出現跨瀏覽器問題？
跨瀏覽器問題發生的原因有很多，請注意，這裡我們討論的是在不同瀏覽器/裝置/瀏覽偏好下行為不同的問題。在解決跨瀏覽器問題之前，您應該已經修復了程式碼中的 bug（如有需要，請參閱之前主題中的除錯 HTML、除錯 CSS 和出了什麼問題？JavaScript 故障排除，以重新回顧）。
跨瀏覽器問題通常是因為：
- 有時瀏覽器有 bug，或者實現功能的方式不同。這種情況比以前好多了；在 20 世紀 90 年代，當 IE4 和 Netscape 4 爭奪主導地位時，瀏覽器公司故意以不同於其他公司的方式實現事物，試圖獲得競爭優勢，這讓開發者的生活變得一團糟。現在瀏覽器在遵循標準方面做得好多了，但差異和 bug 有時仍然會出現。
- 某些瀏覽器對技術功能的支援程度可能與其他瀏覽器不同。當你處理瀏覽器剛剛開始實現的前沿功能時，或者當你必須支援不再開發的非常舊的瀏覽器時，這是不可避免的，這些瀏覽器可能在新功能發明很久之前就已經被凍結（即不再進行新的工作）。例如，如果你想在你的網站中使用尖端 JavaScript 功能，它們可能無法在舊瀏覽器中執行。如果你需要支援舊瀏覽器，你可能不得不不使用這些功能，或者在需要時使用某種交叉編譯器將你的程式碼轉換為舊式語法。
- 某些裝置可能存在限制，導致網站執行緩慢或顯示不良。例如，如果一個網站被設計成在臺式 PC 上看起來很好看，那麼它在移動裝置上可能會顯得很小且難以閱讀。如果你的網站包含大量大型動畫，它可能在高階平板電腦上執行良好，但在低端裝置上可能會遲鈍或卡頓。
……還有更多原因。
在後續文章中，我們將探討常見的跨瀏覽器問題，並尋找解決方案。
跨瀏覽器測試工作流程
所有這些跨瀏覽器測試業務聽起來可能既耗時又可怕，但事實並非如此——你只需要仔細規劃，並確保在正確的地方進行足夠的測試，以確保你不會遇到意想不到的問題。如果你正在處理一個大型專案，你應該定期測試它，以確保新功能對你的目標受眾有效，並且程式碼的新增內容不會破壞以前正常工作的老功能。
如果你把所有測試都留到專案結束，那麼你發現的任何 bug 都會比你邊做邊發現和修復的 bug 更昂貴、更耗時。
一個專案的測試和 bug 修復工作流程大致可分為以下四個階段（這只是非常粗略的劃分——不同的人可能會以非常不同的方式完成）：
初步規劃 > 開發 > 測試/發現 > 修復/迭代
步驟 2-4 將根據需要重複多次，以完成所有實現。我們將在後續文章中更詳細地介紹測試過程的不同部分，但現在，我們只總結每個步驟中可能發生的情況。
初步規劃
在初步規劃階段，你可能會與網站所有者/客戶（可能是你的老闆，或你正在為其構建網站的外部公司的某人）舉行幾次規劃會議，在會議中，你將確切地確定網站應該是什麼樣子——它應該擁有什麼內容和功能，它應該看起來如何等等。此時，你還需要知道你有多少時間來開發網站——他們的截止日期是什麼，他們會為你的工作支付多少費用？我們不會對此進行太多詳細討論，但跨瀏覽器問題可能會對此類規劃產生嚴重影響。
一旦你對所需的功能集和可能用於構建這些功能的技術有了概念，就應該開始探索目標受眾——此網站的目標受眾將使用哪些瀏覽器、裝置等？客戶可能已經從他們之前進行的研究中獲得了這方面的資料，例如，從他們擁有的其他網站，或從你現在正在處理的網站的先前版本。如果沒有，你可以透過檢視其他來源（例如競爭對手的使用統計資料或網站將服務的國家/地區）來獲得一個很好的概念。你也可以憑直覺來判斷。
例如，你可能正在構建一個服務於北美客戶的電子商務網站。該網站應該完全相容最流行的桌面和移動瀏覽器的最新幾個版本——這應該包括 Chrome（以及基於 Chrome 相同渲染引擎的 Edge、Opera）、Firefox 和 Safari。它還應該符合 WCAG AA 級無障礙標準。
現在你知道你的目標測試平臺了，你應該回去審查所需的功能集和你將要使用的技術。例如，如果電子商務網站所有者希望在產品頁面中嵌入一個由 WebGL 驅動的產品 3D 導覽，他們將需要接受這在所有舊版瀏覽器中都無法工作。
你應該列出潛在的問題區域。
注意：你可以在 MDN（你當前所在的網站）上查詢不同的功能來找到技術的瀏覽器支援資訊！你還應該查閱 caniuse.com，以獲取一些其他有用的詳細資訊。
一旦你同意了這些細節，你就可以繼續開發網站了。
開發
現在開始網站的開發。你應該將開發的各個部分拆分成模組，例如，你可以將不同的網站區域拆分開來——主頁、產品頁面、購物車、支付流程等。然後你還可以進一步細分這些——實現通用的網站頁首和頁尾，實現產品頁面詳細檢視，實現持久購物車小部件等。
跨瀏覽器開發有多種通用策略，例如：
- 讓所有功能在所有目標瀏覽器中儘可能接近地工作。這可能涉及編寫不同的程式碼路徑，以不同的方式重現針對不同瀏覽器的功能，或者使用 Polyfill 來使用 JavaScript 或其他技術模擬任何缺失的支援，或者使用一個允許你編寫一段程式碼，然後根據瀏覽器支援情況在後臺執行不同操作的庫。
- 接受有些東西在所有瀏覽器上都無法以相同的方式工作，並在不支援完整功能的瀏覽器中提供不同的（可接受的）解決方案。有時這是由於裝置限制不可避免的——電影寬屏不會提供與 4 英寸手機螢幕相同的視覺體驗，無論你如何程式設計你的網站。
- 接受你的網站在某些舊瀏覽器中無法正常工作，然後繼續前進。如果你的客戶/使用者群對此沒有意見，那就可以了。
通常你的開發會涉及上述三種方法的組合。最重要的是，在提交每個小部分之前進行測試——不要把所有測試都留到最後！
測試/發現
在每個實現階段之後，你需要測試新功能。首先，你應該確保你的程式碼沒有普遍性問題，阻礙了你的功能正常工作。
- 在你的系統上用幾個穩定的瀏覽器進行測試，例如 Firefox、Safari、Chrome 或 Edge。
- 進行一些低保真輔助功能測試，例如嘗試僅使用鍵盤瀏覽你的網站，或透過螢幕閱讀器使用你的網站以檢視其是否可導航。
- 在移動平臺（例如 Android 或 iOS）上進行測試。
此時，修復你在新程式碼中發現的任何問題。
接下來，你應該嘗試將你的測試瀏覽器列表擴充套件到目標受眾瀏覽器的完整列表，並開始專注於排除跨瀏覽器問題（有關確定目標瀏覽器的更多資訊，請參見下一篇文章）。例如：
- 嘗試在所有你能接觸到的現代桌面瀏覽器上測試最新的更改——包括桌面版 Firefox、Chrome、Opera、Edge 和 Safari（理想情況下，在 Mac、Windows 和 Linux 上）。
- 在常見的手機和平板電腦瀏覽器中進行測試（例如，iPhone/iPad 上的 iOS Safari，iPhone/iPad/Android 上的 Chrome 和 Firefox），
- 還要在你目標列表中包含的任何其他瀏覽器中進行測試。
最簡陋的選擇是自己儘可能地進行所有測試（如果你在團隊中工作，可以拉隊友幫忙）。在可能的情況下，你應該嘗試在真實的物理裝置上進行測試。
如果你沒有條件在物理硬體上測試所有這些不同的瀏覽器、作業系統和裝置組合，你也可以利用模擬器（在你的臺式計算機上使用軟體模擬裝置）和虛擬機器（允許你在你的臺式計算機上模擬多個作業系統/軟體組合的軟體）。這是一個非常流行的選擇，尤其是在某些情況下——例如，Windows 不允許你在同一臺機器上同時安裝多個版本的 Windows，因此使用多個虛擬機器通常是唯一的選擇。
另一種選擇是使用者組——使用開發團隊之外的一群人來測試您的網站。這可能是一群朋友或家人，一群其他員工，當地大學的一個班級，或者一個專業的使用者測試設定，人們在那裡獲得報酬來測試您的網站並提供結果。
最後，您可以使用審計或自動化工具更智慧地進行測試；隨著專案規模的擴大，這是一個明智的選擇，因為手動進行所有這些測試可能會花費很長時間。您可以設定自己的測試自動化系統（Selenium 是流行的選擇），例如，它可以在多個不同的瀏覽器中載入您的網站，並且：
- 檢視按鈕點選是否成功觸發了某些操作（例如，顯示地圖），並在測試完成後顯示結果。
- 為每個瀏覽器截圖，讓您可以看到佈局在不同瀏覽器之間是否一致。
如果您希望在測試上投入資金，還有商業工具可以為您自動化大部分設定和測試（例如 Sauce Labs 和 Browser Stack）。這些工具通常支援持續整合工作流，其中程式碼更改在被允許提交到您的程式碼倉庫之前會自動進行測試。
在預釋出瀏覽器上測試
通常在瀏覽器的預釋出版本上進行測試是個好主意；請參閱以下連結：
如果您在網站中使用非常新的技術，並且希望針對最新實現進行測試，或者如果您在瀏覽器的最新發布版本中遇到了錯誤，並且希望檢視瀏覽器開發者是否已在較新版本中修復了該錯誤，則此功能尤為重要。
修復/迭代
一旦你發現了 bug，就需要嘗試修復它。
首先要做的是儘可能縮小 bug 發生的範圍。從報告 bug 的人那裡獲取儘可能多的資訊——平臺、裝置、瀏覽器版本等。在相似的配置上進行嘗試（例如，在不同的桌面平臺上的相同瀏覽器版本，或在相同平臺上的同一瀏覽器的幾個不同版本），以瞭解 bug 的普遍程度。
這可能不是你的錯——如果一個 bug 存在於某個瀏覽器中，那麼希望廠商會迅速修復它。它可能已經修復了——例如，如果 Firefox 49 版本中存在一個 bug，但 Firefox Nightly（版本 52）中已經沒有了，那麼他們已經修復了它。如果還沒有修復，那麼你可能需要提交一個 bug（請參閱下面的報告 bug）。
如果是你的錯，你需要修復它！找出 bug 的原因涉及與任何 Web 開發 bug 相同的策略（再次請參閱除錯 HTML、除錯 CSS 和出了什麼問題？JavaScript 故障排除）。一旦你發現是什麼導致了你的 bug，你需要決定如何在導致問題的特定瀏覽器中解決它——你不能直接修改問題程式碼，因為這可能會破壞其他瀏覽器中的程式碼。通常的方法是以某種方式分支程式碼，例如使用 JavaScript 特性檢測程式碼來檢測問題特性不起作用的情況，並在這些情況下執行一些不同的、可行的程式碼。
完成修復後，您需要重複測試過程，以確保修復正常工作，並且沒有導致網站在其他地方或其他瀏覽器中出現問題。
報告 bug
重申一下上面所說的，如果你在瀏覽器中發現了 bug，你應該報告它們：
總結
本文應該已經為您提供了關於跨瀏覽器測試所需瞭解的最重要概念的高階理解。掌握了這些知識，您現在就可以繼續學習跨瀏覽器測試策略了。