Selenium 運作方式：第一集 - 傳輸
分類
在 2020 年 1 月最後一個週末的互動之後，在一個 Selenium 問題中，有人說「為什麼你們不能…」，在我解釋了問題之後，我認為我應該開始解釋 Selenium WebDriver 中的指令，以及為什麼我們今天會採用這樣的設計。
我會在系列文章的每一頁重複這一點，但有非常多，有時令人惱火的，思考投入到 Selenium 的每個小部分的運作方式中。
為什麼？
Selenium，偶然地且擅長其功能，被全球數百萬人使用。從 Microsoft 和 Google 到小型新創公司，都使用它來確保他們的網站在每個瀏覽器中都能運作。
Selenium 如何與瀏覽器溝通？
多年來，Selenium 決定我們將使用 HTTP 與瀏覽器進行通訊。我們建立了一個 REST-ish API，每個用戶端繫結都可以使用，並希望獲得相同的結果。
HTTP 和 REST-ish？真的嗎？
是啊…
讓我們從 HTTP 部分開始。當我們開始時，我們必須有一種獨特的方式來與每個瀏覽器進行通訊，基於與它們通訊的最佳方式。因此，對於 Internet Explorer，我們編寫了 COM 程式碼。它很好，它可以運作，但給我們帶來了惡夢。對於 Firefox，我們編寫了一個怪物，逐行讀取，幸運的是，由於 Mozilla 的「讓瀏覽器成為你的」態度，我們可以做很多事情。Opera 允許我們透過 DevTools 協定進入。
現在，這意味著，尤其是在 WebDriver 的早期，我們需要維護 N: M 繫結，其中 N 是語言繫結，M 是我們支援的瀏覽器。這不是通往好產品的道路。我們決定我們需要每個語言都能理解的東西。我們還需要一些相當穩定的東西。HTTP 被選擇了，我們開始建構 JSONWireProtocol。
JSONWireProtocol 是我們建構 REST-ish 介面的地方，它會說 JSON。我說 REST-ish 是因為它沒有遵循 REST 的所有原則，但足以滿足我們的需求。
它現在與事物有何關聯？
網路、網際網路和世界都向前發展了。為什麼 Selenium 沒有？
這是一個好問題，重點是我們正在努力推動事情向前發展。不幸的是，網路有一種狀態，除非它正在運作，否則它是壞掉的。HTTP 作為一種協定非常穩健。它還可以讓人們建立測試叢集，而無需過於擔心多工處理如何運作。這就是 Selenium Grid 被創建的原因，並且在將您的測試分配到多個裝置和多個機器時，它仍然是一個相當不錯的選擇。
但是某些使用 Chrome Debug Protocol 的自動化框架更像網路，要像它們一樣。
所以… 有些工具使用 Chrome 的 Debug Protocol 來驅動瀏覽器，它們在某些方面比 Selenium 做得更好，這歸功於它們選擇如何與瀏覽器通訊。不幸的是，這是一個 Chrome 專有協定，Google 對於與其他瀏覽器合作使其不成為專有協定不感興趣。
此外，忽略 Google 團隊有趣的設計選擇，還有一個問題是我們必須保持永久開啟的連線。在這種情況下，它使用 WebSockets，但如果您還記得我之前關於網際網路在啟動之前是關閉的評論。WebSockets 將不斷重新建立連線。還有一個問題是，有多少流量會在這個管道中上下傳輸。
這對於 puppeteer 來說很好，您只與本地機器上的東西通訊，但如果您結合了 CI 服務，例如 Circle CI 或 TravisCI，以及 AWS Device Farm、Sauce Labs 或 BrowserStack 之類的東西，您突然在您和您的執行器之間有很多網際網路，並且這些數據需要到達某個地方。
W3C 瀏覽器測試和工具工作組，由瀏覽器供應商和 Selenium 人員組成，正在努力設計它的外觀，以確保我們可以從一開始就使其跨瀏覽器，而無需對瀏覽器進行奇怪的駭客修補並自行發布這些瀏覽器。
想要閱讀更多？
這最初發布在 https://www.theautomatedtester.co.uk/
