Classic Interview Questions on Interface Automation Testing

距离过年又可以倒计时了，小伙伴们是不是都在摩拳擦掌为来年做起计划，下面为大家助助力，整理一份接口相关的经典面试题及附上答案供参考。

距离过年又可以倒计时了，小伙伴们是不是都在摩拳擦掌为来年做起计划，下面为大家助助力，整理一份接口相关的经典面试题及附上答案供参考。

接口自动化经典面试题

1、L = [1, 2, 3, 11, 2, 5, 3, 2, 5, 3]，用一行代码得出 [11, 1, 2, 3, 5]。 答： list(set(L))

2、L = [1, 2, 3, 4, 5]，L[10:]的结果是？ 答： 空列表(当时有点紧张，一直在"空列表"和"索引超出范围"两个答案之间徘徊)。

3、L = [1, 2, 3, 5, 6]，如何得出 '12356'？ 答： 注意，个人觉得这个题有坑，列表的元素不是字符串，所以不能 ''.join(L) 。以下是过程：

s = '' for i in L: s = s + str(i) print(s) # 12356 print(type(s)) # <class 'str'> 4、列表和字典有什么区别？ 答： 一般都是问列表和元组有什么不同。 （1）获取元素的方式不同。列表通过索引值获取，字典通过键获取。 （2）数据结构和算法不同。字典是hash算法，搜索的速度特别快。 （3）占用的内存不同。 5、如何结束一个进程？ 答： （1）调用terminate方法。 （2）使用subProcess模块的Popen方法。使用简单，具体用法，这里不展开。 6、进程、线程有什么区别？什么情况下用进程？什么情况下用线程？ 答：（1）区别： ① 地址空间和其它资源（如打开文件）：进程之间相互独立，同一进程的各线程之间共享。某进程内的线程在其它进程不可见。 ② 通信：进程间通信 IPC，线程间可以直接读写进程数据段（如全局变量）来进行通信——需要进程同步和互斥手段的辅助，以保证数据的一致性。 ③ 调度和切换：线程上下文切换比进程上下文切换要快得多。 ④ 在多线程操作系统中，进程不是一个可执行的实体。 （2）使用场景：同时操作一个对象的时候，比如操作的是一个全局变量，我用线程，因为全局变量是所有线程共享的。 7、什么是ORM？为什么要用ORM？不用ORM会带来什么影响？ 答： ORM框架可以将类和数据表进行对应，只需要通过类和对象就可以对数据表进行操作。 通过类和对象操作对应的数据表，类的静态属性名和数据表的字段名一一对应，不需要写 SQL 语句。 ORM另外一个作用，是根据设计的类生成数据库中的表。 8、写一段代码，ping 一个 ip地址，并返回成功、失败的信息。 答： 使用 subProcess 模块的 Popen 方法(使用简单，具体用法，这里不展开)。 9、说说接口测试的流程，介绍一下 request 有哪些内容。 答： （1）流程：获取接口文档，依据文档设计接口参数，获取响应，解析响应，校验结果，判断测试是否通过。 （2）request 内容： ① 封装了各种请求类型，get、post 等； ② 以关键字参数的方式，封装了各种请求参数，params、data、headers、token 等； ③ 封装了响应内容，status_code、json()、cookies、url 等； ④ session 会话对象，可以跨请求。 10、ui自动化，如何做集群？ 答： Selenium Grid。 11、移动端 UI 自动化，经常会自动安装 2 个程序，你知道那两个程序是什么东西不？ 答： 守护精灵，和 Python 并发编程中的 daemon 原理一样，父进程/父线程的代码执行完毕，它就终止，要写在 start 方法前面。另外，要找到配置文件，注释掉两行代码。 12、说5个以上 Linux 命令。 答： cd、pwd、tail -f 、unzip、cp、mkdir、rm -rf、whereis、date、vim、find、ps -ef 、htop。 13、介绍一下你在这个项目中是如何使用 Jenkins 的。 答： 用的不深入，说了基本操作，比如定时构建执行代码。 14、说说你对敏捷模式的认识。 答： 小步快跑，拥抱变化。测试中，可以通过行为驱动测试，有个框架 lettuce 可以用。 15、了解过 Docker 不？ 答： 了解，没用过。然后说了下对 Docker 大概的认识、优势。 16、说一下你对软件测试的深刻心得。 答： 软件测试对测试工程师来讲,要求具备较强的专业知识,严谨细心耐心的测试态度,良好的反向思维、发散思维能力、沟通能力等等。 17、性能测试怎么做，需要监控哪些指标？ 答： 一般性能分析的过程 序号 步骤名称 说明 1 检查RT 客户端响应时间 2 检查TPS TPS大时RT小， 说明性能良好 3 检查负载机资源消耗 检查CPU使用率 4 检查被压服务器的资源消耗 CPU 、 内存、磁盘IO、带宽、响应时间 5 检查中间件配置 确定是否有配置参数问题 6 数据库服务器 CPU、内存、IO繁忙程度、数据库监控。 18、bug定位、分析、类型。 答： 一般来说bug大多数存在于3个模块： 1、前台界面，包括界面的显示，兼容性，数据提交的判断，页面的跳转等等，这些bug基本都是一眼可见的，不太需要定位，当然也不排除一些特殊情况，本身数据传过来的时候就有问题，所以显示会出问题的情况（这个后面会说到）。 2、后台程序，包括前台调用的接口，中间层缓存和转发数据，定时任务脚本异步处理数据，程序之间的相互调用等等，而这些bug往往都是不可见的，有可能在功能上体现，也有可能隐藏的深处不易发现，这时候就要通过一些辅助工具以及人工的判断去定位了。 3、数据库，包括表中缺少字段，字段定义错误，字段长度限制，数据重复等等，这些bug需要通过数据库工具以及一些基本的数据库查询语句来定位，当然前提是要对每个表，每个字段甚至每一个值代表什么意思有一定的了解（一些常用的重要的表，字段，值就可以了）。 排除一些显而易见以及可以直接判断的bug，很多不容易判断的bug该如何定位呢? 这就需要借助一些工具来一个个排除了，也许还是会觉得雨里雾里，那么就举一个常见的例子来讲解： 比如在提交正常的表单发生了错误导致提交失败，那么如何从定位呢? 1、首先要打开抓包工具，然后提交正常的表单，看是调用后台接口的时候传的参数是否和之前填写的一致，比如表单填的是数字，而接口需要传的是字符串，那么就是前台传的问题，如果一致说明不是前台问题，继续往下查。 2、需要一方面继续看抓包的数据，接口返回的错误是什么，如果能明确看到错误原因的消息，也就定位到问题，如果不能看到则要继续连接测试服务器查看日志，看是程序处理到哪一步有问题， 3、如果从程序的角度发现没问题，那继续往下查，看是否连接的数据库不对，亦或是超过数据库字段限制的长度等等。就这样追寻着程序执行的轨迹一步一步去排查，最终基本都能定位到问题。 19、测试策略、测试方案的区别。 答：请参考以下两个网址： https://blog.csdn.net/stephen_shijun/article/details/84323718 、 https://blog.csdn.net/kongsuhongbaby/article/details/86747889 20、测试的数据你放在哪? 答： 测试数据存放总结： 1.对于账号密码，这种管全局的参数，可以用命令行参数，单独抽出来，写的配置文件里（如ini）
2.对于一些一次性消耗的数据，比如注册，每次注册不一样的数，可以用随机函数生成
3.对于一个接口有多组测试的参数，可以参数化，数据放yaml,text,json,excel都可以
4.对于可以反复使用的数据，比如订单的各种状态需要造数据的情况，可以放到数据库，每次数据初始化，用完后再清理
5.对于邮箱配置的一些参数，可以用ini配置文件
6.对于全部是独立的接口项目，可以用数据驱动方式，用excel/csv管理测试的接口数据
7.对于少量的静态数据，比如一个接口的测试数据，也就2-3组，可以写到py脚本的开头，十年八年都不会变更的 总之不同的测试数据，可以用不同的文件管理。