使用螢幕截圖來顯示全螢幕外觀，使用 OCR 來顯示可見文本，使用圖像匹配來顯示已知的視覺目標。最強大的 Android 視覺測試將一項集中的斷言與穩定的計時和失敗證據結合在一起。
簡短的答案：測驗必須保持真實的事情
當整個螢幕、組件、間距、顏色或排版必須保持視覺一致時，請使用螢幕截圖測試。當要求涉及人們可以看到的單字時，尤其是本地化或動態呈現的文本，請使用 OCR。當已知的圖示、按鈕、徽章或插圖必須出現時，即使沒有可靠的 UI 標識符，也可以使用圖像匹配。
當需求是語意時，從 UI 選擇器或輔助功能狀態開始：控制項存在、已啟用、已選擇或公開穩定標籤。僅當目標屬於視覺類別並且可能對一個模板的大小或位置更改過多時才添加物件檢測。這些方法是層，而不是競爭的測試框架。
- 詢問什麼證據可以讓審閱者相信該要求已通過。
- 選擇最窄的可靠訊號，而不是預設比較每個像素。
- 在觀察之前穩定螢幕，然後在斷言失敗時儲存工件。
Android視覺測試方法比較
| 方法 | 最適合 | 主要弱點 | 有用的證據 |
|---|---|---|---|
| UI 或輔助使用狀態 | 控制項、標籤、啟用狀態、選擇、導航結構 | 自訂渲染或不可存取的元素可能對 UI 樹不可見 | UI 層次結構、選定的屬性、螢幕截圖 |
| 螢幕截圖或黃金圖像 | 版面、間距、顏色、排版、組件外觀 | 動態資料、動畫、裝置差異和渲染變更可能會產生雜訊的差異 | 目前影像、核准的基線、視覺差異 |
| 光學字元辨識 | 可見文字、本地化、收據、狀態訊息、呈現為像素的值 | 辨識品質取決於裁剪、比例、對比、語言資料、旋轉和分割 | 來源作物、識別的文字、置信度或結果列表 |
| 模板匹配 | 已知的圖示、按鈕、徽章、縮圖或小的穩定區域 | 主題、規模、壓縮和重新設計可能會使模板失效 | 模板、搜尋區域、最佳匹配、得分、螢幕截圖 |
| 物體偵測 | 當位置或大小改變時，其類別保持有意義的視覺對象 | 需要相容的模型、標記的類別、閾值和模型驗證 | 模型版本、类别、方框、分数、截图 |
Android 的官方螢幕截圖測試指南描述了將目前渲染與核准的參考影像進行比較。 Appium 的圖像外掛程式公開了特徵匹配、模板匹配和相似度比較。 OpenCV 記錄了在影像上滑動模板的機制，而 Tesseract 記錄了 OCR 預處理和頁面分割的重要性。工具不同，但測試設計問題保持不變：什麼觀察證明了這個要求？
透過四個問題來選擇正確的斷言
1. 需求是語意的還是視覺的？
如果測試顯示“提交按鈕已啟用”，請先檢查 UI 狀態。如果顯示“字體變更後提交按鈕未被裁剪”，請使用螢幕截圖或重點目視檢查。語義查詢通常更容易維護，但它不能證明外觀。
2. 確切的文字重要嗎？
當需要面向使用者的字串且文字無法透過 UI 樹可靠地公開時，請使用 OCR。將識別限制在最小的有意義區域，選擇正確的語言，然後比較標準化結果。保留螢幕截圖，因為單獨正確的 OCR 字串無法顯示截斷、重疊或對比度差。
3.是否有穩定的視覺目標？
對已知圖示或小控制項使用範本匹配。緊密裁剪模板，在感興趣的區域內搜索，並根據真實的正樣本和負樣本設定閾值。一個通用的閾值很難在不同的主題、解析度和壓縮的遠端流中站穩腳跟。
4. 整個構圖必須保持一致嗎？
當許多元素之間的關係很重要時，請使用螢幕截圖比較。控製字體、區域設定、裝置配置、系統列、時間、網路資料、動畫和種子內容。如果無法控制這些輸入，請封鎖或裁切動態區域，而不是接受永久的雜訊測試。
建構一個有效失敗的視覺測試
- 在授權設備或模擬器上將應用程式置於指定的啟動狀態。
- 等待穩定的情況，而不僅僅是固定的延遲。 UI Automator 提供穩定的等待，並且特定於應用程式的就緒訊號甚至更好。
- 捕獲包含所需證據的最小源區域。
- 執行一項主要斷言：UI 狀態、OCR、範本、偵測或螢幕截圖比較。
- 在採取下一步操作之前保存來源影像和結構化結果。
- 發生故障時，停止或遵循經過審查的恢復路徑。不要僅僅為了讓測試繼續進行而點擊附近的相似者。
當目視檢查授權轉換時，它會變得更安全。觀察當前狀態，做出斷言，僅在成功後執行允許的操作，並驗證後置條件。這與影像辨識自動點擊指南中所述的設計原理相同：辨識並不能證明工作流程已完成。
對於真實設備工作，用於行動應用程式測試的Android 螢幕鏡像在設計測試時為審閱者提供即時視圖。Android 自動化 QA 冒煙測試指南解釋如何維持重複檢查的範圍和重複性。
三個實用的Android視覺測試場景
結帳畫面上的在地化品質檢查
使用 UI 狀態導航到結帳螢幕，使用 OCR 確認本地化的總和和操作標籤，並使用聚焦螢幕截圖來顯示字串沒有被剪切或重疊。使用受控測試資料運行每個語言環境。單獨的全螢幕像素比較對於翻譯後的字串長度過於敏感，而單獨的 OCR 會錯過佈局損壞。
檢查重新設計的工具列圖標
在小工具列區域中使用接受圖示的範本。同時支援淺色和深色主題時，保留單獨的模板。當匹配失敗時，附上工具列裁剪和最佳候選得分。如果故意重新設計圖標，請檢查並替換模板，而不是降低閾值，直到任何形狀通過。
部署後的真實手機冒煙測試
從已知的帳戶和應用程式狀態開始，等待登陸螢幕，斷言其身份，執行一項允許的操作，並驗證下一個指定狀態。每次失敗時捕獲螢幕截圖。設備密度、權限對話框、鍵盤、通知和系統更新是真實手機環境的一部分，因此測試應該報告它們而不是隱藏它們。
常見誤報故障及預防方法
| 症狀 | 可能的原因 | 更好的反應 |
|---|---|---|
| 螢幕截圖差異每次運行都會改變 | 時鐘、動畫、廣告、種子資料、鍵盤、系統欄或網路內容 | 凍結輸入，等待穩定，僅裁剪或遮蓋動態區域 |
| OCR 傳回看似合理但錯誤的文本 | 錯誤的語言、低對比、微小的裁剪、旋轉、噪音或不合適的分割 | 保存作物，提高比例和對比度，精心選擇語言和分割 |
| 模板匹配僅適用於一部手機 | 不同的密度、主題、縮放、縱橫比或壓縮 | 使用感興趣的區域和經過驗證的模板來支援視覺變體 |
| 找到了正確的圖像，但點擊失敗 | 匹配座標未轉換為目前螢幕或覆蓋區塊輸入 | 將辨識與動作分開並驗證下一個狀態 |
| 測試在錯誤的螢幕上繼續 | 無後置條件或失敗邊緣 | 指定預期狀態並在目前畫面超出審查路徑時停止 |
| 物件偵測器發現錯誤的類 | 模型或標籤不適合應用程式域，閾值未驗證 | 使用相容的模型，記錄版本和評分，測試負樣本 |
關於 Android 迴歸測試的社群討論通常會回到相同的維護成本：裝置矩陣、不穩定的時序、基準審查和內容變更的畫面。這些並不是放棄視覺測驗的理由。它們是明確測試環境、可接受的變異數和故障工件的原因。
萊彩 Flow 如何適應視覺測試
萊彩 Flow是 萊彩投屏 內部的自動化功能。流程可以結合螢幕截圖擷取、UI 檢查、OCR、範本匹配、物件偵測、條件、操作以及明確的成功或失敗轉換。這使得測試人員可以將螢幕建模為一種狀態，而不是將識別視為孤立的技巧。
使用萊彩 Flow Inside，部署後可在電話上透過萊彩 Android Agent運行相容的Profile。相容性仍然取決於該設定檔使用的每個節點和資產。本地OCR使用Tesseract；模板匹配使用選定的圖像資源和可配置的分數；相容的本地檢測使用受支援的模型。網路節點或遠端模型仍然需要其自己的網路依賴性。
這並不意味著每個視覺測試都自動可靠。團隊仍然需要代表性基線、模板、OCR 區域、模型、閾值、負面案例和後置條件。價值在於可以在一個工作流程中審查這些決策和轉換。AI Android 自動化指南提供了更廣泛的創作和真實裝置執行視圖。
視覺測試失敗的最小證據包
- 測試名稱、應用程式版本、裝置型號、Android 版本、區域設定、主題和方向。
- 斷言使用的來源螢幕截圖或裁剪區域。
- 預期的基線、模板、文字、類別或 UI 屬性。
- 觀察到的差異、OCR 結果、邊界框、匹配分數或 UI 值。
- 先前指定的狀態、嘗試的操作、預期的下一個狀態和停止原因。
- 資產、模型或基線版本，以便審閱者可以重現決策。
沒有此上下文的通過/失敗標籤會迫使下一個人重現整個運行。緊湊的證據包將失敗轉變為可審查的決策：修復產品、穩定測試、更新已批准的視覺資產或拒絕不受支援的設備配置。
Android 視覺測試常見問題解答
每個 Android UI 測試都應該包含螢幕截圖嗎？
不可以。當外觀很重要或故障工件對審閱者有幫助時，請使用螢幕截圖。語意斷言通常更適合 UI 樹可靠公開的行為。
OCR 比影像匹配更好嗎？
OCR 回答有關可見文字的問題。影像匹配回答有關已知視覺模式的問題。如果要求包含標籤及其外觀，請使用 OCR 加上重點螢幕截圖或範本檢查。
截圖測試可以在真實的 Android 手機上運行嗎？
是的，但真實設備比受控的主機端渲染器或模擬器引入更多變化。記錄設備配置，穩定係統 UI 和數據，並設定對您實際支援的設備矩陣的期望。
我什麼時候應該使用對象檢測？
當有意義的物件類別移動或縮放超出穩定模板的容差時，並且僅當相容模型已在應用程式的真實影像上得到驗證時，才使用它。不要因為聽起來更先進就添加檢測器。
選擇技術前先選擇證據
可靠的 Android 視覺測試始於一句話：審核者必須能夠證明什麼？選擇用於語義的 UI 狀態、用於合成的螢幕截圖、用於文字的 OCR、用於已知視覺目標的模板匹配以及用於具有可變幾何形狀的經過驗證的類別的物件檢測。
然後使觀察成為狀態轉換的一部分：穩定、捕獲、斷言、僅在成功後採取行動、驗證後置條件並保留失敗證據。這種設計比一組斷開連接的視覺呼叫更容易理解，並且在應用程式或裝置發生變化時更容易維護。