自动化测试主要用于回归测试，因此自动化用例来源于我们编写的功能用例，不管是接口的还是业务测试的用例。所以我们会从原有用例中进行筛选，筛选出需要实现自动化测试的，但是这个实现过程并不是按部就班，需要根据原有用例进行自动化用例设计，比如修改昵称这样的功能，自动化用例中需要实现每次修改都和上一次不一样，否则无法验证修改是否正确。增加了这样的设计之后再按照使用脚本来实现自动操作的过程，并实现结果判断，也就是断言

不多

那么自动化测试的价值是什么? 怎么证明它不是伪需求?

比起发现bug,自动化测试更擅长保持旧有的功能没有bug出现

引用自动化测试之后，能代替大量繁琐的回归测试工作，把业务测试人员解放出来，既而让业务测试人员把精力集中在复杂的业务功能模块上

一般来说相对稳定的功能更适合自动化

功能自动化尽可能用接口\验收自动化则使用端到端

回归测试效率和频次的提升

可以说出以下自己擅长的一种：

1.pytest+requests+allure

2.python+selenium+pytest+allure

3.robotframework+Selenium2Library

CI 持续集成主要是在开发范围，包括：构建>单元测试；主要针对在集成新代码时所引发的问题（亦称：“集成地狱”）。

主要关联git技术\代码管理现代应用开发的目标是让多位开发人员同时处理同一应用的不同功能。但是，如果企业安排在一天内将所有分支源代码合并在一起（称为“合并日”），最终可能造成工作繁琐、耗时，而且需要手动完成。这是因为当一位独立工作的开发人员对应用进行更改时，有可能会与其他开发人员同时进行的更改发生冲突。如果每个开发人员都自定义自己的本地集成开发环境（IDE），而不是让团队就一个基于云的 IDE 达成一致，那么就会让问题更加雪上加霜。

持续集成（CI）可以帮助开发人员更加频繁地（有时甚至每天）将代码更改合并到共享分支或“主干”中。一旦开发人员对应用所做的更改被合并，系统就会通过自动构建应用并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对应用造成破坏。这意味着测试内容涵盖了从类和函数到构成整个应用的不同模块。如果自动化测试发现新代码和现有代码之间存在冲突，CI 可以更加轻松地快速修复这些错误。

CD持续交付涉及开发、测试、运维合作,包括：构建>测试环境部署>测试（不涉及生产环境的自动化部署）完成CI中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确保 CI已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。

在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中。这个阶段应该关联接口\ui的自动化测试

1.线程等待（强制等待）如time.sleep(2)：线程强制休眠2秒钟，2秒过后，再执行后续的代码。建议少用。

2.imlicitlyWait（隐式等待）会在指定的时间范围内不断的查找元素，直到找到元素或超时，是一种全局性设置，可以随时更改，并且只针对查找元素生效

3.WebDriverWait（显式等待）通常是我们自定义的一个函数代码，这段代码用来等待某个元素加载完成，再继续执行后续的代码，可以针对js弹框、iframe、新窗口等进行实施

id：根据id来获取元素，返回单个元素，id值一般是唯一的；

name：根据元素的name属性定位；

tagName：根据元素的标签名定位；

className：根据元素的样式class值定位；

linkText：根据超链接的文本值定位；

partialLinkText：根据超链接的部分文本值定位；

cssSelector：css选择器定位；

xpath：通过元素的路径来定位；

优先级最高：ID

优先级其次：name

优先级再次：CSS selector

优先级再次：Xpath

①CSSlocator比XPathlocator速度快,因为css是配合html来工作，它实现的原理是匹配对象的原理，而xpath是配合xml工作的，它实现的原理是遍历的原理，所以两者在设计上，css性能更优秀

②对于class属性Css能直接匹配部分，而Xpath对于class跟普通属性一致

③xpath可匹配祖先元素,css不可以

④查找兄弟元素， Css只能查找元素后面(弟弟妹妹)的元素，不能向前找(哥哥姐姐)

当然可以，我写的用例可以在在IE，火狐和谷歌这三种浏览器上运行。实现的思路是封装一个方法，分别传入一个浏览器的字符串，如果传入IE就使用IE，如果传入FireFox就使用FireFox，如果传入Chrome就使用Chrome浏览器，并且使用什么浏览器可以在总的ini配置文件中进行配置。需要注意的是每个浏览器使用的驱动不一样。

这个问题，不管是自动化还是任何工作，都会被问到。主要想知道你是如何解决问题的，从而推断你问题分析和解决的能力。当然有遇到问题和挑战，主要有以下几点：频繁地变更UI，经常要修改页面对象里面代码 运行用例报错和处理，例如元素不可见，元素找不到这样异常 测试脚本复用，尽可能多代码复用 一些新框架产生的页面元素定位问题，例如ck编辑器，动态表格等

PO是Page Object 模式的简称，它是一种设计思想，意思是，把一个页面，当做一个对象，页面的元素和元素之间操作方法就是页面对象的属性和行为，PO模式一般使用三层架构，分别为：基础封装层BasePage，PO页面对象层，TestCase测试用例层。

对于简单的Selenium自动化测试，我们要做的不过是找到页面元素，并且值传递给这些元素。但是假如有10个脚本同时调用了一个相同的页面元素，当这个元素发生改变，我们需要修改10个脚本。随着脚本数的增加，时间工作复杂度也飞速增长。这个时候我们就可以考虑设计一个类，专门用来页面元素的查找、传递值和修正。这样，当一个页面元素发生改变的时候，只用修改一个类，而不用同时修改10个脚本。

Page Object是一种程序设计模式，将面向过程转变为面向对象( 页面对象)，将测试对象（按钮、输入框、标题等）及单个的测试步骤封装在每个Page对象中，以page为单位进行管理。

这样，在Selenium测试页面中可以通过调用页面类来获取页面元素，从而巧妙的避免了当页面元素id或者位置变化时，需要改测试页面代码的情况。当页面元素id变化时，只需要更改测试页Class中页面的属性即可。可以使代码复用，降低维护成本，提高程序可读性和编写效率。

POM 解决的问题：

以页面为单位，集中管理元素对象和方法。当页面元素或流程变动时只需要修改相关页面方法即可，不需要修改相应脚本编写脚本简单，顺着业务逻辑写脚本。page object模式以业务逻辑上的每一步操作作为区分点，页面方法代表了此页面的一个业务操作并严格控制此操作的后续流程
后期维护方便

在编写PO前，建议先掌握以下几个知识点：

selenium库的基础运用

xpath语法

pytest 或者 unittest

面向对象中的类 和 继承

说在前边：PO模式是一种设计思想，在实际编码的时候可以有若干种实现方式。实际上，也建议大家根据自己项目的情况来动态的编码。具体来说，常见的PO模式有：

1）三层：对象库层+case层+page层

2）四层：对象库层+case层+page层+公共类

考点：

①. 是否具备接口测试实际经验

②. 是否熟悉接口测试的流程

③. 是否熟悉接口测试的具体步骤

④. 是否熟悉接口测试用例设计

参考答案：

先了解接口的业务功能、入参出参以及接口对应的数据存储，再依据接口测试用例设计方法完成接口测试的设计，用例设计先业务场景再参数判断，比如参数的边界值、格式、组合等等，最后依据测试用例使用接口测试工具完成接口测试，并在测试过程中查看日志及数据以确保接口测试结果的正确性

考点：

对接口测试的熟悉程度

测试软技能

1.没有接口文档，那就需要先跟开发沟通，然后整理接口文档（本来是开发写的，没办法，为了唬住面试官，先说自己整理了）

2.没有接口文档，可以抓包看接口请求参数，然后不懂的跟开发沟通

考点:

接口测试用例设计

参考答案:

1）必填字段：请求参数必填项、可选项

2）合法性：输入输出合法、非法参数

3）边界：请求参数边界值等

4）容错能力：大容量数据、频繁请求、重复请求（如：订单）、异常网络等的处理

5）响应数据校验：断言、数据提取传递到下一级接口…

6）逻辑校验：如两个请求的接口有严格的先后顺序，需要测试调转顺序的情况

7）性能：对接口模拟并发测试，逐步加压，分析瓶颈点

8）安全性：构造恶意的字符请求，如：SQL注入、XSS、敏感信息、业务逻辑（如：跳过某些关键步骤；未经验证操纵敏感数据）

考点：

①. 是否熟悉加解密方式

②. 是否具备处理加密参数的能力

③. 是否实际应用过

参考答案：

首先了解参数的加解密方式，常见的有md5、aes、rsa等等，如果是aes的需要找开发要私钥，如果是rsa需要找开发要公钥和私钥，然后在接口测试工具中引用加解密的代码实现参数的加解密过程，实现参数加解密的处理；如果公司有自定义的加密算法则需要找开发要加解密的代码实现，然后在测试工具中使用。

问题1：设计接口测试⽤用例例时，涉及的是电商系统，其中包括很多修改，如商品、商家、店铺等等，针对这些数据的修改，会涉及到很多参数。如商品的名称，商品的尺码，商品的颜色等等。那在设计实现“修改”接口时，如何确定要传哪些参数,是只需要传我要修改的参数，还是全部参数都要传？

考点：

①. 考察对企业中接口通信机制的认识

②. 考察同步通信和异步通信的原理

参考答案：

同步和异步是一种通讯方式

同步：执行一个操作时，需要等待其处理完成，然后再进行下一个操作

异步：执行一个操作时，不需要等待返回，就进行下一个操作，一般需要使用消息中间件

举例：

下单接口中，需要调用库存接口做库存判断，所以必须等待库存接口返回数据才能进行下一步操作，这是同步；

下单接口中，下单成功后需要调用邮件通知接口，不用等待接口返回成功，就可以直接进行下一步操作，这是异步

考点：

考察使用pytest组织case的能力

参考答案：

1.默认使用检查以test_ .py 或**test.py命名的文件名，在文件内部查找以test打头的方法或函数，并执行

2.可以使用自定义marker（标签），比如pytest运行的时就只运行带有该marker的测试用例，比如下面的@pytest.mark.P0

3.在pytest.ini配置文件中可以针对pytest执行时的case做处理，比如要执行某个目录下的用例，执行某个脚本文件等等

考点：

pytest基础知识

参考答案：

几个常用的钩子：

pytest_runtest_makereport(item,call): 针对测试报告进程处理，比如失败截图

pytest_collection_modifyitems(items)：在case收集后调用，可以对项目顺序或其他功能进行自定义

pytest_addoption(parser):为命令行添加自定义参数，比如指定浏览器名称

1. appium的工作原理

这个题目考察的就是appium工作原理

appium工作原理需要分很多方面进行阐述

安卓：

1.1 appuim基于uiautomator2的原理

Appium服务启动后默认在4723端口上创建一个http服务，脚本通过服务地址http://xxxx:4723/wd/hub 和appium进行通信在初始化脚本和appium连接的过程中appium会向手机就安装辅助app uiautomator2.server.apk和uiautomator2.server.test.apk，并且做端口转发adb forward tcp 8200 tcp 6790,安装以后会在手机上启动uiautomator2的server，这个server启动后会在手机上创建一个netty server，端口是6790，appium和手机上的uiautomator2 server的6790端口进行通信，把从4723端口收到的脚本指令通过8200端口转发到手机的6790端口上

1.2 Appium基于uiautomator1的原理

Appium服务启动后默认在4723端口上创建一个http服务，脚本通过服务地址http://xxxx:4723/wd/hub 和appium进行通信在初始化脚本和appium连接的过程中appium会向手机发送AppiumBootstrap.jar，并且做端口转发adb forward tcp 4724 tcp 4724,安装以后会在手机上启动AppiumBootstrap.jar，启动后会在手机上创建一个socket服务，端口是4724，appium和手机上的socket服务的4724端口进行通信，把从4723端口收到的脚本指令通过4724端口转发到手机的4724端口上

1.3 Appium基于chromedriver的原理，测试H5时使用

Appium服务启动后默认在4723端口上创建一个http服务，脚本通过服务地址http://xxxx:4723/wd/hub 和appium进行通信在初始化脚本和appium连接的过程中会启动chromedriver创建一个http服务，端口是8000，appium和chromedriver的服务通过8000端口进行通信，chromedriver服务接收到appium指令后去操作手机，操作完成再返回给appium，appium再返回给脚本

1.4 IOS手机：

Appium服务启动后默认在4723端口上创建一个http服务，脚本通过服务地址http://xxxx:4723/wd/hub 和appium进行通信在初始化脚本和appium连接的过程中会向手机编译安装webdriveragent app，并且启动wda在手机上创建一个基于8100的http服务，appuim通过4723的端口接收到脚本传递的指令，appium再通过本地的8100端口将收到的指令转发给手机上8100 wda服务，wda服务接收到指令再去操作待测app，操作完成后返回给appium操作结果，appium再将结果返回给脚本

在java自动化测试中解析json的第三方包有很多，比如fastjson、gson等等，如果不使用第三方的话则需要采用java原生的字符串处理方法，比如一个json字符串是{“name”:“shamo”,“age”:18,“job”:“tester”}，可以采用字符串分割、替换等方式拆解，得到其中某个字段对应的值

Testng的监听器在自动化中的使用主要集中在失败截图和失败重试
失败重试的需要实现两个接口IRetryAnalyzer、IAnnotationTransformer
失败截图的需要实现ITestListener
实现后需要在testng的配置文件中增加监听标签
Testng的数据驱动返回结果是一个二维数组，因此在做数据驱动时，不管我们的数据是存在excel、xml或者数据库等存储介质中，最终我们都需要将他们转换成二维数组

自动化测试框架涵盖基础方法封装、自定义异常封装、工具类封装、元素管理封装、Page Object模式封装、日志封装、数据管理封装、失败重试封装、浏览器/手机适配封装、数据库操作封装、测试用例管理封装、测试报告等等

1.相同点都是智能等待，在一定时间范围内不断查找元素，一旦找到立刻结束查找继续执行代码，没找到才会一直找到超时为止

2.不同点是隐式等待是全局性设置，并且可以随时更改，在更改后对之后的findxxx方法生效，对点击、输入、滑动之类的操作不起作用；

显式等待仅仅针对单一元素或一组生效，并且不仅仅是针对查找，还可以针对弹框或者frame等特殊情况起作用，也可以针对元素的某些属性进行自定义判断

Testng单元测试框架中有基本的9大注解，BeforeSuit/AfterSuit、BeforeTest/AfterTest、BeforeClass/AfterClass、BeforeMethod/AfterMethod、Test，其中比较特殊的注解是BeforeMethod/AfterMethod，他的含义是在每一个@Test注解执行前后都会被执行

接口关联指的就是一个接口要使用另一个接口的返回值作为参数，这种我们在jmeter中叫做关联。

关联的实现方式有多种：

使用正则表达式提取器获取上一个请求的响应结果中的某个值，储存在某个变量中，然后下一个接口使用变量进行引用

使用json提取器获取上一个请求的响应结果中的某个值，储存在某个变量中，然后下一个接口使用变量进行引用

使用beanshell后置处理器，解析响应结果存储在变量中，然后下一个接口使用变量进行引用

跨线程组关联则需要将关联字段设置为全局属性

首先各公司自动化和手工的占比取决于对自动化测试的投入，这个问题的回答建议做好数据，比如我们的功能测试用例总计1000，从其中分析出要实现的自动化用例300条，那么自动化的占比就出来了。那么哪些测试用例会被用来做自动化，稳定模块的用例、功能优先级高的用例。手工测试一般用来做新功能测试业务，自动化一般用来做旧的功能用来回归业务

自动化测试稳定性主要表现在两个方面：一个是元素定位的问题，一个是用例之间的依赖问题。元素定位问题可以采用智能等待的方式尽可能的避免；用例依赖可以解耦用例之间的关系，让每条用例都从一个共同的页面开始执行，比如首页，这就需要在测试框架中采用后置处理的方式使每条用例执行完成后都回到首页。

会话（Session）跟踪是Web程序中常用的技术，用来跟踪用户的整个会话Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份

区别：

1、数据存放位置不同：cookie数据存放在客户的浏览器上，session数据放在服务器上。

2、安全程度不同：cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,考虑到安全应当使用session。

3、性能使用程度不同：session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能,考虑到减轻服务器性能方面，应当使用cookie。

4、数据存储大小不同：单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie，而session则存储与服务端，浏览器对其没有限制。

不管是接口自动化还是ui自动化都会存在自动化case依赖数据如何构造的问题，可以从三个方面去考虑，第一个是在测试前采用接口去构造需要的数据；第二个是使用初始化sql去初始化数据，但是如果说表结构复杂的话，sql编写也是比较大的工作量；第三个方式是提前准备好一套数据，并且将该数据对应的数据库进行备份，在之后每次执行测试前先备份当前数据库数据，再导入之前的测试数据，再执行测试，测试执行完后再恢复原有的数据

web端自动化通常采用selenium的grid方式可以实现多浏览器的测试，也可以采用Testng的多线程配置方式实现不同浏览器的本地测试；appium本身也支持移动端多设备的测试，需要注意的是一台设备必须对应一个appium服务，同样可以采用grid方式或者本地多设备测试；或者通通采用jenkins的多节点方式实现

首先接口测试方式不同则处理方式不同，如果用的jmeter则无需特殊处理，jmeter默认会自动处理重定向接口自动发起对重定向的接口地址的访问并返回结果；如果是采用代码框架的方式则需要特殊处理，拿到第一个接口响应header中的location字段对应的接口地址，发起对该地址的请求

这种情况下我们会采用mock的方式来模拟第三方接口的返回，但是注意这种mock一般都需要开发配合，将自己公司的接口调用指向mock出来的接口服务

restful规范的接口中，通常是一个url就代表一种资源，对于资源的操作是通过http请求方法实现的，其中有get、post、put、delete四种方式，get表示获取数据、post表示新增数据、put表示修改数据、delete表示删除数据

1.iframe元素，当要操作的元素在iframe中是需要先将driver切换至该iframe才能操作，切换方式有四种，通过id、name、索引、iframe元素对象，并且在多iframe切换时还需要进行各种转换

2.新窗口打开，当要操作的元素在一个新窗口打开的页面上时，就需要先将driver切换至新窗口上才能进行操作

3.时间控件，通常时间控件只能选择无法输入，那么可以采用js的方式修改时间控件的只读属性然后再进行输入，或者用js直接修改时间控件的value值

4.元素不在当前视野需要滚动才会出现，可以采用js的方式滚动，但是有时候界面中有多个滚动条js就会无效，则需要先将光标置入到滚动条区域然后模拟键盘的上下左右键来操作

一般情况下手机解锁的大元素可以定位到，那么可以先定位大元素，然后获取该元素的起始点坐标及长和宽，通过坐标计算出手势解锁需要的9个点的坐标，然后调用TouchAction里的press.moveTo.moveTo方法实现手势解锁

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.对异常进行处理

7、你一般一天能编写多少个自动化脚本
这个取决于测试用例场景的复杂度，一般一天能写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()函数，查看是不是禁止了这个函数。

总结：

感谢每一个认真阅读我文章的人！！！

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

          视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。