3D 雲設計工具的前端效能自動化及核心問題分析解決

1. 3D 雲設計工具的前端特徵及前端效能自動化測試

1.1 3D 雲設計工具前端特徵

酷家樂作為一家面向未來的大家居全案設計平臺及生態解決方案提供商，支援從家居到全空間的雲端設計繪製。
同時根據業務特性，前端方面創造性的構建了基於 React 檢視框架的資料流，並支援了大量設計繪製業務。
而我們的前端效能測試關注點也有其獨特性存在。

1.2 前端效能自動化測試

對於如此重要、眾多的雲設計前端架構和業務，我們勢必需要高效、高質量的測試保障手段。
酷家樂質量效能部開發了用於 Ui 自動化測試 Hades 測試框架，並結合前端效能特性進行效能自動化擴充支援；並對全業務的一些前端效能測試做了實現支撐。

1.3 測試面臨的 “挑戰”

在使用 Hades 框架做前端效能測試、逐漸豐富框架的過程中，遇到了一些問題。除去大家比較熟悉的本身 ui 自動化會面臨的問題，自動化前端效能測試對於資料的準確性、穩定性也提出了更高的要求。
這個問題我們也可以從 ui 自動化通常面臨的挑戰及效能測試的要求中看出來，因此亟需我們測試同學去 “定義” - “分析” - “解決” 這個 “穩定性” 問題。

2. 為什麼 “穩定性” 對於前端效能測試格外重

從上面的初步分析及以前的執行情況也可以看出，前端效能自動化測試的 “穩定性” 是個重要問題，是 “獨特”、“高於” 普通 ui 自動化遇到的困難之外的一個問題。
對於 “穩定性” 問題我們理解是如下三方面：

case 的穩定執行不言而喻，即這些 case 每條都可以正確的按照 case 步驟執行完成、上傳結果；資料的準確性是測試操作/結果資料標示與真實資料（比如肉眼/手測/devtool 收集）的逼近程度；資料的穩定性是我們的測試資料在版本測試周期（比如同一個版本、跨版本）內的波動穩定程度。
在第一項的基礎上，後兩項穩定性對於前端效能自動化測試尤為重要。

2.1 資料準確性

是指自動化 case 執行得到的資料與真實測試資料之間的差距。如果差距較大，這個資料則完全不具備參考性。
因此，測試資料的準確性很重要。比如對於雲設計工具中的畫布移動旋轉，手動測試 36fps，自動化測試 34fps，這個資料可信嗎？

2.2 資料穩定性

是指自動化 case 執行得到的資料的波動程度。如果波動範圍極大，這個資料的可信度也不高。
對於一項效能最佳化，它的提升可能是 3-5fps，現在有了自動化資料的支撐，但如果資料時而是 +3fps、時而是-1fps、時而是 +2fps，那我們怎麼判斷最佳化效果，甚至懷疑是負最佳化。
如下兩個測試資料，哪個認為更準確可靠呢？

3. 哪些會影響 “穩定性”？

類似對於 ui 自動化中問題的分析解決一樣，我們首先去了解一個用例的執行過程，其次分析這個過程中有哪些 “不穩定” 的影響因素，再次還需瞭解對於雲設計平臺來說，又有哪些獨特之處。

3.1 雲設計工具前端效能自動化執行過程

對於雲設計工具來說，它的前端自動化以框架和執行環境為基礎，設計繪製操作核心圍繞著方案操作、畫布\視角操作、模型\材質操作、引數元素這樣的從廣泛到深入的過程。

3.2 自動化 “穩定性” 影響範圍分析

基於用例自動化執行過程，我們對其中涉及的各個環節進行細化分析。包括：
所執行在的硬體執行環境（物理機）、軟體執行環境（瀏覽器、酷家樂工具/客戶端、CI 持續整合測試）、自動化效能測試流程操作（自動化用例設計）、以及效能資料的收集處理（效能分析及監控）。

4. 如何保障這些環節的穩定性

從上圖我們知道，對於前端效能自動化來說，這些環節可能都對資料穩定性產生影響，我們逐一分析各個環節具體對我們的結果會有哪些影響，並且是怎麼解決/弱化影響的。

4.1 硬體執行環境保障穩定

前端效能測試本身吃哪些硬體資源？大家都知道記憶體、CPU、GPU 這些會深刻的影響前端效能表現。
以記憶體舉例，看下對前端流暢度效能（通常以 fps 標記）的影響，而 GPU 記憶體及使用率的影響則會更明顯：

這些硬體資源本身的效能無疑會影響效能 case 執行的穩定性，資源好、資源狀態好，可能效能 case 的結果表現就好，資源差一點/資源狀態差一點，效能 case 的結果表現可能就差了。那怎麼保障這些資源的穩定性。

4.1.1 保障效能自動化測試硬體環境的穩定性

現在比較明確，不同硬體資源，case 執行的結果不同。因此首先要對效能測試的機器進行選型和固化。對於選型上，為了保障測試資料與真實使用者資料的儘量接近。
【建議】利用線上埋點資料，尋找與平均值接近的硬體配置，從資料準確性上來說，可能更接近使用者的。而對於雲設計工具來說，有時候會面向特定場景/使用者（比如工裝場景、地產、家居），這時候有必要做一些使用者分析調研，選取儘量與使用者靠近的硬體配置。

4.1.2 保障硬體資源狀態的穩定性

從上面可以看到，即使同一資源，不同的狀態（CPU 佔用不同、記憶體佔用不同、GPU 佔用不同）產生的效能測試資料都不一樣。
【建議】前端效能自動化測試前做資源標準初始化（如重啟測試資源、測試資源清理釋放等）；Windows 資源管理器可以檢視資源狀態，我們對測試資源進行監控，判斷初始執行狀態健康度。

4.2 保障軟體執行環境的 “穩定性”

拋去硬體資源對效能測試的影響，軟體資源環境對我們前端自動化效能也會產生影響。這裡包括：瀏覽器版本環境、測試分支環境等。

4.2.1 “穩定” 的瀏覽器環境

軟體環境來看，前端效能還受瀏覽器及其版本影響。就前端效能來說，例如 Chrome 85 版本引入的 PGO 技術提升頁面載入速度，而在我們雲設計工具的方案載入中，也可以明顯的感知到差異。


【建議】一般建議使用最新發布的穩定版本作為測試 chrome 軟體版本，有其對於前端效能自動化測試，儘量保證版本穩定性。PS：chrome85+ 版本 FpsMeter 展示發生變化，不方便直觀的觀測 FPS 了。

4.2.2 可配置的軟體前後端版本環境

測試效果肯定受我們的待測版本影響（也是我們的測試目標），執行前端效能自動化測試環境包括前端分支環境，後端分支環境，而我們的一些效能表現是受後端服務的影響的，我們需要思考怎樣提供一個穩定的測試版本環境。
【建議】
1、通常 ui 自動化 case 中是透過待測環境的域名的方式進行訪問和測試的，這個建議不管是 ui 測試框架，還是前端效能測試框架，均抽象為配置層或用例層，與底層的資料（甚至用例）做好隔離（也是業界通常做法）。
2、對於微服務框架的業務測試環境來說，測試框架提供手動環境配置的方法介面。例如下圖中我們可以透過 Hades 框架對各種微服務進行配置。

4.3 持續整合測試配置及環境的影響

我們主要使用的是 Jenkins 進行持續整合測試，這塊兒網上的資料比較多，遇到問題可以參考解決的方法也比較多。
【建議】在遇到一段時間下有資料結果、另一段時間沒有資料結果的情況時，除了懷疑本身用例設計穩定度外，可以看看是否持續整合測試環境出現失敗。

4.4 前端效能自動化用例的 “穩定性” 方法

除去環境之外，影響最高頻、最廣泛的就是我們真正在執行的前端效能自動化用例了。除去常見的 UI 自動化的一些編寫問題點外，在我們雲設計工具的前端自動化中還需要考慮更繁雜的內容。

4.4.1 最佳化測試方案 -- 前端效能自動化測試方案對效能資料的影響

不同資料大小、不同量級大小、不同前端業務特徵的雲設計工具方案，對前端資源的消耗不一樣，效能結果自然不一樣



【建議】選取合適的前端效能測試方案，可以從以下兩種方式考慮；且無特殊需求下，必須固化這些測試方案；避免測試方案被任何情況汙染。

4.4.2 最佳化等待 - 方案開啟耗時影響

在效能測試用例設計中，儘量避免使用 time.sleep 此類耗時方法。而這個方法在 ui 自動化用例中通常很常見（等待元素出現）。
例如開啟方案時會使用配置預設的 pageGoto 超時時間（30s），對於較大的效能方案，需要刪除這個超時時間，保障資料的準確性。
比如雲設計工具中，開啟畫布方案的方法有個起始時間和終止時間對判斷，終止是以某個 load 標示進行判斷的（可以是蒙層消失），這時候我們就可以看一下這個耗時統計方法是否有超時設計。
【建議】ui 自動化用例中可以使用 time.sleep 類似的方法，而前端效能測試用例中儘量避免，可以使用 clickIfExist 等實時判斷方法，實時性準確性會更佳。

4.4.3 最佳化校驗 -- 增加業務領域校驗

對於雲設計工具，我們有多個業務領域，不同業務領域使用著不同的前端程式碼，因此，相同的行為操作在不同的業務領域中前端效能資料是不一樣的，這個也是影響資料準確性的重要因素。
比如某些元素 xpath、zoom、view，以及 entityID，在定製業務和傢俱業務中是同一個，但在不同業務領域中操作它們時的效能結果是不一樣的。

【建議】每個測試用例明確所處的業務領域（頁面），並增加對業務領域的校驗，校驗失敗則測試資料不可採。

4.4.4 最佳化校驗 -- 業務資料狀態校驗

另外需要考慮業務資料狀態對前端效能表現的影響。比如常見的各個前端資原始檔、圖片下載完成後才可以統計元素載入時間效能，而不是在過程中做統計分析。
對於雲設計工具來說，我們模型/方案載入有一個過程（例如從蒙層到蒙層消失、模型藍框到模型渲染完成），在這個載入過程的前、中、後，相同操作的效能資料的效果也是不一致的。
【建議】需要考慮業務領域的內的業務資料狀態是穩定/完成情況下，再執行相應效能測試，不建議將 case 結果收集置於一個非穩定態，這樣收集到的前端效能資料必然是不準的。

4.4.5 最佳化元素選取 -- 操作模型選取的準確性

對於通常的 ui 自動化測試，有各種各樣的元素需要選取，對於雲設計工具，除頁面元素外，還包括上文中提到的各種模型。
從業務角度，被測模型的選擇儘量以該業務領域的高頻/常用/典型模型為主，比如普通的傢俱沙發、衣櫃、普通牆樑柱，這樣操作得到的效能資料更接近真實；
【建議】對於有效能差異的元素/模型，需要進行差異覆蓋或差異選取，比如單模型、組合模型的效能資料一般是有差異的。比如下方是兩種模型的效能自動化測試資料。

4.4.6 最佳化元素定位–模型 id/元素 xpath(id) 的穩定性

在具體 case 設計時，我們可以分析一下模型選取的操作流。看看有哪些地方會影響” 穩定性 “



【建議】模型 ID 的準確性和可用性對於 case 穩定性非常重要，因此一定需要保證被測模型可以被穩定讀取到（注意一些模型在方案複製過程中可能會發生模型 ID 的改變）；另外，業界目前也有透過影像識別或者 AI 進行元素選取的方案，可以提供選取的穩定性。

4.4.7 最佳化元素定位 -- 模型 position 的準確性

在透過 ui 自動化設計中，會對定位到的元素進行點選等操作，通常是透過查詢頁面中元素位置再來執行點選。對於不方便使用 id/class 等方式的，也建議不要透過絕對位置去點選，以保證每次點選的準確性。
對應到 3D 設計工具，存在一個畫布中的座標系（我們可以叫世界座標），複雜模型中部分子模型相對主模型來說，又有一個相對座標。
例如對我們框架，對於一些簡單模型，getposition 拿取的是世界座標 2d position，但對於一些複雜的模型，position 就是相對 position，需要手動進行一些 position 矩陣變換。這個會影響 position 的準確性，間接影響用例穩定性。

【建議】不管是 ui 自動化還是前端效能自動化，模型 position 儘量保持穩定，或者使用相對 position 的方式，較大的場景下，絕對 position 受影響機率更高。

4.4.8 最佳化元素位置 -- 模型 position 的穩定度

我們雲設計工具的 UI 自動化通常是透過查詢和模擬滑鼠點選對應真實座標來實現選中操作的，可點選性對於 case 的穩定性（可用性）就十分重要。
比如，上面看到第三步是 position 的點選，對於這類 mouseclick 的方式，在我們一個 3D 設計工具方案中，對要點選的模型大小、位置、視角的要求會高一些。比如如下幾種情況，可點選性就不高，勢必成功率不高。

【建議】建議在設計具體前端效能測試用例時，最佳化元素/模型在場景中的位置，保障可點選性，以提高可點選的穩定度。

4.4.9 最佳化用例設計 -- 操作靠近使用者操作

對於 3D 設計工具來說，除去模型，另外一個影響比較重要的就是畫布，而且畫布在效能方面可能會產生更直接的影響。
比如這兩個視角下，流暢度/幀率是不一樣的（需要渲染的內容是不一樣的）。選擇合適的視角，對於資料的準確性也很重要。

其次，畫布視角大小&ZOOM 與真實操作的接近性也很重要，這個會影響資料的準確性。

【建議】對於 ui 自動化來說，可以接近使用者真實操作方式是更好的；而對於前端效能自動化來說，這個是必須要達成的，與使用者使用方式偏差越大，效能資料的偏離度可能越大。

4.4.10 最佳化用例順序–畫布類操作路徑

在 ui 自動化設計中，也會考慮不同用例的解耦，以擺脫關聯影響和資料不準確性。
在雲設計工具的前端效能自動化中，同樣需要考慮這方面，而且需要考慮更多的內容點。比如以下是一條畫布操作路徑用例設計

畫布操作（rotate）如果指到了天花板、地板，且是部分面積情況下，我們前端效能測試資料的準確性勢必差一點。
【建議】雲設計工具的前端效能用例設計時，測試畫布移動時設定 move 函式相對值儘量保證大部分方案處於可視的畫布內。對於類似場景，也建議將待測元素置於中間

4.4.11 最佳化用例順序 - 模型類操作路徑

與畫布類操作類似，雲設計工具前端效能測試的操作路徑如果與使用者/首測路徑差異極大，那麼得到的效能資料的差異性也會大一些。建議：這條路徑應該跟使用者的真實路徑更貼近。
比如：我們設計工具中，同時對於模型來說，操作路徑關係著模型的狀態，比如模型的吸附、適配等。選擇一條 “合適”“穩定” 的路很重要。如同樣路徑，吸附和無吸附下流暢度效果。


【建議】在做前端效能/ui 自動化用例設計時，如果涉及多個操作路徑流程，設計比較吻合真實使用路徑的用例。

4.4.12 最佳化用例解耦 - 連續性操作路徑

對於 ui 自動化來說，用例間的耦合度越高，維護成本越高，鏈條中一個環節出錯導致整個失敗的機率越高。
對於我們雲設計工具來說，同樣需要考慮用例之間是否解耦，而這對我們前端效能自動化測試也影響重大。如下圖，通常每個 case 結束也不會置為初始狀態，所以前後兩條關聯 case 之間可能會產生影響並對效能準確性有一定影響

【建議】對於 case 之間是否互相關聯，不同情況可能不一樣，關聯強可能使用者接近程度更貼近；case 結束重置解耦，case 異常情況可能更低。

4.5 效能資料分析收集的準確性

4.5.1 最佳化效能指標演算法 -- 效能資料收集統計方法

前面做了很多前端效能測試操作方面的最佳化，那麼資料分析和統計上是否準確也對整個 “穩定性” 影響重大。
Hades 框架使用效能收集的啟動和終止方法（start、stop fpscollect），然後將每一個活動幀的幀率算出來後放入佇列。
我們分析一個前端效能操作用例的過程，比如移動 3 次模型/畫布後收集這段時間的流暢度效能，涉及了三次是滑鼠 mouseup\mousedown，而每次滑鼠 mouseup 之後的幀率也會被收集，但這段資料實際不是真實的運算元據。


【建議】細化分析關鍵效能計算方式和流程，擠出水分，儘量在框架層來做好演算法最佳化，而不是用例層/業務邏輯層來人為設計。

4.5.2 最佳化效能指標收集–去除非必要效能資料

通常 ui 自動化框架下的很多方法都提供了豐富的配置引數；對於前端效能自動化測試同樣需要考慮這些配置引數的設定和使用。
比如針對雲設計工具，我們的前端效能收集方法支援了對於非活動幀的過濾，這個對於資料的準確性又有了一定的提升，用於過濾效能操作過程中非活動幾幀的影響


PS：活動幀是指正常運動的有效幀，丟擲那些非動態下的幀率影響。比如我們以 chrome 的 fpsmeter 觀察，非畫布活動情況下、或者只有滑鼠滑動下，也有一個幀率值，但明顯不是我們所想要的。

5. 總結展望

前端效能是每一個網際網路技術公司都不會忽略的點，它直接影響著使用者使用體驗的優劣，間接決定了網際網路產品的生死。
對於雲設計平臺來說，如此專業的設計工具平臺，前端效能更加直觀的影響著使用者在使用平臺進行設計、繪製、生產時的體驗，這塊的質量保障建設我們尤其重視。我們依賴已有的前端 ui 自動化框架的擴充套件能力來承擔前端效能自動化測試的質量保障，並且逐步完成了每次發版前的前端效能自動化測試和質量卡點，有效的保障了上線質量；並透過分析和測試對效能資料的準確性和穩定性做了初期的保障。

我們不能停留在目前的地方，一方面需要從技術的角度，分析、最佳化、深化框架中效能操作、效能分析、效能統計等方法和內容，不斷迭代，達成更穩定精確深入的效能資料質量；二方面需要從使用者的角度，沉澱使用者思維，分析使用者方案和行為，以使用者的角度結合測試的有效分析，設計合理高效的用例，達到自動化測試與使用者操作的可比擬性；三方面需要擴充前端效能業務領域和支撐範圍，標準化每個流程，前端程式碼框架承擔著眾多的業務領域，框架需要逐漸抽象支撐更多的業務領域，同時利用框架可以完成前端效能的整體質量流程保障。
本篇簡要介紹針對雲設計工具的前端效能特徵和前端效能自動化流程，重點針對效能測試過程中十分重要的 “可靠性”“穩定性” 問題，進行鏈路分析和解決提議。

想了解更多關於酷家樂技術質量的文章，歡迎關注我們的公眾號