在很大程度上,軟件開發(fā)生命周期(SDLC)中質(zhì)量關(guān)口的兩個主要位置是在拉式請求(PRs)和構(gòu)建作業(yè)(CI)期間。對于pull請求,最常用的工具之一是GitHub Actions,它允許開發(fā)團(tuán)隊在提交或部署代碼時自動化一組應(yīng)該完成或檢查的任務(wù)。在CI作業(yè)中,工具的內(nèi)置功能(Azure、Jenkins)用于創(chuàng)建腳本,檢查測試用例或場景是否通過。那么,為你的團(tuán)隊準(zhǔn)備一個有什么意義呢?這完全取決于開發(fā)團(tuán)隊希望為易訪問性測試結(jié)果設(shè)置什么樣的關(guān)卡。如果團(tuán)隊正在進(jìn)行更多的林挺和組件級測試,那么可訪問性門在拉請求級別上最有意義。如果自動化測試處于集成級別,這意味著一個完全成熟的站點已經(jīng)準(zhǔn)備好進(jìn)行部署,那么就可以將gate與CI作業(yè)放在一起。
軟檢查在定義上相對簡單。它查看可訪問性測試是否被執(zhí)行。就是這樣!如果運行了可訪問性檢查,則測試通過。相比之下,斷言對允許通過的內(nèi)容更加具體和嚴(yán)格。例如,如果我的可訪問性測試用例運行,并且它發(fā)現(xiàn)了一個問題,斷言失敗,gate將說它沒有通過。那么哪個對你的團(tuán)隊最有效呢?如果你想讓更多的團(tuán)隊整體上接受易訪問性測試,最佳實踐是不要馬上拋出一個強硬的斷言。團(tuán)隊最初會為增加的任務(wù)或需求而掙扎,可訪問性也不例外。從軟門開始,團(tuán)隊可以看到需求是什么,他們需要做什么。
一旦經(jīng)過了一定的時間,那么軟門可以切換到硬斷言,不允許單個自動發(fā)布出去。然而,如果您的團(tuán)隊足夠成熟,并且已經(jīng)使用可訪問性自動化有一段時間了,最初可能會使用硬斷言,因為他們已經(jīng)有了這方面的經(jīng)驗。
2022-02-28
2021-03-09
2020-08-13
2022-05-23
2020-09-02
2020-12-23
2020-05-14
2021-12-06
2020-07-02
2021-12-17
2021-05-30
2021-01-28
2021-05-10
2020-12-25
2021-07-31
2022-12-19
2021-12-15
2021-03-01
2021-01-16
2021-07-20