多語言檢測工具實踐

酷家樂質量效能發表於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.郵件成品