从入门到不放弃：多浏览器的自动化测试（1）- 本地测试
本文將作為多瀏覽器自動化測試的第一篇文章，給讀者從頭介紹如何進行本地多瀏覽的自動化測試工作，包括測試的原理、測試框架的選取、測試工程的搭建和實現等。另外“從入門到不放棄”系列將給讀者們帶來更多從零開始的前端實踐案例，諸如前端組件庫設計與實施、項目自動化構建等案例，歡迎大家關注本系列的其他文章。
前端之殤
要是你碰到前端工程師朋友，那聊聊瀏覽器的兼容性準是沒錯，這和碰到英國朋友就談天氣是一個道理。大部分程序員朋友們一定會捶胸頓足，連連訴苦，不過如果對方一時語塞，或者欲言又止，請拍拍他 / 她肩膀說：
“沒事，過兩年出了新瀏覽器又是一條好漢。”
在前端界，瀏覽器兼容性是讓工程師們頭疼的問題，對于經驗豐富的人來說，很清楚瀏覽器有哪些坑，但是對于大部分程序員，最可怕的是代碼明明在這個瀏覽器運行得很好，但是到了另一個瀏覽器中就不能正常運行了。對于這部分的程序員，保障代碼能正常運行的方法便是能盡早發現問題，然后將其解決。
通常情況下，發現兼容性問題的方法莫過于將程序在各個瀏覽器中執行一遍，但這是極其浪費人力和時間的，最省力的方法也需要在每次版本的更迭時重復一遍測試工作。對于不同的兼容性要求，測試需要的時間各不相同，若是只支持最新版本的瀏覽器，那么便測試 3、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();
??}
};
```
5. 運行測試
到此為止，我們簡單的測試工程已經搭建完畢。現在我們回過頭去，執行我們最開始配置的 test 指令，啟動測試任務。你需要在命令中執行：
```
npm test
```
如果順利的話，此時你會看到瀏覽器自動地打開關閉，很快就能從終端上看到如下的測試結果,圖 2 展示的是多個測試用例成功的結果，圖 3 展示的是測試失敗的結果（如遇到無法測試或者其它異常情況請 Google。：D)。
從測試結果中可以查看測試用例的測試結果，包括測試的瀏覽器、未通過測試的信息詳情等。至此，一個從零開始的本地測試實踐教程結束。
本地測試與云測試
因為本地瀏覽器的類型有限，一般我們更多地使用本地的多瀏覽器測試來完成功能驗證的工作，對于要求更嚴的兼容性測試，我們將采用云測試的方式。云測試即云服務提供商將向我們提供更多的云主機，每臺主機上運行著不同版本的瀏覽器。通過使用云測試服務，我們就能將測試覆蓋到更多類型、版本的瀏覽器。
在下一篇文章中，我們仍以項目 A 為例子，使用 Nightwatch 框架，在此文章的基礎上介紹云測試和云測試工程的搭建。
潘潘，豈安科技軟件工程師
同濟大學畢業，曾在VMware等多家知名公司實習，3年全棧開發經驗，負責豈安科技核心產品初期的前端開發和架構工作。
總結
以上是生活随笔為你收集整理的从入门到不放弃：多浏览器的自动化测试（1）- 本地测试的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： MATLAB批量读取航摄相片EXIF信息
- 下一篇： selenium 处理多浏览器测试