App测试中,强制等待和隐式等待谁更强?

简介: 本文介绍了在自动化脚本中添加等待以确保与应用程序同步的重要性。由于应用响应时间的不确定性,适当等待能防止脚本在操作未完成前继续执行,提高测试稳定性。等待包括强制等待(如`time.sleep()`)、隐式等待(全局设置查找元素的等待时间)和显式等待(根据预期条件等待)。示例代码展示了如何在Python的Appium测试中应用这些等待策略,以优化脚本的可靠性和与应用的同步。

image.png

简介

添加等待是为了确保自动化脚本在执行过程中与应用程序之间的同步和稳定性。

应用程序的响应时间是不确定的,可能存在网络延迟、加载时间、动画效果等因素。如果在执行自动化脚本时没有适当的等待机制,脚本可能会在应用程序还未完成相应操作或加载完成之前继续执行下一步,导致测试失败或产生不稳定的结果。

通过添加适当的等待操作,可以使脚本在关键操作后等待一段时间,以确保应用程序完成相关任务或操作。这可以包括显式等待(例如等待特定元素出现、消失或可点击),或隐式等待(在整个脚本执行过程中设置一个全局的等待时间)。

等待操作有助于提高脚本的稳定性,减少因应用程序响应不一致而导致的测试失败。它还能够模拟用户在与应用程序交互时的真实等待时间,提供更真实的测试场景。
因此,在编写自动化脚本时,考虑添加适当的等待操作是一个重要的实践,可以提高脚本的可靠性和稳定性,并确保脚本与应用程序之间的同步。

强制等待

  • 解决方案:在报错的元素操作之前添加等待。
  • 原理:线程休眠一定时间。
  • time.sleep(3)
import time
from appium import webdriver
from appium.options.android import UiAutomator2Options
from appium.webdriver.common.appiumby import AppiumBy
from selenium.webdriver.support import expected_conditions
from selenium.webdriver.support.wait import WebDriverWait


class TestWait:

    def setup_class(self):
        '''
        完成 capability 设置
        初始化 driver
        :return:
        '''
        # 设置 cpability
        caps = {
   
   
            # 设置 app 安装的平台(Android,iOS)
            "platformName": "Android",
            # 设置 appium 驱动
            "appium:automationName": "uiautomator2",
            # 设置设备名称
            "appium:deviceName": "emulator-5554",
            # 设置被测 app 的包名
            "appium:appPackage": "io.appium.android.apis",
            # 设置被测 app 启动页面的 Activity
            "appium:appActivity": ".ApiDemos",
            # 不清空缓存信息
            "appium:noReset": True,
            # 首次启动的时候,不停止app
            "appium:dontStopAppOnReset": True,
            # 跳过安装,权限设置等操作
            "appium:skipDeviceInitialization": True,
        }

        # 初始化 driver
        self.driver = webdriver.Remote(
            "http://127.0.0.1:4723",
            options=UiAutomator2Options().load_capabilities(caps)
        )

    def teardown_class(self):
        '''
        关闭 driver
        :return:
        '''
        self.driver.quit()

    def test_wait(self):
        '''
        点击 OS 按钮后等待 3 秒
        输入框输入内容后等待 2 秒
        点击返回按钮后等待 2 秒
        :return:
        '''
        # 测试步骤
        # 找到 OS 元素
        el5 = self.driver.find_element(by=AppiumBy.ACCESSIBILITY_ID, value="OS")
        # 点击 OS 元素
        el5.click()
        # 等待 3 秒
        time.sleep(3)
        # 找到 Morse Code 元素
        el6 = self.driver.find_element(AppiumBy.ACCESSIBILITY_ID, "Morse Code")
        el6.click()
        # 找到输入框元素
        el7 = self.driver.find_element(AppiumBy.ID, "io.appium.android.apis:id/text")
        # 在输入框中输入内容
        el7.send_keys("ceshiren.com")
        # 等待 2 秒
        time.sleep(2)
        # 点击返回按钮
        self.driver.back()
        # 等待 2 秒
        time.sleep(2)
        # 点击返回按钮
        self.driver.back()
        # 断言:判断首页中第一个元素的文本内容是 Access'ibility
        result = self.driver.find_element(
            AppiumBy.XPATH,
            "//*[@resource-id='android:id/text1'][1]"
        )
        print(result.text)
        assert result.text == "Access'ibility"

隐式等待

  • 问题:难以确定元素加载的具体等待时间。
  • 解决方案:针对于寻找元素的这个动作,使用隐式等待添加配置。
  • 演练环境:雪球 app。
  • 原理:隐式等待是一种全局的等待方式,设置一个等待时间,轮询查找(默认 0.5 秒)元素是否出现,如果没出现就抛出异常。

#设置一个等待时间,轮询查找(默认0.5秒)元素是否出现,如果没出现就抛出异常
driver.implicitly_wait(3)

隐式等待无法解决的问题

  • 元素可以找到,使用点击等操作,出现报错。
  • 原因:

    • 页面元素加载是异步加载过程,通常 xml 会先加载完成,相应的元素属性后加载。
    • 元素存在与否是由 xml 决定,元素的交互是由属性决定。
    • 隐式等待只关注元素能不能找到,不关注元素能否点击或者进行其他的交互。
  • 解决方案:使用显式等待。

显式等待基本使用

  • 示例:WebDriverWait(driver实例, 最长等待时间, 轮询时间).until(结束条件)。
  • 原理:在最长等待时间内,轮询,是否满足结束条件。
  • 注意:在初级时期,先关注使用。
# 显示等待 Morse Code 元素可点击
WebDriverWait(self.driver, 10).until(
    expected_conditions.element_to_be_clickable(
        (AppiumBy.ACCESSIBILITY_ID, "Morse Code")))
# 找到 Morse Code 元素
el6 = self.driver.find_element(AppiumBy.ACCESSIBILITY_ID, "Morse Code")
el6.click()

总结

Appium 提供了三种等待方式,确保测试脚本在执行时与应用程序状态同步。这些等待分为强制等待、隐式等待和显式等待三种。用户可以根据不同的需求结合使用这些等待方式,以提高测试脚本的稳定性和可靠性。

相关文章
|
5月前
|
Java Android开发
Rockchip系列之CAN APP测试应用实现(4)
Rockchip系列之CAN APP测试应用实现(4)
82 1
|
5月前
|
测试技术 UED Python
App自动化测试:高级控件交互技巧
Appium 的 Actions 类支持在移动应用自动化测试中模拟用户手势,如滑动、长按等,增强交互性测试。ActionChains 是 Selenium 的概念,用于网页交互,而 Actions 专注于移动端。在Python中,通过ActionChains和W3C Actions可以定义手势路径,例如在手势解锁场景中,先点击设置,然后定义触点移动路径执行滑动解锁,最后验证解锁后的元素状态。此功能对于确保应用在复杂交互下的稳定性至关重要。
115 5
|
16天前
|
测试技术
基于LangChain手工测试用例转App自动化测试生成工具
在传统App自动化测试中,测试工程师需手动将功能测试用例转化为自动化用例。市面上多数产品通过录制操作生成测试用例,但可维护性差。本文探讨了利用大模型直接生成自动化测试用例的可能性,介绍了如何使用LangChain将功能测试用例转换为App自动化测试用例,大幅节省人力与资源。通过封装App底层工具并与大模型结合,记录执行步骤并生成自动化测试代码,最终实现高效自动化的测试流程。
30 4
|
2月前
【Azure App Service】同一个App Service下创建多个测试站点的方式
【Azure App Service】同一个App Service下创建多个测试站点的方式
|
2月前
|
网络协议 安全 前端开发
【应用服务 App Service】Azure 应用服务测试网络访问其他域名及请求超时限制(4分钟 ≈ 230秒)
【应用服务 App Service】Azure 应用服务测试网络访问其他域名及请求超时限制(4分钟 ≈ 230秒)
|
2月前
|
测试技术
一款功能完善的智能匹配1V1视频聊天App应该通过的测试CASE
文章列举了一系列针对1V1视频聊天App的测试用例,包括UI样式、权限请求、登录流程、匹配逻辑、消息处理、充值功能等多个方面的测试点,并标注了每个测试用例的执行状态,如通过(PASS)、失败(FAIL)或需要进一步处理(延期修改、待定、方案再定等)。
39 0
|
2月前
|
Linux C#
【Azure App Service】C#下制作的网站,所有网页本地测试运行无误,发布至Azure之后,包含CHART(图表)的网页打开报错,错误消息为 Runtime Error: Server Error in '/' Application
【Azure App Service】C#下制作的网站,所有网页本地测试运行无误,发布至Azure之后,包含CHART(图表)的网页打开报错,错误消息为 Runtime Error: Server Error in '/' Application
|
3月前
|
前端开发 开发者
移动端-------app开发02,了解apicloud功能和使用,真机测试
移动端-------app开发02,了解apicloud功能和使用,真机测试
|
5月前
|
XML 数据格式
Xpath高阶定位技巧,轻松玩转App测试元素定位!
XPath是一种用于XML文档中节点定位的语言,支持逻辑运算符(and、or、not)、轴定位、谓词和内置函数。
75 0
|
5月前
|
测试技术 Python
App自动化测试中,如何更好地处理弹窗?
在App自动化测试中,处理弹窗异常是保证测试稳定性和可靠性的重要环节。当遇到广告弹窗、升级提示等不定时出现的UI元素时,可以采用黑名单处理方法,如上述Python代码示例,通过尝试点击黑名单中的元素来避免干扰。同时,利用异常处理装饰器可以增强函数功能,保持代码整洁,当异常发生时记录日志、截图并保存页面源代码,便于问题排查。这两种策略能有效提升测试的效率和质量。
87 0
下一篇
无影云桌面