PageObject设计模式进行自动化用例的设计方法

关于PageObject模式进行自动化代码的编写:

PageObject简而言之理解就是:一个页面作为一个类,页面中所有的元素均作为类中的方法

当然PageObject也是一种分层思想。

以Python登录163邮箱举例:

BrowserDriver作为打开浏览器驱动的一个方式

Page是所有的页面组成的一个包

Testcase就是实际的测试用例

1、Page中存在一个基本的page类,所有的页面类都需要继承的类:这样写的好处就是元素一旦修改,UI界面发生变化,我仅需修改我的page就行,不影响我所有测试用例。

(1)base.py:

(2)Firstpage.py中继承了Page类:

在FirstPage中将测试用例中需要的元素全部以函数方法的形式写出来,下次使用这些元素直接调用即可。

2、浏览器操作:

BrowserDriver.py:指定需要操作的浏览器,如果我需要测试所有用例中的兼容性,我仅需要改driver即可,当然在用例中,所有的driver需要使用这个方法,而不是直接webdriver.xxx

3、编写用例:在以上准备好的时候,直接操作已经定义好的页面元素,无须再次定位

test_login_firstpage_case.py:

4、用discover和HTMLtestrunner批量搜索测试用例和生成测试报告

时间: 2024-10-11 00:05:04

PageObject设计模式进行自动化用例的设计方法的相关文章

Android UI自动化用例设计技巧

一.封装方法 1.编程如何越来越快: 首先,需要经验丰富,知识面广. 其次,每一个熟练编程的人员,都会有自己的一个库,解决各种问题.各种通用的方法函数. 同理,自动化脚本也是编程,测试用例则为需求,UI自动化编写虽然容易,但是界面变化快.维护庞大.所以封装通用方法,是最快最容易的途径. 2.哪些方法需要封装: 公共的操作方法 经常使用的步骤:超过两次以上 经常使用的组件:输入框.文本框.列表 经常操作的布局:多个组件组成通用的布局 经常操作的页面:ui页面由一个一个单独Activity组成,就可

自动化用例设计原则

1.自动化用例分3步走 初始化,输入准备 执行(方法调用),结果验证(断言) 清理环境 2.用例独立 不同的执行顺序,相同的结果 用例间没有状态共享 用例执行前的环境状态与用例执行结束后的一致 3.单一职责 一个单测用例只负责一个场景/行为 一个用例中的多个断言仅验证一个场景 如:调用api返回结果需要验证error no是否为0,error msg是否为空 一个方法,N个场景需要写N个用例 一个场景,多个方法可以写一个用例 遵循的原则就是一个场景对应一个用例 4.自描述 变量名.方法名.类名等

自动化用例设计

用例设计部分,无论是手工测试还是自动化测试,都必须要的环节,也是非常重要的环节.在做自动化的时候,用例需要考虑前置后置.步骤和对比,每一个部分都要有提供非常明确的测试数据,要考虑数据的重复使用是否会影响脚本的执行结果. 自动化用例设计原则 1.不是所有的手工用例都要转成自动化测试用例 2.考虑到脚本开发的成本,不要选择流程太复杂的测试用例,如果有必要,可以考虑把流程拆分成多个用例来实现脚本 3.选择的用例最好可以构建成场景.例如,一个功能模块,分多个用例,多个用例使用同一个场景 4.选择的用例可

dubbo接口自动化用例性能优化

前言 去年换了一个新部门,看了下当前的自动化用例的情况,发现存在三类性能问题: 本地调试运行时等待时间较长,就算是一个简单的case,执行时间都需要1分钟以上 单用例执行时间比较长,部分用例执行时间超过2分钟 集成到CI中运行时,执行时间较长 对于上述三个问题花时间进行了一定程度的优化,总结如下 优化本地调试时间 通过调试可以发现,一个需要执行660ms的case,在执行前的初始化工作就需要消耗约1分半钟,那么就需要思考下能否减少这部分初始化时间了. 公司用的自动化框架是基于AbstractTe

命令行运行Android Robotium自动化用例或单元测试用例

本文目录 1.运行所有的测试用例 2.运行单个测试类或某个TestSuite 3.运行某个测试类里面的某个测试方法 4.运行两个不同的测试类或类中的方法 命令行运行Android Robotium自动化用例或单元测试用例 1.运行所有的测试用例 举个栗子:运行测试工程下的所有用例 1 adb shell am instrument -w com.taobao.taobao.test/android.test.InstrumentationTestRunner 2.运行单个测试类或某个TestSu

robot+selenium编写web UI自动化用例

通常我们可以用robot framework写接口自动化用例,但是有些站点如果未做前后端分离,迭代过程中又有大量的重复测试工作量,没有接口可调用验证,也有自动化测试需求,怎么办?这时候,那个深坑频现的web UI自动化就势在必行了.robot只是自动化框架,好在他稳定而且扩展性极好,要想驱动web浏览器自动干活,只需要安装另外一个神器selenium,下文将提纲携领介绍web UI如何入门,一旦你入了门,其余的就是baidu和看官网帮助的工作量了,建议用到了在查,不然也没卵用. 用例编写前提:

Robot Framework测试框架用例脚本设计方法

Robot Framework介绍 Robot Framework是一个通用的关键字驱动自动化测试框架.测试用例以HTML,纯文本或TSV(制表符分隔的一系列值)文件存储.通过测试库中实现的关键字驱动被测软件.    Robot Framework灵活且易于扩展.它非常适合测试有不同接口的复杂软件:用户接口.命令行,Web服务,专有的编程接口等. Robot Framework是开源软件,通用的测试库源码安装包和文档等可通过http://robotframework.org获取.Robot Fr

接口自动化用例设计

返回结果是[{},{},{}]这种格式的,用assertNotEqual和assertIn进行判断,前提要先str一下,cases里的用例执行顺序是从上到下获取的 接口属性有两种,一种是get型的,一种是写入型的,get型的主要是获取信息,写入型的就是对数据库进行写入,修改的接口,所有项目都包含get型的和写入型的接口,get型的接口只要关注返回结果是否正常就可以,写入型的不要关注返回结果而是调用接口后去相关的数据库里取相关的字段值和你的预期结果进行校验 原文地址:https://www.cnb

jenkins执行自动化用例(详细、有用、mark 优先级高高高)

http://blog.sina.com.cn/s/blog_68f262210102vx8o.html 第七章 测试用例接入jenkins自动运行 ------Web自动化测试之Webdriver+TestNG--从零到熟练(系列) 自动化测试用例的最终目的就是无人值守的自动化回归测试,不管是用什么语言,什么框架编写的测试用例,如果想达到这个效果,都需要借助于Jenkins或是Hudson.根据业界的习惯,我们还是使用Jenkins.在本人的各个自动化测试教程中,已经多次介绍到了Jenkins