微信讀書排版引擎自動化測試方案

2021-07-24 07:31:06 字數 4077 閱讀 7502

為了獲得極致的閱讀體驗,產品同學經常會提出細緻的排版需求,交給開發同學修改。而排版引擎的修改,往往牽一發動全身,可能導致書城上萬本書籍排版結果受影響。

舉個例子,有個需求是增加正文段落的 margin:

再舉個極端的例子,有個需求要把章節標題往右移動1個畫素:

當開發按需求修改排版引擎、自測後,會把**提交到 svn,然後交給測試同學進行測試。

人工測試方法比較耗時,需要開啟每本書,一頁一頁地翻頁、對比,而且無法覆蓋很多書籍,存在漏測的風險。

另外,通過人眼檢查兩台裝置上的排版結果有沒有差異,是很困難的任務,一是容易疲憊導致判斷失誤,二是對細緻的排版變更(如第二個例子)很難判斷是否符合預期。

為什麼需要自動化測試?

前面提到,人工測試費時耗力,且容易漏測。

此外,排版需求的特點是細節多、變更快,且修改影響範圍大,全網書籍上萬本,無法一一驗證。一旦出錯,直接影響口碑。這些因素都增加了人工測試的工作量和壓力。

除了精細化的排版需求會對排版引擎**做修改,在日常的維護中,也會重構排版引擎、修改排版引擎相關但不影響排版結果的**。每次重構、修改後,也會交給測試同學驗證此次修改對排版結果沒有影響。由於人工測試比較耗時、無法一一驗證,每次重構排版引擎**壓力很大,輕易不敢改動。

還有一種情況,是在開發其他需求、修復缺陷時,意外地導致排版結果受影響。這種錯誤一旦發布到現網,後果很嚴重。

所以,把人工測試流程自動化十分有必要。自動化以後,可以大大減少人工測試的時間,同時方便開發同學自測。開發同學對排版引擎也可以大膽重構、持續改進**質量。最終,達到確保排版引擎質量的目的。

首先,我們要分析一下,在人工測試中,主要有哪些步驟?每個步驟是否能自動化?

在人工測試中,對每次變更的測試,有步驟如下:

開啟要測試的書,設定排版偏好,翻頁,用眼睛檢視螢幕上的排版結果,對比螢幕中的排版結果是否有差異

如果有差異,根據需求判斷差異是否符合預期

其中步驟 1、2 利用自動化測試工具是比較容易完成的。步驟 3 借助演算法能夠使其自動化,會在後面詳細展開。步驟 4 自動化的難度比較大,可能需要借助非常高階的人工智慧完成,我們把這個步驟交給測試和開發同學。

那麼,如何完成步驟 3 的自動化,讓機器做人類的事情呢?我們把它再細分成三個步驟:

首先,需要找到一種機器能讀懂的資料表示,這種資料表示要既能夠表示排版的結果、反映**的修改,也能夠通過演算法來對比,對比的結果要便於視覺化的展示,方便開發、測試同學判斷差異是否符合預期。

我們的選擇有:

nsattributedstring,是從 epub、txt 處理後得到的中間資料,包括文字和排版樣式。這種資料結構比較抽象,沒有一種很好的差異計算方法、和差異結果視覺化方法。

閱讀器螢幕截圖,位圖格式,借助各種成熟的數字影象處理演算法,容易計算差異

考慮到 2 容易計算差異,視覺化輸出效果較好,我們選取閱讀器螢幕截圖作為資料表示。

選擇了影象作為排版結果的資料表示,那麼如何對比影象差異呢?

首先,我們要選取影象特徵,然後才能對比差異。影象的特徵,從視覺認知概念上,有低、中、高階特徵:

有了特徵後,我們需要定義差異,就是兩個灰度影象矩陣的距離函式,如:

我們關心有多少畫素點不一致,所以我們這裡取 l0距離,即兩個影象有多少個畫素點不一樣,作為差異衡量的指標。

當距離大於10時,我們認為這一頁的排版結果有差異,把它視覺化輸出,給開發或者測試同學作為參考。

檢測到差異後,我們把兩個影象矩陣灰度化後相減,得到乙個新的矩陣,把它歸一化得到差異影象,如右圖所示:

但是考慮到 automation 模擬翻頁、截圖速度慢,且 ui 變更頻繁導致 automation 指令碼後續維護麻煩等問題,所以我們通過提供乙個測試 scheme 介面來完成這個任務。

scheme 格式如下:

weread://typeset?books=三體,賈伯斯傳,失控,1984,烏蘭拖拉機簡史&indent=1&fontsize=2&font=2&theme=3&folder=f1223

輸出排版結果到目錄/libary/[vid]/[folder]/[bookid].zip

@param books 需要排版的書單

@param indent 0首行不縮排 1首行縮排,預設0

@param fontsize 1,2,3,4,5,6,7 字型大小,預設4

@param font 字型 1系統字型 2

34 為對應選項字型,預設1

@param bgcolor 背景顏色 1白 2黃 3綠色 4夜間,預設1

@param folder 輸出資料夾名,預設"cropimage"

通過這個 scheme,在真機或者模擬器都可以隨時得到排版結果,而且速度比模擬翻頁要快10x。

下面,將介紹我們完整的排版引擎自動化測試流程。

首先,使用者需要確定引數:待生成排版結果的 svn 版本範圍 r1~rn、書單、閱讀偏好設定(字型、縮排、主題模式)。把這些引數傳給指令碼batch_scan.py,然後自動化流程開始,指令碼會執行以下步驟:

在指定 svn 版本範圍內,找出排版引擎有變更的版本,checkout

對每個 checkout 的版本,用 xcodebuild 編譯專案,安裝到模擬器

把結果從模擬器移動到指定的目錄下

得到排版結果後,執行指令碼batch_diff.py,對相近的版本,每本書的每一頁通過 diffimg.py 對比,如果有差異,則輸出視覺化的差異結果。

自動化流程結束後,我們得到排版結果差異,需要人工去檢查差異是否符合預期。

我們以資料夾的形式組織展示差異的視覺化結果:版本 r1(修改前)與 r2(修改後),對書籍 book1 排版差異視覺化結果,儲存在資料夾 diff_result_r1_r2/book1 中。

視覺化結果影象中,深色字型是 r1 (修改前)的排版結果,淺色字型是 r2 (修改後)的排版結果。

另外,排版效能變化也納入了監控。

自動化流程的建立,使排版引擎的測試時間縮短了 95%,測試期間無需人工干預,對比資料如圖:

例如,人工測試一本 550頁的 《哈利波特與被詛咒的孩子》需要約 20 分鐘,而自動化測試指令碼掃瞄、對比差異只需 22 秒(不含編譯時間);人工測試 10 本書籍,用時約 3 小時,而自動化測試用時約 4.9 分鐘;人工測試 100 本書籍需 33 小時,而自動化測試用時約 50 分鐘。

除了大大減少人工測試的時間,開發同學借助自動化測試工具,能大膽重構**,通過自動化測試來確保重構不影響排版結果,擁抱快速變更的需求。

隨著自動化測試覆蓋的變更版本、測試的書籍數量越來越多,帶來的收益越大。

目前,自動化測試工具已經投入使用。未來會持續優化、增加特性,以滿足測試、開發同學的需求。

未來工作包括但不限於:

郵件通知:執行指令碼得到結果後,如果兩個版本之間的排版結果有差異,通過郵件通知相關同學;另外,排版的效能對比結果也可以生成乙份報告,通過郵件通報。

執行速度優化:目前對 20 本書生成排版結果,耗時約 10 分鐘,對比耗時約 2 分鐘。可以進一步優化執行速度,爭取覆蓋更多樣本書籍

嘗試應用在其他模組:對執行預期結果相對固定、測試代價大的功能模組,可以通過支援測試 scheme,輸出執行結果截圖,以外掛程式的形式接入這一套自動化測試流程。

然後本文分析了人工測試的流程,以及這些流程改造成自動化的可能性。

微信讀書排版引擎自動化測試方案

為了獲得極致的閱讀體驗,產品同學經常會提出細緻的排版需求,交給開發同學修改。而排版引擎的修改,往往牽一發動全身,可能導致書城上萬本書籍排版結果受影響。舉個例子,有個需求是增加正文段落的 margin 再舉個極端的例子,有個需求要把章節標題往右移動1個畫素 當開發按需求修改排版引擎 自測後,會把 提交...

《自動化測試方案書》方案書目錄排版

qq 585499566 背景 因為工作需要,測試經理 測試組長的職位會需要做 自動化測試方案書 使用人群 測試組長 測試經理 自動化測試小白 收穫 對於自動化測試平台的搭建具有巨集觀的認識 能夠部署多種自動化測試工具 自動化測試包含 api介面 pc端ui android端ui ios端ui 一 ...

微信小程式自動化測試

缺點 元素定位符不夠精確,content desc resource id 多數都沒有 各版本情況 7.x改版後預設已經無法使用基於 webview 的自動化 檔案傳輸助手傳送 debugtbs.qq.com或者debugx5.qq.com 注意事項 webview 開關 x5核心除錯開關 x5核心...