本文從營銷頻道H5業務展開，講述了H5測試的通用測試技巧與實作方案，對測試工作和經驗進行總結提煉。通過本文可以了解京東内常用研發架構的測試方法和實踐效果。
【本文目錄】
- 了解H5業務
- 常用測試手段
- 針對京東現有H5常用架構和實作方案的測試
- 痛點和不足
背景
H5頁面是營銷域最常見的一種營運形式，業務通過H5來提供服務，可以滿足使用者對于便捷、高效和低成本的需求。H5頁面是業務直面使用者的端點，其品質保證工作顯得尤為重要。各業務的功能實作具有通用性，相應也有共性的測試方法，本文進行總結和分享。
1 了解H5業務
多角度認識H5業務，了解功能的實作鍊路，明确各個節點是由哪一方如何實作，一方面可以打開設計用例的思路；另一方面在遇到問題時，可以快速定位，精确回報。
【1.1 前端展示】
1.1.1 兩種開發技術
提及前端，需要首先介紹兩種開發技術“原生開發”、“H5開發”：
原生應用開發：是在 Android、iOS 等移動平台上利用官方提供的開發語言、開發類庫、開發工具進行 App 開發。是以原生架構的 App 在應用性能上和互動體驗上應該是最好的，比如APP中的“直播”、“登入”以及提醒元件等是純原生開發的子產品。
H5開發：是指利用 Web 技術（HTML5、JavaScript、CSS）進行的 App 開發。H5 開發的好處是可以跨平台，編寫的代碼可以同時在 Android、iOS、Windows 上進行運作。目前APP内的主要活動比如“百億補貼”、“便宜包郵”以及“秒殺”等均為H5開發實作。
兩種開發實作的特點對比如下：
| H5 | 原生 | |
| 開發成本 | 低：一套代碼，跨平台使用 | 高：同樣的邏輯、界面要寫兩套 |
| 開發周期 | 短：量級低，直接添加功能釋出 | 長：更新疊代緩慢，上架時需要等待官方稽核通過 |
| 調用底層功能 | 複雜：不能直接調用，需要橋接等其他操作 | 簡單：更加貼近底層，對于調取底層功能也是很容易 |
| 性能體驗 | 有局限性：H5 移動應用不能直接通路裝置硬體和離線存儲 | 更優：直接運作在裝置作業系統上，通常性能更優，響應更快 |
| 部署更新 | 快：隻需更新伺服器上的代碼，使用者無需下載下傳即可享受最新功能 | 慢：需要通過應用商店進行釋出和更新，更新可能需要使用者下載下傳新版本 |
| 營銷 | 較為靈活：可以通過網站和社交媒體等管道更容易地推廣 | 限制較多：通過應用商店進行推廣和分發，但需要遵守商店的政策和指南 |
1.1.2 容器角度分層
以春晚頁面為例，從容器的角度，一個H5頁面從頂層到底層的層級展示如下圖：
其中通天塔H5 fragment容器重寫了JDHybrid的CommonMFragment，X5WebView容器重寫了x5webview，支援自行決定使用系統還是x5。圖中涉及4方，分别是通天塔團隊、JDHybrid團隊、JSSDK和H5具體業務方。其中通天塔團隊、JDHybrid團隊是原生開發的架構，屬于容器側，JSSDK和H5具體業務方屬于H5開發，各自作用可概述如下：
•JDHybrid：提供環境裝置資訊、導航欄、頁面路由、頁面事件、通用JS功能、性能優化
•通天塔：提供自定義的導航欄的邏輯，包括UI和JS橋；其他複用webview容器的能力
•JSSDK：統一API，調用用戶端協定；同時提供性能異常上報、常用函數等
•H5前端：接入JSSDK，展示頁面内容，實作前端互動等業務邏輯
1.1.3 具體功能實作
具體功能的實作，往往涉及多個功能提供方，大體可分兩類：
•能力由JDHybrid提供的
H5通過JSSDK調JDHybrid封裝的方法， JDHybrid調自身邏輯
例如：擷取裝置資訊中的uuid
JDHybrid提供了擷取裝置基礎資訊的JS橋，按照約定的規則入參，可以即可獲得uuid等資訊。但原生底層API，但不再對外暴露，而是由JSSDK統一維護，京東電器的H5代碼隻需要調用JSSDK即可
•能力由其他團隊（通天塔或其他元件）提供的
H5調JS代碼，經過webview核心 ，核心調用 JDHybrid封裝的統一方法， JDHybrid調通天塔（或其他插件）
例如：打開位址清單，位址清單是位址元件提供的能力，JDHybrid提供了路由方法可以通過測試demo簡單判斷是否具體業務問題。
【1.2 内容資料】
能為多個業務提供同一類功能的應用，被抽象為各個“上遊”。營銷内容從配置到呈現給使用者，需要多重業務邏輯處理，除本業務服務端進行精細化業務處理，還需要與各個上遊進行互動。一個業務整體的功能實作，與各常見上遊之間調用的鍊路如下圖所示：
1.2.1 資料來源
商品資訊、優惠券、紅包和利益點，是一個H5頁面常見的元素，其底層來源各不相同：
| 頁面元素 | 底層來源 | 舉例 |
| 商品資訊 | 投放商品組 | |
| 優惠券資訊 | 券中台 | |
| 紅包資訊 | 紅包中台 | |
| 利益點 | 業務CMS | |
1.2.2 資料政策
通常，業務方不會與底層資料直接互動，而是通過多個上遊，實作資料的千人千面效果，例如：
•算法：根據業務配置政策，将商品組資訊整合之後提供給具體業務
•UMC：基于使用者資料，針對不同人群，制定發放不同權益類型的規則
•互動工坊：按照活動次元，設定任務和獎品的組合規則
關于内容資料的驗證，測試關鍵在于所配即所得，不同的使用者畫像獲得的資料要符合業務預期。
2 常用測試手段
【2.1 測服務端】
2.1.1 檢視日志
•平台：泰山-日志管理
•适用場景：涉及上下遊邏輯，且不能在前端直接觀察
•關注點：
通過關鍵字，篩選各個應用的資訊，驗證服務端對上遊的入參、上遊對服務端的傳回是否符合預期
2.1.2 特殊場景
•平台：deeptest-mock管理
•适用場景：對于一些異常場景或者邊界值，營銷活動或素材無法精準滿足場景要求，
•關注點：
可在平台上錄入上遊接口資訊，通過mock上遊傳回，驗證業務服務端的處理邏輯
2.1.3 JMQ驗證
•平台：泰山-JMQ
•适用場景：應用服務之間通過MQ來通信的場景
•關注點：開啟消費軌迹，驗證發送給其他應用服務的MQ資訊時機是否準确，内容是否正确
2.1.4 緩存查詢
•平台：泰山-JIMDB
•适用場景：需求改動到緩存邏輯，尤其針對長期互動類
•關注點：緩存的寫入時間是否及時、有效期是否合理、緩存内容正确性
2.1.5 直接調用
•平台：deeptest-用例管理
•适用場景：
前置操作較長（如需要先展示再領取）、條件苛刻（如需要多重身份打标）、門檻值較高需要批量操作等
•關注點：接口傳回同入參預期，邊界邏輯正确處理
【2.2 測前端】
2.2.1 功能測試
| 功能 | 驗證點 |
| 使用者行為 | 點選 單次點選：點選事件是否被響應、多層頁面是否會出現點選穿透多次點選：頁面在等待資料傳回過程中，後續點選行為是否會出現業務邏輯錯誤 |
| 滑動 滑動速度：不同速度滑動，業務功能需保持一緻，快速滑動資料加載不能太慢 滑動互動：是否支援左右橫滑、滑動時是否響應點選操作 | |
| 重新整理 主動重新整理：如下拉重新整理、點選按鈕重新整理，關注頁面加載行為與接口請求被動重新整理：業務特殊邏輯，關注觸發重新整理時機與互動 | |
| 系統互動 傳回：一級頁面傳回、二級頁面傳回，關注傳回層級和曆史浏覽記錄 輸入：特殊内容、格式、輸入面闆喚起與隐藏 退前背景：頁面行為如倒計時、動畫效果、接口請求等是否被中斷 | |
| 多媒體相關 | 圖檔 圖檔展示放大、還原、切換等操作支援 |
| 音頻和視訊 不同域名下的資源加載情況 互動體驗：播放、停止、退出 | |
| 頁面請求 | 通過檢視、修改HTTP、HTTPS、Websocket的請求、響應，驗證前端入參、各種資料展示邏輯是否符合預期 接口請求 接口傳回過程中動畫效果 請求時機、接口降級、接口異常前端兜底 |
| 資源請求 請求是否重複 翻頁、分頁場景下請求資料正确性 | |
| 登入 | 未登入使用者路徑 登入态打通 不同使用者身份判定 特殊賬号的昵稱、頭像顯示 使用微信或其他站外資訊登入 |
| 彈框 | 彈框觸發時機 彈框内容的正确性 彈框的素材、動效 彈框關閉的觸發條件 |
| 網絡環境 | 不同網絡環境：WiFi、3G/4G/5G 網絡環境切換，使用者是否有感覺 弱網條件下使用者體驗 無網兜底邏輯 |
| 兜底測試 | 針對關鍵字段，驗證“不下發”、下發為空、異常值等驗證，用于規避由于異常下發導緻的“開天窗”、掉樓等使用者可感覺的問題 |
2.2.2 相容測試
覆寫原則：
•Android、iOS不同系統
•兼顧不同螢幕分辨率
•如涉及到站外投放，需考慮到容器版本微信版本相容，不同原生浏覽器
•系統核心、X5核心
平台：
目前已有一些自動化手段，如Airtest、活動自動化測試等以插件形式內建在賽博雲測平台
2.2.3 埋點測試
關注點：埋點事件名稱、上報時機、關鍵字段是否與埋點方案一緻
平台：track
2.2.4 與原生架構結合
| 功能 | 驗證點 |
| APP版本 | 需要關注元件/架構支援的最低版本，進行版本控制，邊界測試 ·需要區分原生用戶端，iOS、Android、鴻蒙進行功能驗證 |
| 容錯手段 | APP改動需要重新釋出，已經發版則無法使用，是以要注意驗證功能開關的邏輯、配置 ·完善降級方式，如根據URL參數降級某些功能 |
| 核心相容 | 系統核心：此處可簡單了解為浏覽器核心，也稱渲染引擎或者排版引擎，主要對網頁的文法進行解釋，并且進行渲染網頁，将網頁的代碼轉換為看得到的頁面，目前主流廠商多使用Chromium。·X5核心：最初是由騰訊基于開源Webkit深度優化而來。基于X5核心，騰訊提供的TBS服務，整合騰訊底層浏覽技術和騰訊平台資源及能力，提供整體浏覽服務解決方案。是以京東APP内，會在APP安裝好之後，下載下傳X5核心，供H5使用 |
注意：
1.X5核心需要為京東APP開啟存儲權限，才會下載下傳
2.X5核心下載下傳好之後，需重新開機APP才可以使用
3.快速定位問題方法：使用手機自帶浏覽器，通路H5頁面，如果和APP内表現不一緻，可縮小問題範圍
【2.3 線上追蹤】
需求上線之後，還需要在真實使用者場景下，對需求的功能、性能和體驗進行監控、分析和驗證。目前公司已有的追蹤平台和手段陳列如下：
| 平台 | 關注點 |
| 使用者之聲 | 真實使用者回報，側重使用者體驗 |
| 行雲-接口監控 | 監控接口的業務邏輯處理，側重業務服務的連通性、可用性 |
| 泰山-雷達大屏 | 可以全局視角觀察系統服務健康狀态，側重全鍊路服務性能 |
| UIπ-啄木鳥 | 檢測H5活動頁各類問題，側重前端展示 |
| 燭龍 | 可提供多元度的使用者行為資訊，對排查使用者問題有助益 |
3 針對京東現有H5常用架構和實作方案的測試
【3.1 釋出】
3.1.1 ihub
大前端共建平台，基于iPaaS标準建設，面向開發者提供包含h5、iOS、安卓等端的跨端樓層開發管理能力。賦能開發者跨業務線、跨系統（符合iPaaS标準）的開發内容複用、檢索及二次開發等功能
驗證點：
•位置：樓層位于首屏，非首屏等，驗證是否有異常，比如資料加載，樓層渲染等
•數量：一個頁面中是否使用了多個共模組化闆，是否有沖突
•共存：共模組化闆與通天塔的自有模闆共存時是否有異常
•關聯：共模組化闆關聯錨點導航
目前已經沉澱出針對大促會場的自動化測試方法
3.1.2 通天塔可視化平台
是活動/頻道頁面可視化搭建平台，支援一次搭建輸出H5、原生、PC等多端頁面，供産研、采銷營運、商家等使用者免費使用
驗證點：可視化配置、服務端儲存與下發、前端展示正常，關注新增功能點對老功能的相容
【3.2 性能優化】
使用者能夠正常通路頁面，頁面的内容才能産生價值，最大程度減少頁面的加載時間，進而降低跳失率，就顯得尤為重要。目前公司内部已有一些較為成熟的性能優化工具，會涉及到工具接入和效果的測試驗證工作。
3.2.1 頁面加載過程
一個H5頁面的加載過程可簡單歸納為以上幾個步驟，性能優化手段，主要是從提前請求時機、減少資源請求等方面入手。
3.2.2 現有優化手段
驗證原則：接入生效、接入後對業務邏輯無影響。
3.2.2.1 JDHybrid離線包
原理：
把首屏的一些靜态資源(如img、js、css、html等)打包提前加載到本地磁盤，當加載頁面時直接從本地磁盤（或記憶體）擷取資源加載
驗證方法：
1）日志：借助JDHybrid團隊提供的測試工具（Xconsole、xdog等），确認對應資源使用離線資源
2）抓包：H5在使用該資源時，不發起網絡請求
3）hybrid快速驗證工具：
使用業務：
通天塔會場、跨晚、春晚等
3.2.2.2 通天塔-資料直出
原理：前端直接從HTML中擷取展示資料， 無需發起首屏接口請求。
驗證方法：抓包觀察，接入的樓層不發起網絡請求
使用業務：部分通天塔會場、領券中心等
3.2.2.3 通天塔-SSR
原理：服務端渲染網頁内容，并且将渲染後的HTML發送給浏覽器，浏覽器直接顯示。資料直出和SSR差別在于直接加載一整個html，還是先頁面、 後樓層順序的加載頁面片。
驗證方法：禁用JS，頁面仍可加載
使用業務：百億補貼、便宜包郵等
3.2.3 優化效果驗證
3.2.3.1 同業比對性能測試工具
錄制使用者操作流程，通過自動化拆幀的方式，從使用者視角對場景進行耗時采集和分析。控制變量的情況下可與競品進行性能對比與分析
3.2.3.2 燭龍
通過侵入式埋點方式，實作了對APP應用的全方位監控，實時采集使用者的性能異常資料，快速精準定位問題，發現性能瓶頸，減少使用者流失，提升使用者體驗
【3.3 風控】
H5常用的風控手段，集中在反爬和使用者身份兩大方向，驗證的關注點在于“接入的正确性”和“政策的有效性”。
3.3.1 價格反爬接口三件套
•神盾處置
驗證點：
登入加黑白名單，請求接口，可觸發處置，網關傳回605
在處置頁放棄驗證，可傳回上一頁，不能循環進入處置頁面
在處置頁成功驗證，處置頁面消失，H5頁面重新加載
•神盾接口加強
驗證點：
入參的h5st正常，驗簽面闆傳回結果200，soa接口正常下發資料，前台頁面正常展示
mock入參中異常，驗簽面闆傳回非200，soa接口在網關側攔截（下發403或者mock資料），前台頁面走業務兜底邏輯
•裝置指紋
驗證點：body中傳參正确即可
3.3.2 RCS風控
驗證點：根據不同畫像人群的配置政策，驗證對應pin觸發業務處理邏輯是否符合預期
4 痛點和不足
1. 元件測試
元件的代碼改動偏底層，測試過程相對黑盒，劃定測試範圍時，往往隻能是重複性回歸，因為更加底層的邏輯測不到，如場景無法創造等。如何提高可測性、增加測試精準性，是需要進一步解決的問題。
2. 相容測試
目前裝置機型較多，落實到相容測試，其實是單一行為的重複，靠人工執行耗時長，且覆寫範圍有限。但目前缺乏可靠的自動化工具，可以替代相容驗證，同時降低腳本的維護成本。
3. 測試素材
涉及到權益相關的需求，依賴真實素材，可能會阻礙測試進度。通過mock的方式前提是有一方作保證，或内容已驗證，風險較大。
4. 兜底測試
大型互動中，調用接口較多，且互動複雜，但對健壯性要求較高，兜底工作量較大。目前的兜底自動化工具，還需要豐富支援的場景。
作者:技術品質 丁嘉瑩
來源-微信公衆号:京東零售技術
出處:https://mp.weixin.qq.com/s/AlwRQriRqVfGmWC8sgRq7w