針對(duì)自動(dòng)化測(cè)試的 23 種 Node.js 優(yōu)秀實(shí)踐

作者：陳峻 2021-04-02 09:00:00

本文通過和您討論23種有關(guān)Node.js的優(yōu)秀實(shí)踐，方便您以系統(tǒng)化的方法，無縫地執(zhí)行各類自動(dòng)化測(cè)試用例。

【51CTO.com快譯】如果您是一名開發(fā)者，那么對(duì)Node.js一定不陌生。由Node.js提供的各種優(yōu)秀實(shí)踐，可以方便您大幅地提高應(yīng)用的性能。而在JavaScript的支持下，Node.js可以運(yùn)行在服務(wù)器上，以方便開發(fā)人員用它來構(gòu)建企業(yè)級(jí)應(yīng)用。目前，像Amazon和LinkedIn之類的知名應(yīng)用網(wǎng)站都用到了Node.js。當(dāng)然，Node.js也可以被用在自動(dòng)化測(cè)試的場(chǎng)景中。本文將和您討論23種有關(guān)Node.js的優(yōu)秀實(shí)踐。

1.最小化測(cè)試用例

為了獲得更好的測(cè)試結(jié)果，我們通常會(huì)最小化Node.js中的測(cè)試用例，以避免測(cè)試數(shù)據(jù)的相互干擾。也就是說，就算某一項(xiàng)測(cè)試失敗了，也不會(huì)影響到其他測(cè)試，并且能夠提供更加具體的結(jié)果。同時(shí)，此法還能最大程度地提高測(cè)試的效率。

2.測(cè)試用例的命名規(guī)則

規(guī)范化且有意義的名稱對(duì)于有效編寫測(cè)試用例，并實(shí)現(xiàn)其預(yù)定效果是至關(guān)重要的。例如，您應(yīng)該使用諸如：checkCountryLanguage()和validateUserPhoneNumber()之類的正確命名方式，而不應(yīng)隨機(jī)、任意地分配名稱。通常，良好的測(cè)試用例名稱，應(yīng)當(dāng)能夠明確說明以下內(nèi)容：

待測(cè)試的功能。
待執(zhí)行的特定場(chǎng)景。
預(yù)期的測(cè)試結(jié)果。

3.使用BDD樣式

使用與被測(cè)產(chǎn)品類似或相同的語言，來編寫測(cè)試樣式的好處在于，既能讓用戶一目了然地理解測(cè)試流程和期望，又能將實(shí)際的代碼部分對(duì)非技術(shù)相關(guān)人員進(jìn)行隱藏。行為驅(qū)動(dòng)開發(fā)(Behavior Driven Development，BDD)是這種方法的優(yōu)秀示例，它不但易于操作，而且能與Node.js進(jìn)行良好的集成，因此備受企業(yè)用戶的歡迎。

4.實(shí)施斷言(Assertions)

作為測(cè)試用例的重要組成部分，斷言的聲明性語句能夠通過提供布爾輸出，協(xié)助測(cè)試人員驗(yàn)證是否已按照預(yù)期執(zhí)行了測(cè)試用例。在Node.js的自動(dòng)化測(cè)試中，斷言通過self-explanatory的方式，不但可以減少代碼總量，并且能夠提供可靠的結(jié)果。對(duì)于開發(fā)人員而言，斷言既可以節(jié)省他們檢查完整輸出的時(shí)間，又能夠通過將每個(gè)步驟中的響應(yīng)結(jié)果，與期望值做比較，以判斷是否通過了測(cè)試。整個(gè)過程都可以通過節(jié)點(diǎn)中的Chai庫(kù)，來輕松實(shí)現(xiàn)的。例如，我們可以構(gòu)建如下斷言：expect(todayWeather).to.be.(clear);

5.最小化測(cè)試用例的幫助和抽象

作為一個(gè)完整的單元，良好的測(cè)試用例代碼往往具有良好的結(jié)構(gòu)，以及最少的外部交互(或稱耦合)。新手開發(fā)人員或測(cè)試人員不必通過借鑒另一個(gè)測(cè)試，來理解先前的測(cè)試，也不必遍歷完整的測(cè)試用例結(jié)構(gòu)。因此，最小化測(cè)試用例的幫助和抽象，可以讓用例更加簡(jiǎn)單易懂，且易于維護(hù)。

6.測(cè)試運(yùn)行程序

測(cè)試運(yùn)行程序不但帶有各種庫(kù)與工具，還包含許多單元測(cè)試的源代碼目錄。它能夠以用戶可讀的日志文件形式，在其控制臺(tái)上呈現(xiàn)測(cè)試結(jié)果。目前，市場(chǎng)上的眾多測(cè)試運(yùn)行程序中，當(dāng)屬M(fèi)ocha最適合Node.js測(cè)試。

作為一個(gè)開源的測(cè)試運(yùn)行程序，Mocha提供了一種易于編程的程序化方法，來測(cè)試并獲取結(jié)果。在與數(shù)據(jù)庫(kù)一起使用時(shí)，我們可以通過Mocha，將真實(shí)或虛擬值提供給測(cè)試用例，以進(jìn)行全面的Node.js測(cè)試。

7.測(cè)試覆蓋率

通常，測(cè)試覆蓋率可用于評(píng)估測(cè)試用例所覆蓋的代碼量，因此它也是我們?cè)诰帉憸y(cè)試時(shí)的一項(xiàng)重要指標(biāo)。為了保證在編寫Node.js測(cè)試用例時(shí)，能夠獲得良好覆蓋率，我們除了了解目標(biāo)應(yīng)用的基本性質(zhì)與功能，還應(yīng)該從成本增加的角度，謹(jǐn)慎考慮哪些需要被添加到測(cè)試范圍中。例如，對(duì)于實(shí)時(shí)且具有高度交互特點(diǎn)的應(yīng)用，我們應(yīng)當(dāng)保證測(cè)試的覆蓋率盡量達(dá)到100%，以獲得全面的測(cè)試結(jié)果。為此，您可以選用Istanbul測(cè)試覆蓋率工具，以實(shí)現(xiàn)與Mocha的良好集成。

8.用插件提高測(cè)試覆蓋率

為了避免由于某種原因所導(dǎo)致的任何失敗或測(cè)試被跳過，我們可以通過添加插件，來最大程度地提高代碼測(cè)試的覆蓋率。同時(shí)，它們可以共享測(cè)試成敗的相關(guān)報(bào)告，以減少原有測(cè)試的誤報(bào)率。

9.分析測(cè)試覆蓋率報(bào)告

如前文所述，我們可以通過將Mocha和Istanbul相結(jié)合，以生成簡(jiǎn)單、直接、實(shí)用的測(cè)試覆蓋率報(bào)告。而通過對(duì)報(bào)告深入分析，開發(fā)人員則能夠查找出故障的根源，進(jìn)而著手修復(fù)。

10.標(biāo)注測(cè)試用例

不同的測(cè)試用例往往側(cè)重于不同的場(chǎng)景和需求。我們需要根據(jù)使用情況，將它們分門別類。當(dāng)然，由于某些測(cè)試可能會(huì)橫跨多個(gè)組類，因此最好的方法便是對(duì)測(cè)試用例進(jìn)行標(biāo)注。例如我們可以分配：冒煙(smoke)測(cè)試、I/O測(cè)試、健全(sanity)測(cè)試，端到端(e2e)測(cè)試等標(biāo)簽。據(jù)此，我們可以快速分清，哪些測(cè)試用例是真正適合目標(biāo)應(yīng)用的。

11.變異測(cè)試

有時(shí)候，測(cè)試人員需要使用一些虛擬數(shù)據(jù)或模擬數(shù)據(jù)，來通過調(diào)整應(yīng)用程序的邏輯與行為，以定位程序代碼的缺陷。對(duì)此，我們可以事先定義好相關(guān)變異操作，例如：使用錯(cuò)誤的操作符或變量名，來模擬典型的應(yīng)用錯(cuò)誤。此舉有時(shí)也被稱為“植入錯(cuò)誤”，以查看開發(fā)出的代碼邏輯在意外情況下，將如何做出反應(yīng)。在自動(dòng)化Node.js測(cè)試中，此類測(cè)試往往能夠讓開發(fā)人員在極端問題出現(xiàn)之前，予以處理和解決。Stryker是該領(lǐng)域最受歡迎的代碼庫(kù)，建議您將其添加到常用Node.js測(cè)試工具列表中。

12.非剽竊(Non-Plagiarised)測(cè)試

有時(shí)候，開發(fā)人員可能會(huì)直接從互聯(lián)網(wǎng)上復(fù)制一段代碼，并將其運(yùn)用到正在開發(fā)的軟件應(yīng)用中。不過，他們不會(huì)意識(shí)到該代碼可能已經(jīng)被許可給了其他公司。由此引發(fā)的版權(quán)問題，很可能會(huì)導(dǎo)致嚴(yán)重的法律糾紛。因此，在使用Node.js時(shí)，檢查“剽竊”是非常常見的做法。我們可以通過安裝以下軟件包，來實(shí)現(xiàn)：node.js npm plagiarism-checker。具體安裝與使用步驟如下--

1. 安裝：npm i plagiarism-checker

2. 請(qǐng)?zhí)砑右韵聝?nèi)容，以使用該代碼庫(kù)：

var a = require('plagiarism-checker'); 
var b = new a(); 
var config = b.getConfig();

3. 從鏈接--https://www.npmjs.com/package/plagiarism-checker處，下載剽竊檢查器的代碼。

4. 在安裝如下依賴項(xiàng)后，將其添加至項(xiàng)目中：

$ npm install lodash 
$ npm install request 
$ npm install request-promise 
$ npm install mime-types

13.提供邏輯輸入

對(duì)于自動(dòng)測(cè)試用例，測(cè)試人員有時(shí)會(huì)傾向于，將各種與實(shí)際情況相去甚遠(yuǎn)的隨機(jī)值作為輸入，其結(jié)果往往無法評(píng)估出確切的效果與性能。因此我們應(yīng)當(dāng)始終采用與現(xiàn)實(shí)生活場(chǎng)景相切合的近似實(shí)際輸入，來測(cè)試應(yīng)用的真實(shí)水準(zhǔn)。在此方面，F(xiàn)aker庫(kù)能夠通過與Node.js的完美結(jié)合，生成大量實(shí)時(shí)的輸入數(shù)據(jù)，以產(chǎn)生相對(duì)真實(shí)的結(jié)果。

同理，我們不應(yīng)只用少量的輸入去淺嘗輒止，而需要通過大量豐富的輸入數(shù)據(jù)集，來全面檢驗(yàn)Node.js應(yīng)用的各種邏輯與功能。例如，對(duì)于那些將城市名稱作為輸入?yún)?shù)的函數(shù)，有效的測(cè)試數(shù)據(jù)應(yīng)當(dāng)是新德里、孟買、倫敦、紐約等，而不是諸如abc、xyz等毫無意義的隨機(jī)值。

14.使用應(yīng)用代碼校驗(yàn)(Lint)

通常，我們將可用于檢查整個(gè)代碼，并針對(duì)任何編程錯(cuò)誤、代碼樣式問題、以及可疑結(jié)構(gòu)，發(fā)出警告的工具稱為L(zhǎng)inter或Lint。在針對(duì)Node.js應(yīng)用開展測(cè)試時(shí)，我們可以使用linters來捕獲，那些潛藏在程序邏輯之后的代碼結(jié)構(gòu)性錯(cuò)誤，其中包括未聲明的變量分配、未定義的變量使用、以及語法格式錯(cuò)誤等。ESLint(https://eslint.org/)便是此類可與Node.js相集成，并能遵循自動(dòng)化規(guī)范的工具。它可以在修復(fù)各種問題的同時(shí)，讓目標(biāo)代碼更加易于閱讀和理解。

15.基于屬性的測(cè)試

此類測(cè)試可用于檢查功能和程序的各項(xiàng)屬性。目前，可用于自動(dòng)執(zhí)行基于屬性的測(cè)試工具包括：fastCheck，Mocha Test Check和QuickCheck。它們的主要優(yōu)勢(shì)在于：

擁有廣泛的輸入類型范圍，可生成大量有效的測(cè)試數(shù)據(jù)和測(cè)試用例集。
通過長(zhǎng)時(shí)間運(yùn)行某個(gè)功能函數(shù)的屬性類輸入，以協(xié)助檢查其閾值。例如，對(duì)于某個(gè)僅接受兩個(gè)參數(shù)輸入的函數(shù)而言，其規(guī)則是其中一個(gè)參數(shù)必須為偶數(shù)值。那么我們?cè)诓捎没趯傩缘臏y(cè)試時(shí)，便可以檢查其接受各種奇、偶數(shù)組合輸入后的反應(yīng)。

16.用Chai來斷言

如前所述，斷言有助于我們將實(shí)際結(jié)果與預(yù)期結(jié)果進(jìn)行比較，以判定測(cè)試用例在某些意外錯(cuò)誤、或已知的邏輯流程變更時(shí)，是否能到達(dá)預(yù)期的效果。在使用Node.js自動(dòng)化測(cè)試時(shí)，Chai庫(kù)就能夠通過預(yù)期斷言和分析結(jié)果，在無需花費(fèi)更多時(shí)間進(jìn)行挖掘的情況下，節(jié)省團(tuán)隊(duì)可用于修復(fù)的資源和精力。下面是Chai斷言的一個(gè)示例：

expect(‘a’).to.not.have.property(‘b’);

17.測(cè)試異常(Exceptions)

在編寫測(cè)試時(shí)，我們自然而然地會(huì)將重點(diǎn)放在那些提供良好代碼覆蓋率的測(cè)試用例和方案上，而忽略了為這些用例添加可驗(yàn)證的各種異常信息，并導(dǎo)致運(yùn)維人員無法跟蹤應(yīng)用拋出的錯(cuò)誤。當(dāng)然，一些大型組織為此會(huì)用到“混沌測(cè)試”。此外，我們還可以采取如下兩個(gè)處置方式：

在出現(xiàn)錯(cuò)誤時(shí)，立即終止服務(wù)器的各項(xiàng)功能，轉(zhuǎn)為測(cè)試和評(píng)估服務(wù)的穩(wěn)定性、性能、以及對(duì)于整體系統(tǒng)的影響。
從服務(wù)器端強(qiáng)制傳遞出不同的響應(yīng)代碼，并檢查應(yīng)用程序的行為。

18.測(cè)試金字塔

測(cè)試金字塔是一個(gè)三層結(jié)構(gòu)的三角形。如下圖所示，每一層都定義了不同的測(cè)試階段與方法。我們可以根據(jù)產(chǎn)生的成本和執(zhí)行的速度進(jìn)行分類，其頂點(diǎn)表示成功最高，但最快的測(cè)試。

金字塔的底層包括了獨(dú)立的基本功能和單元測(cè)試。中間層的集成測(cè)試，可方便用戶以彼此整合的方式，測(cè)試不同的模塊。頂層是前端與用戶界面測(cè)試，我們可以使用諸如LambdaTest等先進(jìn)的自動(dòng)化工具來完成。顯然，單元測(cè)試最慢，而由于模塊級(jí)分布較少，因此前端測(cè)試最快。

19.分別測(cè)試每個(gè)應(yīng)用組件

分別測(cè)試每個(gè)模塊或組件的功能，有時(shí)也被稱為組件測(cè)試。它可以根據(jù)不同的輸入，來驗(yàn)證被測(cè)模塊的響應(yīng)情況。與單元測(cè)試相比，組件測(cè)試具有良好的覆蓋率和更快的速度。在上述金字塔測(cè)試中，我建議您在完成單元測(cè)試后，再使用組件測(cè)試，以獲得更好的結(jié)果，并能發(fā)現(xiàn)更多的未知問題。

20.檢測(cè)基礎(chǔ)架構(gòu)問題

在自動(dòng)化測(cè)試過程中，測(cè)試人員最容易犯的一個(gè)錯(cuò)誤是：只測(cè)試了應(yīng)用程序的功能，以及關(guān)注到了測(cè)試覆蓋率，而忽略了由基礎(chǔ)架構(gòu)所導(dǎo)致的，各種與實(shí)時(shí)負(fù)載和實(shí)際場(chǎng)景相關(guān)的問題。其中，最常見的基礎(chǔ)架構(gòu)問題包括：內(nèi)存過載、服務(wù)器突然關(guān)閉、以及API響應(yīng)延遲等方面。它們都會(huì)顯著地影響到應(yīng)用的正常行為與服務(wù)的提供。

21.并行測(cè)試

通常，我們的傳統(tǒng)測(cè)試流程是：執(zhí)行一個(gè)用例，等待其結(jié)果，對(duì)其進(jìn)行分析，提供反饋意見，執(zhí)行下一個(gè)測(cè)試，周而復(fù)始。開發(fā)團(tuán)隊(duì)需要對(duì)所有測(cè)試的運(yùn)行結(jié)果，逐一予以反饋和解決。顯然，這種串行方式不但增加了團(tuán)隊(duì)成員的工作量，并且可能導(dǎo)致不必要的返工。

而并行測(cè)試則能夠讓團(tuán)隊(duì)同時(shí)執(zhí)行多個(gè)用例。他們既能一次性獲取待分析的報(bào)告，進(jìn)而共享與合并待處理的反饋。對(duì)此，整個(gè)團(tuán)隊(duì)可以使用前文提到的Mocha之類的并行測(cè)試工具，為Node.js的自動(dòng)化測(cè)試大幅減少反饋的層級(jí)，并且能夠在更短的時(shí)間內(nèi)協(xié)同解決問題，進(jìn)而為公司節(jié)省了大量的時(shí)間和資源。

22.保持依賴關(guān)系的更新

為了有效地開展測(cè)試，并獲得準(zhǔn)確的結(jié)果，我們需要通過各種手動(dòng)的方式，來保證各種依賴項(xiàng)和庫(kù)的更新，進(jìn)而防止未知錯(cuò)誤的出現(xiàn)。不過，為了避免可能發(fā)生的人為錯(cuò)誤，我們往往可以通過工具，定期檢查是否有最新的版本出現(xiàn)，并對(duì)任何依賴項(xiàng)的新版本觸發(fā)自動(dòng)更新。