自动化测试常见问题-Toy模板网

这篇具有很好参考价值的文章主要介绍了自动化测试常见问题。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

1、开发能力的帮助

（1）提高编程能力，缺陷定位到更底层，通过Exception或者error日志能够初步判断哪里出了问题，跟开发的沟通更方便。
（2）写脚本过程中，让脚本可复用，可维护，有封装和复用的思想。比如引入做UI自动化测试框架的时候，做关键字驱动。
（3）测试用例和测试计划评审，站在开发的角度提出一些更专业的建议，更好的推动测试工作。

2、测试框架封装的优点

在没有框架的时候是通过工具让人工去运行的，有了框架之后就只需要去维护测试用例，通过跟Jenkins的配置，就能够在迭代的一个周期里面自动的运行测试脚本，自动发现问题，自动生成测试报告，能够省去大量执行回归测试的一个工作。

3、发现问题处理的流程

发现问题，收到邮件，查看日志的问题。

4、接口脚本的维护频率

有新增的业务时，在一个迭代周期里面，在编写完用例后我们更新接口自动化的用例，框架就能够自动化的读取用例执行。

5、共享类

导出jar包，给到测试同事，导入使用，即是热加载。

6、ui自动化的脚本的编写方式

人工编写比脚本录制的维护起来更容易，成本更低。但是冒烟测试和主流程覆盖率不到30%，一些具体的业务还需要人工去测试。

7、docker容器的优点。

（1）利于开发，测试，运维环境的部署（结合项目）；
（2）需要一些依赖的软件直接pull就可以了
（3）docker容器编排可以根据服务的情况实施扩容和减容，以及在容灾方面有很多的效果。
（4）UI自动化中，可以多浏览器，分布式运行UI自动化的用例，从而减少我们的UI用例的测试时间。

8、紧急的项目处理

（1）进行测试计划和风险控制。
（2）提取测试点，可以暂时不写详细的测试用例。
（3）根据开发和产品计划做对接。

9、结果校验

断言的实际：一般返回的是json格式的数据，有三个字段：
code：0
msg：成功返回码的说明
data：数据列表
断言的预期：
①返回码的断言，预期来自接口文档的说明。
②业务的断言，预期来自项目，需求，数据库。根据项目提取关键的业务值。

10、封装的使用情境

（1）可以重复利用的情况，就会封装。
（2）可以增加代码的可维护性的需要封装。
（3）可以使自动化落地简化的需要封装。
（4）能够形成流程化，标准化的需要封装。

11、需要通过JS强制处理的特殊场景

（1）可见不可控（不可读），readonly，比如日历。
（2）不可见，style＝"display:none"，比如隐藏的主键，动态显示。
（3）元素高亮显示。

12、PO模式的定义

PO模式，全称为Page Object Model，简称PO，是页面对象模式。意思是把一个页面当做一个对象，页面的元素就是对象的属性，页面的操作就是对象的行为(方法)，PO模式一般使用三层架构，分别为:基础封装层BasePage，PO页面对象层，TestCase测试用例层。
使用PO模式可以使我们的测试用例更简单，更清晰，很多时候我们可以在页面对象中封装很多业务操作方法，测试脚本只需要调用相关方法就可以。
另一个就是如果有页面元素发生改变，我们只需要去修改这个页面对象的元素定位和相关方法就可以了，不需要修改其它脚本，增加代码的可维护性。

13、数据驱动和关键字驱动的区别

（1）数据驱动是从某个数据文件(例如Excel文件、Csv文件、YAML文件等)中读取输入、输出的测试数据，然后通过数据驱动方法(ddt，paramTerize等)传入自动化测试脚本中。在整个过程中，自动化测试脚本实现数据的读取、测试状态的改变、结果的判断等，从而实现数据和代码分离，这种方式叫数据驱动。
（2）关键字驱动是从面向对象的思路出发，同样的业务逻辑会编写成一个函数作为关键字来被不同的测试脚本所调用。当所有的业务逻辑测试都可以被写好的函数所组合完成时，就是关键字驱动框架。这个时候测试用例的开发就变成了测试数据和关键字的组合，并把这种组合工作简化为所有人都很熟悉的表格填写任务，从而最终达到一个由数据和关键字驱动整个测试的效果。

14、自动化测试常用的Python库和常见的异常

（1）web自动化测试:
webdriver，WebDriverWait，By，os，xlrd，xlwt，unittest/pytest，time，logging，HTMLTestRunner等。
（2）接口自动化测试:
requests，time，logging，json，csv,jsonpath，pyyaml，re，unittest/pytest，allure。
（3）常见的异常有以下:
NoSuchElementException：没有如此元素异常；
NoSuchAttributeException：没有如此属性异常
NoSuchFrameExceptio：没有如此frame异常
ElementNotSelectableException：元素不能选择异常
ElementNotVisibleException：元素不可见异常
Element not visible at this point：在当前点元素不可见
TimeoutException：超时异常

15、自动化测试误报的原因

误报就是指自动化测试发现了 bug，实际去通过手工测试去确认又不存在该bug;
误报原因可能是:
(1)元素识别不稳定–尽量提高脚本的稳定性;
(2)开发更新了页面–测试没有及时维护；

16、ui自动化元素定位方法

定位方法:id，name，xpath，css，link text，partial link text，tag name，class name
定位不到的原因可能是:
1.定位器或者是定位字符串选择错误；
2.页面加载元素过慢，加等待时间；
3.页面有frame/iframe框架页，需要先跳转入frame框架再定位；
4.元素在新打开的窗口window中；
5.可能该元素是动态元素，定位方式要优化，可以使用部分元素定位或通过父节点或兄弟节点定位。
6.可能识别了元素，但是不能操作，比如元素不可用，不可写等。需要使用 js 先做处理；
7.元素可能不在当前页面。

17、Webdriver中关闭浏览器的quit和close的区别

简单来说，这两个都可以实现退出浏览器session功能；
close 是关闭你当前聚焦的 tab 页面，而quit 是关闭全部浏览器tab页面，并退出浏览器session。
close用在执行单个用例过程中关闭某一个页面的操作，quit一般用在结束测试之前的操作。

18、ui自动化三类等待的特点

（1）线程等待(强制等待)如time.sleep(3)：线程强制休眠3秒钟，3秒过后，再执行后续的代码、建议少用。
（2）imlicitlyWait(隐式等待)：这种是全局设置的等待，如设置超时时间为 10秒，使用了implicitlyWait后，如果第一次没有找到元素，会在10秒之内不断循环去找元素，如果超过10秒还没有找到，则抛出异常，特点是必须等待整个页面加载完成。
（3）WebDriverWait(显式等待)：也称为智能等待，通常是我们自定义的一个函数代码，这段代码用来针对指定元素定位指定等待时间，在指定时间范围内进行元素查找，找到元系则直接返回，如果在超时还没有找到元素，则抛出异常，显示等待是selenium 当中比较灵活的一种等待方式，他的实现原理其实是通过whiie 循环不停的尝试需要进行的操作。

19、验证码的几种处理方式

（1)在产品没有上线前，需要找开发将验证码先注释掉，或者让开发给web验证码留一个万用验证码，只要输入给定的验证码，就可以强制登录
（2)可以通过Coakie 跳过登录验证码
（3)滑块验证码可以直接使用人工智能+代码的方式处理。
（4)使用第三方的验证码识别技术(比如百度智能)

20、selenium处理多窗口

当你点击一个链接，这个链接会在一个新的tab打开，然后你接下来要在新tab打开的页面定位元素并处理。步骤如下，
1.我们在点击链接前使用driver_corent_window_handle获得当前窗口句柄；
2.再点击链接，点击后通过 driver_window_handles获得所有窗口的句柄；
3.然后再循环找到新窗口的句柄，然后再通过driver_switch_to.window()方法跳转到新的窗口；
4.window 太多则可以按照title、url等其它信息进行判断切换。

21、iframe里面元素定位

有时候我们写的元素定位表达式没有问题，但是脚本还是提示nosuchelement，那么我们就需要考虑这个元素是否在frame/iframe中。通过f12查看元素HTML中是否有 frame/iframe标签，如果有frame/iframe，需要先将driver切换到frame/iframe中，可以通过frame的name和id和索引三种方法来定位frame，步骤如下:
先用driver.switch to.frame()跳转进去frame，然后再操作页面元素，操作完后使用driver.swith to.defaultcontent跳转出来。