AI Android 自動化用於 App 在地化測試：QA 實戰指南

構建一個Android應用程式本地化測試工作流程，該工作流程結合了假地點、真實語言檢查、RTL審查、OCR、螢幕截圖和人工判斷，而不會將每個測試乘以每個地點。

簡短的答案：自動化路線，審查語言

可靠的安卓應用程式本地化測試工作流程將可重複的裝置工作與語言判斷分開。自動化語言設定、應用程式啟動、導航、等待、螢幕截圖、已知狀態檢查和證據收集。在人類審查下保持翻譯品質、語氣、文化含義、模棱兩可的剪輯和視覺平衡。目標不是在每種語言中執行每項測試。而是建立一個小型、基於風險的矩陣，揭示最有可能影響使用者的故障。

這很重要，因為本地化缺陷不僅僅是錯誤的單詞。它們包括硬碼字串、缺少的資源、文字擴充套件、左右對齊佈局錯誤、日期或貨幣不正確、鍵盤不匹配、無法讀取的字型、剪切按鈕和不持久的語言設定。 一AI Android自動化工具可以幫助重複可見的路線並收集證據，但它無法決定一句話是否聽起來對當地客戶來說聽起來很自然。

下面的工作流程將安卓的官方本地化功能與可觀察的裝置檢查相結合。它並不聲稱萊彩 Flow取代單元測試、構建測試、Espresso、UI Automator、Appium、一個翻譯管理系統或原生語言審查。使用每個層面來產生最佳證據。

從本地化釋出矩陣開始，而不是語言列表

支援的語言列表不是一個測試計劃。釋出矩陣將本地化與螢幕、裝置狀態、資料格式、寫作方向和使該本地化具有意義的業務風險聯絡起來。沒有這種聯絡，團隊通常會以多種語言開啟主螢幕，截圖，然後錯過結賬、搜尋、帳戶恢復、通知或設定中的失敗。

在每個版本中，選擇一個基線語言區域、一個擴充套件量大的語言區域、一個緊湊或複雜指令碼語言區域和一個RTL語言區域。僅將市場特定語言區域新增到承擔重大業務風險的流程中。Firebase Test Lab的Android矩陣同樣地，將本地化與裝置型號、Android版本和方向一起視為一個維度；即使在您對自己的裝置進行檢查時，這也是一個有用的規劃模型。

在翻譯到達之前使用Android假地點

假位置是工作流程中最便宜的早期預警系統。Android的偽地點指南描述`en-XA`，它擴充套件和強調英語文字，以及`ar-XB`，它行使從右向左的行為。它們可以暴露硬寫入字串、斷裂的字串拼接、佈局壓力、雙向文字問題以及在翻譯器交付最終副本之前未能映象的元素。

• 執行主要使用者旅程`en-XA`並記錄每個仍然是普通英語的字串；它可能是硬寫入或位於本地化資源路徑之外。
• 重複同樣的旅程`ar-XB`並檢查導航順序、後退箭頭、標籤、進度指示器、混合數字和標點符號。
• 捕獲錯誤、空格、許可權、升級和確認狀態；它們在普通的順利路徑審查中不太明顯。
• 將假位置故障視為可定位性缺陷，而不是證明特定真實翻譯是錯誤的。

開發人員還可以更早地檢查所選螢幕。Android的本地化文件和構建預覽工具支援特定地區的預覽，包括RTL示例。這些相鄰程式檢查速度快，應該在完整的裝置工作流程之前捕捉到元件級別的問題。

測試使用者實際走的路徑

如果使用者無法選擇、保留或重置語言，翻譯的螢幕是不夠的。Android的每個應用程式語言指南解釋說，Android 13及更高版本為應用程式的首選語言提供了一個集中式的系統設定，而AndroidX則在舊版本上支援相容的應用程式本地化處理。應用程式還可能具有自己的語言選擇器。每個支援的條目路徑都需要進行一個小的狀態轉換測試。

1. 從一個已命名的清潔狀態開始：全新安裝、升級安裝、已登入帳戶或恢復備份。
2. 透過預期的系統或應用程式內路徑選擇地區，並確認應用程式是否重新啟動、重新建立活動或原地更新。
3. 導航離開設定，並確認目標語言環境出現在業務關鍵螢幕上。
4. 關閉並重新開啟應用程式，然後驗證偏好設定是否保持。
5. 重置為系統預設值，並確認不會保留過時的翻譯資源。
6. 在舊版本的Android上，請測試實際的相容路徑，而不是假設Android 13的行為。

裝置語言和鍵盤語言是獨立的問題。BrowserStack的本地化測試文件請注意，在Android裝置上更改語言並不一定會更改鍵盤語言。在矩陣中保留這種區別，以免文字輸入失敗被誤診為資源故障。

按風險選擇代表性螢幕

不要將每個現有的端到端測試乘以每個本地化。選擇更改本地化行為、佈局、信任或金錢的螢幕。一個緊湊的套件通常包括入職、登入、主頁導航、搜尋、一個詳細頁面、一個表格、一個付款或確認表面、設定、通知和最重要的錯誤狀態。

優先考慮具有固定寬度的控件、相鄰圖示、多個變數、複數規則、動態伺服器文字、緊湊卡片、底部導航和翻譯文字，而不是圖片。包括一個具有最大現實內容的螢幕，而不僅僅是空的演示資料。如果您的應用程式支援平板電腦、可摺疊裝置或橫向模式，請僅在佈局真正發生變化的地方新增它們。

為每個選定的螢幕分配一個所有者和一個原因。例如，結賬確認頁面存在於驗證貨幣、行疊、按鈕標籤和法律副本；帳戶恢復螢幕存在於驗證輸入方法、錯誤訊息和雙向電子郵件地址。這使得失敗成為可操作的，而不是產生一個包含無法解釋的螢幕截圖的資料夾。

將證據方法與定位缺陷相匹配

沒有單一的定位器或影象技術可以證明定位品質。選擇可以支援決定的最小觀察結果。現有的Android視覺測試指南解釋了使用者介面狀態、OCR、影象匹配、物體檢測和螢幕截圖之間的更廣泛差異；本地化QA將這些方法應用於特定語言的風險。

在當前的萊彩 Flow合同，OCR返回一個結果集，而不是一個神奇的答案。流程必須在比較文字或位置之前選擇相關段落。同樣，視覺匹配報告已知狀態；它不應被擴充套件為每個畫素或句子都是正確的的主張。

在真實的安卓裝置上構建可觀察的本地化流程

當團隊需要在真實的安卓裝置上重複相同的導航，並向審查員提供一致的證據時，可觀察到的視覺工作流程很有用。萊彩 Flow是內部的一個自動化功能萊彩投屏。它可以組織可見的步驟，如等待、使用者介面狀態檢查、OCR、模板匹配、螢幕截圖、條件、受限迴圈和明確停止。 這萊彩 Flow指南涵蓋產品工作流程。

1. 命名構建、裝置、Android版本、地區、主題、字型比例和初始帳戶狀態。
2. 開啟應用程式或設定路徑，在螢幕依賴的觀察之前使用明確的等待。
3. 一次性瀏覽一個使用者級別的階段，當旅程變得複雜時，將技術查詢詳細資訊保留在可讀的子流程中。
4. 在每次破壞性或狀態更改操作之前，請檢查螢幕的穩定性。
5. 捕獲所需的螢幕截圖和任何帶有本地化和螢幕識別符號的已選擇的OCR結果。
6. 在導航後驗證後條件，而不是假設點選成功。
7. 當螢幕未知時，請停止提供證據；不要繼續點選意外的語言或對話方塊。

此層與基於程式的測試相輔相成。元件和儀器測試仍然應該擁有資源查詢、狀態邏輯、可訪問性語義和接近應用程式的確定性斷言。當支援、本地化或釋出審查員需要可重複的路徑和可人為閱讀的證據資料包時，可見的流程最強。 這Android QA煙霧測試工作流程提供一個相關的通用模式。

給RTL和雙向內容頒發自己的測試通過證書

RTL不是在LTR螢幕截圖清單的末尾新增的專案。使用阿拉伯語或其他支援的RTL本地化執行專門的過濾器，並包含混合方向內容，如電子郵件地址、電話號碼、價格、版本字串、URL、程式和拉丁品牌名稱。這些組合會揭示完全翻譯的段落可能不會顯示的標點符號和排序失敗。

• 確認導航、抽屜、標籤、進度方向和方向圖示只有在它們的意義應該反映時才會反映。
• 檢查數字、單位、產品名稱和輸入游標在RTL句中是否仍然可讀。
• 檢查空狀態、對話方塊、小吃欄、許可權說明和表單驗證訊息中的對齊。
• 測試滑動和後退導航是根據行為進行的，而不是假設每個手勢都會隨著文字方向相反。
• 使用母語評論員來檢查標點符號、語法、行尾空白和文化解釋。

使用`ar-XB`儘早發現結構性故障，然後在釋出前至少執行一個真正的RTL本地化。假本地化可以揭示映象缺陷，但它不能驗證生產阿拉伯文字的排版或含義。

測試格式、輸入、通知和外部表面

一些最昂貴的本地化失敗位於應用程式主螢幕之外。新增針對日期和時間、小數點分隔符、貨幣放置、地址順序、測量單位、電話號碼、複數形式、鍵盤輸入、剪貼簿行為、通知文字、深度連結、網路內容以及旅程所依賴的任何系統對話方塊的專注檢查。

記錄每個值的所在地區。應用程式語言、系統地區、帳戶國家、伺服器偏好設定、時區和鍵盤可能存在差異。顯示出令人驚訝的值的螢幕截圖是有用的證據，但錯誤報告還必須指定這些輸入，以便工程人員能夠重現不匹配的來源。

將商店列表和促銷螢幕截圖視為單獨的釋出表面。它們的文字可能來自不同的儲存庫，它們的影象可能由不同的管道生成。重複使用相同的螢幕庫存和命名方案，但不要僅僅因為商店描述已被翻譯而標記應用程式為本地化。

保留人工審查，因為自動化能力較弱

自動化擅長重複路線並檢測已知證據。人類仍然更擅長理解、語氣、上下文、文化契合度、視覺層次、幽默、模稜兩可以及決定斷行只是看起來不同還是實際上會損害理解力。故意建立交接，而不是將手動審查視為意外例外。

• 自動化：本地化設定、啟動、導航、等待、穩定狀態檢查、選定文字存在、螢幕截圖、檔案命名和證據打包。
• 手動審查：翻譯含義、自然性、法律細微差別、複雜指令碼的可訪問性、模稜兩可的截斷、文化形象和視覺平衡。
• 升級到程式測試：精確的資源對映、複數邏輯、確定性格式化函式和元件語義。
• 升級到裝置或框架測試：系統許可權、跨應用程式行為、鍵盤整合和生命週期過渡。

一個有用的停止規則很簡單：當可見狀態不是經批准的狀態之一時，收集證據並停止。不要讓自動化透過未知的同意螢幕、付款步驟、破壞性操作或未翻譯的系統路徑繼續執行。 這安卓自動化測試工具比較可以幫助將每個斷言分配到正確的層。

建立一個證據包，供釋出團隊採取行動

沒有上下文的通過/不及格儀表板會產生另一個調查。每個本地化發現都應確定構建、應用程式包和版本、語言和地區、Android版本、裝置和解析度、字型比例、主題、初始狀態、螢幕名稱、預期結果、實際結果以及支援該主張的螢幕截圖或選定的觀察結果。

使用穩定的檔名，例如`build-locale-device-screen-state.png`，然後保留一個對檔案進行對映到測試矩陣的明細單。將預期的視覺變化與缺陷分開：不同的行尾可能可以接受，而隱藏的價格、無法到達的按鈕、倒轉的品牌標記或缺失的錯誤訊息則不可接受。根據使用者影響分配嚴重程度，而不是根據畫素差異。

由於當前一代環境中沒有可用的LaiCai管理的裝置，本文描述的是基於合同的工作流程，而不是聲稱特定應用程式、裝置或地區的基準結果。在擴充套件矩陣之前，請在您的環境中執行一個代表性的試點。

Android本地化QA釋出清單

1. 定義受支援的地區列表、備用地區、語言選擇路徑和高風險市場。
2. 跑步`en-XA`和`ar-XB`在最終翻譯到達之前，在代表性螢幕上。
3. 驗證每個路徑都支援的真實應用程式、系統和應用程式內語言切換。
4. 在小螢幕上覆蓋一個包含大量擴充套件的本地化環境、一個包含複雜指令碼的本地化環境和一個RTL本地化環境。
5. 包括錯誤、空格、載入、確認、許可權、升級和通知狀態。
6. 檢查區域格式、輸入方法、字型比例、亮度/暗度主題和語言持久性。
7. 僅在他們可以支援的索賠中使用UI狀態、OCR、模板匹配、螢幕截圖和人工審查。
8. 儲存一個命名的證據資料包，並在未識別的狀態下停止。
9. 讓母語審查員批准含義、語氣、標點符號和文化合適性。
10. 將主要自動化CTA保留在本地化識別的所有者頁面上，並使用支援指南瞭解實施細節。

關於作者：BeePOS LLC開發萊彩投屏和它的萊彩 Flow自動化功能。本指南基於當前的Android文件、觀察到的本地化測試實踐和已釋出的萊彩 Flow節點合同。產品問題可以透過以下方式傳送LaiCai公司和支援頁面。

來源

• Android開發人員：使用假地點測試您的應用程式
• Android開發人員：每個應用程式語言偏好設定
• Android開發人員：本地化您的應用程式
• Android開發人員：使用可組合預覽預覽您的使用者介面
• Firebase：使用Test Lab開始測試Android
• BrowserStack：使用App Live進行本地化測試