多語言檢測工具實踐

酷家乐质量效能發表於2020-12-04

一、產生背景

眾所周知，酷家樂是國內首屈一指的大家居全案設計平臺及生態解決方案提供商，致力於為數字化升級提供一站式的解決方案，客戶多是以中文為主的公司。雖然有英文版，但是實際使用上還是會遇到很多問題：

語言問題：酷家樂以中文為主，英文版支援不夠完整，且無其他語言。
部署問題：酷家樂沒有全球部署，在海外服務的載入和訪問速度會受限制
模型問題，酷家樂的模型庫模型受眾主要是國內的，非海外本地審美。由此誕生了海外版本--coohom。目前 coohom 線上共支援 7 種語言，受眾最大的是英語客戶，並且他們也最接受不了中文的存在。coohom 的功能基本上都是從酷家樂延伸的，有些模組甚至是雙發的（酷家樂釋出新版，coohom 自動更新），這就導致酷家樂一旦新增或者修改某個功能，都有可能影響到 coohom，導致線上上出現中文。因此存在以下中文的痛點：
coohom 對接使用者線較多，雲圖，定製，硬裝，快搭等，這些細節問題採用人肉測試，效率太低，需要有自動化的檢測工具輔助測試；
工具每週釋出迴歸，週期短，迭代快，工作量大，上線時間緊，測試資源有限，一些細小的問題（如商品類目，名稱等）不會一個個去看，因此急需一種自動化工具幫助迴歸檢測；
由於 coohom 現在主要語言是英語，而且出問題比較多的是英語中混有中文，因此先檢測英文環境下是否含有中文的問題。若檢測有效，再推廣到其它語言。
coohom 目前沒有獨立的模型庫/素材庫，跟酷家樂使用一套資料，且模型以及素材都是運營手動新增，不會過多考慮多語言，因此時常有模型/素材未翻譯的問題。

二、實現方案

多語言檢測方案主要分為三個部分：爬取文案、檢測文案以及文案資訊展示。
第一步：文案爬取分為靜態網頁文案爬取和動態網頁文案爬取，靜態文案可以直接透過 html 獲取，獲取比較容易，但是動態文案就比較麻煩了，雖然在瀏覽器中可以看到，但是在 html 原始碼中卻發現不了，調研選擇了兩種方案，分別是 “使用自動化測試工具對網頁進行模擬訪問” 以及 “直接 Ajax 請求，得到返回的 json 資料”，透過分析對比，採用模擬 ajax 的方法去獲取動態文案。
第二步：由於前期只是檢測英文中是否有中文存在，所以文案檢測部分就相對簡單一點，可以透過中文的 unicode 編碼範圍進行檢測。
第三步：文案資訊展示，主要是定時檢測傳送郵件。

三、文案爬取

3.1 靜態文案爬取

前端程式碼直接展示的文案，包括滑鼠 hover 的文案、彈窗的文案、按鈕的文案可以直接透過 html 原始碼中的” window.PUB_LANG” 關鍵字獲得
以工具為例，紅框處的文案為靜態文案

可以直接透過” window.PUB_LANG” 獲取各個外掛的靜態文案，以 “yundesign_kaf_plugin” 為例，只需要看每個 key 對應的值是否為中文

實際的獲取方法如下：

3.2 動態文案獲取

目前抓取動態文案主要有三種方法：
1.使用自動化測試工具對網頁進行模擬訪問：
在抓取階段，在爬蟲中內建一個瀏覽器核心，執行 js 渲染頁面後，再抓取。常用的工具為 Selenium、HtmlUnit、PhantomJs、Puppeteer 等。如下圖所示，透過 webdriver 模擬登陸是可以拿到對應的文案的。

該方案需要知道控制元件的 xpath，模擬手工操作，由於渲染的時間無法預估，所以存在一定的效率問題，同時也不是那麼穩定。好處是編寫規則同靜態頁面一樣。該方法適用於一次性或者小規模的需求。
2.直接 Ajax 請求，得到返回的 json 資料（有些資料是加密過的，需要解密）：
因為 js 渲染頁面的資料也是從後端拿到，而且基本上都是 AJAX 獲取，所以分析 AJAX 請求，直接拿到對應的資料，也是比較可行的做法。

相對於頁面樣式，這種介面變化可能性更小。缺點就是要找出所有的介面，並進行模擬，是一個相對困難的過程，也需要相對多的分析經驗。比較適用於長期性的、大規模的需求。
模擬訪問法和 ajax 請求法各有優缺點，由於前者需要依據 xpath，根據 coohom ui 自動化的經驗，各個控制元件的 xpath 會經常變化，需要定期去維護；而且如果要爬取整個網站，如果去整理每一步的 xpath，將會是一個很龐大的工程；
模擬 ajax 請求法雖然要整理所有的介面，但是目前已有介面整理文件 (參考 cemon 巡檢)，而且介面相對於 xpath 來說，不僅數量小的多，而且變化的可能性也更小，更容易維護。
因此，本次採用模擬 ajax 的方法去獲取動態文案。
3.Ajax 請求法
現採用開源的工具包 selenium+browsermob-proxy 模擬瀏覽器訪問，來自動獲取介面資訊。
browsermob-proxy 是基於 Java 的代理服務，它的具體流程有點類似與 Fidder 或 Charles。即開啟一個埠並作為一個標準代理存在，當 HTTP 客戶端（瀏覽器等）設定了這個代理，則抓取並有能力修改所有的請求細節並獲取返回內容。呼叫方式如下

3.3 異常文案獲取

目前異常文案是根據 unicode 編碼來獲取的，目前只是考慮中文，中文的編碼範圍是 [\u4e00-\u9fa5]（不考慮中文標點之類的）
呼叫方法如下：

四、檢測方式

目前前端主要有 3 種檢測方式，分別是 URL 檢測，API 檢測以及迴歸檢測

4.1 URL 檢測

該檢測方式主要是根據輸入的 URL 爬取靜態文案，使用 Ajax 請求法爬取動態介面文案，最後根據 unicode 編碼抓取出匹配的異常文案（中文）並在前端展示。
適用範圍：coohom SAAS 後臺的所有連結，不適用於工具

4.2 API 檢測

該檢測方式主要是根據輸入的介面爬取介面返回文案，最後根據 unicode 編碼抓取出匹配的異常文案（中文）並在前端展示。
適用範圍：目前只支援 GET、POST 介面，包括 coohom SAAS 後臺以及工具
為了輔助定位問題，會把異常文案的介面，所在欄位以及一些相關的 id 屬性都會列印出來

4.3 迴歸檢測

先預置 url 以及介面資訊在資料表中，檢測時根據所選的模組分別呼叫去爬取資料檢測
saas 後臺主要是 url 資訊，檢測方式按照 4.1，其餘都是介面資訊，檢測方式按照 4.2，也可以選擇全量檢測所有，迴歸檢測時傳入的 url 和介面太多，一次性跑完需要時間較長，會導致前端超時或者一直處於 loading 狀態，顯示很不友好，現採用多執行緒 +redis 儲存機制解決。

五、資訊顯示

第 4 節中已經包含了前端頁面的展示部分，但前端頁面的展示每次都需要人為去前端操作才能獲取，想要有任務可以按時間每天自動去檢測並且傳送郵件，因此開發了定時自動檢測功能。
1.coohom saas 後臺自行維護，文案相關改動較小，屬於可控範圍
2.工具是每週整合 kujiale 的，並且運營會上新一些新的模型以及素材，會導致模型名稱以及品牌等為中文的情況
基於以上，自動檢測拿的是迴歸檢測中的工具的 api 介面的部分，檢測內容以及檢測流程在第二部分已經具體描寫了，這裡主要是定時檢測併發郵件
定時任務比較簡單，就是基於註解@Scheduled，使用 Cron 表示式來建立定時任務。
郵件內容採用以下方式：
用 freemarker 模版來確定郵件格式

具體框架圖如下：

3.郵件成品