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

相关文章
|
7月前
|
Java Android开发
Rockchip系列之CAN APP测试应用实现(4)
Rockchip系列之CAN APP测试应用实现(4)
117 1
|
1月前
|
Java 测试技术 持续交付
【入门思路】基于Python+Unittest+Appium+Excel+BeautifulReport的App/移动端UI自动化测试框架搭建思路
本文重点讲解如何搭建App自动化测试框架的思路,而非完整源码。主要内容包括实现目的、框架设计、环境依赖和框架的主要组成部分。适用于初学者,旨在帮助其快速掌握App自动化测试的基本技能。文中详细介绍了从需求分析到技术栈选择,再到具体模块的封装与实现,包括登录、截图、日志、测试报告和邮件服务等。同时提供了运行效果的展示,便于理解和实践。
95 4
【入门思路】基于Python+Unittest+Appium+Excel+BeautifulReport的App/移动端UI自动化测试框架搭建思路
|
3月前
|
测试技术
基于LangChain手工测试用例转App自动化测试生成工具
在传统App自动化测试中,测试工程师需手动将功能测试用例转化为自动化用例。市面上多数产品通过录制操作生成测试用例,但可维护性差。本文探讨了利用大模型直接生成自动化测试用例的可能性,介绍了如何使用LangChain将功能测试用例转换为App自动化测试用例,大幅节省人力与资源。通过封装App底层工具并与大模型结合,记录执行步骤并生成自动化测试代码,最终实现高效自动化的测试流程。
|
4月前
【Azure App Service】同一个App Service下创建多个测试站点的方式
【Azure App Service】同一个App Service下创建多个测试站点的方式
|
4月前
|
网络协议 安全 前端开发
【应用服务 App Service】Azure 应用服务测试网络访问其他域名及请求超时限制(4分钟 ≈ 230秒)
【应用服务 App Service】Azure 应用服务测试网络访问其他域名及请求超时限制(4分钟 ≈ 230秒)
|
4月前
|
测试技术
一款功能完善的智能匹配1V1视频聊天App应该通过的测试CASE
文章列举了一系列针对1V1视频聊天App的测试用例,包括UI样式、权限请求、登录流程、匹配逻辑、消息处理、充值功能等多个方面的测试点,并标注了每个测试用例的执行状态,如通过(PASS)、失败(FAIL)或需要进一步处理(延期修改、待定、方案再定等)。
73 0
|
4月前
|
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
|
5月前
|
前端开发 开发者
移动端-------app开发02,了解apicloud功能和使用,真机测试
移动端-------app开发02,了解apicloud功能和使用,真机测试
|
7月前
|
XML 数据格式
Xpath高阶定位技巧,轻松玩转App测试元素定位!
XPath是一种用于XML文档中节点定位的语言,支持逻辑运算符(and、or、not)、轴定位、谓词和内置函数。
|
4天前
|
监控 JavaScript 测试技术
postman接口测试工具详解
Postman是一个功能强大且易于使用的API测试工具。通过详细的介绍和实际示例,本文展示了Postman在API测试中的各种应用。无论是简单的请求发送,还是复杂的自动化测试和持续集成,Postman都提供了丰富的功能来满足用户的需求。希望本文能帮助您更好地理解和使用Postman,提高API测试的效率和质量。
30 11
下一篇
DataWorks