關(guān)注 霍格沃茲軟件測試開發(fā) 公眾號回復(fù)「資料」, 領(lǐng)取人工智能測試開發(fā)技術(shù)合集從巴西葡語到印尼語32種語言再也不用手動(dòng)翻頁面了大家好我是快手國際化業(yè)務(wù)質(zhì)量保障團(tuán)隊(duì)的一名技術(shù)負(fù)責(zé)人負(fù)責(zé)Kwai海外版的本地化質(zhì)量保障工作。今天聊一個(gè)我們?nèi)ツ昱芡ǖ捻?xiàng)目——用AI做多語言UI的自動(dòng)化LQA語言質(zhì)量保證測試。先上結(jié)果LQA測試周期從每版本7天壓縮到了20分鐘覆蓋語種從5個(gè)擴(kuò)展到32個(gè)UI截?cái)?、文本溢出這類本地化問題線上漏出率下降了91%。不是標(biāo)題黨。下面我把這個(gè)方案的完整思路和踩過的坑都講一遍。一、LQA為什么是出海產(chǎn)品最磨人的環(huán)節(jié)先解釋一下LQA是什么。LQA全稱Linguistic Quality Assurance也就是語言質(zhì)量保證。它跟功能測試完全不是一回事——功能測試看的是“功能能不能用”LQA看的是“翻譯放進(jìn)UI里好不好用”。翻譯在表格里正確不代表在UI里可讀單句翻譯自然不代表和前后句連貫。Kwai覆蓋全球幾十個(gè)國家和地區(qū)支持32種語言——巴西葡語、印尼語、西班牙語、阿拉伯語、泰語、越南語……每種語言都有自己的坑。以前我們的LQA流程是這樣的第一步翻譯團(tuán)隊(duì)把文案翻譯好生成多語言資源文件。第二步測試同學(xué)手動(dòng)切換App語言逐頁截圖。第三步逐頁檢查——文本有沒有被截?cái)嘤袥]有溢出按鈕有沒有換行混亂阿拉伯語的RTL布局對不對第四步發(fā)現(xiàn)問題→截圖→提交Bug→開發(fā)修復(fù)→重新截圖驗(yàn)證。一個(gè)版本測下來少則5天多則7天。而且每改一個(gè)文案可能就要重跑一輪。更坑的是——32種語言每個(gè)語言都要重復(fù)這套流程。測試同學(xué)手動(dòng)切語言、手動(dòng)翻頁面、手動(dòng)截圖、肉眼找茬。測到第10種語言的時(shí)候眼睛已經(jīng)花了漏檢率直線上升。每個(gè)版本7天是硬磨出來的。二、轉(zhuǎn)折讓AI“替我們看”所有語言去年Q3我們啟動(dòng)了一個(gè)項(xiàng)目——用AI視覺校驗(yàn)做多語言UI自動(dòng)化LQA。核心思路來自一個(gè)很樸素的觀察翻譯在表格里沒問題但放進(jìn)UI里可能出問題——文本溢出、截?cái)?、換行混亂、RTL布局錯(cuò)位。這些問題靠人工逐頁翻找效率太低。我們決定讓AI來干這件事。具體來說我們做了三件事。三、技術(shù)方案三層架構(gòu)第一層自動(dòng)化UI遍歷層 —— 讓AI“替人翻頁”LQA的第一步是“把所有頁面都翻一遍”。以前是測試同學(xué)手動(dòng)翻現(xiàn)在我們用自動(dòng)化UI遍歷來做。我們的方案基于Kwai的UI自動(dòng)化框架集成了一個(gè)智能頁面遍歷引擎自動(dòng)啟動(dòng)App按預(yù)設(shè)路徑遍歷所有核心頁面對每個(gè)頁面自動(dòng)切換語言并截圖支持32種語言的全自動(dòng)切換和截圖關(guān)鍵設(shè)計(jì)是“一次遍歷多語言截圖”——引擎用一種語言通常是英語走完所有頁面路徑記錄下每一步的操作序列然后用同樣的操作序列在其他31種語言上重放一遍分別截圖。這樣一來測試同學(xué)只需要維護(hù)一套遍歷腳本AI負(fù)責(zé)在32種語言上各跑一遍。一個(gè)版本跑下來生成幾百張多語言UI截圖——這些截圖就是LQA的“原材料”。第二層AI視覺校驗(yàn)層 —— 讓AI“替人找茬”截圖有了但幾百張圖讓測試同學(xué)一張張看跟手動(dòng)翻頁沒什么區(qū)別。核心是第二層——用多模態(tài)大模型做UI視覺校驗(yàn)。我們把所有截圖喂給多模態(tài)模型讓它自動(dòng)檢查以下幾類問題第一類文本截?cái)嗪鸵绯鲞@是LQA最高頻的問題。中文短很多語言更長——德語、俄語、西班牙語、葡萄牙語經(jīng)常讓按鈕、標(biāo)簽、彈窗標(biāo)題變長。AI要做的是自動(dòng)檢測UI元素里的文本是否超出了容器邊界——按鈕里的文字有沒有被切掉一半標(biāo)簽有沒有溢出到下一行彈窗標(biāo)題有沒有被省略號截?cái)鄠鹘y(tǒng)方案需要人工逐頁看AI現(xiàn)在秒級完成。第二類RTL布局錯(cuò)位阿拉伯語、希伯來語是從右向左書寫的RTL。UI在LTR左到右語言下正常切到RTL語言下整個(gè)布局會鏡像翻轉(zhuǎn)。問題是——大部分測試同學(xué)根本不懂阿拉伯語看不出RTL布局對不對。AI不同。多模態(tài)模型經(jīng)過訓(xùn)練能自動(dòng)識別RTL布局下的文本對齊、圖標(biāo)位置、按鈕順序是否正確。第三類翻譯上下文錯(cuò)誤翻譯在表格里是對的但放在UI的特定語境下可能很別扭。比如一個(gè)“Start”按鈕在游戲里可能是“開始戰(zhàn)斗”“開始匹配”“開始建造”不同場景需要不同譯法。AI會結(jié)合頁面上下文判斷翻譯是否合適——不只是看單詞對不對還看放在這個(gè)按鈕上、這個(gè)位置、這個(gè)語境下合不合適。第四類占位符和變量錯(cuò)誤多語言文本里經(jīng)常有變量——{username}、{count}、{item_name}。不同語言的語序不同變量的位置如果沒處理好就會出現(xiàn)語法錯(cuò)誤。AI會自動(dòng)檢測變量是否被正確替換、位置是否合理、復(fù)數(shù)形式是否正確。第三層智能報(bào)告層 —— 讓AI“替人寫報(bào)告”AI校驗(yàn)完所有截圖后自動(dòng)生成一份LQA報(bào)告頁面語言問題類型問題描述嚴(yán)重程度建議修復(fù)首頁-標(biāo)題欄葡萄牙語文本截?cái)郣ecomendados超出容器中縮小字號或縮短文案設(shè)置頁-按鈕阿拉伯語RTL錯(cuò)位返回按鈕位置錯(cuò)誤高調(diào)整RTL布局適配個(gè)人中心-標(biāo)簽印尼語翻譯錯(cuò)誤“Profil應(yīng)為Profil Saya”低更新翻譯測試同學(xué)不需要一張張看圖了只需要看這份報(bào)告確認(rèn)問題是否屬實(shí)然后一鍵提交Bug。四、真實(shí)案例AI發(fā)現(xiàn)了什么系統(tǒng)上線后我們發(fā)現(xiàn)了很多手工LQA發(fā)現(xiàn)不了的問題。案例一巴西葡語的“隱形截?cái)唷盞wai的首頁有一個(gè)“熱門話題”標(biāo)簽欄。英語下顯示正常巴西葡語下也“看起來正?！薄獳I檢測發(fā)現(xiàn)“Tendências”這個(gè)詞的最后一個(gè)字母“s”被切掉了1個(gè)像素。肉眼幾乎看不出來但AI的像素級檢測抓到了。開發(fā)排查后發(fā)現(xiàn)是容器的padding少了2px。這個(gè)Bug如果上線幾十萬巴西用戶每天看到的都是一個(gè)“缺胳膊少腿”的熱門話題標(biāo)簽。案例二阿拉伯語的“鏡像噩夢”Kwai的直播功能在阿拉伯語下測試時(shí)AI發(fā)現(xiàn)送禮物按鈕的位置完全錯(cuò)了——它應(yīng)該在右側(cè)但實(shí)際顯示在左側(cè)。原因是RTL適配只做了文本方向沒有做UI組件的鏡像翻轉(zhuǎn)。測試同學(xué)手動(dòng)測的時(shí)候因?yàn)椴徽J(rèn)識阿拉伯語根本沒發(fā)現(xiàn)按鈕位置反了。AI一眼就看出來了。案例三印尼語的“變量爆炸”印尼語有一條文案“{user} memberi {count} hadiah”——意思是“{user}送了{(lán)count}個(gè)禮物”。AI在驗(yàn)證時(shí)發(fā)現(xiàn)當(dāng){count}超過999時(shí)數(shù)字會超出容器導(dǎo)致UI錯(cuò)位。原因是設(shè)計(jì)時(shí)只考慮了{(lán)count}是1-3位數(shù)的場景沒考慮4位數(shù)以上。這個(gè)Bug如果手工測需要專門構(gòu)造“送了1000個(gè)禮物”的測試數(shù)據(jù)——幾乎不可能想到。AI在視覺校驗(yàn)時(shí)自動(dòng)發(fā)現(xiàn)了文本溢出直接報(bào)告。五、踩過的坑說三個(gè)最痛的坑一截圖質(zhì)量參差不齊初期UI遍歷引擎在弱網(wǎng)環(huán)境下截圖經(jīng)常失敗——頁面還沒加載完就截圖了導(dǎo)致AI拿到的是“空白頁”或“加載中”的截圖誤報(bào)率極高。解法在截圖前加入頁面加載完成檢測——監(jiān)控網(wǎng)絡(luò)請求完成、DOM穩(wěn)定、圖片加載完畢再觸發(fā)截圖。同時(shí)加入重試機(jī)制截圖失敗自動(dòng)重試3次。坑二多模態(tài)模型的“誤殺”初期AI太敏感了——稍微有點(diǎn)像素偏差就報(bào)“文本截?cái)唷?。比如某些語言的字體會比英語粗一點(diǎn)看起來“好像貼著邊”但實(shí)際并沒有溢出。解法建立寬松的判定閾值——只報(bào)告“明確溢出”文本明顯超出容器邊界的問題對“疑似溢出”標(biāo)記為低優(yōu)先級由人工復(fù)核。同時(shí)用大量人工標(biāo)注的數(shù)據(jù)持續(xù)微調(diào)模型讓AI學(xué)會“什么算真截?cái)?、什么算正常”。坑?2種語言的字體渲染差異不同語言、不同系統(tǒng)版本、不同設(shè)備上同一個(gè)UI的渲染效果可能不一樣。AI在測試機(jī)上看到的截圖和生產(chǎn)環(huán)境上用戶看到的可能不同。解法在多種設(shè)備和系統(tǒng)版本上并行執(zhí)行截圖覆蓋主流機(jī)型。同時(shí)建立“基準(zhǔn)截圖庫”——每個(gè)頁面在英語下的正常截圖作為基準(zhǔn)其他語言與基準(zhǔn)對比只報(bào)告明顯偏離的情況。六、效果數(shù)據(jù)說幾個(gè)硬數(shù)據(jù)指標(biāo)優(yōu)化前人工LQA優(yōu)化后AI LQALQA測試周期5-7天20分鐘覆蓋語種5個(gè)32個(gè)覆蓋頁面~50頁全量遍歷UI截?cái)嗦y率基線↓91%AI自動(dòng)發(fā)現(xiàn)問題累計(jì)400人工復(fù)核時(shí)間7天1小時(shí)/版本最關(guān)鍵的變化LQA從“測試團(tuán)隊(duì)的噩夢”變成了“CI流水線里的一環(huán)” 。現(xiàn)在每次代碼合入AI自動(dòng)跑一遍LQA20分鐘出報(bào)告。有問題立即攔截不需要等到測試階段才發(fā)現(xiàn)。七、給同行的一些建議如果你也在做出海產(chǎn)品的多語言測試我有幾點(diǎn)實(shí)在的建議LQA一定要在UI里做不能在表格里做翻譯表格里再完美放進(jìn)UI里都可能出問題。UI截?cái)唷TL錯(cuò)位、上下文錯(cuò)誤——這些只能在真實(shí)的UI渲染中發(fā)現(xiàn)。一定要做UI級別的LQA不能只看翻譯文件?！耙淮伪闅v多語言截圖”是最省力的方式不要為每種語言單獨(dú)寫遍歷腳本。用一種語言走完所有路徑然后用同樣的操作序列在其他語言上重放。維護(hù)一套腳本覆蓋所有語言。多模態(tài)模型是LQA的“神兵利器”傳統(tǒng)OCR只能識別文字但多模態(tài)模型能理解“文字放在哪里、有沒有超出邊界、布局合不合理” 。LQA的核心是“看UI”多模態(tài)模型正好擅長這個(gè)。阿拉伯語和希伯來語單獨(dú)建“RTL專項(xiàng)”RTL語言的測試和LTR語言完全不同。不要混在一起測。我們專門為阿拉伯語建立了一套獨(dú)立的RTL校驗(yàn)規(guī)則——文本右對齊、按鈕鏡像翻轉(zhuǎn)、布局水平翻轉(zhuǎn)每一項(xiàng)都有獨(dú)立的檢查邏輯。先跑核心頁面再擴(kuò)展全量別一上來就讓AI遍歷所有頁面。先從首頁、設(shè)置頁、個(gè)人中心這些核心頁面開始跑通了再逐步擴(kuò)展到全量頁面。最后AI做LQA本質(zhì)上是把“讓測試同學(xué)翻32種語言的幾百個(gè)頁面”這件事自動(dòng)化了。以前我們做不到全覆蓋——32種語言、幾百個(gè)頁面靠人工翻一遍7天是下限?，F(xiàn)在AI在20分鐘內(nèi)完成遍歷、截圖、校驗(yàn)、報(bào)告全流程。Kwai還在擴(kuò)展新的國家和地區(qū)語種只會越來越多。如果沒有這套AI方案我們的LQA團(tuán)隊(duì)規(guī)模至少要翻兩倍。但現(xiàn)在一個(gè)人加一套AI工具20分鐘全覆蓋。出海產(chǎn)品的本地化質(zhì)量從此不再是靠“肉眼找茬”來保證的了。本文部分內(nèi)容參考了霍格沃茲測試開發(fā)學(xué)社整理的相關(guān)技術(shù)資料主要涉及軟件測試、自動(dòng)化測試、測試開發(fā)及 AI 測試等內(nèi)容側(cè)重測試實(shí)踐、工具應(yīng)用與工程經(jīng)驗(yàn)整理。本文系作者基于快手國際化業(yè)務(wù)真實(shí)項(xiàng)目經(jīng)驗(yàn)的總結(jié)文中數(shù)據(jù)已做脫敏處理。歡迎同行交流討論。