自动化测试面试中常见的问题

一、测试用例再执行点击元素时失败导致整个测试用例失败。如何提高点击元素的成功率?解决办法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底层调用junit2.历史上曾有testng优于junit的一段时期但随后junit已更新并追赶上来3.testng的data provider使用较方便4.testng能做的事情junit都能做但是有的地方会比较麻烦例如数据驱动多线程并发执行测试用例。testng更便捷自带。junit则要依靠第三方工具提供。5.junit能做的事情testng也都能做但junit也有更便捷的时候。比如soft assertionjunit可以直接继承jassert做testng你要自己去实现静态类来做。6.junit是testng的底层灵活度上更高。testng调用junit对测试员来说用户体验更好。六、request 框架有哪些方法?像用来发送请求的一般都是调用以下方法reponse requests.get()reponse requests.post()获取响应数据一般都是调用以下方法reponse.status_codereponse.reasonreponse.textreponse.json()reponse.headersreponse.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 就可以了。