自动化测试面试题（一）

NO.1 什么是自动化测试

自动化测试就是把以人为驱动的测试行为转化为机器执行的一种过程，即模拟手工测试的步骤，通过执行测试脚本自动地测试软件；

自动化测试就是程序（脚本）测试程序,使用自动化工具编写、执行测试人员测试脚本和案例的技术

自动化测试的主要目标是减少手动运行的测试用例数量，而不是完全取消手动测试。

NO.2 什么是分层测试？

• 1.数据层
• 2.接口层’
• 3.UI层

NO.3 自动化测试的适用和不适用场景

自动化测试决定基于ROI（投资回报率），自动化测试适用于需求比较稳定（不经常变更）的场景

在以下情况下首选自动化

• 重复性任务
• 烟雾和理智测试
• 使用多个数据集进行测试
• 回归测试用例

以下场景不适合用自动化

• 受测试的应用程序频繁更改
• 临时测试
• 随机测试

NO.4 你觉得自动化测试最大的缺陷是什么？

• 不稳定
• 可靠性不强
• 不易维护
• 成本与收益

NO.4 项目使用的自动化测试框架

appium 、selenium、unittest 或 robotframework
看项目情况回答

根据自动化测试目标不一致，分为三种：appUI自动化测试，webUI自动化测试，接口自动化测试。
appUI搭建框架使用python+uniitest+appium工具
webUI搭建框架使用python+selenium+unittest
接口测试框架使用python+unittest+requests

NO.5 对库的使用

自己最熟悉哪个库，如何使用这些库的，是否做了基于复用的封装，怎么考虑的这些封装

参考以下内容：
分别封装了基础类例如:等待某元素出现的方法，更方便查找操作元素的方法，和被测试业务相关的类和方法

代码举例：

class BaseView(object):
def __init__(self, driver):
        self.driver = driver

    # 获取一个页面,参数为url
    def get(self, *loc):
        return self.driver.get(*loc)

    # 普通元素定位
    # by_id  find_element(By.id,'xxx')或find_element_by_id('')
    # by_name  find_element(By.name,'xxx')或find_element_by_name('')
    # by_xpath  find_element(By.xpath,'xxx')或find_element_by_xpath('')
    # by_class_name  find_element(By.className,'xxx')或find_element_by_class_name('')
    # by_link_text  find_element(By.linkText,'xxx')或find_element_by_link_text('')
    # by_partial_link_text  find_element(By.partialLinkText,'xxx')或find_element_by_partial_link_text('')
    # by_tag_name  find_element(By.tagName,'xxx')或find_element_by_tag_name('')
    # by_css_selector  find_element(By.cssSelector,'xxx')或find_element_by_css_selector('')
    def find_element(self, *loc):
        return self.driver.find_element(*loc)

    # 元素定位返回一个数组list，一般用于判断元素是否存在
    def find_elements(self, *loc):
        return self.driver.find_elements(*loc)

    # 获取屏幕大小
    def get_window_size(self):
        return self.driver.get_window_size()

    # 滑动屏幕
    def swipe(self, star_x, star_y, end_x, end_y, duration):
        return self.driver.swipe(star_x, star_y, end_x, end_y, duration)

    # 时间等待(隐形等待)
    def implicitly_wait(self, t):
        return self.driver.implicitly_wait(t)

    # 时间等待(显性等待)
    def web_driver_wait(self, t, s):
        # 由于不长使用,不再进行具体的封装
        # 每经过s秒就查看一次指定元素是否可见,如果操作ts薄超时异常
        return WebDriverWait(self.driver, t, s)  # 可以配合until或者until_not方法，再辅助以一些判断条件，就可以构成这样一个场景

NO.6 如何设计高质量自动化脚本

• 1.使用四层结构实现业务逻辑、脚本、数据分离。
• 2.使用PO设计模式，将一个页面用到的元素和操作步骤封装在一个页面类中。如果一个元素定位发生了改变，我们只用修改这个页面的元素属性
• 3.对于页面类的方法，我们尽量从客户的正向逻辑去分析，方法中是一个独立场景，例如：登录到退出，而且不要想着把所有的步骤都封装在一个方法中。
• 4 测试用例设计中，减少测试用例之间的耦合度。

NO.7 如何在脚本中组织测试用例，按什么模式设计

按page object设计模式（PO模式）

page object设计模式:

• 1.通俗来讲，把每个页面当成一个页面对象，页面层写定位元素方法和页面操作方法
• 2.用例层从页面层调用操作方法，写成用例
• 3.可以做到定位元素与脚本的分离

NO.8 page object设置模式中，是否需要在page里定位的方法中加上断言

不需要，page页只做元素抓取和操作方法

NO.9 page object设计模式中，如何实现页面的跳转？

初始化driver参数，Page类传driver参数

NO.10 你的自动化用例的执行策略是什么？

• 1.自动化测试用例是用来监控的。集成到jenkins，创建定时任务定时执行；
• 2.有些用例在产品上线前必须回归。jenkins上将任务绑定到开发的build任务上，触发执行；
• 3.有些用例不需要经常执行。jenkins创建一个任务，需要执行的时候人工构建即可。

NO.11 如何去提升用例的稳定性？

用例在运行过程中经常会出现不稳定的情况，也就是说这次可以通过，下次就没办法通过了

可采用以下措施：

• 1.在经常检测失败的元素前尽量加上显式等待时间，等要操作的元素出现之后再执行下面的操作；
• 2.多线程的时候，减少测试用例耦合度，因为多线程的执行顺序是不受控制的；
• 3.多用 try 捕捉，处理异常；
• 4.尽量使用测试专用环境，避免其他类型的测试同时进行，对数据造成干扰。

NO.12 自动化遇到用例fail掉如何排查故障

按层次说清楚排查失败：

• 手工查应用是否真的有bug,
• 确认不是bug，是不是新版本引入了新的变更；调试脚本看看自己的脚本是不是因为没有等待元素出现后就操作了；是不是元素上面有其他元素出现这样操作是不是操作了其他的元素上了

NO.13 什么是持续集成？

频繁的将代码集成到主干，持续性的进行项目的构架，以便能能够快速发现错误，防止分支大幅度偏离主干

NO.14 什么自动化测试的需要连接数据库做数据校验？

• UI自动化不需要
• 接口测试会需要

NO.15 如何去定位页面上动态加载的元素？

首先触发动态事件，然后再定位。
如果是动态菜单，则需要层级定位。——JS实现（对动态事件封装）

NO.16 如何去定位属性动态变化的元素？

先去找该元素不变的属性，要是都变，那就找不变的父元素，用层级定位(以不变应万变)
属性动态变化也就是指该元素没有固定的属性值，可以通过：
JS实现，
通过相对位置来定位，比如xpath的轴，paren/following-sibling/percent-sibling

NO.17 如何使用xpath定位一个兄弟元素

因为兄弟元素和该元素同属于一个父亲节点的元素，所以使用xpath定位一个兄弟元素应先定位父亲节点的元素

NO.18 等待元素出现的这个方法如何实现的

用一个循环间隔时间去检查这个元素是否可见

NO.19 怎样去选择一个下拉框中的value＝xx的option？

1.select类里面提供的方法：select_by_value（“xxx”）
2.xpath的语法也可以定位到

NO.20 如何在定位元素后高亮元素（以调试为目的）？

重置元素属性，给定位的元素加背景、边框

NO.21 webdriver可以用来做接口测试吗？

不可以，webdriver是专门做web的UI自动化参数

NO.22 什么是断言和验证？

断言（assert）：测试将会在检查失败时停止，并不运行后续的检查

• 优点：可以直截了当的看到检查是否通过
• 缺点：检查失败后，后续检查不会执行，无法收集那些检查结果状态

验证（vertify）：将不会终止测试

• 缺点：你必须做更多的工作来检查测试结果

查看日志——>耗时多，所以更偏向于断言

NO.23 什么是数据驱动框架？它与关键字驱动框架有什么不同？

数据驱动框架：
在这个框架中，测试用例逻辑驻留在测试脚本中。测试数据被分离并保存在测试脚本之外。
测试数据是从外部文件（Excel文件）中读取的，并被加载到测试脚本中的变量中。
变量用于输入值和验证值。

关键字驱动框架：
关键字/表驱动框架需要开发数据表和关键字。
它们独立于执行它们的测试自动化工具。
可以使用或不使用应用程序来设计测试。
在关键字驱动的测试中，被测试的应用程序的功能记录在一个表格中，以及每个测试的分步说明。

NO.24 解释使用TestNG而不是JUnit框架的好处？

TestNG相较于Junit的优势：

• 在JUnit中，我们必须声明@BeforeClass和@AfterClass，这是JUnit中的一个约束，而在TestNG中没有像这样的约束。

• TestNG提供了更多的setUp / tearDown级别。

  • 1.@ Before/AfterSuite
  • 2.@Before/AfterTest
  • 3.@Before/AfterGroup

• TestNG中不需要扩展任何类。

• TestNG中没有方法名称约束，就像JUnit一样。
  在TestNG中，我们可以告诉测试一个方法依赖于另一个方法，而在JUnit中这是不可能的。

• 测试用例的分组在TestNG中可用，而JUnit中则不可用。执行可以基于组完成。例如，如果你已经定义了许多案例，并通过将2个组分别定义为“离职“与”回归”隔离。如果你只是想执行“理智”的情况，那就告诉TestNG执行“理智”。TestNG将自动执行属于“离职”组的案例。
  另外，TestNG支持并行测试用例执行。

NO.25 与@Test注释相关的TestNG参数的目的是什么？

在TestNG中，参数是修改注释功能的关键字。

NO.26 可以使用TestNG运行一组测试用例吗？

是的，TestNG框架支持在测试组的帮助下执行多个测试用例。
它提供了以下选项来运行特定组中的测试用例。
如果想基于回归测试或冒烟测试等其中一个组来执行测试用例，那么：
@Test(groups = {“regression-tests”, “smoke-tests”})