1.怎么判断元素是否存在?
判断元素是否存在和是否出现不同, 判断是否存在意味着如果这个元素压根就不存在, 就会抛出NoSuchElementException
这样就可以使用try catch,如果catch到NoSuchElementException 就返回false。通常在项目中会把这个功能封装在isElementPresent方法中。
2.如何判断元素是否出现?
判断元素是否出现,存在两种情况,一种是该元素压根就没有,自然不会出现;另外一种是有这样的元素,但是是hidden状态
可以通过先判断是否存在,如果不存在返回false;如果存在再去判断是否displayed。
3.selenium中hidden或者是display = none的元素是否可以定位到?
不能,想点击的话,可以用js去掉dispalay=none的属性。
4. selenium中如何保证操作元素的成功率?也就是说如何保证我点击的元素一定是可以点击的?
1.通过封装find方法实现waitforEmelentPresent,这样在对元素进行操作之前保证元素被找到,进而提高成功率
2.在对元素操作之前,比如click,如果该元素未display(非hidden),就需要先滚动到该元素,然后进行click操作;为啥使用滚动? 因为如果页面没有完全显示,element如果是在下拉之后才能显示出来,只能先滚动到该元素才能进行click,否则是不能click操作
1 2 3 |
|
3.不同方式进行定位,与expectedConditions判断方法封装,循环判断页面元素出现后再操作;
4.开发人员规范开发习惯,如给页面元素加上唯一的name,id等。
5. 如何去定位页面上动态加载的元素?
触发动态事件,然后findElemnt
如果是动态菜单,需要一级一级find(JS实现)
6.如何去定位属性动态变化的元素?
属性动态变化是指该element没有固定的属性值,所以只能通过相对位置定位
比如通过xpath的轴, parent/following-sibling/precent-sibling等
另外也可以尝试findbyelements遍历
7.点击链接以后,selenium是否会自动等待该页面加载完毕?
不会的。所以有的时候,当selenium并未加载完一个页面时再请求页面资源,则会误报不存在此元素。所以首先我们应该考虑判断,selenium是否加载完此页面。其次再通过函数查找该元素。
8.自动化测试的时候是否需要连接数据库做数据校验?
一般来说1、 UI自动化不需要(很少需要);2、接口测试会需要:从数据库层面来进行数据校验可以更方便验证系统的数据处理方面是否正确;
9.有几种元素常用定位方式,分别是?你最偏爱哪一种,为什么?
8种:id、name、class name、tag name、link text、partial link text、xpath、css selector 偏爱哪一种?答:
我最常用的是xpath(或CssSelector)因为很多情况下,html标签的属性不够规范,无法通过单一的属性定位,这个时候就只能使用xpath可以去重实现定位唯一element
事实上定位最快的是Id,因为id是唯一的,然而大多数开发并没有设置id。
10.怎么提高selenium脚本的自动化执行效率?
1.优化测试用例,尽可不使用 sleep,减少使用ImplicitlyWait
2.多使用selenium的WebDriverWait/FluentWait,这样可以优化等待时间
3.减少不必要的操作步骤,如经过三四步才能打开我们要测试的页面的话,我们就可以直接通过网址来打开,减少不必要的操作。
4.中断页面加载,如果页面加载的内容过多,我们可以查看一下加载慢的原因,如果加载的内容不影响我们测试,就设置超时时间,中断页面加载。
5.使用性能好的电脑
11.用例在运行过程中经常会出现不稳定的情况,也就是这次可以通过,下次无法通过了,如何提高用例的稳定性?
1,查找元素前先做判断:ExpectedConditions里面的各种方法;
2,显式等待:多使用WebDriverWait,加上显式等待时间,等要操作的元素出现之后再执行下面的操作;
3、多用try catch捕获异常;
4,多线程的时候,减少测试用例耦合度,因为多线程的执行顺序是不受控制的;
5,尽量使用测试专用环境,避免其他类型的测试同时进行,对数据造成干扰。
12.你的自动化用例的执行策略是什么?
1.自动化测试用例是用来监控的。集成到jenkins,创建定时任务定时执行;
2.有些用例在产品上线前必须回归。jenkins上将任务绑定到开发的build任务上,触发执行;
3.有些用例不需要经常执行。jenkins创建一个任务,需要执行的时候人工构建即可。
13.什么是持续集成?
频繁的将代码集成到主干,持续性的进行项目的构架,以便能能够快速发现错误,防止分支大幅度偏离主干
14.webdriver client的原理是什么?
在selenium启动以后,driver充当了服务器的角色,跟client和浏览器通信,client根据webdriver协议发送请求给driver。driver解析请求,并在浏览器上执行相应的操作,并把执行结果返回给client.
15.webdriver的协议是什么?
The Wire Protocol
16.启动浏览器的时候用到的是哪个webdriver协议?
http
17. 什么PO模式,什么是page factory?
PO模式是page object model的缩写,顾名思义, 是一种设计模式,把每个页面当成一个页面对象,页面层写定位元素方法和页面操作方法,实现脚本的page和真实的网站页面Map起来,一一对应起来。这样能测试框架更容易维护。 比如一个登陆页面,使用PO模式后,会创建一个LoginPage的class,该class会定义用户名输入框,密码输入框,登陆按钮的webElenent;用例层从页面层调用操作方法,写成用例,这种模式可以做到定位元素与脚本分离。所以这样的设计理念就是PO模式。 而PageFactory隶属PO模式,是用来初始化每个PO模式实现的Page Class,初始化对象库。
18.怎样去选择一个下拉框中的value=xx的option?
1.select类里面提供的方法:selectByValue(“xxx”)
2.xpath的语法也可以定位到
19.如何在定位元素后高亮元素?
重置元素属性,给定位的元素加背景、边框
20. 如何设计高质量自动化脚本
1. 使用四层结构实现业务逻辑、脚本、数据分离。
单元测试四层结构:
1)、DAO层
DAO的目的:根据指定的参数对相关的数据对象进行处理
基本操作有查询操作 对数据源无影响 有返回值
增改操作 影响数据源 无返回值
删除操作 影响数据源 无返回值
从上面我们可以看出,DAO的test主要是针对DAO的3种操作进行测试
对于查询操作我们可以从返回的结果集来进行判断
而对于增改操作和删除操作我们就是只能在方法调用后对数据源进行判断了
这里,现在一般DAO层我们都会使用Spring+hibernate来进行构建,那么一个DAO的实例就需要引入到spring和DAO的相关配置了。而且由于牵扯到外部环境,所以这里外部环境的处理可以采用两种方式,一种是直接使用数据库,这里就需要有一个真实的数据源存在了 二是模拟一个数据源,比如使用内存数据库或者文本数据库来建立一个模拟环境,方便单机进行测试
而且由于DAO是由Spring来进行管理的,所以在测试的时候需要加载Spring的上下文来获取dao的bean,关于spring的加载我使用的是spring-mock,它的好处是在事物处理后可以对相关的数据库操作进行rollback
2)、BL层
BL层的目的:根据业务逻辑对业务处理进行封装
以往其实我们有时候习惯把一些业务逻辑代码放置到上层DAO或者下层Action,taglib中
所以我总结了一下,基本的业务逻辑有:
参数的验证和判断
业务逻辑错误处理
业务规则判断
所以针对于这些功能我们可以把原本属于BL的代码归还给BL了,然后针对于bl的几个功能就可以清晰地编写单元测试了,这时候一般会用到做单元测试时比较有用的一个副产品:重构。而这个副产品的价值将会在你重构后体现出来,DAO,BL,ACTION,taglib的代码职责更加明晰了,该做什么判断的就座什么判断
BL这层一般也是用Spring来进行管理的,所以我们还是需要加载spring的上下文,当然也可以不加载Spring,然后根据接口模拟一个DAO出来,但是我一般觉得这种模拟花消比较大,这个代价是否值得一直是我所怀疑的
3)、Action层
action层的目的:对于请求进行跳转控制
一个控制层方法的主要功能有:获取参数,调用BL对参数进行执行,根据执行的结果进行页面参数赋值,跳转到结果页面
当然上面除了跳转的到结果页以外其他功能都不是必须的
针对于上述功能action的单元测试基本框架是:封装请求参数,发送请求,判断所需的页面bean和跳转的结果页面是否正确
这里牵扯到对于请求环境的模拟,一般不同的前台构架会有不同的模拟方法,struts下我使用的是strutstescase,它可以较为完整的读取Struts配置文件
当然一般在action中会用到Spring的上下文获取bl,由于之前已经对bl进行了测试确认,所以我建议可以直接使用实际的bl,而不是再花费代价开发一个模拟的BL
4)、taglib层
taglib层目的:根据参数在页面上按照固定的样式输出
一个标签的基本功能有:获取参数,调用BL对参数进行执行,把执行结果放到指定样式中,把得到的页面代码输出
相对来说获取参数,调用BL对参数进行执行,把得到的页面代码输出,比较固定,测试的意义不大,所以主要测试的就是把执行结果放到指定样式中这个功能。这个功能通常就是给一个结果集参数然后组合返回一个StringBuffer,所以测试起来也比较容易
但是taglib在使用的时候也需要的Spring甚至Struts的配置,这就需要在初始化的时候把相关环境也要加载进来
2. 使用PO设计模式,将一个页面用到的元素和操作步骤封装在一个页面类中。如果一个元素定位发生了改变,我们只用修改这个页面的元素属性。
3. 对于页面类的方法,我们尽量从客户的正向逻辑去分析,方法中是一个独立场景,例如:登录到退出,而且不要想着把所有的步骤都封装在一个方法中。
4. 测试用例设计中,减少测试用例之间的耦合度。
21.get和post 的区别?
1、GET请求:请求的数据会附加在URL之后,以?分割URL和传输数据,多个参数用&连接。
POST请求:POST请求会把请求的数据放置在HTTP请求包的包体中。
2、传输数据的大小
使用GET请求时,传输数据会受到URL长度的限制。
对于POST,理论上是不会受限制的
3、安全性。POST的安全性比GET的高