重試無法修復錯誤的定位器 

登入測試週一通過，週二失敗，週三又通過了。登入流程沒有任何改變。改動之處在於設計團隊在登入按鈕周圍新增了一個容器，這使得按鈕在螢幕元素樹中向下移動了一層。指向該按鈕的 XPath 是基於舊佈局編寫的。根據螢幕渲染速度的不同，尋找結果有時有效，有時無效。 

這就是 Appium 測試套件中常見的不穩定表現。這並非什麼神秘現象，而是測試依賴它原本不該檢查的 UI 細節。 

片狀現象的成因不只一個。 

不穩定的測試是指在同一段程式碼上時而通過時而失敗的測試。大規模應用時，這種測試成本很高。 Atlassian 報告稱，不穩定的測試約佔其 Jira 後端程式碼庫失敗總數的 15%，導致重複運行，每年浪費超過 150,000 萬個開發人員工時；此外，不穩定的測試還導致 Jira 前端主分支構建失敗的 21%（Atlassian，2025). 

造成這些原因的原因可以分為兩類： 

• 測試所有權原因。 脆弱的定位器、用固定的睡眠取代真正的等待、分享的測試數據、順序依賴。這些問題都存在於你的程式碼中，你可以修復它們。 

• 環境因素是造成這種情況的原因。 設備斷線、後端呼叫緩慢、意外的作業系統對話框，這些都存在於你的程式碼之外。你可以減少它們的影響，但無法完全消除它們。 

區分兩者至關重要，因為修復方法不同。如果定位器有問題，重試測試只會以較慢的速度出現同樣的錯誤，更糟的是，偶爾還會出現通過的情況，從而掩蓋問題。首先要檢查你負責的部分。在行動端 UI 測試中，定位器通常是首先要檢查的地方。 

為什麼定位器在應用程式沒有崩潰的情況下也會失效 

Appium 的每個步驟都從尋找元素開始。定位器是測試用來尋找元素的位址。如果該位址描述的是螢幕結構而不是元素的標識，那麼任何佈局變更都可能導致測試失敗。 

研究人員稱之為定位器脆弱性。 2026 年的一項研究分析了 359 個開源程式碼庫，並重現了 449 個定位器故障：即 UI 的結構性變更導致測試失敗，即使應用程式仍然運作正常（ReproBreak，ASE 2026這項研究涵蓋了網頁測試框架，但其機制在行動裝置上是相同的。重新命名元素、新增容器、重新排序列表，基於結構的定位器就會指向其他位置。 

行動端又帶來了兩大壓力： 

• 平台差異。 同一個畫面在 iOS 和 Android 上會產生不同的元素樹，因此一個 XPath 很少能在兩者上都適用。 

• 渲染時序。 移動螢幕是異步加載的。即使定位器正確，如果測試在元素存在之前進行，仍然可能失敗，這就是為什麼定位器問題和等待問題經常同時出現的原因。 

人工智慧產生的測試提高了風險 

測試量增長速度超過了團隊審查的速度。據估計，目前企業代碼中有 40-50% 是由 AI 產生的（Digital.ai），而且越來越多的測試程式碼也是產生的。 

Slack 的工程團隊最近針對實際工作流程執行了 AI 產生的 Playwright 測試。在簡單的流程中，產生的測試大約有 8% 的失敗率；而在更複雜的流程中，失敗率約為 48%。 Slack 將失敗的主要原因歸咎於 UI 狀態的不穩定性以及現有抽象概念對精確元素定位的干擾。Slack 工程，2026 年那是指網頁端，不是行動端，但其中的教訓同樣適用：產生的測試會繼承預設的定位器習慣。如果沒有人審查元素查找方式，測試套件越大，查找機制就越脆弱。 

Appium 的實用定位器訂單 

Appium 專案本身的指南也依此順序對定位策略進行排序，並將 XPath 列為最後的選擇。: 

 

1. 首先是輔助使用 ID。 這是應用程式團隊特意設定的，查找速度很快，而且在 iOS 和 Android 上都採用了相同的策略。 
2. 資源 ID 或 ID 下一個。 只要開發者不重新命名它們，它們就一直穩定。 
3. 當不存在 ID 時，執行平台原生查詢。 iOS 使用謂詞字串和類鏈，Android 使用 UiAutomator。比 XPath 更精確，但受限於平台。 
4. XPath 最後。 Appium 的指南將其描述為速度慢且不穩定。如果必須使用它，請盡量使用簡短的表達式，並基於屬性而不是基於索引。 

維持定位器穩定的習慣 

• 將可測試性納入「完成」的定義中。 請套用團隊為互動元素新增輔助功能標識符。這也有助於提升真實使用者的使用體驗。 

• 集中定位器。 將它們保存在頁面物件或螢幕類別中，這樣 UI 變更只需編輯一次，而不是二十次。 

• 等待條件成熟，而不是等待時間。 將固定的休眠時間替換為明確等待，等待元素出現或可點擊。 

• 審查程式碼審查中的定位器，包括產生的測試。 包含三個索引的 XPath 注定會失敗。 

• 單獨追蹤查找失敗情況。 如果找不到元素的錯誤集中在幾個螢幕上，那麼定位器清理就能首先發揮作用。 

先解決你擁有的東西，再管理你沒有的東西。 

穩定定位器可以排除一大類完全可控的故障，但無法排除那些不可控的故障。設備、網路和環境仍然會產生間歇性故障，這時問題就變成了：你的團隊如何在不手動重新運行測試的情況下，快速區分這些故障和真正的缺陷？ 

這是不穩定性問題的第二部分，也是我們下一篇文章的主題： 重試很容易，但知道他們告訴你什麼卻很難。.