本文主要首先主要介紹了什么是自動化測驗,接著對常用的自動化測驗框架進行了對比分析,最后,介紹了如果將自動化測驗框架Cypress運用在專案中,
一、自動化測驗概述
為了保障軟體質量,并減少重復性的測驗作業,自動化測驗已經被廣泛運用,在開始學習自動化測驗之前,我們很有必要先搞清楚這幾個問題,什么是自動化測驗?為什么要做自動化測驗?哪些專案適合做自動化測驗?
1、什么是自動化測驗
自動化測驗是一種測驗方法,是指使用特定的軟體,去控制測驗流程,并比較實際結果與預期結果之間的差異,通過將測驗自動化,可以把人對軟體的測驗行為轉化為由機器自動執行測驗的行為,從而替代大量的手工測驗操作,使得測驗可以快速,反復的進行,
關于自動化測驗,有一個測驗金字塔模型,該模型把測驗從下到上分為了單元測驗、集成測驗和端到端測驗(E2E測驗/UI界面測驗),越往金字塔底層,測驗成本越低,效率也越高,而越往金字塔的頂層,測驗成本會逐漸增高,收益也會越低,

- 單元測驗
單元測驗又稱為模塊測驗,主要針對程式中最小可測驗單元(一般指方法,類)的測驗,具備投入小、收益產出高的特征,可以較早期地發現代碼缺陷,適用于公共函式庫的測驗,
- 集成測驗
集成測驗主要包括模塊介面測驗,子功能模塊集成起來的功能模塊測驗等,目的是為了驗證在單元測驗的基礎上,所有模塊集成起來的子系統、子功能是否仍然滿足質量目標,
- 端到端測驗
端到端測驗的主要目的是從軟體使用者角度來檢驗軟體的質量,如打開瀏覽器,進行一系列的操作,驗證界面或功能是否符合預期,
不同型別的專案,具有不同的測驗場景,因此也需要采用不同的測驗型別,對于開發人員來說,單元測驗專注于代碼底層,可能是一種比較友好的選擇,但是站在產品的角度上,也許端到端測驗(E2E)是更好的選擇,更能保障產品功能符合預期,
講完了自動化測驗型別,我們再來看看測驗中常用的測驗模式,一般常用的測驗模式包括TDD和BDD兩種,
- TDD
TDD(測驗驅動開發,Test Driven Development),TDD是指先寫測驗用例代碼,再寫功能代碼,并且不斷的重復上述步驟直到完成開發作業,TDD一般結合單元測驗使用,是白盒測驗,
- BDD
BDD(行為驅動開發,Behavior Driven Development),BDD是指先寫功能代碼,再寫測驗用例代碼,BDD一般結合集成測驗或端到端測驗使用,是黑盒測驗,
當然,是選擇TDD還是BDD,也是需要從專案的實際角度出發考慮,再做選擇,
2、為什么要做自動化測驗
接下來,我們再來聊聊為什么要做自動化測驗?在實際的專案開發中,我們常常會遇到以下問題:
- 產品迭代頻繁
迭代程序中不可避免的需要新增功能或修改功能,怎么保障新功能的發布不會影響原有功能呢?
- 多人共同參與開發,代碼維護難
專案開發程序中多人參與開發,人員變動頻繁,開發程序中可能出現誤刪或誤改他人代碼邏輯的問題,如何保障代碼的質量和可靠性?
- 測驗人力不足,回歸測驗耗時耗力
為了解決上面提到的兩個問題,其實方法很簡單,就是每次新功能發布后,都對原有功能再進行回歸測驗,但是又可能遇到測驗人力不足的情況,自己手動進行回歸測驗又耗時耗力,如何才能減少重復性作業,提高效率呢?說到這里,自動化測驗就派上用場啦~
那專案引入自動化測驗有什么好處呢?自動化測驗的好處主要包括了以下幾點,
- 驗證代碼正確性,保障產品質量
可以驗證代碼或產品功能的正確性,確保每次產品迭代,新功能和原有功能能夠正確集成,保證產品質量,
- 提高測驗效率
撰寫的測驗用例具有一次撰寫,多次運行的特點,通過執行測驗腳本,可以實作使得測驗快速,反復的進行,可以替代大量的重復性手動測驗作業,提高效率,
- 起到檔案作用
撰寫的測驗用例可以起到檔案的作用,有利于專案后續的維護,
3、哪些專案適合引入自動化測驗
既然自動化測驗有這么多好處,那是不是所有專案都適合引入自動化測驗呢?當然不是!自動化測驗需要進行測驗用例的撰寫,需要一定的開發成本,我們需要立足于專案本身,再來決定是否適合引入自動化測驗,
- 適合引入自動化測驗的專案
1)產品周期較長,需要不斷進行迭代/重構的專案,2)公共庫類的開發維護,
- 不適合引入自動化測驗的專案
1)產品周期過短的專案,2)需求變動過于頻繁的專案,
二、前端自動化測驗框架選擇
在明確了我們的專案有必要引入自動化測驗之后,就需要選擇一款自動化測驗框架或工具來幫助我們完成自動化測驗作業啦~
1、測驗框架對比
下面主要對比了現在常用的Web前端自動化測驗框架,如果需要了解更多的框架,可以參考測驗框架選型
| Jest | Mocha | Selenium/WebDriver | Nightwatch | TestCafe | Cypress | |
| 支持測驗型別 | 單元測驗 | 單元測驗 | E2E測驗 | E2E測驗、Node.js單元和集成測驗 | E2E測驗 | 單元測驗、集成測驗、E2E測驗 |
| 支持語言 | JS、Node | JS、Node | Java、Python、C#、JS | JS、Node | JS、TypeScript | JS |
| 是否支持可視化測驗 | 否 | 否 | 否 | 否 | 否 | 是 |
| 是否自帶斷言庫 | 是 | 否 | 否 | 是 | 否 | 是 |
| 是否開箱即用 | 是 | 否 | 否 | 是(安裝配置繁瑣) | 是 | 是 |
| 錄制生成腳本 | / | / | 支持 | 不支持 | 不支持 | 不支持 |
| Github Star | 35.2k | 20.5k | 20.8k | 10.7k | 8.9k | 31.3k |
| 檔案 | Jest檔案 | Mocha檔案 | Selenium檔案 | Nightwatch檔案 | Testcafe檔案 | Cypress檔案 |
在上述框架中,由于Cypress能夠同時支持單元測驗、集成測驗和E2E測驗,提供了一套完成的測驗解決方案,能夠滿足我們的需求,此外,Cypress支持JS撰寫測驗用例,支持Jquery元素定位選擇器,支持Headless和CI持續集成,運行速度快,上手成本低,并且具有可視化除錯界面,方便定位問題,因此決定嘗試將Cypress運用到專案中,
三、Cypress實踐
接下來,主要介紹如何將Cypress運用在專案中,
1、Cypress安裝
在安裝Cypress時,可以直接在原有的專案上進行安裝,也可以另起一個專案安裝,
npm install cypress --save-dev
2、Cypress啟動
Cypress主要包含以下兩種啟動方式:
1)命令列執行npx cypress open:會在瀏覽器打開測驗用例集的界面,需要手動運行,
2)命令列執行npx cypress run:會以無頭瀏覽器模式運行指定的所有測驗用例,沒有可視化界面,但運行程序中會錄制整個測驗程序的視頻,可在cypress/videos目錄下查看,
當然,除了直接在命令列運行上述命令,也可以通過配置package.json的scripts欄位來定義啟動方式,
"scripts": { "serve": "vue-cli-service serve", "build": "vue-cli-service build", "lint": "vue-cli-service lint", "cypress:open": "npx cypress open", "cypress:run": "npx cypress run" }
- 可視化界面運行
如果我們需要在可視化界面進行測驗,在配置好package.json后,只需要執行npm run cypress:open,就可以啟動Cypress,實作可視化除錯,如果在啟動的程序中遇到以下錯誤,可以先執行npx cypress install -force,再重新啟動Cypress,

如果成功啟動Cypress,將會看到以下界面,examples目錄下是cypress自帶的測驗用例演示代碼(如果后面不需要,我們可以將這些測驗用例洗掉),點擊其中的某個測驗用例,將會自動打開瀏覽器運行測驗用例,

如果我們是第一次啟動Cypress,會發現在專案根目錄下也自動生成了cypress.json組態檔和cypress目錄,其中,integration檔案夾就是我們用來存放測驗用例的目錄,可以在cypress.json中自定義這些默認目錄的命名,

- 無頭瀏覽器模式運行
如果我們想以無頭瀏覽器模式運行,在配置好package.json后,需要執行npm run cypress:run,Cypress就會以無頭瀏覽器的模式運行指定的所有測驗用例,

3、撰寫測驗用例
接下來以驗證百度頁面的搜索功能為例,演示如何撰寫測驗用例,測驗用例可以以.spec.js或.js結尾命名,并放入cypress/integration中,
專案目錄如下所示,在cypress/integration中創建test.js或test.spec.js測驗用例檔案,

接著,可以在test.js中開始撰寫測驗用例,Cypress支持Jquery元素選擇器及漢字選擇器,并且也支持鏈式操作,此外,由于Cypress擁有自動等待機制,我們無須在測驗中添加wait或sleep,Cypress會自動等待元素至可操作狀態時才執行命令或斷言,
/// <reference types="cypress" /> context('百度頁面測驗', () => { it('訪問百度頁面,驗證搜索功能', () => { cy.visit('https://www.baidu.com').then(() => { // 1. 輸入搜索內容 cy.get(".s_ipt").should("exist").type("Cypress自動化測驗"); // 2. 點擊百度一下按鈕 cy.get(".s_btn").contains("百度一下").should("exist").click(); // 3. 驗證搜索內容不為空 cy.get("#content_left").find("div").then(ele => { expect(ele.length).gt(0); }); }); }); });
撰寫完上述代碼,我們就可以直接啟動Cypress運行啦,當然,我們也可以根據實際需要在cypress.json進行一些配置,下面給出了一些常用的配置,可以在Cypress檔案查看更多配置,

最后,執行npm run cypress:open啟動Cypress,啟動成功后,我們就可以看到以下界面,點擊test.js,就會在瀏覽器中運行該測驗用例,

在測驗用例執行的程序中,每一步操作都會被記錄下來,可以點擊左邊的界面對每一步的操作進行回看,可以幫助我們快速定位問題,


4、Cypess檔案上傳/下載
在實際的使用程序中,我們通常也需要驗證檔案上傳或下載功能,而Cypress也能夠滿足這些需求,
1)檔案上傳
首先需要安裝cypress-upload-file插件,
npm install cypress-upload-file --save-dev
將要上傳的檔案放到cypress/fixtures中,

撰寫測驗用例代碼,
/// <reference types="cypress" /> context('檔案上傳', () => { it('驗證檔案上傳功能', () => { // 訪問頁面,此處步驟省略 let file = "file/cover.jpg"; cy.get("input[type='file']").attachFile(file); // 執行斷言,此處步驟省略 }); });
2)檔案下載
若我們在運行測驗用例的程序中存在檔案下載操作,Cypress會自動在cypress目錄下創建一個downloads目錄,所下載的檔案會自動保存在該目錄中,

可以在測驗用例中讀取并決議下載的檔案,
/// <reference types="cypress" /> const path = require("path"); context('檔案下載', () => { it('驗證檔案下載功能', () => { // 訪問頁面,執行下載操作,此處步驟省略 const downloadsFolder = Cypress.config("downloadsFolder"); const downloadedFilename = path.join(downloadsFolder, "下載檔案.xls"); // 讀取檔案 cy.readFile(downloadedFilename).then(data =https://www.cnblogs.com/Yellow-ice/p/> { // 執行斷言,此處步驟省略 }); }); });
5、Cypress測驗報告
在執行完自動化測驗后,我們通常都希望能夠得到一份詳細的測驗報告,而Cypress也能夠提供這個功能,Cypress除了內置的測驗報告,也支持用戶自定義報告格式,
1)內置的測驗報告
Cypress內置的測驗報告主要包括了spec格式報告(在控制臺視窗輸出嵌套分級視圖),json格式報告(在控制臺視窗輸出一個大的json物件)和junit格式報告(輸出一個xml檔案),以spec格式報告為例,在啟動cypress時加上以下引數即可,

2)自定義的測驗報告
常用的自定義測驗報告有Mochawesome報告,Mochawesome是與Mocha一起使用的自定義報告程式,并與mochawesome-report-generator結合使用以生成獨立的HTML/CSS報告,
安裝mocha和mochawesome,
npm install mocha --save-dev
npm install mochawesome --save-dev
修改啟動引數,

運行npm run cypress:run,執行結束后,會在專案根目錄下生成mochawesome-report目錄,

在瀏覽器中打開mochawesome.html,就可以查看可視化測驗報告,

四、撰寫可維護的測驗腳本
在實際撰寫測驗用例的程序中,隨著頁面的增多,我們常常會遇到以下這些問題,而這個時候,如何撰寫可維護的測驗腳本,方便后期維護,也顯得非常重要,這里也總結了實際開發中的一些經驗,

1、測驗用例代碼結構組織
在撰寫測驗用例時,我們可以一個頁面對應一個測驗檔案,也可以同個功能模塊的頁面一起對應一個測驗檔案,并且和平時開發中所采用的代碼組織結構類似,將不同的測驗檔案劃分到對應的目錄下進行管理,方便后期的維護,

2、頁面選擇器統一管理
在E2E測驗中,我們通常需要獲取頁面元素,才能夠進行點擊等操作,而Cypress支持Jquery選擇器,我們可以通過元素的class或id定位元素,但是一旦頁面的類名或id發生變化,我們不得不修改對應頁面的所有測驗用例,

在撰寫測驗用例的程序中,我們可以將頁面選擇器進行統一管理,實作類名或id選擇器和邏輯代碼的分離,對于每個頁面或者每個測驗檔案,可以創建一個對應的xxxControl.js檔案,在該檔案中,將會定義一個json物件并且export出來,其中,key為我們自己定義的選擇器名稱,而value值對應頁面中實際的class或id,

由于目前專案中使用到了iview組件庫,因此也提取出了commonControl.js,對iview的選擇器進行統一管理,

由于每個頁面都采用到了iview組件,因此每個頁面或每個測驗檔案對應的control.js都需要將上面的commonControl.js引入進來,

最后,每個測驗檔案只需要引入對應的control.js,就可以通過自己定義的key值獲取頁面真正的class或id,

上面的方法看起來雖然麻煩了點,但是有兩個好處,首先,采用自己定義的key值,更容易方便我們記憶,可以減少撰寫測驗用例程序中反復查看頁面元素對應的class或id名,其次,當頁面的類名或id發生變化時,我們只需要修改頁面對應的control.js檔案就可以,而不用修改所有的測驗用例檔案,有利于后續的維護,
3、路徑名及介面統一管理
在撰寫測驗用例的程序中,我們通常需要使用cy.visit()去訪問某個頁面,或者使用cy.request()去呼叫后臺介面以請求資料或創建測驗資料,對于頁面url或后臺介面api,我們也可以放入某個檔案中進行統一管理,


4、代碼復用
在測驗的程序中,我們可能會注意到,不同的頁面可能會存在一些相同的功能,比如像目前的專案中,不同的頁面都需要對一些操作進行彈框確認或表單輸入,而在驗證彈框功能是否正確的程序中,我們都需要對彈框執行點擊確定按鈕、點擊取消按鈕、點擊關閉按鈕等操作,而這個時候就可以采用面向物件編程的方法實作代碼的封裝和復用,

定義一個彈框類,并且定義屬性和方法,

在測驗檔案中,需要實體化物件,并呼叫相關的方法完成某個操作,

當然,有些方法并不是所有的頁面都共有的,但是在某個頁面或功能中會反復使用到,因此也可以為每個頁面或每個測驗檔案單獨封裝相應的方法,比如為課程管理頁面封裝相應的通用方法,


以上就是關于將Cypress運用在專案中的一些總結,而如何將Cypress和CI/CD結合,并且實作自動化測驗的定時執行,也是接下來需要繼續完成的內容~
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/285660.html
標籤:其他
上一篇:我的N年軟體測驗感悟
