0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

前端領(lǐng)域的自動化測試

冬至子 ? 來源:林不渡也不是不能渡 ? 作者:林不渡 ? 2022-10-12 10:35 ? 次閱讀

前言:前端領(lǐng)域的自動化測試

一直以來對于前端同學(xué)來說,自動化測試都是一個比較特殊的命題。一方面,大家其實(shí)都知道自動化測試的好處,做了什么改動只要跑一遍測試用例就知道有沒有改掛了之前的邏輯,進(jìn)行修改時(shí)也更有底氣。而另一方面,前端本身就具有特殊性,活動頁從需求評審到正式上線可能在一周內(nèi)就完成了,這種迭代速度還寫測試用例就是折磨自己。

但實(shí)際上,自動化測試在前端工程中也是相當(dāng)重要的一部分。即使是快速迭代的活動頁面,也會有通用的工具函數(shù)與 SDK,對這一部分的代碼進(jìn)行測試用例的完善是有必要且意義重大的,而對于某些流量巨大且長期存在的頁面,我們甚至需要進(jìn)行多種測試場景的保障。

然而由于這兩種情況的存在,很多前端同學(xué)其實(shí)都對自動化測試的認(rèn)知相當(dāng)空白,它有哪些分類?有哪些推薦的實(shí)踐?有哪些框架與方案?而這篇文章的目的就是進(jìn)行一個基礎(chǔ)的掃盲,至少完成閱讀以后你會知道如何為項(xiàng)目編寫測試用例,以及應(yīng)該編寫哪些場景的測試用例。

單元測試與集成測試

單元測試(Unit Testing)正如其名,其中的測試用例應(yīng)當(dāng)是針對代碼中的各個單元的,如前端代碼中,每一個工具方法都可以被作為一個單元,對應(yīng)一個獨(dú)立的測試用例。但這么說并不意味著你要寫出非常細(xì)粒度的代碼——這不是沒事折磨自己嗎?我通常使用“功能單元”的方式來確定粒度,比如生產(chǎn)薯?xiàng)l的流水線上,清洗-削皮-切片-包裝就是四個完全獨(dú)立的功能單元。

你可能會感到疑惑,這四個功能單元明明存在依賴關(guān)系,為何說是完全獨(dú)立的?這是因?yàn)樵趩卧獪y試時(shí),非常重要的一個步驟就是對當(dāng)前測試單元的外部依賴進(jìn)行模擬,比如我在測試削皮功能時(shí),會直接給到“已經(jīng)清洗完畢的土豆”,然后檢查“削皮后的土豆”,而不會真的去調(diào)用前后的功能單元。

常見的模擬操作可以分為 Fake、Stub、Mock、Spy 這么幾種,我們在下文會有更詳細(xì)的介紹。

一種常見的情況是工具方法中會基于外部依賴的表現(xiàn)執(zhí)行不同分支的代碼(if/else,try/catch,resolve/reject 等)。這種時(shí)候,我們需要做的就是通過修改外部依賴的表現(xiàn),來檢查工具方法內(nèi)部各個代碼分支的執(zhí)行情況。比如,在 fetch 成功返回時(shí)應(yīng)當(dāng)調(diào)用 processData 方法,在 fetch 失敗時(shí)應(yīng)當(dāng)調(diào)用 reportError 方法,此時(shí)你就可以篡改掉 fetch 的實(shí)現(xiàn),然后檢查 processData 、reportError 方法是否被調(diào)用(注意,這兩個方法也需要被模擬(Stub / Spy) ,然后才能檢查它們的調(diào)用情況)。

當(dāng)然,完全模擬所有外部依賴是最理想的情況,在很多時(shí)候一個工具方法可能具有許多外部依賴,此時(shí)你可以省略掉其中能確定無副作用(如 logger 這樣的純函數(shù)),或者是與核心邏輯無關(guān)的部分。

我們知道,測試用例也可以反過來對代碼產(chǎn)生檢查作用,而在單元測試階段這種作用基本是最明顯的,比如你可以很容易發(fā)現(xiàn)某一處功能單元設(shè)計(jì)得過于耦合,或是某一外部依賴將導(dǎo)致代碼進(jìn)入錯誤分支等情況。

目前推薦的單元測試方案主要有這么幾種,Jest、Mocha、Sinon、Jasime 以及 AVA,它們之間各有優(yōu)劣,這里不做比較。但需要注意的是,一套完整的,能夠滿足實(shí)際需求的單元測試方案,通常意味著需要包括這么幾個功能:

如果你此前并沒有對這些單元測試方案非常熟悉,那我推薦你了解一下 Vitest ,來自 antfu 的作品,特色是快(畢竟基于 Vite)以及對 TypeScript、ES Module 的良好支持,我目前在工作中的單元測試也已經(jīng)全部遷移到 Vitest,同時(shí) Vitest 還自帶了 UI 界面,讓你可以更享受編寫測試并看著它們一個個通過的過程。

測試覆蓋率報(bào)告,這一功能常見的方式是通過 istanbul (1.0版本,2.0 更名為 nyc)或 c8 來進(jìn)行實(shí)現(xiàn),其原理包括代碼插樁與使用 V8 引擎內(nèi)置功能兩種,這里不再贅述。另外一個常見的場景是輸出其他語言格式的覆蓋率報(bào)告(如 JUnit),社區(qū)也通過 Reporters 的機(jī)制為這些測試框架做了支持。

模擬功能(Stub 、Fake Timers 等),包括對一個對象的 Spy,一個函數(shù)的 Stub,對一個模塊的 Mock,都屬于模擬的范疇。

用例收集,編寫測試用例時(shí)我們同樣需要基于功能單元區(qū)分,常見的方式就是 describe 收集一個功能單元,內(nèi)部又使用 it / test 來進(jìn)行功能單元各個邏輯分支的驗(yàn)證。如:

describe('Utils.Reporter',()=>{
it('shouldreporterrorwhenxxx',()=>{})
it('shouldshowwarningswhenxxx',()=>{})
})

斷言,Jest 提供了注入到全局的 expect 風(fēng)格斷言(expect(1+1).toBe(2)),而 Sinon 提供的則是類似 NodeJs asserts 模塊風(fēng)格的斷言(``sinon.assert.pass(1 + 1 === 2)`),而 Mocha 則不綁定斷言庫,你可以使用 asserts 模塊或者 Chai 來進(jìn)行斷言。另外,斷言又包括了幾種不同的風(fēng)格,我們同樣在下文講解。

poYBAGNGJ5yAD5FgAAEP3CnJME8895.png

如果說單元測試是為了測試單個功能單元,那么集成測試(Integration Testing)很明顯就是為了測試多個功能單元的協(xié)作。但需要注意的是,多個功能單元協(xié)作并不意味著對整個系統(tǒng)(流水線)進(jìn)行完整的功能測試,通常我們還會將幾個功能單元分散開進(jìn)行組合,成為系統(tǒng)的某一部分,比如清洗-削皮作為預(yù)處理功能,需要確定一籮筐土豆能否正確地變成干凈的去皮土豆,切片-包裝作為核心功能,需要確定去皮土豆能變成冷凍薯?xiàng)l。

而要進(jìn)行集成測試的編寫,其實(shí)我們?nèi)匀恢恍枰褂脝卧獪y試方案即可,因?yàn)楸举|(zhì)上集成測試就是同時(shí)對多個功能單元進(jìn)行測試,我們驗(yàn)證的范疇也隨之?dāng)U大了而已。

而關(guān)于集成測試的維度拆分則并沒有準(zhǔn)確的界限,你可以像上面那樣將預(yù)處理功能作為一個系統(tǒng)部分,也可以將整個流水線作為一個系統(tǒng)部分(還有供應(yīng)鏈部分、烹飪部分與服務(wù)部分),按照你的實(shí)際業(yè)務(wù)場景就行。

Mock、Fake、Stub

很多時(shí)候測試用例的運(yùn)行時(shí)是受限的,比如我們并不希望真的發(fā)起網(wǎng)絡(luò)請求,或者是和數(shù)據(jù)庫交互,以及 DOM API 的操作等。這個時(shí)候我們會使用一系列模擬手段,來特定地模擬一個可交互的對象,并通過修改它的行為來檢查預(yù)期的處理邏輯是否執(zhí)行。

這個模擬行為通常被直接稱為 Mock,但實(shí)際上,由于模擬的對象類型以及注入的模擬邏輯,更準(zhǔn)確的描述是將這些行為劃分為三大類。首先是最常用的 Stub ,假設(shè)我們在為 UserService 編寫單元測試,其內(nèi)部注入的 PrismaService 負(fù)責(zé)數(shù)據(jù)庫的讀寫,我們可以使用一個 PrismaServiceStub 替換掉實(shí)際的服務(wù),并且在其內(nèi)部提供對應(yīng) PrismaService.user.findUnique 這樣的方法,然后在我們調(diào)用 UserService.queryUser 時(shí),就可以檢查 PrismaServiceStub 上對應(yīng)的方法是否被預(yù)期的入?yún)⒄{(diào)用,而其出參是否被預(yù)期地處理后返回。Spy 也可以認(rèn)為是 Stub 的一種,但它更強(qiáng)調(diào)“是否按照預(yù)期調(diào)用”這個過程,我們甚至可以僅僅監(jiān)聽一個對象而無需提供模擬實(shí)現(xiàn)(如 console 這樣的 API)。

而如果我們不希望替換掉 PrismaService,而是希望它真的去進(jìn)行數(shù)據(jù)讀寫,但不是對真實(shí)的數(shù)據(jù)庫,就可以提供一個 Fake 的數(shù)據(jù)庫——比如一個對象,這樣對數(shù)據(jù)庫的讀寫就變成了對內(nèi)存對象的讀寫,變得更加快捷和穩(wěn)定,這就是 Fake。另外一個常見的 Fake 場景就是定時(shí)器,常見的單元測試框架都提供了 Fake Timers 的功能支持。

而 Mock 其實(shí)和 Stub 也非常類似,但 Mock 更像是其中“預(yù)期的入?yún)ⅰ?,而并不關(guān)注返回值,我個人理解通常項(xiàng)目中 fixtures 文件夾下的各種對象和 JSON 就是典型的 Mock 。

當(dāng)然,Mock、Stub、Spy 三者還是非常相似的,我們也并不是必須搞清楚其中的差異,因?yàn)樗鼈兊谋举|(zhì)都是模擬罷了。

斷言:expect、assert、should

我們常見的斷言包括 expect 與 assert 形式,NodeJs 提供了原生的 asserts 模塊讓你來編寫一些簡單的斷言,你可以在實(shí)際代碼中也使用斷言來確保邏輯正確運(yùn)行,而 expect 形式則通常只見于測試用例中。如檢查一個函數(shù)的調(diào)用和比較兩個對象,兩種風(fēng)格分別是這樣的:

expect(mockFn).toBeCalledWith(

"linbudu"

);

assert.pass(mockFn.calls[

0

].arg===

"linbudu"

);

expect(obj1).toEqual(obj2);

assert.equal(obj1,obj2);

通常我個人更喜歡命令式風(fēng)格明顯的 expect 斷言,而除了這兩種風(fēng)格以外,其實(shí)還有一種 should 形式的鏈?zhǔn)斤L(fēng)格斷言,它寫起來是這樣的:

mockFn.should.be.called();

obj1.should.equal(obj2);

值得一提的是在 Chai 這個斷言庫中對以上三種斷言風(fēng)格都進(jìn)行了支持,如果你有興趣,不妨都試一試。

前端頁面中的組件測試與 E2E 測試

單元測試和集成測試是前后端應(yīng)用中通用的概念,而完成了對基礎(chǔ)功能單元的測試以后,我們需要更進(jìn)一步,關(guān)注領(lǐng)域中特定的功能,比如從前端視角來看一個組件的 UI 與功能,從后端視角來看一個接口面對千奇百怪入?yún)⒌捻憫?yīng)。

在當(dāng)今的前端項(xiàng)目中,組件化應(yīng)該是最明顯的一個趨勢,那么進(jìn)行組件維度的測試也自然是相當(dāng)有必要的。以 React 組件為例,我們可以模擬這個組件的入?yún)ⅲ⒂^察其實(shí)際渲染的 UI 組件是否正確,以及使用快照的方式,來檢查組件的實(shí)際渲染是否一致。

目前使用的組件測試方案通常是和框架綁定的,如 React 下的 @testing-library/react 和 Enzyme,Vue 下的 @vue/test-utils,Svelte 下的 @testing-library/svelte,這是因?yàn)楸举|(zhì)上我們是在孤立地渲染這個組件,并模擬框架行為來驗(yàn)證其表現(xiàn)。

在組件測試方案中,我更推薦 @testing-library/react (還包括 @testing-library/react-hooks),Enzyme 的 API 要更加復(fù)雜,同時(shí)其目前應(yīng)該已經(jīng)不再維護(hù)(或是維護(hù)力度堪憂)。使用其編寫的測試用例是這樣的:

import

*

as

React

from

'react'

function

HiddenMessage

({children}){

const

[showMessage,setShowMessage]=React.useState(

false

)

return

(

<

div

>

<

label

htmlFor

=

"toggle"

>ShowMessage

label

>

<

input

id

=

"toggle"

type

=

"checkbox"

onChange

=

{e

=>setShowMessage(e.target.checked)}

checked={showMessage}

/>

{showMessage?children:null}

div

>

)

}

export

default

HiddenMessage

import

*

as

React

from

'react'

import

{render,fireEvent,screen}

from

'@testing-library/react'

import

HiddenMessage

from

'../hidden-message'

test(

'showsthechildrenwhenthecheckboxischecked'

,()=>{

const

testMessage=

'TestMessage'

//將組件模擬渲染出來

render(<

HiddenMessage

>{testMessage}

HiddenMessage

>)

//基于模糊查詢來驗(yàn)證DOM元素的存在

expect(screen.queryByText(testMessage)).toBeNull()

//同樣基于模糊查詢來觸發(fā)事件

fireEvent.click(screen.getByLabelText(

/show/i

))

//驗(yàn)證結(jié)果是否符合預(yù)期

expect(screen.getByText(testMessage)).toBeInTheDocument()

})

單元測試、集成測試、組件測試,看起來我們已經(jīng)非常完美地使用自動化測試從不同場景與不同維度進(jìn)行了功能的驗(yàn)證,但實(shí)際上,我們還少了一個非常重要的維度——用戶視角。在程序最終交付驗(yàn)收時(shí),我們可愛的測試同學(xué)會來把各個功能和鏈路都檢查一遍,而即使你已經(jīng)寫了巨量的測試用例,還是有可能會被發(fā)現(xiàn)大量的問題,這就是因?yàn)橐暯遣煌W鳛槌绦虻?a target="_blank">開發(fā)者,你清楚地了解程序的控制流走向,也對每一個分支了然于胸,所以在編寫測試用例時(shí)你其實(shí)更像是上帝視角。

要從用戶的視角出發(fā),實(shí)際上我們只需要屏蔽對程序內(nèi)部的所有感知,而只是去使用這個程序即可。這樣的測試被稱為端到端測試(End-to-End Testing,E2E),它不再關(guān)注內(nèi)部功能單元的細(xì)節(jié),而是完全從外部還原一個真實(shí)的用戶視角,如前端應(yīng)用中,用戶登錄-搜索商品-加入購物車-編輯商品-結(jié)算商品的一系列交互,誰管你的登錄背后隱藏了多少權(quán)限分級,商品貨架分級設(shè)計(jì)得多么精細(xì),只要這個流程無法順利走通,那你的系統(tǒng)就是有問題的。

而既然 E2E 測試是在模擬用戶行為,那么其實(shí)我們所需要做的就是使用用戶的環(huán)境來運(yùn)行系統(tǒng)罷了。如對于前端頁面,其實(shí)就是瀏覽器(更準(zhǔn)確地說是瀏覽器內(nèi)核),而對于后端服務(wù)則是客戶端。

Cypress 的功能為例,來看看我們是如何模擬用戶行為的:

poYBAGNGJ7mACSr6AACIqDFNSjw017.png

在前端領(lǐng)域中編寫 E2E 測試,常見的 E2E 測試框架主要包括 Puppeteer、Cypress、Playwright、Selenium 這么幾種。它們之間各有優(yōu)劣,適用場景也有所不同,我們會在下面進(jìn)行比較。

與其他測試場景的重要不同之一,就是 E2E 測試是可以由測試同學(xué)來編寫的(如支持 PythonJava 的 Selenium),在產(chǎn)品進(jìn)行迭代的同時(shí),測試同學(xué)會按照功能點(diǎn)變化對應(yīng)地完善測試用例,同時(shí)確保以往所有功能的測試用例不受影響。

Puppeteer、Cypress、Playwright 的取舍

前端 E2E 測試目前常用的包括 Puppeteer、Cypress、Playwright 這么幾款,這就可能讓你感到選擇困難,到底應(yīng)該選哪個?萬一選了一個,寫著寫著發(fā)現(xiàn)不符合需求了,咋辦?這一部分我們就來簡單介紹一下它們。

先上結(jié)論:非常簡單的場景使用 Puppeteer(需要搭配 Jest-Puppeteer),PC 應(yīng)用使用 Cypress,移動端應(yīng)用使用 Playwright。

接著我們再來一個個解釋。首先是 Puppeteer,認(rèn)真地說,它就不應(yīng)該用來做 E2E 測試,因?yàn)槿思艺娴木椭皇且粋€無頭瀏覽器,你要用它來寫寫爬蟲之類的倒還好,強(qiáng)行霸王硬上弓要人家給你干 E2E,一方面是只支持 Chrome + Chromium 內(nèi)核,另一方面人家不帶斷言庫,你還得帶一個 Jest-Puppeteer 一起。但如果是真的非常非常簡單的場景,你還是可以用 Puppeteer ,加上 NodeJs 的基礎(chǔ)斷言庫,通過自動化方式確定一些頁面功能還是沒問題的。

然后是 Cypress ,其場景從人家的 Slogan 其實(shí)也能感覺出來:Fast, easy and reliable testing for anything that runs in a browser,注意 in a browser,其實(shí)人家就是提供了無頭瀏覽器,斷言,GUI,以及 Web 下的各種 API ,然后你就可以完全模擬使用瀏覽器進(jìn)行的一切行為了。同時(shí) Cypress 也通過代碼插樁的方式支持了覆蓋率報(bào)告相關(guān)的能力。需要注意的是,Cypress 只支持瀏覽器維度的配置,如 chrome(也支持chromium)、edge、firefox。

因此,如果你更側(cè)重于檢查應(yīng)用在移動端的表現(xiàn),那其實(shí)應(yīng)該使用 Playwright 。為什么?Playwright 支持同時(shí)運(yùn)行多個 project,這些 project 可以被配置為使用瀏覽器內(nèi)核(檢驗(yàn) PC、桌面端場景),也可以被配置為使用內(nèi)置的 devices 預(yù)設(shè),來檢驗(yàn)其在移動端的表現(xiàn),這些預(yù)設(shè)包括了視口大小、默認(rèn)瀏覽器內(nèi)核(chromium,webkit,safari 等)等等,參考官網(wǎng)的示例配置:

//playwright.config.ts

import

{

type

PlaywrightTestConfig,devices}

from

'@playwright/test'

;

const

config:PlaywrightTestConfig={

projects:[

{

name:

'DesktopChromium'

,

use:{

browserName:

'chromium'

,

viewport:{width:

1280

,height:

720

},

},

},

{

name:

'DesktopSafari'

,

use:{

browserName:

'webkit'

,

viewport:{width:

1280

,height:

720

},

}

},

{

name:

'DesktopFirefox'

,

use:{

browserName:

'firefox'

,

viewport:{width:

1280

,height:

720

},

}

},

{

name:

'MobileChrome'

,

use:devices[

'Pixel5'

],

},

{

name:

'MobileSafari'

,

use:devices[

'iPhone12'

],

},

],

};

export

default

config;

在我所在的團(tuán)隊(duì),目前也正在基于 Playwright 建立 E2E 測試用例,來更方便快捷地保障核心應(yīng)用的頁面功能。

最后,如果你并不是在開發(fā)一個前端應(yīng)用,而是在開發(fā)一個 UI 組件庫,那你可以使用 StoryBook 提供的測試能力(基于 Jest 與 Playwright),這樣一來你既能夠基于 StoryBook 獲得組件的可視化文檔說明,也可以獲得自動生成的 E2E 測試用例:

poYBAGNGJ86AWKinAADFZJ09x0E682.png

后端服務(wù)中的 E2E 測試與壓力測試

而對于后端服務(wù)中的測試,由于我暫時(shí)還沒有比較深入地實(shí)踐,這里就只簡單介紹下 Node API 中的 E2E 測試、壓力測試。

上面我們已經(jīng)提到,對于后端服務(wù)來說其實(shí)用戶就是各個客戶端,而我們也只需要模擬客戶端,向 API 發(fā)起請求,模擬登錄態(tài)信息和各種參數(shù),然后查看最終返回的結(jié)果是否符合預(yù)期即可。在這個過程中,API 由哪個 Controller 承接,調(diào)用了哪些 Service,走過了哪些 Middleware ,我們都不應(yīng)該也無需關(guān)心。而假裝自己是客戶端的方式就簡單多了,常見的方式是使用 supertest 。另外,通常后端服務(wù)的 E2E 測試也應(yīng)該是盡量模擬完整的交互過程:上傳商品-編輯商品-上架商品-下架商品-...,只不過這個過程并不像在前端那樣直觀。

另外后端服務(wù)中的 E2E 測試如何 Mock 也有不同的情況,如果希望盡可能模擬用戶,可以使用專用的測試環(huán)境數(shù)據(jù)庫,但這樣測試的執(zhí)行就不完全穩(wěn)定。如果希望從簡,那么可以像單元測試與集成測試中那樣模擬掉外部依賴。另外,部分 NodeJs 框架也直接提供了原生的測試支持,如 @nestjs/testing,@midwayjs/mock 等等。

另外一個后端服務(wù)特殊的測試場景則是壓力測試,在某些時(shí)候也可以被等價(jià)于性能測試,從某些方面它其實(shí)也是在模擬用戶,只不過不是模擬一個用戶的交互行為,而是模擬較大量級的用戶訪問,以此來測試服務(wù)的性能。本質(zhì)上壓力測試并不是在測試 API 的邏輯,而是承載 API 的服務(wù)器性能與負(fù)載均衡相關(guān)邏輯。進(jìn)行壓力測試可以很簡單地使用腳本開多線程并發(fā)請求,也可以使用 Apache Bench、Webbench、wrk(wrk2)測試工具,或者 npm 社區(qū)也有 autocannon 這樣的實(shí)現(xiàn)。

在壓力測試下,我們主要關(guān)注這么幾個指標(biāo):

每秒請求數(shù) RPS,Request Per Second,更常見的稱呼是每秒查詢數(shù) QPS,Query Per Second,它代表了到達(dá)服務(wù)器的請求數(shù)量。

并發(fā)用戶數(shù) CL,Concurrency Level,不同于 RPS,并發(fā)數(shù)代表了當(dāng)前仍未完結(jié)的等待處理的請求。舉例來說,假設(shè)某個神奇 API 的請求處理速度非常快,每個請求的處理時(shí)間無限趨近于 0 ,那么即使其 RPS 可能達(dá)到一百萬,并發(fā)數(shù)卻也非常低(趨近于0)——因?yàn)樗幚淼膶?shí)在是太快了,幾乎不需要同時(shí)處理兩個請求。

每秒事務(wù)數(shù) TPS,Transactions Per Second,TPS 有點(diǎn)類似于 QPS,但它所關(guān)注的事務(wù)其實(shí)是比請求-響應(yīng)過程更具象的過程,舉例來說,訪問 server/index.html ,實(shí)際上還訪問了 server/index.css 與 server/index.js 文件,那么這個過程實(shí)際上只會記為一次事務(wù),但會記為三次查詢。

響應(yīng)時(shí)間 RT,Response Time,一個請求從進(jìn)入到帶走響應(yīng)的耗時(shí),這個耗時(shí)包括了等待時(shí)間-處理時(shí)間-IO讀寫時(shí)間-響應(yīng)到達(dá)時(shí)間。

除了這些指標(biāo)以外,我們還會關(guān)注服務(wù)器當(dāng)前的性能指標(biāo),如內(nèi)存與 CPU 占用率,駐留集(RSS,當(dāng)前進(jìn)程獲得分配的物理內(nèi)存,包括堆、棧與執(zhí)行代碼段等),你也可以使用 NodeJs 提供的 --prof --prof-process 等啟動參數(shù),或使用 heapdump 提供的內(nèi)存快照打印功能來幫助分析 Node API 的性能。

尾聲

除了以上介紹的這些自動化測試分類,其實(shí)還有著前端頁面的性能測試(如基于 LightHouse、Performance API),主要關(guān)注各種“首次”的指標(biāo),如首屏繪制、可交互時(shí)間、最大內(nèi)容繪制等等,基于 axe-core 的可訪問性測試(Accessibility Testing),關(guān)注網(wǎng)頁的可訪問性,以及一些相對少見的場景,如基于 Needle 的 CSS 測試、基于 Coffee 的命令行應(yīng)用測試,以及混沌工程理念中的混沌測試等,這些概念要么在社區(qū)里已經(jīng)存在大量的高質(zhì)量介紹文章,要么我并沒有深入了解過,在這里就不贅述了。

另外,想要進(jìn)一步地保障頁面的功能穩(wěn)定性,監(jiān)控平臺(白屏,JS Error,404)這一類的存在也是相當(dāng)有意義的,但這一部分功能已經(jīng)存在太多方案,社區(qū)的 Sentry,以及各大廠內(nèi)部自己建設(shè)的平臺等等,這里就不再贅述。

這篇不長也不短的小作文里,我們基本上把前端開發(fā)者會接觸到的自動化測試種類都了解了一遍,包括它們的使用場景,實(shí)踐方式,以及可選的庫/框架。在完成全文閱讀后,如果你恰好在開發(fā)“值得投入精力編寫測試”的應(yīng)用,不妨思考下,上面是否恰好有符合你所需求的部分。




審核編輯:劉清

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報(bào)投訴
  • API
    API
    +關(guān)注

    關(guān)注

    2

    文章

    1563

    瀏覽量

    63578
  • python
    +關(guān)注

    關(guān)注

    56

    文章

    4825

    瀏覽量

    86255
  • DOM
    DOM
    +關(guān)注

    關(guān)注

    0

    文章

    18

    瀏覽量

    9704
  • JSON
    +關(guān)注

    關(guān)注

    0

    文章

    121

    瀏覽量

    7279
收藏 人收藏

    評論

    相關(guān)推薦
    熱點(diǎn)推薦

    UTP系統(tǒng)通過ModBus協(xié)議對溫度傳感器的自動化測試介紹

    一、UTP系統(tǒng)簡介 宏控UTP協(xié)同自動化測試系統(tǒng)(簡稱UTP測試系統(tǒng))是一款通用的自動化測試系統(tǒng),支持對總線通信(如串口、CAN、以太網(wǎng)等)
    的頭像 發(fā)表于 06-07 15:12 ?61次閱讀
    UTP系統(tǒng)通過ModBus協(xié)議對溫度傳感器的<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>介紹

    TH2822系列LCR測試儀的自動化測試

    在電子元件制造與研發(fā)領(lǐng)域,LCR測試儀(電感、電容、電阻測試儀)是評估無源元件性能的關(guān)鍵工具。隨著智能制造與自動化測試需求的增長,傳統(tǒng)的手動
    的頭像 發(fā)表于 04-23 16:38 ?188次閱讀
    TH2822系列LCR<b class='flag-5'>測試</b>儀的<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>

    矢量信號發(fā)生器在工業(yè)自動化測試中的應(yīng)用場景

    隨著工業(yè)自動化技術(shù)的飛速發(fā)展,對測試設(shè)備的要求也日益提高。矢量信號發(fā)生器作為一種先進(jìn)的測試設(shè)備,憑借其強(qiáng)大的信號調(diào)制能力和廣泛的頻率覆蓋范圍,在工業(yè)自動化
    的頭像 發(fā)表于 03-26 14:10 ?260次閱讀

    泰瑞達(dá)收購英飛凌自動化測試設(shè)備團(tuán)隊(duì)

    近日,自動化測試解決方案領(lǐng)域的知名供應(yīng)商泰瑞達(dá)(Teradyne)與電源系統(tǒng)和物聯(lián)網(wǎng)芯片大廠英飛凌科技股份公司聯(lián)合宣布,雙方已達(dá)成戰(zhàn)略合作伙伴關(guān)系,旨在共同推進(jìn)功率半導(dǎo)體測試技術(shù)的發(fā)展
    的頭像 發(fā)表于 02-06 18:25 ?614次閱讀

    通用自動化測試軟件 - TAE

    INTEWORK-TAE(Test Automation Executor) 是一款通用的測試用例自動化執(zhí)行框架,用于汽車電子自動化測試,可支持仿真( MIL/SIL/HIL)、故障注
    的頭像 發(fā)表于 01-02 13:42 ?627次閱讀
    通用<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>軟件 - TAE

    串口屏自動化測試

    在當(dāng)今智能、高效的工業(yè)4.0時(shí)代,串口屏作為人機(jī)交互的關(guān)鍵組件,在自動化設(shè)備、物聯(lián)網(wǎng)應(yīng)用、智能制造等領(lǐng)域發(fā)揮著舉足輕重的作用。為了確保這些界面不僅美觀易用,而且在各種復(fù)雜環(huán)境下穩(wěn)定
    的頭像 發(fā)表于 12-27 17:17 ?1435次閱讀

    潤和軟件榮獲IDC測試自動化領(lǐng)域唯一推薦廠商

    近日,國際知名市場研究機(jī)構(gòu)IDC發(fā)布《中國生成式人工智能技術(shù)與品牌推薦》報(bào)告,推薦了人工智能領(lǐng)域中表現(xiàn)突出的廠商。江蘇潤和軟件股份有限公司(簡稱“潤和軟件”)憑借在AI技術(shù)和金融測試領(lǐng)域的深厚積累,成為
    的頭像 發(fā)表于 12-24 10:47 ?557次閱讀

    探索Playwright:前端自動化測試的新紀(jì)元

    作者:京東保險(xiǎn) 張新磊 背景 在前端開發(fā)中,自動化測試是確保軟件質(zhì)量和用戶體驗(yàn)的關(guān)鍵環(huán)節(jié)。隨著Web應(yīng)用的復(fù)雜性不斷增加,手動測試已經(jīng)無法滿足快速迭代和持續(xù)交付的需求。
    的頭像 發(fā)表于 10-22 14:27 ?614次閱讀

    開關(guān)電源自動化測試設(shè)備:如何實(shí)現(xiàn)自動化測試?

    開關(guān)電源自動化測試設(shè)備是將測試軟件和測試硬件集成在一個電源測試柜中的ate自動測試設(shè)備,其
    的頭像 發(fā)表于 08-30 18:19 ?1732次閱讀
    開關(guān)電源<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>設(shè)備:如何實(shí)現(xiàn)<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>?

    XLT高速線纜自動化測試系統(tǒng)

    高速線纜自動化測試系統(tǒng) 隨著高速通信的快速發(fā)展,對于高速數(shù)據(jù)通信線纜性能要求日益增高,在其硏發(fā)、生產(chǎn)階段,需要多次測試射頻性能。傳統(tǒng)人工手動測試存在
    的頭像 發(fā)表于 08-05 16:39 ?590次閱讀

    ATECLOUD智能云測試平臺推動自動化測試發(fā)展

    目前,ATECLOUD專注于為電源模塊、電源管理芯片和射頻組件測試提供自動化測試方案。同時(shí),也支持定制開發(fā),如電機(jī)驅(qū)動測試、元器件測試等,滿
    的頭像 發(fā)表于 07-26 15:26 ?652次閱讀
    ATECLOUD智能云<b class='flag-5'>測試</b>平臺推動<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>發(fā)展

    OTA自動化測試解決方案——實(shí)車級OTA測試系統(tǒng)PAVELINK.OTABOX

    作者|網(wǎng)蟲小編|不吃豬頭肉引言往期內(nèi)容里為大家介紹了OTA技術(shù)、OTA后續(xù)的發(fā)展趨勢預(yù)測及OTA自動化測試解決方案。本文是OTA系列的第三篇文章,今天主要向大家介紹實(shí)車級OTA自動化測試
    的頭像 發(fā)表于 07-11 08:26 ?1113次閱讀
    OTA<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>解決方案——實(shí)車級OTA<b class='flag-5'>測試</b>系統(tǒng)PAVELINK.OTABOX

    機(jī)械自動化和電氣自動化區(qū)別是什么

    機(jī)械自動化和電氣自動化是現(xiàn)代工業(yè)生產(chǎn)中兩個重要的領(lǐng)域,它們在許多方面有著密切的聯(lián)系,但也存在一些明顯的區(qū)別。 一、基本概念 機(jī)械自動化 機(jī)械自動化
    的頭像 發(fā)表于 07-01 09:33 ?6369次閱讀

    機(jī)械自動化自動化的一種嗎

    各個領(lǐng)域得到了廣泛的應(yīng)用,如制造業(yè)、農(nóng)業(yè)、醫(yī)療、物流等。 機(jī)械自動化的概念 機(jī)械自動化是指利用機(jī)械設(shè)備和控制系統(tǒng)來實(shí)現(xiàn)生產(chǎn)過程的自動化。它包括以下幾個方面: 2.1
    的頭像 發(fā)表于 07-01 09:32 ?2366次閱讀

    繼電器在工業(yè)自動化領(lǐng)域的應(yīng)用

    隨著工業(yè)自動化技術(shù)的不斷發(fā)展,繼電器作為電氣控制系統(tǒng)中不可或缺的元件,在工業(yè)自動化領(lǐng)域發(fā)揮著越來越重要的作用。繼電器通過控制電路的通斷,實(shí)現(xiàn)對電氣設(shè)備的遠(yuǎn)程控制和自動化操作,極大地提高
    的頭像 發(fā)表于 06-24 11:53 ?1478次閱讀

    電子發(fā)燒友

    中國電子工程師最喜歡的網(wǎng)站

    • 2931785位工程師會員交流學(xué)習(xí)
    • 獲取您個性化的科技前沿技術(shù)信息
    • 參加活動獲取豐厚的禮品