[[390922]]

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

1.最小化測試用例

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

2.測試用例的命名規則

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

• 待測試的功能。
• 待執行的特定場景。
• 預期的測試結果。

3.使用BDD樣式

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

4.實施斷言(Assertions)

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

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

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

6.測試運行程序

測試運行程序不但帶有各種庫與工具，還包含許多單元測試的源代碼目錄。它能夠以用戶可讀的日志文件形式，在其控制臺上呈現測試結果。目前，市場上的眾多測試運行程序中，當屬Mocha最適合Node.js測試。

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

7.測試覆蓋率

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

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

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

9.分析測試覆蓋率報告

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

10.標注測試用例

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

11.變異測試

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

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

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

1. 安裝：npm i plagiarism-checker

2. 請添加以下內容，以使用該代碼庫：

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

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

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

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

13.提供邏輯輸入

對于自動測試用例，測試人員有時會傾向于，將各種與實際情況相去甚遠的隨機值作為輸入，其結果往往無法評估出確切的效果與性能。因此我們應當始終采用與現實生活場景相切合的近似實際輸入，來測試應用的真實水準。在此方面，Faker庫能夠通過與Node.js的完美結合，生成大量實時的輸入數據，以產生相對真實的結果。

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

14.使用應用代碼校驗(Lint)

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

15.基于屬性的測試

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

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

16.用Chai來斷言

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

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

17.測試異常(Exceptions)

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

• 在出現錯誤時，立即終止服務器的各項功能，轉為測試和評估服務的穩定性、性能、以及對于整體系統的影響。
• 從服務器端強制傳遞出不同的響應代碼，并檢查應用程序的行為。

18.測試金字塔

測試金字塔是一個三層結構的三角形。如下圖所示，每一層都定義了不同的測試階段與方法。我們可以根據產生的成本和執行的速度進行分類，其頂點表示成功最高，但最快的測試。 

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

19.分別測試每個應用組件

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

20.檢測基礎架構問題

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

21.并行測試

通常，我們的傳統測試流程是：執行一個用例，等待其結果，對其進行分析，提供反饋意見，執行下一個測試，周而復始。開發團隊需要對所有測試的運行結果，逐一予以反饋和解決。顯然，這種串行方式不但增加了團隊成員的工作量，并且可能導致不必要的返工。

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

22.保持依賴關系的更新

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

23.在Selenium Grid上執行跨瀏覽器測試

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

小結

總的說來，為了使用Node.js來實現一套穩定、有效的自動化測試框架，您可以有選擇性地參考上述討論的23種優秀實踐，以保證開發和測試的質量與效果。

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

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