一、测试用例再执行点击元素时失败，导致整个测试用例失败。如何提高点击元素的成功率?

解决办法：selenium是在点击元素时是通过元素定位的方式找到元素的，要提高点击的成功率，必须保证找到元素的定位方式准确。但是在自动化工程的实施过程中，高质量的自动化测试不是只有测试人员保证的。需要开发人员规范开发习惯，如给页面元素加上唯一的name,id等，这样就能大大地提高元素定位的准确性。当然如果开发人员开发不规范，我们在定位元素的时候尽量使用相对地址定位，这样能减少元素定位受页面变化的影响。只要我们元素定位准确，就能保证我的每一个操作符合我的预期。

二、脚本太多，执行效率太低，如何提高测试用例执行效率?

解决办法：Selenium脚本的执行速度受多方面因素的影响，如网速，操作步骤的繁琐程度，页面加载的速度，以及我们在脚本中设置的等待时间，运行脚本的线程数等。所以不能单方面追求运行速度的，要确保稳定性，能稳定地实现回归测试才是关键。

我们可以从以下几个方面来提高速度：

• 1)减少操作步骤，如经过三四步才能打开我们要测试的页面的话，我们就可以直接通过网址来打开，减少不必要的操作。

• 2)中断页面加载，如果页面加载的内容过多，我们可以查看一下加载慢的原因，如果加载的内容不影响我们测试，就设置超时时间，中断页面加载。

• 3)在设置等待时间的时候，可以sleep固定的时间，也可以检测某个元素出现后中断等待也可以提高速度。

• 4)配置testNG实现多线程。在编写测试用例的时候，一定要实现松耦合，然后在服务器允许的情况下，尽量设置多线程运行，提高执行速度。

三、测试脚本不稳定，命名调试通过的，执行到一半的时候又失败，怎么优化?

解决办法：此时我们要分析出不稳定的原因，然后有针对性的去解决问题。主要有以下几个方面 ：

1)网速问题：有的时候网页加载的比较慢，在程序执行的时候要操作的元素没有显示出来。这种情况比较常见，运行一次网速好的时候通过了，再运行一次，页面没有打开，就不通过了。为了提高稳定性，我们只能牺牲运行时间了，在经常检测失败的元素前加上等待时间，等要操作的元素出现之后再执行下面的操作。

2)Selelnium的原因：Selenium1.0和2.0还是有区别的，有些儿函数在2.0下运行确实有时而有效，时面无效。如果mouseover()函数，就是这种情况，  我们需要避免使用这类的函数。

3)多线程的时候，测试用例间相互影响。虽然多线程的时候运行速度比较快，但是如果用例之间的耦合性没有设计好，也会影响的，如果用例A先于用例B执行的时候，就会影响到用例B;反之则没有问题。这种情况，如果你的自动化测试工程打算多线程的时候，提前就要把测试用例测试的耦合度比较松，尽量没有任何关系，因为多线程的执行顺序是不受控制的。

四、自动化测试框架都有哪些?

1.模块化框架(test script modularity)

2.函数库结构框架(test library architecture)

3.关键字驱动测试框架(keyword-driven/table-driven testing)

4.数据驱动测试框架(data-driven testing)

5.混合型框架(hybrid test automation)

五、Junit和testNG的区别

——结论是两者差不多，一般人用用testng就好。

原因：

1.testng底层调用junit

2.历史上曾有testng优于junit的一段时期，但随后junit已更新并追赶上来

3.testng的data provider使用较方便

4.testng能做的事情junit都能做，但是有的地方会比较麻烦，例如，数据驱动，多线程并发执行测试用例。testng更便捷，自带。junit则要依靠第三方工具提供。

5.junit能做的事情testng也都能做，但junit也有更便捷的时候。比如soft  assertion，junit可以直接继承jassert做，testng你要自己去实现静态类来做。

6.junit是testng的底层，灵活度上更高。testng调用junit，对测试员来说用户体验更好。

六、request 框架有哪些方法?

像用来发送请求的一般都是调用以下方法

reponse = requests.get()

reponse = requests.post()

获取响应数据一般都是调用以下方法

reponse.status_code

reponse.reason

reponse.text

reponse.json()

reponse.headers

reponse.cookies

七、接口自动化用过哪些库?

Requests 库这个里面主要封装了各种发送请求处理请求的方法

Json 库这个库主要用来将json 格式转化为字典，或者将字典转化为json 格式数据

Re 库，这个库当时是针对后台返回的是html 格式，用来提取html 格式中的数据的

Xlrd 库，这个库当时主要用来读取excel 表格数据的

Ddt 库，这个库主要用来实现数据驱动的

Pymysql 库，这个库主要就是用来读取数据库，操作数据库的。

八、如果要传递请求头如何处理?

传递请求头，其实还是比较简单的，首先要搞清楚这个接口需要传递哪些请求头的参数，然后订制一个请求头，一般都是组装成一个字典，然后在调用post 或get  方法发请求的时候，在这两个函数中有一个关键字参数叫headers，这个参数就是用来传递请求头的，把组装好的请求头的字典格式的数据，通过headers  关键字参数进行传递就可以了。

九、如果某个接口需要用到上一个接口的数据，python 如何处理?

这个就是需要动态关联了，比如当时我们那个电商项目做的支付接口，支付接口就需要用到下单接口中的一个订单号，首先需要发送下单接口的请求，并调试通过，然后把响应数据中的订单号提取出来。之后就在调试支付接口的时候，需要组装支付接口的请求参数，其中的一个参数就是订单号，把上一个接口提取出来的订单号填入即可，然后就发请求就可以了。

比如加入购物车的接口需要先登录，这个加入购物车的接口需要用到登录接口的cookie  值，用来做鉴权，这里先发登录接口请求，调试通过，然后把响应数据中的cookies提取出来(这里需要调用response 这个响应对象中的cookies  就可以了)，在调试加入购物车的接口的时候，post 请求方法中有一个cookies 关键字参数，把刚才提取出来的cookies 值通过这个cookies  关键字参数来传递就可以了。

十、你们做接口自动化，用例数据是怎么组织，管理的?

用例数据这块，当时公司要求使用excel  表格来进行管理，其实这里主要也是为了实现数据与脚本的分离，提高整个工程后期的维护与优化，这里把数据封装到excel  表格之后我们在脚本中通过调用封装好的读取excel 表格的数据函数，然后利用ddt 模型来引用这些数据组织请求参数或头，发请求。

对excel  表格中的用例数据，我们是这么组织的，会有以下几个字段像用例标题，请求地址，请求方式，请求头，请求参数，响应结果，这个几个部分，对于请求头跟请求参数，因为脚本中发请求都是通过组装成字典的形式来发送的，所以这里我们也是通过类似于字典的形式文本格式来进行组织，主要就是方便后期脚本的提取与引用。

十一、接口自动化的用例又是怎么管理的?

自动化用例这块，我们利用unittest 框架来编写的，然后利用unittest 帮我们去统一加载执行用例。如果要全量执行的话， 通过调用unittest  里面提供的defaultTestLoader.discover()这个函数来加载test_case  目录下的所有用例执行即可，如果某条用例没有通过，需要单独调试，可以通过unittest.TestLoader()来创建一个加载器，加载具体的某条用例进行执行，调试即可。最后就是结合HTMLReport  这个库最终会自动帮我们生成报告。

十二、对于返回的数据，你怎么检查校验?

这块的话，首先我们一定得搞清楚后台返回的到底是什么格式的数据，一般都是两种情况，一种就是json 格式的数据，一种就是html  格式的数据，关注几个点一般有以下几个点：

1.状态码

2.响应信息对不对

3.也是最重要的就是响应内容

如果正文内容是json格式的数据，我们就使用response.json()函数来提取就可以了，如果是正文内容html  格式的数据，我们就使用response.text 来提取，然后利用re 库中findall  函数结合正则表达式来提取核心字段进行校验。对于响应内容，我们需要根据接口文档的说明，去检查一些核心的字段信息，去判断就行了。例外，如果有些接口需要检查数据库的话，那我们去连接数据库，查询对应数据，然后去判断校验,断言这块我当时就是这么做的。

十三、如果返回的数据是一个列表，你怎么断言?

如果返回的是列表的，这个其实我也碰到，我当时是这么处理，其实在unittest框架中提供了丰富的断言方法，  其中就有一个方法专门用来断言列表就是，assertListEqual()，它可以帮我们判断整个列表中的数据是否完全匹配。

assertListEqual(实际结果，预期结果，信息)

assertListEqual(response.json().get('result').get('list'),从数据库中进行获取，信息)

十四、如果列表中的数据是有序的，你怎么断言?

对于返回的是一个有序的列表的话，其实在unittest  框架中提供了一个断言方法叫assertListEqual()，这个函数专门是用来对比列表的，而且这个必须保证两个列表的数据完全一致才行，如果对于有序的列表我觉得可以通过这个函数来实现断言。

十五、查询出来返回结果是密文，密文你怎么测试

这里首先要搞清楚用的是什么加密算法，问开发要解密算法，对返回的数据进行解密解密完成之后在与预期结果对比，去进行断言。

十六、unittest 框架的原理?

unittest 它其实是一个单元测试框架，我们主要是用来管理用例的，帮我们统一加载执行用例的。像unittest  包几个组件，一个测试固件，测试固件主要有2个方法一个是SetUp()方法，tearDown()方法还有就是测试用例，测试用例需要定义函数，这个函数必须要以test  开头然后还有就是测试套件，以及测试加载器，跟测试执行器，unittest 框架的执行原理是这样的，首先要写好测试用例，然后由创建一个TestLoader  加载器，利用加载器把测试用例也就是test_case 加入到test_suite 测试套件中，然后再创建一个test_run  运行器去运行测试套件中的用例并且运行结果会保存在testresult 中。

十七、你们接口自动化用例是怎么跑的?

一般正常我们都是全量跑的，如果要全量跑，我们一般都是加载用例目录

也就是testcase下的所有用例文件

这里主要就是调用

unittest.defaultTestLoader.discover

(用例目录的路径，匹配规则)函数进行加载所有用例文件。有时候如果只是某个模块的用例执行不通过，  需要单独执行调试某个模块的用例。这里可以先创建一个套件，  调用unittest.testsuite()来进行创建然后调用unittest.testLoader()函数来创建一个加载器然后在加载具体某个模块的具体用例去执行调试。如果要定时全量跑所有的用例，一般我们会定时全量跑所有的用例，然后周一过来看报告分析报告，这里就需要用到持续集成，我们当时用的jenkins，从SVN  上检出自动化脚本，然后让jenkins 自动帮我们去跑。

十八、接口自动化这块是怎么出报告的?对于报告具体怎么分析的?报告中有哪些内容?

报告这一块，我们当时是用那个htmlreport  这个库去生成的?首先主要关注运行结果，看有多少用例通过了，有多少执行失败，有多少执行错误。一般报告上都会详细说明，我们主要看失败用例以及错误用例，对于失败的用例跟错误的用例一般在报告上都会有详细细节说明，到底哪里执行没有通过。对于执行错误的用例，一般都是自己的脚本编写有问题，这个我一般会找到对应用例代码去调试查看。

对于失败用例，我一般首先怀疑自己的脚本，先检查自己的脚本有没有问题，如果不是自己脚本问题导致的，那这就说明这条用例真的执行失败了，一般就提BUG  就可以了。