APP UI自动化测试中Toast消息获取问题的解决历程（解决Toast识别问题）
APP UI自动化测试中Toast消息获取问题的解决过程
在APP UI自动化测试的实践过程中，我遇到了一个棘手的问题——无法获取Toast消息。为了找到问题的根源，我尝试了多种方法，包括查看脚本运行期间记录的UI层次结构XML文件以及使用ADB动态调试等，但这些尝试都没有取得预期的效果。
在测试脚本中，我采用了一种比较通用的写法，即自己定义了一个app_popup_text方法。该方法的核心是通过WebDriverWait和expected conditions（EC）来等待Toast元素的出现，并获取其文本内容。这种方法是处理短暂出现的UI元素的典型显式等待用法。以下是该方法的代码实现：
def app_popup_text(self, popup_refer, timeout=20, poll_frequency=0.01, model=None):
"""
Toast消息提示框获取方法
"""
try:
self.logger.info(f'等待 {model} Toast提示，定位方式: {popup_refer}')
# 尝试获取 Toast 元素
toast_element = WebDriverWait(self.driver, timeout, poll_frequency).until(
EC.visibility_of_element_located(popup_refer)
)
self.logger.info(f'找到 {model} Toast提示，文本内容: {toast_element.text}')
return toast_element.text
except TimeoutException:
self.logger.error(f'未找到 {model} Toast提示')
raise
except Exception as e:
self._log_and_raise_exception(e, f'获取 {model} Toast提示失败')
在解决问题的过程中，很多资料都提到了Appium 1.7版本的兼容问题，或者建议在APP连接初始化中增加“UIautomator2”的声明，但这会导致检索有用信息比较困难。然而，我所使用的本身就是Appium 2的版本，因此版本相关问题可以排除。
后面根据WebView思想尝试解决这个问题，但是根据APPium-Inspector工具和官方文档中去尝试使用Find element（验证定位）和Selected Element中的格式进行元素定位传参也都无法顺利解决。最终，在一篇来自霍格沃兹（一个培训机构）老师的文章中找到了灵感。文章中提到，结合APPium-Inspector的Class name和xpath定位，可以成功解决Toast消息的获取问题。这里的关键在于，Toast的class属性比较特殊，在当前页面上一般会出现一次class="android.widget.Toast"的元素。因此，使用XPath定位方式（但不是APPium-Inspector中显示的Xpath定位，实际为"//*[@class='android.widget.Toast']"）搭配隐式等待，就可以轻松地定位到Toast元素。
根本原因
关于Toast的Class属性：你提到Toast的class属性是android.widget.Toast，但实际上Toast并不是以这种方式直接暴露给UI自动化工具的。Toast是一种特殊的UI元素，它通常不会出现在UI层次结构中，因为它是一个短暂的、浮层式的提示。在Appium中，Toast通常需要通过特殊的定位方式来捕获，比如使用Accessibility服务或者特定的XPath表达式。
在解决问题的过程中，我也意识到，Toast消息的获取问题可能与多个因素有关，如Toast的短暂性、定位策略的准确性以及测试环境的配置等。通过使用正确的定位方式（如XPath或AppiumBY.ANDROID_UIAUTOMATOR）、调整等待时间、检查设备和Appium配置，以及结合日志和调试工具，可以有效解决Toast定位问题。
个人补充
另外，不要因为效率或者性能问题局限自己的想法，比如在很多文章中提到ANDROID_UIAUTOMATOR比XPath定位效率高30%。还有就是实际上隐式等待并不是解决Toast定位问题的最佳实践。显式等待（WebDriverWait）更灵活，可以结合条件判断来等待Toast出现。
相关资源：
浙公网安备 33010602011771号