这几天跟自动化测试工具UFT耗上了... 网罗了下,居然有不少自动化测试工具,像Selenium,QTP(UFT前身),LoadRunner,真是只有想不到,没有人家办不到. 言归正传,记录下小白使用UFT工具的过程,主要是记录些其中的一些隐藏功能以便以后查阅. 1. 工具版本 界面挺清新的,感觉有些类似VS,要licence,免费使用60天 2. 使用文档 (1) 官方网站 (2) PDF 因为UFT前身叫做QTP,所以QTP的一些指导文档也可以拿来看看 (3) UFT/QTP for Beg

UI自动化的核心在于定位 目录 1.8种基础定位方法 2.xpath定位 3.css定位 4.多组元素 1.8种基础定位方法 driver.find_element_by_id() #id定位 driver.find_element_by_name() #name定位 driver.find_element_by_class_name() #class定位 driver.find_element_by_tag_name() #标签名定位,一般用于iframe:标签较少的也可以使用,用取下标的方式

前言 在UI自动化过程中,需要对手机app上的元素进行定位,然后进一步编写自动化脚本操作app.定位元素首先需要定位工具来辅助查看页面元素.小编常用的定位工具有2种,分别是uiautomatorviewer.appium inspector. uiautomatorviewer 是Android sdk 自带的定位工具,元素层级展示清晰,但是定位不到内嵌H5页元素.appium inspector是appium上自带的定位功能,元素层级展示不够清晰,查看元素不够方便,但是可以定位到内嵌H5页元素

一.UI自动化相关 1. UI自动化的本质(重点) 定位元素→操作元素→模拟页面操作→断言→测试报告 2. 适合UI自动化的场景 UI自动化的前提条件 (1)需求不能频繁变动 (2)UI稳定(UI自动化就是基于UI层面的,UI界面总变化无法开展) (3)项目周期长(UI自动化脚本编写和调试耗时,项目周期短纯手工更高效) (4)回归测试频繁(回归测试多就会有不断的主流程功能需要回归,自动化更高效) 适用场景 (1)冒烟测试 (2)主功能回归测试 3. UI自动化的原则 (1)一个case完成一个功

做ui自动化的最基础的就是页面元素定位了,如果连页面元素都定位不到,自动化从何谈起呢?接下来我们就看看页面元素定位的方法吧!(这里就用百度页面来进行演示) 一.最通用的几种定位方式: 1.通过id定位 driver.find_element_by_id('su') 2.通过name定位 driver.find_element_by_name('mp') 3.通过class属性 driver.find_element_by_class_name('s_ipt') 4.通过文本链接 driver.f

前言 在UI自动化过程中,常遇到元素未找到,代码报错的情况.这种情况下,需要用等待wait. 在selenium中可以用到三种等待方式即sleep,implicitly_wait,WebDriverWait 一.固定等待(sleep) 导入time模块,设定固定的等待时间 缺点:在网络状态良好,元素可以加载出来的情况下,依然需要等待,会导致脚本允许时间延长.        二.隐式等待(implicitly_wait)        隐式等待是指页面元素在设定时间内全部加载完成,才能执行下一步.

UI自动化,通过Xpath定位的总结 当页面展示的内容的html布局格式一样,只能第几个控件的绝对定位来区分时,如果后面有变更控件的顺序,就会导致找不到这个元素,维护成本较高,可以尝试用其他的方式,比如找布局里面,唯一能区分的元素,比如同级的元素的text显示不一样的时候,就可以结合获取同级元素来定位 Xpath常用的父类.同级定位元素 XPath轴(XPath Axes)可定义某个相对于当前节点的节点集: 1.child 选取当前节点的所有子元素 2.parent 选取当前节点的父节点 3.d

自适应内容 artDialog的特殊UI框架能够适应内容变化,甚至连外部程序动态插入的内容它仍然能自适应,因此你不必去考虑消息内容尺寸使用它.它的消息容器甚至能够根据宽度让文本居中或居左对齐——这一切全是XHTML+CSS原生实现. 完善的接口 它的接口完善,可以轻易与外部程序配合使用.如异步写入消息.控制位置.尺寸.显示与隐藏.关闭等. 细致的体验 如果不是在输入状态,它支持Esc快捷键关闭:可指定在元素附近弹出,让操作更便捷:智能给按钮添加焦点:黄金比例垂直居中:超大响应区域特别为ipad等

UI自动化处理文件上传 import win32guiimport win32con def set_uploader(self, file_path): sleep(2) self.file_path = file_path if (os.path.exists(self.file_path) == False): # 判断路径是否存在 print(u"文件路径不存在") return False else: try: dialog = win32gui.FindWindow('#3

UI自动化页面上传文件,百度查的时候说有4中方法,简便的方法是安装SendKeys,但是百度说这个只支持python2.7的 我的python版本是3.7的,目前还只碰到了非<input type="file"...>的情况,所以用pywin32模块,等遇到其他情况再补充 前提:安装pywin32:pip install pywin32 解析:# 文件上传框,定位工具Winspy # 上传窗口  dialog(win32gui.FindWindo) 一级 # 子窗口:打开按

去年春节联欢晚会,为了那张“敬业福”,全家都卯足了劲儿“咻一咻”,连节目都顾不上看了.当时我就想,要是能自动化该多好,不停点击屏幕,屏幕不疼手还疼呢,何况还不好分心,生怕错过了“敬业福”.玩“咻一咻”,是靠不停点击按钮来检查是否得到“敬业福”,而工作中的UI自动化,大抵也和“咻一咻”差不多,都是通过不断地输入,验证系统的输出是否正确.然而做UI自动化,效果并不好,收益低就算了,执行速度还慢.比如打开一个浏览器,可能就要等3-5秒,如果等浏览器访问网址,返回网页内容,就需要更长的时间.要是遇到问题

◆版权声明:本文出自胖喵~的博客,转载必须注明出处. 转载请注明出处:http://www.cnblogs.com/by-dream/p/5993622.html 关于UI自动化的抱怨 听过不少人这样讲 "UI自动化非常不稳定,需求一改,界面一遍,全部都费了".我相信做过的人可能也会有同感.既然这个问题一直都是存在的,那么为什么没有人仔细分析原因呢? 我的老板george曾举了这样一个例子:每当需求变化的时候,开发没有跳起来,反而是测试跳了起来.然后不断的抱怨,界面元素全都改了,我的自

人类文明发展的一个重要标识是工具的诞生,当人类开始制作工具来提高生产力时,就逐渐拉开了与其他生物的距离.曾在2013年,<Google如何测试软件>中提到的分层自动化金字塔,轰动业界.而在互联网时代的今天,标识着测试技术重要进步的产物——自动化工具,也在逐渐推陈出新地用各种工具拉开企业间的差距. 图解: Unit代表单元测试,Service代表服务集成测试,UI代表页面级的系统测试:其中UI自动化,以其高度模拟用户真实场景的测试方式,备受广大测试人员的关注.但其高投入低产出的性价比,却让维护人

移动UI自动化,看起来美好,践行起来却难.做个目光短见的务实主义者.Page Objects Pattern是Selenium官方推崇的方式,最近研究写测试用例最佳实践之Page Objects,同时结合Appium的Java Client简单介绍下如何写出靠谱的Page Object. Page Objects Page Object定义为抽象web app页面的一系列对象,通过对页面功能的封装,它得到了很多好处: 减少重复代码 提高测试代码的可读性和稳定性 测试代码易于维护 一个简单的例子

实战项目 均来源于互联网 测试报告2017年11月29日优化后的测试报告:https://github.com/defnngj/HTMLTestRunner 1.项目概述: 本实战已126邮箱为例子进行了实战,对登录.写邮件.发送邮件.删除邮件.退出登录进行了自动化测试: 测试完成后自动发送测试报告到指定邮箱 目录结构: auto_working目录: report                         ---> 目录用于存放测试报告 test_case                

1.什么是UI自动化?模拟人用代码的方式去操作页面2.为什么要做UI自动化?后期迭代的时候,老功能比较多,人工维护成本较大,重复性工作较多,这个时候就考虑因为UI自动化3.什么时候做UI自动化?项目稳定,不再修改的某些老功能,为这些老功能提供UI自动化,来提高效率4.市面上主流的ui自动化方式 基于selenium ****** 基于webdriver Selenium3.x5.selenium的介绍selenium是用于测试web应用程序用户界面常用的框架,他是一款用于运行端到端的功能测试的工

题记: 之前一直用APPium直到用安卓9.0  发现uiautomatorviewer不支持安卓 9.0,点击截屏按钮 一直报错,百度很久解决方法都不可以,偶然间看见有人推荐:uiautomator2 就尝试使用 发现比appium要简单一些: 下面文字主要来自虫师的博客 一.Uiautomator2原理介绍 1.uiautomator2是一个可以使用Python对Android设备进行UI自动化的库.其底层基于Google uiautomator,Google提供的uiautomator库可

解决UI自动化难点痛点: 解决从安装过程中跳出的提示框以及操作过程中任意提示框的操作,来提高用例成功率: 公用用例及业务用例分离,便于维护和多人使用,提高脚本编写效率: 解决用android windowmanager设计的控件,任何UI相关工具是无法获取控件操作问题 解决代码逻辑复杂定位控件问题,任何控件都可快速定位: 解决混合app,涉及到webviewUI操作,还得需要重新打包问题: 解决用例失败后,可配置次数,进行重试执行,提高用例得执行率: 解决测试报告粗糙,纯log输出或者配置简单截

◆版权声明:本文出自胖喵~的博客,转载必须注明出处. 转载请注明出处:http://www.cnblogs.com/by-dream/p/5993622.html 关于UI自动化的抱怨 听过不少人这样讲 “UI自动化非常不稳定,需求一改,界面一遍,全部都费了”.我相信做过的人可能也会有同感.既然这个问题一直都是存在的,那么为什么没有人仔细分析原因呢? 我的老板george曾举了这样一个例子:每当需求变化的时候,开发没有跳起来,反而是测试跳了起来.然后不断的抱怨,界面元素全都改了,我的自动化的用例

最近在UI自动化时遇到了,上一步成功操作后没有响应的情况(动画加载和浏览器加载导致实际没有问题),导致下一步无法成功操作,所有想在尝试2次操作后再次进行上一步操作解决这种情况导致的错误(其实是不想每一次有问题都要手动加线程沉睡) 1.java应用程序,暂停/开始按钮 import java.awt.Dimension; import java.awt.Toolkit; import java.awt.event.ActionEvent; import java.awt.event.ActionL

第一步: 得到功能测试的常规用例,查看是否可以进行自动化,要明确,自动化不是为了自动化而自动化,自动化是节省人力,主要做回归测试,如果变动性特别大,不建议做自动化,具体可查看其它文章“什么适合做自动化”,且有些自动化要评判付出与收益比,如果付出很大,收益很小,这种也不值得做自动化 第二步: 确认可以做自动化,需要把用例转成自动化用例 我关注的点: 自动化用例我会更注重,验证点,数据的准确性,ui的结果不单单只关注界面显示,为了数据准确性,我会从数据库中拿数据进行对比,或者是通过接口请求数据得到数