自动化测试常见面试题（下）

　　自动化测试是通过工具或脚本模拟人工操作，对软件的功能、性能、兼容性等进行验证的过程。其核心目标是提高测试效率、覆盖更多测试场景，并减少人为错误。面试中关于自动化测试的常见问题如下：

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

　　自动化用例这块，我们利用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 就可以了。