• 0
  • 0
分享
  • Appium综合实践(3)-业务逻辑businessView的封装
  • 豆秸 2022-07-11 09:09:37 字数 295 阅读 1342 收藏 0

前言

前面对脚本的基础配置、公共配置进行封装完成后,下一步便是对公司内部的业务进行分模块,按照模块进行对应的封装

业务逻辑的封装目的

将整个应用抽离分成哥哥公共模块,以便在不同的业务场景内直接复用对应的脚本文件;

例如:将登录分成引导页模块、登录模块、注册模块、签到模块等等,各个模块根据业务能力划分,独立封装对应的脚本,便于后续业务功能发生变更时,快速的维护和调用脚本。

脚本目录

以下脚本分别对登陆模块和退出登陆模块两个模块进行独立封装

投71.png

本地对应的文件夹目录:

投72.png

脚本简述

其中登录模块的测试脚本,包含了:

  1. 登录的整个操作流程login_action()

  2. 校验是否登录成功check_login_alter()

1.png

2.png

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   微软近年来在人工智能领域深耕,并最终可能将其添加到 Windows 11 上使用的其他所有应用程序中。Windows 的一项功能"Studio Effects"可能很快就会有新的人工智能特效,将你手里的视频甚至视频里的人物变成水彩画、卡通甚至插图。借助人工智能的神奇魔力,你甚至可以看到自己的视频实时变成这些特效。  Windows Studio Effects 于2022 年首次亮相,在配备 NPU(神经处理单元)的新硬件上工作效果最佳。Studio Effects 专为混合办公而设计,因此如果您使用 Microsoft Teams 或其他应用程序进行交流,不妨打开 S...
            0 0 848
            分享
          • 一、前言       互联网公司常见工种有哪些?       互联网中一个项目的上线会需要各个工种间的配合,以研发为视角上会承接产品需求,下会交给测试验证,最终完成项目交付上线。其实除此之外,还会有业务、运营、UI设计、运维,来配合项目的发起、使用和运维维护。图 18-1,互联网工种协同合作。       除了一条线上的工作交替配合,还有同工种间的跨部门协同工作。 比如:产品阶段:A产品中的部分服务,需要由另外一个部门配合开发相关服务支撑。那么双方产品需要协调好时间节奏,配合...
            15 14 2261
            分享
          • 自2018年被评选为编程语言以来,Python在各大排行榜上一直都是名列前茅。目前,它在Tiobe指数中排名第三个,仅次于Java和C。随着该编程语言的广泛使用,基于Python的自动化测试框架也应运而生,且不断发展与丰富。因此,开发与测试人员在为手头的项目选择测试框架时,需要考虑许多方面的因素,其中包括:框架的脚本质量,测试用例的简单性,以及运行模块可能存在的技术弱点。为了避免出现“选择困难症”,我在此为大家准备了五种Python类型的自动化测试框架,以供比较和讨论。1.Robot Framework作为最重要的Python测试框架之一,Robot Framework主要被用在测试驱动(te...
            12 12 2855
            分享
          •   由于高人气和需求,Web 应用程序领域变得广阔。因此,有时我们会用其他名称来指代特定类型的网络应用程序,这些名称表示更大图片的特定子域。例如,如果您在一个自动刷新的网站上观看现场比分,它就变成了一个动态网站。如果网站在线销售商品,它就会成为电子商务网站,依此类推。  如果我们查看这些小的子域,我们可能会得到一长串 Web 应用程序类型。实际上,我们只考虑四个大部门,并且只关注这些部门。  1. 静态网络应用  静态 Web 应用程序仅包含静态网页。这些页面本质上是静态的(或固定的)并从服务器呈现给用户,即所有用户将看到相同的内容。静态 Web 应用程序的一个示例是显示您的简历的简...
            0 0 258
            分享
          • 读者提问:今天刚刚接到一个项目,项目经理让我们评估测试时间,但我需求还没搞明白,实在不知道怎么评估测试时间呢,阿常能给我支支招吗 ?阿常回答:告诉你一个大多数团队都通用的测试时间评估法则:开发时间的 1/3 ~ 1/2。1、不怎么复杂的项目,测试时间一般按照开发时间的 1/3 来评估。2、稍微复杂一点的项目,测试时间一般按照开发时间的 1/2 来评估。阿常碎碎念:对于以上测试时间的评估,可依据实际项目中可能发生的测试风险,酌情再增加 20%。比如,实际测试下来发现 BUG 很多,开发修复时间长,测试需要等待开发提测新版本;比如实际测试过程中测试人员有变动,原来熟悉这个项目的测试人员休...
            0 0 4133
            分享
      • 51testing软件测试圈微信