[[390922]]

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

1.最小化測試用例

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

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

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

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

3.使用BDD樣式

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

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

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

5.最小化測試用例的幫助和抽象

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

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

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

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

7.測試覆蓋率

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

8.用插件提高測試覆蓋率

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

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

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

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

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

11.變異測試

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

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

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

1. 安裝：npm i plagiarism-checker

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

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.提供邏輯輸入

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

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

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

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

15.基于屬性的測試

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

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

16.用Chai來斷言

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

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

17.測試異常(Exceptions)

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

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

18.測試金字塔

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

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

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

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

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

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

21.并行測試

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

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

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

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

23.在Selenium Grid上執(zhí)行跨瀏覽器測試

作為一個(gè)易用的開源類跨瀏覽器測試工具，Selenium附帶有許多實(shí)用的程序，以滿足不同的測試需求。為了消除對瀏覽器數(shù)量的限制，我們可以使用Selenium Grid的云端應(yīng)用，以提供更多的瀏覽器和更多不同的配置。

小結(jié)

總的說來，為了使用Node.js來實(shí)現(xiàn)一套穩(wěn)定、有效的自動化測試框架，您可以有選擇性地參考上述討論的23種優(yōu)秀實(shí)踐，以保證開發(fā)和測試的質(zhì)量與效果。

原文標(biāo)題：23 Node.js Best Practices For Automation Testing，作者:Rahul Jain

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】