自动化测试问题(一) NO.1自动化测试NO.2什么是分层测试？ NO.3自动化测试的应用和不应用场景NO.4你认为自动化测试最大的缺陷是什么？ NO.4项目使用自动化测试框架NO.5库NO.6高质量自动化脚本NO.7脚本如何组织测试用例，如何设计NO.8 page object设置模式， 在page定位方法中，需要在断言NO.9 page object设计模式中添加断言NO.9 page object设计模式吗？ NO.10你的自动化用例的执行策略是什么？ NO.11如何提高用例的稳定性？ NO.12自动化用例fail的故障排除方法什么是NO.13持续集成？ NO.14什么自动化测试需要连接到数据库进行数据验证？ 如何找到NO.15页面上动态加载的元素？ NO.16如何定位属性动态变化的要素？ NO.17使用xpath等待兄弟元素NO.18出现的这个方法是如何实现的？NO.19如何选择下拉框中的value=xx的option？ 放置NO.20元素后，如何加亮元素？ no.21 web驱动程序可以用于接口测试吗？ 什么是NO.22断言和验证？ NO.23什么是数据驱动框架？ 它与关键字驱动框架有什么不同？ 说明使用TestNG而不是no.24JUnit框架的好处吗？ 与no.25@test注释相关的TestNG参数的目的是什么？ 可以使用no.26Testng执行一组测试用例吗？
什么是NO.1自动化测试
自动化测试是指将人为驱动的测试行为转化为机器执行的过程。 也就是说，模拟手动测试的步骤，通过运行测试脚本自动测试软件
自动化测试是一种程序(脚本)测试程序，是利用自动化工具编写和运行测试人员测试脚本和案例的技术
自动化测试的主要目标是减少手动运行的测试用例数量，而不是完全取消手动测试。
什么是NO.2分层测试？ 1 .数据层2 .接口层’3.ui层NO.3自动化测试的应用和不应用场景自动化测试决策基于投资回报(ROI )，自动化测试应用于需求相对稳定(不经常改变)的场景
以下情况建议自动化
使用重复性任务烟雾和理性测试多个数据集进行测试回归测试用例以下场景不适合自动化
临时测试随机测试NO.4您认为被测试的APP应用程序频繁更改的自动化测试的最大缺陷是什么？ appium、selenium、unittest或robotframework，用于不稳定、不可靠且难以维护成本和收入的4号项目
看项目情况回答
根据自动化测试目标的不一致，可分为appUI自动化测试、webUI自动化测试、界面自动化测试3种。
appUI生成框架使用python uniitest appium工具
webUI构建框架使用python selenium unittest
接口测试框架使用python unittest requests
对于NO.5数据库使用，您是如何看待自己最熟悉的数据库、如何使用这些数据库以及是否创建了基于复用的软件包的
请参阅以下内容。
如何封装基类(如： )以等待元素的出现、如何更容易地查找操作元素、与被测试业务相关的类和方法
代码示例：
在classbaseview(object ) : def _ init _ (self，driver ) : self.driver=driver #中获取页面，参数为urldefget (self ) self * loc (: return self.driver.get ) loc ) #常规元素配置#by_idfind_element ) by.id， ' xxx ' )或find_element_by 'xxx ' )或find_element_by_name (' ) by _ XPath find _ element (by.XPath ) ' xxx ' )或find_element_by 'xxx ' )或find_element_by_class_name (' ) by_link_textfind_element ' xxx ' )或find_element_by_link_text (' ' ) by _ partial _ link _ text find _ element ) by.partial link text 或find _ element _ by _ partial _ link _ text (' ' ) by_tag_namefind_element ) by.tagname，' xxx ' (或fffx )
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实现（对动态事件封装）
先去找该元素不变的属性，要是都变，那就找不变的父元素，用层级定位(以不变应万变)
属性动态变化也就是指该元素没有固定的属性值，可以通过：
JS实现，
通过相对位置来定位，比如xpath的轴，paren/following-sibling/percent-sibling
因为兄弟元素和该元素同属于一个父亲节点的元素，所以使用xpath定位一个兄弟元素应先定位父亲节点的元素
NO.18 等待元素出现的这个方法如何实现的用一个循环间隔时间去检查这个元素是否可见
NO.19 怎样去选择一个下拉框中的value＝xx的option？1.select类里面提供的方法：select_by_value（“xxx”）
2.xpath的语法也可以定位到
重置元素属性，给定位的元素加背景、边框
NO.21 webdriver可以用来做接口测试吗？不可以，webdriver是专门做web的UI自动化参数
NO.22 什么是断言和验证？断言（assert）：测试将会在检查失败时停止，并不运行后续的检查
优点：可以直截了当的看到检查是否通过缺点：检查失败后，后续检查不会执行，无法收集那些检查结果状态验证（vertify）：将不会终止测试
缺点：你必须做更多的工作来检查测试结果查看日志——>耗时多，所以更偏向于断言
NO.23 什么是数据驱动框架？它与关键字驱动框架有什么不同？数据驱动框架：
在这个框架中，测试用例逻辑驻留在测试脚本中。测试数据被分离并保存在测试脚本之外。
测试数据是从外部文件（Excel文件）中读取的，并被加载到测试脚本中的变量中。
变量用于输入值和验证值。
关键字驱动框架：
关键字/表驱动框架需要开发数据表和关键字。
它们独立于执行它们的测试自动化工具。
可以使用或不使用应用程序来设计测试。
在关键字驱动的测试中，被测试的应用程序的功能记录在一个表格中，以及每个测试的分步说明。
TestNG相较于Junit的优势：
在JUnit中，我们必须声明@BeforeClass和@AfterClass，这是JUnit中的一个约束，而在TestNG中没有像这样的约束。
TestNG提供了更多的setUp / tearDown级别。
1.@ Before/AfterSuite2.@Before/AfterTest3.@Before/AfterGroupTestNG中不需要扩展任何类。
TestNG中没有方法名称约束，就像JUnit一样。
在TestNG中，我们可以告诉测试一个方法依赖于另一个方法，而在JUnit中这是不可能的。
测试用例的分组在TestNG中可用，而JUnit中则不可用。执行可以基于组完成。例如，如果你已经定义了许多案例，并通过将2个组分别定义为“离职“与”回归”隔离。如果你只是想执行“理智”的情况，那就告诉TestNG执行“理智”。TestNG将自动执行属于“离职”组的案例。
另外，TestNG支持并行测试用例执行。
在TestNG中，参数是修改注释功能的关键字。
NO.26 可以使用TestNG运行一组测试用例吗？是的，TestNG框架支持在测试组的帮助下执行多个测试用例。
它提供了以下选项来运行特定组中的测试用例。
如果想基于回归测试或冒烟测试等其中一个组来执行测试用例，那么：
@Test(groups = {“regression-tests”, “smoke-tests”})