本文轉載自騰訊TMQ團隊 ，侵權刪。

 

1、開天闢地

 

Hippy是什麼呢？簡單點，能用JavaScript來寫Android和iOS應用的框架, 類似業界的React Native。

 

好吧，我們還是嚴謹一點。Hippy是一個前終端一體化的JavaScript Framework，可以用JavaScript構建Native原生介面，以及呼叫Native的能力。同時可以一次編寫Android和iOS兩端執行。

 

 

 

這麼牛B的框架，應該如何進行程式碼級別的測試保障呢？請繼續往下看。

 

 

 

2、Hippy架構和測試策略

 

（1）Hippy分層框架

 

通過程式碼閱讀分析，我們得到的Hippy框架主要架構圖，如下。

 

 

 

接下來我們對Hippy底層框架進行具體分析，制定相應的測試策略。

 

（2）  前端框架層

 

主要實現了JSX頁面DOM轉化、js/native橋接介面、View/Module的前端實現。

 

Ø JSX頁面DOM轉化

 

這部分我們採用自動化，模擬生成各種型別JSX頁面，通過遺傳演算法混合View和屬性。然後將混合後的JSX做DOM解析，將解析後結果和預期做對比測試。

 

Ø 橋接介面、View/Module的前端實現

 

對於橋接介面、View/Module的前端實現，單獨的前端單元測試難以驗證實際效果，必須要和終端實現進行結合，所以我們這部分測試策略是進行前後端打通的介面測試。

 

（3） JS引擎層

 

JS引擎層主要是JS程式碼通過Google V8引擎執行，然後通過so呼叫java程式碼。主要作用是打通JS和Java程式碼呼叫通道。這部分由於Google自己產品已經有完善測試體系，我們不用在這個地方做重複建設。剩下的只是hippy橋接so，由於只是JNI介面沒有太多業務邏輯。所以我們的測試策略是，採用Code Review和前後端介面測試進行保障。

 

（4）終端框架層

 

主要實現了Dom節點的終端渲染、View/Module的終端實現、Hippy的生命週期管理等功能。

 

Ø Dom節點的終端渲染、View/Module的終端實現

 

這部分View/Module實現和View渲染工作，特別是View部分我們的測試策略是，採用前後端打通的介面測試進行。詳情參考本系列第二彈文章，敬請期待。

 

Ø Hippy的生命週期管理

 

通過程式碼分析得到Hippy的生命週期如下。

 

 

 

其中對啟動速度影響最大的，莫過於“引擎初始化”和“業務JavaScript載入”時間了。其中，針對“引擎初始化”時間，測試策略是在開發階段就進行程式碼埋點，多次進行效能測試後開發優化。

 

但是“業務JavaScript載入”時間，這個完全是由各業務自己決定和優化，並非Hippy底層能決定。所以，這裡測試策略採用程式碼埋點，監控具體業務JavaScript載入時間，如果超過500ms就告警，防止業務使用者體驗下降。

 

 

 

3、 介面測試框架選型和實現

 

由前面第二章內容可見，前後端打通的介面測試是個重頭戲，必須仔細選型構建。

 

（1） 測試框架對比

 

由於Hippy同類產品較少，公司外主要有Facebook的React Native，以及類似的渲染結構的Chrome核心。公司內部選取QQ瀏覽器核心作為對比物件。考察重點集中在：

 

Ø 使用的技術棧

 

Ø 測試條件構建

 

Ø 測試結果驗證

 

Ø 測試執行形式

 

React Native

 

簡介：React native框架是facebook推出的，通過JS程式碼構建跨平臺APP的開發框架。

 

Github：https://facebook.github.io/react-native/

 

那麼通過下載Github上的React Native的原始碼，我們可以清晰看到React Native針對Android測試程式碼的整體結構如下。

 

 

 

同學們一眼就能看出這是標準的android介面測試程式碼形式，接下來我們針對關心的幾個問題一一分析下。

 

Ø 使用的技術棧

 

很顯然就是Android+JUnit+JavaScript。

 

Ø 測試條件構建

 

所有的測試條件都在前端通過JavaScript進行構造，如圖。

 

 

 

Ø 測試結果驗證

 

結果驗證分為在Android端和JavaScript端兩端驗證，下圖是Android端驗證例子。

 

 

 

下圖是在前端JavaScript驗證測試結果，如下圖。

 

 

 

Ø 測試執行形式

 

用例執行標準android介面測試執行，把Demo.apk和Test.apk安裝在Android手機上，通過adb命令啟動單元測試用例。

 

QQBrowser

 

簡介：QQBrowser瀏覽器核心，針對html的渲染機制和hippy工作機制非常類似。只不過QQBrowser核心針對html渲染上屏、hippy針對JavaScript進行渲染上屏。

 

Ø 使用的技術棧

 

JavaScript+Html，主要思想是在不同的瀏覽器上執行js，檢視瀏覽器對js的支援程度。

 

Ø 測試條件構建

 

測試條件直接通過頁面JavaScript編寫，如下圖。

 

 

 

Ø 測試結果驗證

 

結果的驗證也是JavaScript的catch exception來檢驗，如果瀏覽器不支援某個JavaScript屬性，就丟擲exception，我們通過抓取exception判斷結果不通過。

 

 

 

Ø 測試執行形式

 

瀏覽器直接載入頁面執行，需要注意的是有一部分屬性還不能完全自動化，需要人手工進行點選頁面進行判斷，如下圖。

 

 

 

Chrome

 

簡介：谷歌公司的開源專案Chromium中，關於webview（核心）部分渲染測試，和QQBrowser核心渲染測試比較類似。

 

Doc：

 

https://www.chromium.org/developers/testing/android-tests/android-webview-tests

 

Code：

 

https://chromium.googlesource.com/chromium/src.git/+archive/63.0.3239.26.tar.gz

 

Ø 使用的技術棧

 

Android+JavaScript+JUnit，主要思路是在終端Java中直接讀取html和JavaScript程式碼，然後進行渲染結果確認。

 

Ø 測試條件構建

 

直接在終端Android程式碼中寫入測試html。

 

 

 

或者讀取本地html檔案

 

 

 

Ø 測試結果驗證

 

直接在Android程式碼中進行驗證判斷。

 

 

 

Ø 測試執行形式

 

Android介面測試執行形式。

 

對比總結

 

通過以上三種產品測試策略對比，我們列出如下表格資料方便決策。

 

 

 

由於產品形態類似，驗證結構靈活性等原因，最後我們選擇了類似ReactNative的測試架構。

 

（2）測試框架構建

 

從上一節結論可以知道，我們的介面測試架構採用類似ReactNative的測試架構，如下。

 

 

 

前端測試層

 

這裡是針對Hippy“前端框架層”來說的。

 

Ø Param Pip

 

用來將前端引數傳遞給終端Pip。

 

Ø Assert Pip

 

用來將前端斷言結果終端Pip。

 

終端測試層

 

這裡是針對Hippy“終端框架層”來說的。

 

Ø Pip

 

接收前端Pip傳送的各種結果進行處理。

 

Ø PreCondition

 

測試的前置條件，包含例如：jsbundle的設定、啟動APP等。

 

Ø Reflection

 

反射工具，針對各種屬性和回撥物件獲取提供支援。

 

Ø Gesture

 

使用者動作模擬，封裝了常用的使用者操作。

 

Ø Activity

 

作為測試Activity，其中會載入jsbundle並且在終端展示渲染效果。

 

Android Framework層

 

Ø Configuration

 

提供執行環境配置管理。

 

Ø Junit

 

Junit單元測試框架。

相關推薦