從入門到不放棄：多瀏覽器的自動化測試（1）- 本地測試

本文將做爲多瀏覽器自動化測試的第一篇文章，給讀者從頭介紹如何進行本地多瀏覽的自動化測試工做，包括測試的原理、測試框架的選取、測試工程的搭建和實現等。另外「從入門到不放棄」系列將給讀者們帶來更多從零開始的前端實踐案例，諸如前端組件庫設計與實施、項目自動化構建等案例，歡迎你們關注本系列的其餘文章。

前端之殤

要是你碰到前端工程師朋友，那聊聊瀏覽器的兼容性準是沒錯，這和碰到英國朋友就談天氣是一個道理。大部分程序員朋友們必定會捶胸頓足，連連訴苦，不過若是對方一時語塞，或者欲言又止，請拍拍他 / 她肩膀說：

「沒事，過兩年出了新瀏覽器又是一條好漢。」

在前端界，瀏覽器兼容性是讓工程師們頭疼的問題，對於經驗豐富的人來講，很清楚瀏覽器有哪些坑，可是對於大部分程序員，最可怕的是代碼明明在這個瀏覽器運行得很好，可是到了另外一個瀏覽器中就不能正常運行了。對於這部分的程序員，保障代碼能正常運行的方法即是能儘早發現問題，而後將其解決。

一般狀況下，發現兼容性問題的方法莫過於將程序在各個瀏覽器中執行一遍，但這是極其浪費人力和時間的，最省力的方法也須要在每次版本的更迭時重複一遍測試工做。對於不一樣的兼容性要求，測試須要的時間各不相同，如果只支持最新版本的瀏覽器，那麼便測試 三、4 個瀏覽器便可，可是對於兼容性要求高的程序，有可能要測試 10 個瀏覽器以上。

對於中小型公司來講，若是沒有專職的測試人員，這樣的測試耗時是致命的。若進行嚴格測試，則會拖慢項目進度，假若敷衍了事，那程序的質量便無法保證。

本文將做爲多瀏覽器自動化測試的第一篇文章，將以項目 A 做爲例子，給讀者從頭介紹如何進行本地多瀏覽的自動化測試工做，包括測試的原理、測試框架的選取、測試工程的搭建和實現等。在下一篇文章中將介紹如何使用雲服務實現更多瀏覽器的測試工做。另外「從入門到不放棄」系列將給讀者們帶來更多從零開始的前端實踐案例，諸如前端組件庫設計與實施、項目自動化構建等案例，歡迎你們關注本系列的其餘文章。

小窺測試

測試是一個龐大的主題，包括各類分類的測試，諸如黑盒測試/白盒測試、單元測試 / 集成測試 / 端到端測試等。一般程序員在測試本身的代碼的時候用得最多的即是單元測試，可是由於測試也是須要代價，不少人是不喜歡寫測試的，甚至是一點都不寫。固然今天咱們不是要討伐諸位，而是但願讀者能從文中受益，從一個測試小白能夠本身動手搭建本身的測試工程。

在多瀏覽器的自動化測試，咱們多半是進行端到端的測試工做，一小部分是大粒度的單元測試。端到端測試測試模擬用戶的行爲。在 Web 應用程序中，他們會啓動服務器，打開瀏覽器，模擬用戶的行爲進行點擊、輸入、提交等動做，斷言瀏覽器中發生了特定的事情或者是獲得了期待的結果，從而讓咱們相信功能能夠正常的運行。而單元測試根據代碼單元的公共 API 運行它們。這些測試須要建立一個類的實例，使用特定的輸入調用它的方法，斷言被調用的方法達到了預期的效果。

在下文中咱們會看到這兩種測試的實踐，固然有時候區分度並不大，可能沒法明顯地區分哪些是端對端測試哪些是單元測試，有時候他們是混合起來的，不過只要記住咱們的目標是保證功能能夠正常運行就足夠了。

在瀏覽器的測試中，Selenium 可謂是最重要的工具之一。簡單來講 Selenium的做用是 "Automate Browsers"——讓瀏覽器能夠自動化起來的工具。它提供了統一的接口，讓用戶可使用不一樣的編程語言，調用其接口來模擬用戶的操做，例如點擊，移動等操做。基本上一切人工操做的行爲均可以經過 Selenium 的 API 進行觸發操做。咱們將 Selenium 看做是人手的代理，幫程序員完成一切用手乾的活。

測試的技術方案選擇

在進行項目實踐前，很重要的一項工做是選擇合適的技術棧。比如在前端開發時應該選擇 React，Vue 仍是 Angular 做爲框架同樣，前端的測試工做也須要選擇一套技術棧。

不少時候你們在制定技術棧時容易走偏，在選擇技術框架時不是選擇最合適的框架，而是選擇最熱門的框架。固然必定程度上熱門的框架能反應其受歡迎程度，多是由於其出衆的優勢，如較高的開發效率、高效的渲染特性或者是活躍的社區。在前端開發中，很容易有這樣的感覺，就是隻要半個月沒有關注業界的最新動態，就感受恍若隔世，新的解決方案層出不窮，讓人喘不過氣。

就做者本人經驗來講，已通過了慌亂的年紀，不再會盲目地追尋新技術，而轉向關注技術背後解決的痛點，就好像 2C 創業者們嘴上老說的用戶痛點同樣。

在介紹本文涉及項目的技術棧以前，須要提醒諸位，此處的技術選擇並不必定徹底適用於諸位的項目，請各位三思而測。目前市場上有衆多的測試框架，測試斷言庫甚至是全套的測試解決方案。Karma、Jasmine 和 Mocha 是你們熟知的測試框架，而 chai, should.js 是流行的斷言庫，另外在不一樣的技術社區還有自成一套的測試技術，好比 React 社區中的 Jest 和 Enzyme 都是受開發者喜好的測試框架和庫，最近一些新的並行測試解決方案也日漸流行，如 AVA 、Intern 。本文中的實踐來自於項目 A，在項目測試前期咱們分析了測試需求，咱們但願整個測試方案能知足一下要求：

• 支持端到端測試
• 對接雲測試服務方便
• 本地測試和雲測試切換方便
• 提供封裝的瀏覽器操做接口
• 測試用例能夠快速遷移到其餘框架下執行

考量了以上的需求，咱們認爲 NightWatch.js 是一款很是合適的測試解決方案。固然其餘的測試框架也基本能知足需求，可是從方便易用性上考慮，咱們最後採用了 NightWatch.js，該方案不只提供簡易封裝的瀏覽器代理操做 API， 還給咱們提供了方便便捷的雲測試配置(下一篇文章將着重介紹此內容)，就憑這兩點就已經很是吸引咱們了。對於前端測試新手，強烈推薦試用此框架，讓你能夠迅速完成曾經畏而卻步的測試工做。

項目實踐

項目 A 的本地測試實踐是須要分別在兩臺電腦上的多瀏覽器中執行測試，兩臺電腦分別是 Windows 系統和 Mac 系統，包括了 IE 、Firefox(windows / mac)、Chrome(windows / mac)、Safari 等最新的主流瀏覽器。兩臺機子的測試是分別執行的，咱們經過 Jenkins 分別按期執行機子上的測試任務，將測試結果經過郵件的方式反饋給開發人員。 Jenkins 是一個持續集成的平臺，關於若是使用 Jenkins 請各位本身 Google。

在接下來的文章中，咱們將只介紹在一臺機子上的工程實踐，對於多個機子的測試須要將以下的工程部署到不一樣的機子，再使用諸如 Jenkins 之類的工具進行按期執行就能夠。

開始工做前，咱們須要將技術關係瞭然於心。咱們在 Nightwatch 框架下使用 Selenium 中的 driver對瀏覽器進行操做。不一樣的瀏覽器有不一樣的 Driver，整個技術棧圖如圖1所示：

在圖中 Test Runner 即爲 Nightwatch，咱們使用 Nightwatch 提供封裝過的 API 進行 Test Case 的書寫。下面咱們將從零開始手把手教你如何使用 Nightwatch 啓動你的第一個 Test case。

01安裝測試所需包

在本身的前端項目中安裝 Nightwatch.js，並將其保存在 package.json的 devDependencies 中。

npm install nightwatch --save-dev

02增長 npm script 入口

在 npm scripts 中加入 test 指令入口，該條指令的具體工做是使用 test.conf.js 的配置，執行名爲 'A' 、'B' 、'C' 的配置項(若爲了直觀查看測試的內容，可根據項目的測試瀏覽器和版本將名字設爲 chrome52.0, safari9.0 這樣的名字，此處設爲 A , B , C 是避免你們誤認爲是指令是自動根據名字去尋找匹配的瀏覽器）。更多命令的詳解請參照 Nightwatch 文檔。

"scripts": {
      ...
      "test": "./node_modules/.bin/nightwatch -c conf/test.conf.js -e A,B"
      ...
    }

03配置 Nightwatch

完成指令入口的配置工做，接下來須要完成 test.conf.js 的配置工做。在本地測試中，咱們使用 Selenium 對瀏覽器進行代理操做。配置使用本地 Selenium 操做本機瀏覽器 Nightwatch 有三個重點：

Selenium 的配置：配置好 Selenium jar 包的路徑，該包從 Selenium 的官網上下載，host 和 port 按照下文配置書寫。
driver 的配置：cli_args 是 Selenium 參數，在這咱們指定了 chromedriver 和 geckodriver 的路徑，chromedriver 是用來操做 chrome，geckodriver 用來操做 safari 和 firefox（顧名思義，geckodriver 支持基於 gecko 的瀏覽器），均可以從網上進行下載。在項目A中，咱們將其下載到前端下面的 bin 目錄下。
測試目標瀏覽器的配置：也就是A和B，每個 Object 都是一個配置項，A是測試Chrome瀏覽器，B是測試 Safari 瀏覽器，若是沒有指定版本，就使用本地最新版，更多的配置能夠參考 Nightwatch 文檔，能夠指定系統、版本，並能夠啓動、禁用瀏覽器的某些特性，如 Cookie。

...

    selenium : {
      "start_process" : true,
      "server_path":"./bin/selenium-server-standalone-3.4.0.jar",
      "host" : "127.0.0.1",
      "port" : 4444,
      "cli_args": {
        "webdriver.chrome.driver": "bin/chromedriver",
        "webdriver.gecko.driver" : "bin/geckodriver"
      }
    },
    ...
    test_settings: {
      A: {
        desiredCapabilities: {
          'browserName': 'chrome'
        }
      },
      B: {
        desiredCapabilities: {
          'browserName': 'safari'
        }
      }
    }

諸位須要根據本身機子的實際狀況進行配置，若是是Windows系統，那麼將沒有safari瀏覽器，而使用 IE 瀏覽器，這樣則會須要 IE 瀏覽器對應的 driver。

04書寫測試用例

在各項準備工做完畢後，就只差測試用例了，下面是項目 A 的一個測試用例的片斷，用於檢測頁面上 id 爲 testid 的 DOM 中的內容字符，咱們期待字符的長度爲 32， 若是該字符爲 32 個字符，那麼測試經過，不然測試失敗。

須要注意的是由於此 DOM 是動態插入的，因此在判斷其字符前，咱們使用 waitForElementVisible 來檢查瀏覽器中 testid 的 DOM 是否已經顯示，若在5秒內顯示則進行下面的工做，若是沒有顯示，那麼測試也會失敗。

module.exports = {
      '@tags': ['unit'],
      'unit testing' : function (browser) {
        browser.url(`http://localhost:3010/test`)
          .waitForElementVisible('#testid', 5000)
          .getText("#testid",function(result){
            this.assert.equal(result.value.length,32);
          });
        browser.end();
      }
    };

1. 運行測試
   到此爲止，咱們簡單的測試工程已經搭建完畢。如今咱們回過頭去，執行咱們最開始配置的 test 指令，啓動測試任務。你須要在命令中執行：

npm test

若是順利的話，此時你會看到瀏覽器自動地打開關閉，很快就能從終端上看到以下的測試結果,圖 2 展現的是多個測試用例成功的結果，圖 3 展現的是測試失敗的結果（如遇到沒法測試或者其它異常狀況請 Google。：D)。

從測試結果中能夠查看測試用例的測試結果，包括測試的瀏覽器、未經過測試的信息詳情等。至此，一個從零開始的本地測試實踐教程結束。

本地測試與雲測試

由於本地瀏覽器的類型有限，通常咱們更多地使用本地的多瀏覽器測試來完成功能驗證的工做，對於要求更嚴的兼容性測試，咱們將採用雲測試的方式。雲測試即雲服務提供商將向咱們提供更多的雲主機，每臺主機上運行着不一樣版本的瀏覽器。經過使用雲測試服務，咱們就能將測試覆蓋到更多類型、版本的瀏覽器。

在下一篇文章中，咱們仍以項目 A 爲例子，使用 Nightwatch 框架，在此文章的基礎上介紹雲測試和雲測試工程的搭建。

潘潘，豈安科技軟件工程師同濟大學畢業，曾在VMware等多家知名公司實習，3年全棧開發經驗，負責豈安科技核心產品初期的前端開發和架構工做。