赞
踩
目录
3.xpath和css定位都比较强大,那他们之间有什么区别?
1.3 Appium基于chromedriver的原理,测试H5时使用
3.Testng的监听器是怎么使用的?TestNg的数据驱动返回
15.restful标准接口中,有哪几种请求方式,他们分别代表
3、什么样的项目比较适合做自动化测试,什么样的不适合做自动化测试
24、selenium中hidden或者是display = none的元素是否可以定位到
25、selenium中如何保证操作元素的成功率?也就是说如何保证我点击的元素一定是可以点击的?
27、用例在运行过程中经常会出现不稳定的情况,也就是说这次可以通过,下次就没办法通过了,如何去提升用例的稳定性
31、id,name,class,xpath, css selector这些属性,你最偏爱哪一种,为什么
34、点击链接以后,selenium是否会自动等待该页面加载完毕
39、如果你进行自动化测试方案的选型,你会选择哪种语言,java,js,python还是ruby
40、page object设置模式中,是否需要在page里定位的方法中加上断言
45、公司内一直在使用的测试系统(B/S架构)突然不能访问了,需要你进行排查并恢复,说出你的检查方法
isElementPresent
通过工具或脚本代替手工测试执行过程的测试都叫自动化测试 自动化测试的优势: 1.减少回归测试成本 2.减少兼容性测试成本 3.提高测试反馈速度 4.提高测试覆盖率 5.让测试工程师做更有意义的测试
适合做的项目: 1.项目周期长且相对稳定 2.需要做频繁的冒烟测试 3.需要经常做回归测试 4.需要进行大数据量的数据驱动测试 不适合做的项目: 1.项目周期短用例不会多次重复执行 2.被测项目不稳定变化太频繁
1.选择合适的测试工具 2.定义自动化测试覆盖的范围 3.制定测试计划 4.自动化测试环境搭建 5.脚本开发 6.测试执行 7.测试脚本维护
1.选择适合的测试工具或分析当前的工具是否适合新项目 2.选择合适的自动化测试框架 3.确定要做自动化测试的范围和不做自动化测试的范围 4.测试环境的准备与搭建 5.制定一个粗略的脚本开发的时间表 6.制定脚本执行的一些策略,如冒烟测试的频率,回归测试的时间点及频率等 7.定义自动化测试的输出,比如脚本,测试数据,发现的缺陷,测试报告等
1.统一的命名约定,如用例名,方法名等 2.良好的脚本注释 3.遵循代码规范,使用适当的缩进 4.对异常进行处理
这个取决于测试用例场景的复杂度,一般一天能写2~5个左右,复杂的话一天只能写一个
1.自动化测试用例的覆盖率=自动化测试用例数/所用用例总数,这个比例越高测试反馈越快,成本节约越多 2.节省的时间成本=手工测试所花的时间-自动化测试所花的时间 3.自动化测试的投入=开发脚本的投入+脚本维护的投入+工具价格 4.自动化测试发现的缺陷数 每次回归测试时自动化测试发现的缺陷数及漏测数,反应了自动化用例的有效性
自动化测试投入产出比: ROI=(手工测试的成本-自动化测试成本)/自动化测试成本 ROI如果是负值说明自动化测试的成本未收回,ROI为正值说明自动化测试成本已回收,且值越大说明回报越好
比较难 因为有些用例场景无法被自动化 一些验证易用性友好性的用例不适合做自动化有些边缘的用例很少被重复执行,从投入产出比来说也不适合做自动化
1.项目流程不规范,项目变动频繁导致自动化用例维护成本高 解决:深入理解用户需求,规范开发流程,自动化用例先覆盖已经稳定的功能。 2.对自动化期望太高 自动化也是一个逐步完善的过程,不可能一下子完全代替手工 3.有些自动化工程师的技术能力偏弱 提升编程能力,提升自动化工具使用能力,对新人进行培训等
jsonwireprotocol
selenium IDE、webdriver、 selenium GRID
有八种 ID NAME CLASSNAME LINKTEXT PARTIALLINKTEXT TAGNAME XPATH CSS SELECTOR
一般是自己写Xpath表达式,再利用 try xpath小工具严重xpath表达式是否正确 也可以运用谷歌和火狐中按F12后,对选中的元素是由右键中copy xpath功能
driver = webdriver.FirefoxFDriver() driver = webdriver.ChromeDriver() driver = webdriver.internetExplorerDriver()
webelement类中的isdisplayed()方法
//select selectByVissbleText
需要使用driver.switchTo().alert(): alert.accpt()相当于点击弹窗的ok按钮 alert.dismiss()相当于点击弹窗的cancel按钮
selenium本身是不可以处理windows弹窗的,但是selenium可以借助Autolt小工具来完成对windows弹窗的操作
强制固定等待 全局的隐式等待 等待具体某个元素某个状态的显示等待 driver.quit()和driver.close()的区别 driver.close()仅关闭当前用户正在操作的页面 driver.quit()关闭整个浏览器,关闭所有的页面
线性脚本框架、数据驱动框架、关键字驱动框架、混合框架等
是一种设计模式 好处是复用代码,减少重复代码的编写 减少维护成本,页面ui变动时,只改动一处即可
不能
-添加元素智能等待时间 driver.implicitly_wait(30) - try 方式进行 id,name,clas,x path, css selector 不同方式进行定位,如果第一种失败可以自动尝试第二种 -Selenium保证元素成功率是通过元素的定位,当然它的定位方法很多,一定能有合适的。但是在自动化工程 的实施过程中,高质量的自动化测试不是只有测试人员保证的。需要开发人员规范开发习惯,如给页面元素加 上唯一的name,id等,这样就能大大地提高元素定位的准确性。当然如果开发人员开发不规范,我们在定位元素的时候尽量使用相对地址定位,这样能减少元素定位受页面变化的影响。只要我们元素定位准确,就能保证我的每一个操作符合我的预期
Selenium脚本的执行速度受多方面因素的影响,如网速,操作步骤的繁琐程度,页面加载的速度,以及我们 在脚本中设置的等待时间,运行脚本的线程数等。所以不能单方面追求运行速度的,要确保稳定性,能稳定地 实现回归测试才是关键。 我们可以从以下几个方面来提高速度: 一,减少操作步骤,如经过三四步才能打开我们要测试的页面的话,我们就可以直接通过网址来打开,减少不 必要的操作。 二,中断页面加载,如果页面加载的内容过多,我们可以查看一下加载慢的原因,如果加载的内容不影响我们 测试,就设置超时时间,中断页面加载。 三,在设置等待时间的时候,可以sleep固定的时间,也可以检测某个元素出现后中断等待也可以提高速度。 四,配置testNG实现多线程。在编写测试用例的时候,一定要实现松耦合,然后在服务器允许的情况下,尽量 设置多线程运行,提高执行速度
- time.sleep() - driver.implicitly_wait(30) -多用 try 捕捉,处理异常 -此时我们要分析出不稳定的原因,然后有针对性的去解决问题。主要有以下几个方面: 一,网速问题:有的时候网页加载的比较慢,在程序执行的时候要操作的元素没有显示出来。这种情况比较常 见,运行一次网速好的时候通过了,再运行一次,页面没有打开,就不通过了。为了提高稳定性,我们只能牺 牲运行时间了,在经常检测失败的元素前加上等待时间,等要操作的元素出现之后再执行下面的操作。 二,Selelnium的原因:Selenium1.0和2.0还是有区别的,有些儿函数在2.0下运行确实有时而有效,时面 无效。如果mouseover()函数,就是这种情况,我们需要避免使用这类的函数。 三,多线程的时候,测试用例间相互影响。虽然多线程的时候运行速度比较快,但是如果用例之间的耦合性没 有设计好,也会影响的,如果用例A先于用例B执行的时候,就会影响到用例B;反之则没有问题。这种情况, 如果你的自动化测试工程打算多线程的时候,提前就要把测试用例测试的耦合度比较松,尽量没有任何关系, 因为多线程的执行顺序是不受控制的。
自动化测试用例的执行策略是要看自动化测试的目的,通常有如下几种策略: 一,自动化测试用例是用来监控的,在此目的下,我们就把自动化测试用例设置成定时执行的,如果每五分钟 或是一个小时执行一次,在jenkins上创建一个定时任务即可。 二,必须回归的用例。有些儿测试用例,如BVT测试用例,我们在公司产品任何变动上线之前都需要回归执 行。那我们就把测试用例设置成触发式执行,在jenkins上将我们的自动化测试任务绑定到开发的build任务 上。当开发人员在仿真环境上部代码的时候,我们的自动化测试用例就会被触发执行。 三,不需要经常执行的测试用例。像全量测试用例,我们没有必要一直回归执行,必竟还是有时间消耗的,有 些非主要业务线也不需要时时回归。这类测试用例我们就采用人工执行,在jenkins创建一个任务,需要执行 的时候人工去构建即可。
持续集成源于极限编程(XP),是一种软件实践,软件开发过程中集成步骤是一个漫长并且无法预测的过程。集成过程中可能会爆发大量的问题,因此集成过程需要尽可能小而多,实际上持续集成讲的是不断的去做软件的 集成工作。持续集成,最简单的形式是包括一个监控版本控制(SVN等等)变化的工具。当变化被发觉时,这 个工具可以自动的编译并测试你的应用
- UI自动化不需要
-接口测试会需要
css 、xpath 几乎所有的元素都可以定位到
触发动态加载元素的事件,直至动态元素出现,进行定位
xpath或者css通过同级、父级、子级进行定位
会的
http
相似功能地方,代码基本都是一样的,界面元素换个查找方式,把原来的使用 xpath方式,改为使用 id 查 找,需要对每个用例脚本都要改,虽然几个用例看不出什么工作量,但是重复findElement的代码,已经让我 们感到了代码的笨重。如果某些定位发生了改变,我们就得贯穿整个测试代码进行调整元素定位,这样就会导 致我们的脚本在后期,难以维护。因此通过Page Object Model 我们可以创建更加健壮代码,并减少或者 消除重复的测试代码,从而也能够提高代码的可读性,减少编写脚本的工作量。Page Object Model的实 现,就是通过分离测试对象和测试脚本的抽象来实现的。
重置元素属性,给定位的元素加背景、边框
-断言的英文是assertion,断言检查的英文是assertion checking。 -断言是指定一个程序必须已经存在的状态的一个逻辑表达式,或者一组程序变量在程序执行期间的某个点上必须满足的条
使用自己熟悉的语言
不需要
get、click
-手工用例中抽取 -可以参考自动化用例的执行策略
-不稳定
-可靠性
-不易维护
-成本与收益
有难度,不推荐
一、网站输入域名直接无法访问,网站之前还正常,突然就无法访问 1.测试FTP是否正常可以登录,不能登录的直接问空间商那是空间商的问题直接联系他们。 2.空间赠送的三级域名是否能够访问网站打开网站(空间都赠送三级域名),如果也不能访问应该是空间问 题。 3.在电脑的开始菜单运行中输入cmd,在弹出的黑框中输入:ping 你的域名;然后回车,如果看不到IP或IP 地址与你的主机地址不符,则说明域名解析有误,是域名的问题得重新解析域名。 二、访问报404错误(无法找到该页)。说明是网站内容都正常是程序出现问题,看看程序是否完整。 三、访问网站出现MySQL Server Error 这个是数据库链接错误,查看数据库连接文件和数据库是不是错 误。 四、访问网站出现500错误。 1.请登录FTP查看是否多了异常文件或丢失文件,说明网站被侵入了,马上联系网站制作进行进行排查故障。 2.如果空间且FTP程序目录没有缺失文件或刚刚安装就出现500错误,请确认空间已开启scandir()函数,查 看是不是禁止了这个函数。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。