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

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

前一段时间帮助团队搭建了UI自动化环境,这里将Jenkins环境的一些配置分享给大家. 背景: 团队下半年的目标之一是实现自动化测试,这里要吐槽一下,之前开发的测试平台了,最初的目的是用来做接口自动化测试和性能测试,但由于各种原因,接口自动化测试那部分功能整个废弃掉了,其中和易用性有很大关系,另外,也和我们公司的接口业务也有关.不过性能测试功能开发同学用的很欢快,还有接口的管理,目前是连接前端与后端的重要桥梁.目前又加入了环境管理(我公司主要用docker创建开发和测试环境),最近又加入了需求管

1.什么是ui自动化模拟人用代码的方式去操作页面2.为什么要做ui自动化后期迭代的时候,老功能比较多,人工维护成本大这时候考虑引入ui自动化3.什么时候做ui自动化项目稳定,不在修改的某些老功能,为这些老功能提供ui自动化,来提高的效率 4.市面上主流的ui自动化方式 ****** 基于selenium,基于webdriver Selenium3.x,uirecorder 5.from selenium import webdriver生成浏览器服务driver = webdriver.Chro

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

一 .引子 UI自动化,在移动互联网时代的今天,一直都是在各大测试社区最为火爆的一个TOPIC.甚至在测试同行面前一提起自动化,大家就会自然而然的问:“恩,你们是用的什么框架?appium?还是robotium?” 其实在笔者看来,UI自动化是一个ROI较低的测试项(ROI即return on investment,中文意思是投资回报率).但UI自动化相比接口自动化.白盒测试等,它更贴近手工业务测试行为.对于刚起步测试左移.效率提升的团队来说,是最迅速的切入点,也是广大黑盒tester,提升自身

使用appium+python做UI自动化的demo 案例使用的知乎app,下载最新的知乎apk,存在了电脑上,只需要配置本机上app目录,不需要再配置appPackage和appActivity #! /usr/bin/env python#coding=utf-8import osimport timeimport unittestfrom selenium import webdriverfrom lib2to3.pgen2.driver import Driverfrom lib2to3

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

一.背景汽车导航作为ToB业务,需要满足不同汽车厂商在功能和风格上体现各自特色的需求.针对这种情况,传统的UI开发方式,基本上是一对一的特别定制.但是这种方式动辄就要500~600人日的工作量投入,成为业务发展的重要瓶颈.因此,能够对导航UI进行快速定制开发,成为汽车导航业务UI开发的必解课题. 高德地图技术团队希望打造一套快速精准的UI解决方案,通过自动化的方式生产UI代码,解放研发生产力的同时满足客户需求. 二.方案调研为了避免重复造轮子,我们调研了行业上现有的UI自动化生成方案.主要分为两

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

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

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

1.首先接口测试是跳过前端界面对服务端的测试,UI测试是对前端界面的测试,从分层测试的角度考虑,两者不应该是可以互相取代的关系.   2.从公司开展自动化的的角度考虑,可以重点关注这个项目开展接口自动化和UI自动化的分别需要的时间消耗.自动化测试人员成本.项目开展自动化测试的可行性.接口自动化和UI自动化的投入产出比,最终来确定开展接口自动化和UI自动化的比重.   3.从自动化测试覆盖率和难易程度来考虑,一般来说,系统中可测试的接口数量要比前端界面的功能点要少,并且接口的改动频率比前端界面改动

Selenium学习笔记 selenium webdriver是业界公认ui自动化测试的标准,其封装的api可以对浏览器的任何地方进行操作 selenium2.0和selenium3.0的区别? 3.0任何浏览器的厂商都支持selenium,他们只要给予驱动就可以了,2.0只支持火狐和谷歌 webdriver工作原理? 通过webdriver创建一个浏览器服务,remote server(底层服务).启动脚本后会通过驱动打开浏览器,并绑定端口,不同浏览器端口不同 client端创建一个sessi

环境:Python2.7.10, selenium3.141.0, pytest4.6.6, pytest-html1.22.0, Windows-7-6.1.7601-SP1 特点:- 二次封装了selenium,编写Case更加方便. - 采用PO设计思想,一个页面一个Page.py,并在其中定义元素和操作方法:在TestCase中直接调用页面中封装好的操作方法操作页面. - 一次测试只启动一次浏览器,节约时间提高效率(适合公司业务的才是最好的). - 增强pytest-html报告内容,加

ATOMacTest 一.缘 起 近期工作需要对一款Mac端应用实现常用功能的自动化操作,同事推荐ATOMac这款工具,这几天简单研究了下,同时也发现现网介绍ATOMac的资料非常有限,故在此记录下ATOMac的一些简单用法,仅供学习参考~ 二.概 述 如标题,ATOMac是一个基于Python语言,通过Apple Accessibility API实现的Mac端应用Ui自动化控制库,下面是官方的说明: We are pleased to introduce the first Python l

实施过了web系统的UI自动化,回顾梳理下,想到什么写什么,随时补充. 首先,自动化测试不是手动测试的替代品,是比较好的补充,而且不是占大比重的补充. 70%的测试工作集中在底层接口测试和单元测试,20%的测试工作为集成测试,其他10%的测试即为界面测试. 开发方向: 尽可能的相通的模块,通用的封装 开发约定好,便于定位 适用兼容测试 无界面运行 快速定位问题:报错信息.错误截图 多环境 收益点 脚本开发时间和复用次数 快速验证,第一时间响应问题 还可以做哪些? 兼容性 多环境 便于快速定位 提

目录 1. 前言 2. 工具/框架/库选择 2.1 miniprogram-automator官方介绍(摘自官方哈) 小程序自动化 特性 2.2 minium官方介绍 特性 3. 如何选择 4. 对应方案的报告展示 5. 其他 6. 后续 参考资料: miniprogram-automator:https://developers.weixin.qq.com/miniprogram/dev/devtools/auto/ minium:https://git.weixin.qq.com/minit

Python3--Uiautomator2--Pytest--Alure使用 官方源码GitHub地址:https://github.com/openatx/uiautomator2 介绍 uiautomator2 是一个可以使用Python对Android设备进行UI自动化的库.其底层基于Google uiautomator,Google提供的uiautomator库可以获取屏幕上任意一个APP的任意一个控件属性,并对其进行任意操作,但有两个缺点: 1.测试脚本只能使用Java语言. 2.测试

本文首发于果的博客园,原文链接:https://www.cnblogs.com/yuxiuyan/p/14992682.html, 转载请注明出处. UI自动化 我们为什么要搞UI自动化 可能很多同学都有疑问:我们写了这么多单元测试,为什么还需要UI自动化测试呢? 按照测试金字塔理论,其实每种类型的测试都有自己的意义,UI自动化的意义就在于更贴近用户真实场景的校验,比如对于手机QQ来说,我们需要确保主流程的真实链路是通畅的,而单元测试和接口测试很难做到这一点. 我们需要多少用例 UI自动化的意义