盘点100道腾讯、字节、滴滴大厂常驻面试题!你离成功只差1步了

Hello,大家好。金九银十,有的人盼望升职加薪,有的人立了新的Flag,有跳槽计划的该提上日程

大家好,我是圆圆,金九银十,有的人盼望升职加薪,有的人立了新的Flag,有跳槽计划的该提上日程了。为解大伙的燃眉之急,今天分享面试题预热一波,欢迎留言区补充评论。

这里赠送一套软件测试相关资源:

- 软件测试相关工具
- 软件测试练习集
- 深入自动化测试
- Python学习手册
- Python编码规范
- 大厂面试题和简历模板

关注我公众号:【程序员二黑】即可免费领取!

交流群:642830685

以下自动化面试题

请描述一下自动化测试流程?

自动化测试流程一般可以分为以下七步:

  • 编写自动化测试计划;

  • 设计自动化测试用例;

  • 编写自动化测试框架和脚本;

  • 调试并维护脚本;

  • 无人值守测试;

  • 后期脚本维护(添加用例、开发更新版本)。

自动化测试有误报过bug吗?产生误报怎么办?

有误报过,有时候自动化测试报告中显示发现了bug,实际去通过手工测试去确认又不存在该bug。

误报原因一般是:

  • 元素定位不稳定,需要尽量提高脚本的稳定性;

  • 开发更新了页面但是测试没有及时更新维护。

什么是PO模式?

全称:page object model  简称:POM/PO,PO模式最核心的思想是分层,实现松耦合,实现脚本重复使用及脚本易维护性。

PO模式主要分层:

1.基础层BasePage:封装一些最基础的selenium的原生的api方法,元素定位,框架跳转等。

2.PO层:元素定位、获得元素对象,页面动作

3.测试用例层:业务逻辑,数据驱动。

三者的关系:PO层继承基础层,测试用例层调用PO层。

po模式和非po模式区别?

图片

非PO模式 PO模式
面向过程的线性脚本 POM把页面元素定位和业务操作流程分开,实现松耦合。
复用性差 UI元素的改变不需要修改业务逻辑代码。只需要找到对应的PO页修改定位即可,数据代码分离。
维护性差 PO能使我们的测试代码提高代码的可读性,高复用性,可维护性。

怎么对含有验证码的功能进行自动化测试?

对有验证码的功能模块进行自动化测试,可以通过以下方式:

  • 让开发去掉验证码。未上线前,让开发去掉验证码验证,方便做自动化测试;

  • 设置一个万能的验证码。未上线前,让开发生成固定的验证码,方便做自动化测试。

  • 通过 cookie 绕过登录。

  • 自动识别技术识别验证码。第一种是:OCR 自动识别技术,第二种是:通过第三方打码平台的接口来识别。

如何提高脚本的稳定性?

提高脚本的稳定性,可以通过以下方式:

  • 不要右键复制 xpath(绝对路径很不稳定),自己写相对路径;

  • 定位没问题,第二个影响因素那就是等待了,sleep 等待尽量少用(影响执行时间);

  • 定位元素方法重新封装,结合 WebDriverWait 和 expected_conditions 判断元素方法,自己封装一套定位元素方法;

如果一个元素无法定位,你一般会考虑哪些方面的原因?

一个元素无法定位,可能的原因有:

  • 页面加载元素过慢,加等待时间;

  • 页面有frame框架页,需要先跳转入frame框架再定位;

  • 可能该元素是动态元素,定位方式要优化,可以使用部分元素定位或通过父节点或兄弟节点定位;

  • 可能识别了元素,但是不能操作,比如元素不可用,不可写等。需要使用js先把前置的操作完成。

你的自动化用例的执行策略是什么?

自动化用例的执行策略的含义:

  • 自动化测试用例是用来监控的。集成到Jenkins,创建定时任务定时执行;

  • 有些用例在产品上线前必须回归。Jenkins上将任务绑定到开发的build任务上,触发执行;

  • 有些用例不需要经常执行。Jenkins创建一个任务,需要执行的时候人工构建即可。

编写自动化用例的原则?

编写自动化用例的原则包括以下几个方面:

  • 一个用例是一个完整的场景。

  • 一个用例只验证一个功能点。

  • 用例与用例之间尽量避免产生依赖。

  • 一条用例完成测试之后需要对测试场景进行还原,以免影响其它用例的执行。

  • 脚本编写好了之后,需要反复执行,不断调试,直到运行正常为止。脚本的编写和命名要符合管理规范,以便统一管理和维护。

selenium工作原理?

Selenium的工作原理可以概括为以下5个方面:

  • selenium client(Python等语言编写的自动化测试脚本)初始化一个service服务,通过webdriver启动浏览器驱动程序chromedriver.exe;

  • 通过RemoteWebDriver向浏览器驱动程序发送HTTP请求,浏览器驱动程序解析请求,打开浏览器,并获得sessionid,如果再对浏览器操作需携带此sessionid;

  • 打开浏览器后,所有的selenium的操作(访问地址,查找元素)均通过RemoteConnection链接到remote server,然后使用execute方法调用request方法通过urlib3向remote server请求;

  • 浏览器通过请求的内容执行对应动作;

  • 浏览器再把执行的动作结果通过浏览器驱动程序返回给测试脚本。

你的自动化框架结构是怎么样的?

搭建的自动化测试框架采用分层设计模型框架,主要分为以下几个模块:

  • common:一些基础的底层方法类,例如:测试报告类、数据配置读取类、日志类、封装webdriver类、数据库连接类、发送邮件类、公共方法类,只要是我们想要实现的一些功能,可以把基础方法的实现放在common文件夹。

  • config:配置文件放在这里,比如:账号密码、数据库连接地址等。

  • log:运行用例后,日志的存储文件夹。

  • report:运行用例后,测试报告的存储文件夹。

  • page:在POM设计模式下,关于具体UI页面操作的方法。

  • test_case:具体存放编写的测试用例。

  • run_all:用来批量运行测试用例。

以下分享性能测试相关面试题,欢迎在文末留言补充评论✍️。

一、解释常用的性能指标名称与具体含义

性能测试是通过测试工具模拟多种正常、峰值及异常负载条件来对系统的各项性能指标进行测试。验证软件系统是否能够达到用户提出的性能指标,发现系统中存在的性能瓶颈并加以优化。

性能指标分为两个方面:

  • 系统指标:与用户场景和需求相关指标;

  • 资源指标:与硬件资源消耗相关指标;

系统指标

  • 响应时间:即系统响应时间(Transaction Response Time),应用系统从发出请求到客户端接收到响应所消耗的时间,是用户视角最关心的软件性能业务体验。响应时间为网络响应时间与应用程序响应时间之和;

    一般响应时间在2s内,用户会感觉比较满意;

    在2s~5s之间,用户勉强能接受;

    大于8s,用户就可能无法接受,从而刷新页面或者离开;

  • 平均响应时间:所有请求花费的平均时间;

  • 吞吐量:单位时间内系统能够处理的客户请求的数量,直接体现软件系统的性能承载能力,计算方式是完成的事务数除以时间;

  • 并发用户数:并发主要是针对服务器而言,在同一时刻与服务器进行交互(指向服务器发出请求)的在线用户数;

  • 在线用户数:某段时间内,用户访问系统的用户数,如多个用户在浏览网页,但没有对同时对服务器进行数据请求,需要与并发用户数区分开;

  • 最大并发用户数:有两种理解方式一种是从业务的角度来模拟真实的用户访问,体现的是业务并发用户数,指在同一时间段内访问系统的用户数量。另一种是从服务器端承受的压力来考虑,这里的“并发用户数”指的是同时向服务器端发出请求的客户数,一般结合并发测试(Concurrency Testing)使用,体现的是服务端承受的最大并发访问数;

  • 事务:可以看作是一个动作或是一系列动作的集合,例如登录,从登录开始到登录结束为一个事务。

  • TPS:Transaction per second,每秒钟系统能够处理的交易或者事务的数量,即服务器对客户请求的能力,是衡量系统处理能力的重要指标。

  • 吞吐量:网络传输的数据量(处理客户的请求数);

  • 吞吐率:单位时间(可以是秒/分/时/天)内网络成功传输的数据量,如请求数/秒、页面数/秒;

  • 点击数:Web Server收到的HTTP请求数;

  • 点击率:HPS,每秒钟用户向Web Server提交的HTTP请求数;

资源指标

  • 硬件性能指标:CPU,内存Memory,磁盘I/O(Disk I/O),网络I/O(Network I/O) ;

  • 中间件:常用的中间件如web服务器Tomcat,Weblogic web服务器,JVM(java虚拟机),ThreadPool线程池,JDBC数据驱动 ;

  • 数据库指标:SQL,吞吐量,缓存命中率,连接数等;

  • JVM:Java虚拟机,为使java的代码可以编译运行在不同的平台上顺畅,仿真模拟各种计算机来实现 ;

  • 前端指标 :首次显示时间,页面数量,页面大小,网络startRender,firstRender等。前端的性能与后端的性能的不同点在于,前端是每个用户的直观的感受,如前端页面加载元素耗费的时间,而后端的性能关注点在于多用户使用系统时,服务器是否能够承受或者服务器的处理能力如何,能否以较好的响应时间响应;

  • Load:系统平均负载,特定时间间隔内运行进程数,Load与cpu核数一致;

简述性能测试步骤?

1.熟悉应用:了解应用的架构、功能逻辑;

2.需求分析:根据测试目的,细化需求;

3.测试准备:客户端准备、测试数据准备、测试脚本准备;

4.执行测试:监控测试客户端和服务器性能,监控服务器端应用情况;

  • 客户端的系统资源(CPU、IO、Memory)情况;

  • 服务端的系统资源(CPU、IO、Memory)情况;

  • 服务器的JVM运行情况;

  • 服务端的应用情况是否有异常;

  • 响应时间、吞吐量等指标;

5.性能分析与调优:找出性能瓶颈,提高系统整体性能,满足用户需求;

6.编写测试报告:测试结束后,归档整理测试报告;

服务端性能分析都从哪些角度来进行?

从维度上划分,性能指标主要分为两大类,分别是业务性能指标系统资源性能指标

业务性能指标可以直观地反映被测系统的实际性能状况,常用的指标项有:

  • 并发用户数; 

  • 事务吞吐率(TPS/RPS);

  • 事务平均响应时间;

  • 事务成功率;

系统资源性能指标,主要是反映整个系统环境的硬件资源使用情况,常用的指标包括:

  • 服务器:服务器的CPU平均使用率小于70%,内存使用率小于75%;

  • 数据库:数据库连接数、数据库读写响应时长、数据库读写吞吐量等;

  • 网络:网络吞吐量、网络带宽、网络缓冲池大小;

  • 缓存(Redis):静态资源缓存命中率、动态数据缓存命中率、缓存吞吐量等;

  • 测试设备(压力发生器):CPU 利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘 IO 状态、网卡带宽使用情况等。

如何理解压力、负载、性能测试?

性能测试是一个较大的范围,实际上性能测试本身包含了强度、压力、负载等多方面的测试内容。

压力测试是对服务器的稳定性以及负载能力等方面的测试,是一种很平常的测试。增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。

负载测试是压力相对较大的测试,主要是测试系统在一种或者集中极限条件下的相应能力,是性能测试的重要部分。100个用户对系统进行连续半个小时的访问可以看作压力测试,那么连续访问8个小时就可以认为负载测试,1000个用户连续访问系统1个小时也可以看作是负载测试。

实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行测试。

tps无法上升原因有哪些?

1.网络带宽

在压力测试中,有时候要模拟大量的用户请求,如果单位时间内传递的数据包过大,超过了带宽的传输能力,就会造成网络资源竞争,导致服务端接收到的请求数达不到服务端的处理能力上限。

2.连接池

可用连接数太少,造成请求等待。连接池一般分为服务器连接池(比如Tomcat)和数据库连接池(或者理解为最大允许连接数也行)。

3.GC

如果堆内存分配的不合理,就会导致频繁的gc,gc会导致线程暂停。尤其是fullgc,会造成线程长时间暂停。

4.数据库配置

高并发情况下,如果请求数据需要写入数据库且需要写入多个表的时候,数据库的最大连接数不够,或者写入数据的SQL没有索引,或没有主从分离、读写分离,就会导致数据库事务处理过慢,影响到TPS。

5.硬件资源

包括CPU(配置、使用率等)、内存(占用率等)、磁盘(I/O、页交换等)。

6.压力机

单机负载能力有限,如果需要模拟的用户请求数超过其负载极限,会影响TPS(这个时候就需要进行分布式压测来解决问题)。

如何识别性能瓶颈? 

硬件上的性能瓶颈:

一般指的是CPU、内存、磁盘I/O 方面的问题,分为服务器硬件瓶颈、网络瓶颈(对局域网可以不考虑)、服务器操作系统瓶颈(参数配置)、中间件瓶颈(参数配置、数据库、web服务器等)。

应用软件上的性能瓶颈:

一般指的是应用服务器、web 服务器等应用软件,还包括数据库系统。

例如:中间件weblogic 平台上配置的JDBC连接池的参数设置不合理,造成的瓶颈。

应用程序上的性能瓶颈:

一般指的是开发人员新开发出来的应用程序(SQL语句、数据库设计、业务逻辑、算法等),例如,程序架构规划不合理,程序本身设计有问题(串行处理、请求的处理线程不够),造成系统在大量用户访问时性能低下而造成的瓶颈。

操作系统上的性能瓶颈:

一般指的是windows、UNIX、Linux等操作系统。例如,在进行性能测试,出现物理内存不足时,虚拟内存设置也不合理,虚拟内存的交换效率就会大大降低,从而导致行为的响应时间大大增加,这时认为操作系统上出现性能瓶颈。

网络设备上的性能瓶颈:

一般指的是防火墙、动态负载均衡器、交换机等设备。例如,在动态负载均衡器上设置了动态分发负载的机制,当发现某个应用服务器上的硬件资源已经到达极限时,动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现,动态负载均衡器没有起到相应的作用,这时可以认为网络瓶颈。

性能测试出现的原因及其定位十分复杂,这里只是简单介绍常见的几种瓶颈类型和特征,而性能测试所需要做的就是根据各种情况因素综合考虑,然后协助开发人员、DBA、运维人员一起定位性能瓶颈。

 性能测试常用的linux命令

top 用来监控linux的系统状况,是常用的性能分析工具,能够实时显示系统中各个进程的资源占用情况。

vmstat 用于显示虚拟内存、内核线程、磁盘、系统进程、I/O 块、中断、CPU 活动 等的统计信息。

netstat 用于监控进出网络的包和网络接口统计的命令行工具。

iostat 统计CPU使用情况,以及统计磁盘设备IO和磁盘分区IO的使用情况。

free  显示当前系统未使用的和已使用的内存数目,还可以显示被内核使用的内存缓冲区。

lsof 用于查看你进程打开的文件。

pidstat 用于监控全部或指定进程占用系统资源的情况,如CPU,内存、设备IO、任务切换、线程等。

strace 跟踪程序执行过程中产生的系统调用及接收到的信号,帮助分析程序或命令执行中遇到的异常情况。

perf  Linux kernel自带的系统性能优化工具,用于查看热点函数。

如何设计性能测试场景?

并发测试:基础线程组(强调单位时间的并发,不存在绝对并发)。

基准测试:反复对比结果,验证调优结果是否通过(tps是否提升,响应时间是否下降)。

负载测试:持续不断地增加负载,发现性能瓶颈(阶梯加压线程组)。

  • 并发用户模式的负载:不断增加并发用户数,发现瓶颈。

  • 吞吐量模式的负载:不断增加每秒请求数(rps)对服务端施压,发现tps瓶颈。

压力测试:tps瓶颈点上持续负载

  • 稳定性压力测试:tps保持高压稳定。一般取最大tps的80%持续运行。

  • 破坏性压力测试:目的是只需要服务端出现异常。

失效恢复测试:出现异常之后,系统可以很快的恢复。

容量规划测试:如果计算出集群当前的负荷快达到极限处理能力时,我们可以垂直扩展(加CPU/内存/磁盘)和水平扩展(加机器)两种方式来增加集群容量。

如何规避IO负载过高?

  • 如果服务器用来做日志分析,注意随机读和顺序写,避免定期的压缩、解压大日志。

  • 如果是前端应用服务器,要避免程序频繁打本地日志、或者异常日志。

  • 如果是存储服务(mysql、nosql),尽量将服务部署在单独的节点上,做读写分离降低压力。

最后为方便大家学习测试,特意给大家准备了一份13G的超实用干货学习资源,涉及的内容非常全面。

包括,软件学习路线图,50多天的上课视频、16个突击实战项目,80余个软件测试用软件,37份测试文档,70个软件测试相关问题,40篇测试经验级文章,上千份测试真题分享,还有2021软件测试面试宝典,还有软件测试求职的各类精选简历,希望对大家有所帮助……

关注我公众号:【程序员二黑】即可获取这份资料了!
 

Guess you like

Origin blog.csdn.net/weixin_54928936/article/details/118305020