從0開發3D引擎（四）：搭建測試環境

時間 2020-01-24

標籤開發 3d 引擎搭建測試環境简体版

原文原文鏈接

目錄javascript

你們好，本文介紹了3D引擎的測試方法，搭建了本地的測試環境。html

上一篇博文

從0開發3D引擎（三）：搭建開發環境前端

下一篇博文

從0開發3D引擎（五）：函數式編程及其在引擎中的應用java

瞭解自動化測試

對於引擎開發這種複雜、長期的項目，爲了減小bug，提高長期的開發效率，自動化測試必不可少。在咱們的Wonder.js引擎中，包括了本節介紹的3種自動化測試，測試覆蓋率達到了95%。git

本系列爲了節省篇幅，不進行自動化測試。所以本節只進行簡單的介紹，不給出實際的案例，讀者能夠到Wonder.js->test/目錄下查看自動化測試實例。github

單元測試

咱們須要寫測試用例對單個函數進行單元測試。web

搭建環境
使用jest做爲測試框架，sinon進行stub。
若是讀者想了解stub的概念，能夠參考我對Stub和Mock的理解chrome

由於不能直接使用js庫，須要寫對應的FFI（相似於typescript的d.ts文件）才能在Reason中被調用，因此咱們可使用bs-jest和Wonder的Wonder-bs-sinon做爲FFItypescript

集成測試

相對於單元測試，集成測試的測試目標變爲某個特性，該特性跨越多個函數或多個模塊。編程

搭建環境
與單元測試的環境同樣。

目錄結構
能夠在test/unit/目錄下寫單元測試用例，而在test/integration/目錄下寫集成測試用例。

端對端測試

也稱爲e2e測試，包括了「渲染測試」和「性能測試」。它們都須要安裝puppeteer，經過chrome內核渲染3D場景來進行測試。

渲染測試

渲染測試是針對特定的場景（如只有一個模型的場景，或者只有一個光源的場景）進行測試，從而保證渲染的正確性。

測試步驟爲：
一、預先渲染一張正確圖片
二、使用引擎渲染一張當前圖片
三、逐個像素地比較二者，若是95%以上的像素都相同，則測試經過；不然測試失敗

性能測試

性能測試是針對極端場景（如5000個box）進行測試，從而保證花費的時間和佔用的內存大小符合要求。

測試步驟爲：
一、預先準備基準數據
使用引擎運行場景屢次，取平均值，記錄到json文件中
二、使用引擎運行場景屢次（少於「準備基準數據」的運行次數），取平均值，獲得當前數據
三、比較二者的花費的時間和佔用的內存大小，若是在偏差範圍內，則測試經過；不然測試失敗

注意事項：
只有在本地測試時，保持基準數據不變。若是在雲端（如在push到Github倉庫時使用CI工具-travis進行測試）或者其它環境（如換一臺電腦進行測試）進行性能測試，須要在每次測試時更新基準數據（由於不一樣的環境，性能不同，因此對應的基準數據也不同）。

經過打印日誌來調試

有如下的緣由使得能夠在單元測試和集成測試中經過打印日誌來進行調試：

由於在自動化測試中打開watch，代碼修改後可以當即刷新，因此可以即時看到打印的結果，測試很方便
由於在函數式編程中，函數爲純函數（Reason也容許非純），沒有狀態，因此咱們能夠經過打印函數的輸入和輸出，來驗證該函數是否正確

瞭解運行測試

本系列經過在Chrome瀏覽器中進行運行測試來驗證程序的正確性。

經過如下的方式進行運行測試：

斷點調試

由於瀏覽器運行的是Reason編譯後的js代碼，因此咱們能夠在瀏覽器的控制檯->Sources中經過斷點來調試js代碼

具體能夠參考：
使用斷點暫停代碼

經過Spector.js測試WebGL

Spector.js調試預覽：

Spector.js能查看一幀中WebGL的調用狀況、shader代碼和WebGL的狀態，它支持WebGL 1.0或WebGL 2.0，也支持WebGL 1.0的VAO等擴展。

另外，Spector.js支持多個canvas，能查看指定的canvas對應的WebGL信息。這對於調試編輯器（如咱們的Wonder-Editor在線編輯器）頗有用。由於編輯器有多個canvas（如一個canvas進行主場景繪製，另外一個canvas以材質球的方式顯示單個material資產的效果），而咱們但願分別調試從每一個canvas中取得上下文的WebGL。

Spector.js能夠在Chrome的擴展中安裝，詳情請見官方Github

經過log調試Shader

本系列經過在fragment shader中，將變量做爲輸出的顏色，來調試Shader的變量值。

更多能夠參考：

調試OpenGL -> 調試着色器輸出

OpenGL shader如何調試？

OpenGL ES 2.0 Shader 調試新思路(一): 改變提問方式

移動端測試

咱們經過下面兩種方法進行測試：

模擬測試

咱們能夠在Chrome瀏覽器上，點擊控制檯->Toggle Device Toolbar，打開用於模擬移動設備視口的界面。

本系列主要用該方法測試引擎對於移動端touch事件的支持。

詳細的介紹參考：
使用 Chrome DevTools 中的 Device Mode 模擬移動設備

真機測試

具體步驟以下：
一、在測試html頁面中引入vConsole庫
從而能夠經過打印日誌的方式，在手機上查看錯誤和日誌信息
vConsole介紹參考：
前端開發 - 在手機上調試利器vConsole
二、把測試頁面push到測試環境的服務器上（如使用Github Pages搭建的服務器）
三、把測試頁面的訪問地址轉換爲二維碼
如使用草料二維碼在線轉換
四、用測試手機的微信掃該二維碼，運行測試頁面，驗證渲染結果，查看錯誤和日誌信息

瞭解性能測試

由於本系列開發的引擎重視性能，因此會經過手動的性能測試，來指導引擎優化。

性能測試的指標包括時間開銷和內存開銷，下面分別分析：

測試時間開銷

使用Chrome DevTools的Javascript Profiler

經過在測試頁面記錄profile，查看每一個函數的時間開銷，從而定位到熱點函數進行優化。

使用Chrome DevTools的Performance

經過時間線Timeline，能夠查看CPU端各個線程和GPU的執行順序和熱點函數的時間開銷。

本系列主要用該方法測試在多線程中，每一個線程的執行順序和性能開銷

使用Chrome DevTools的NetWork

查看各個資源的加載時間和順序。

本系列用該方法測試在「使用函數式反應式編程的流來異步加載 js、二進制文件等資源」時，各個資源的加載順序是否正確。

使用Performance.now

使用該方法打印某段邏輯的時間開銷，多用於自動化測試->端對端測試—>性能測試。

本系列在使用profile定位到熱點函數後，會使用該方法肯定具體代碼的時間開銷。經過比較優化前和優化後的時間開銷，來評估優化的效果。

示例代碼爲：

var n1 = performance.now();

執行某些邏輯


var n2 = performance.now();

//打印邏輯的時間開銷（ms爲單位）
console.log(n2 - n1);

使用Console.profile

相對於Chrome DevTools的Javascript Profiler，該方法能夠測試某一段邏輯的profile，而不是整個頁面的profile，粒度更小，更加可控。

（圖來自Chrome 控制檯console的用法（學了以後對於調試js但是大大有用的哦））

測試內存開銷

使用Chrome DevTools的Memory

本系列對這個工具的應用：
使用Allocation sampling，定位內存佔用的熱點函數；
使用Allocation instrumentation on timeline來比較每一幀內存開銷的增加狀況，從而肯定是否有內存泄漏。若是有內存泄漏，則經過Heap snapshot，記錄多個內存快照並進行比較，定位到具體是哪些地方增長了內存。

相關資料可參考：
解決內存問題