软件测试常见面试题（第三弹）

一、自我介绍

• 体现个人工作经历-几家公司、公司类型、测试项目类型（业务类型、技术类型B/S C/S /APP H5、微信小程序、公众号）
• 体现个人技能水平-独立组织策划过项目版本的完整测试过程，UI、接口自动化测试 体现个人对于测试的理解
• 预期或则规划

二、请简单介绍下最近这家公司你是如何开展测试工作的？（你们公司的测试工作流程？、你是如何执行测试的？在项目中怎么测试？）

这里其实就是将测试流程进行细化、丰富。这里就没有标准答案

三、描述一下你最近(简历中的项目)这个项目是做什么的？

• 体现项目是什么架构类型，包含哪些平台，分别给谁用，用来做什么？
• 体现核心的业务流程是什么？

四、描述在这个项目里面你主要负责哪些模块的测试？挑选其中一个难度大点或业务比较复杂的模块讲述你是如何测试？

• 一定是核心流程所涵盖到的模块：
  订单、库存（库存锁）、支付、抢购、优惠券、分销、资质、银行对接（接口阶段mock第三方接口）、利息计算、逾期计算规则、借款投资流程 进(采购）销(销售)存(库存)。
• 如何测试需要体现：
  测试哪些业务场景采用什么方式测试；
  对于这类型的模块一般测试几轮，测试结果如何。

五、如何测试支付业务？

基于之前项目中做支付场景,当时测试的时候分成两种方式进行测试。由于我们的支付渠道:微信、支付宝、银行任意选，没有开通测试接口，只能进行真实支付。所以采用的第一种方式:在确认订单后修改订单金额为1分钱,测试支付成功后的跳转。其它异常情况正常测试即可:如余额不足、密码错误等。 基于接口测试层面,采用mock模拟接口的方式，模拟银行各种异常返回，检查我们系统对应响应处理是否正确即可。

六、给你一个网站你如何开展测试工作？

1、首先查找需求说明、网站设计等相关文档，分析测试需求；
2、制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测，试界面测试，性能测试，数据库测试，安全性测试，兼容性测试；
3、设计测试用例；
4、功能性测试可以包括，但不限于以下几个方面：链接测试：链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回等；提交功能的测试；多媒体元素是否可以正确加载和显示；多语言是否能够正确显示选择的语言等。
5、界面测试可以包括但不限于一下几个方面：页面是否风格统一，美观。页面布局是否合理，重点内容和热点内容是否突出。控件是否正常使用。对于必须但为安装的空间，是否提供自动下载并安装的功能。文字检查。
6、性能测试一般从以下方面考虑：压力测试，负载测试，强度测试 。
7、数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。
8、安全性测试：基本的登录功能的检查；是否存在溢出错误，导致系统崩溃或者权限泄露；相关开发语言的常见安全性问题检查，例如 SQL 注入等；如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试， 或者获取支持。
9、兼容性测试，根据需求说明的内容，确定支持的平台组合：浏览器的兼容性；操作系统的兼容性；软件平台的兼容性；数据库的兼容性。
10、开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）
11、定期评审，对测试进行评估和总结，调整测试的内容。

七、没有需求文档，你会如何执行测试？

假如没有需求文档我会从以下一些方面着手:
1、根据客户的功能点整理测试需求追溯表
2、根据开发人员的Software Specification List整理我们的功能测试点
3、开展项目跨部门讨论会
4、测试人员整理用例需求疑问递交项目组和客户代表回复
5、项目内部用例评审
6、邮件和客户代表确认部分争议问题
7、项目Demo和部分已开发系统
8、参考同行业和竞争对手的类似产品
9、交叉模块的测试要注意
10、咨询客户部分需求疑问

八、给你一个物件（杯子、花瓶、笔、桌子）你怎么测试？

无论是哪个物件,都从以下几个维度出发设计:
1、UI
2、功能
3、性能
4、安全
5、接口
6、易用性

举例，面试官问给你一个杯子你怎么测，至少写出20条测试用例：

1、功能测试：主要关注水杯基本功能

1.1  水杯是否可以正常装水
1.2  水杯是否可以正常喝水
1.3  水杯是否有盖子，盖子是否可以正常盖住
1.4  水杯是否有保温功能，保温功能是否正常保温
1.5  水杯是否会漏水，盖住盖子拧紧后是否会漏水

2、ui测试：主要关注水杯外观、颜色、设计等方面

2.1  外观是否完整
2.2  外观是否舒适
2.3  颜色搭配及使用是否让人感到舒适
2.4  杯子外观大小是否适中
2.5  杯子是否有图案，图案是否易磨损

3、易用性测试：主要关注水杯使用是否方便

3.1  水杯喝水时否方便
3.2  水杯拿起放下是否方便，这里会衍生到水杯形状的测试
3.3  水杯装水是否方便
3.4  水杯携带是否方方便
3.5  水杯是否有防滑功能
3.6  水杯装有低温或者高温水时，是否会让手感到不适

4、性能测试：

4.1  水杯装满水时，是否会漏出来
4.2  水杯最大使用次数
4.3  水杯的保温性是否达到要求
4.4  水杯的耐寒性是否达到要求
4.5  水杯的耐热性是否达到要求
4.6  水杯掉落时，是否可以正常使用
4.7  水杯长时间放置时，是否会发生泄露

5、安全性测试：主要关注水杯外观和各种异常条件下是否释放有毒物质等

5.1  当水杯装满热水时，水杯是否会烫手
5.2  当水杯装上水后，是否会产生有毒物质
5.3  把水杯放在零下环境时，是否会产生有毒物质
5.4  把水杯放在高温环境时，是否会产生有毒物质

6、接口（杯子没有想到怎么和接口关联起来）
7、兼容性测试：主要关注水杯是否可以装其他液体，如果汁、汽油、酒精等
8、可移植性测试：主要关注水杯放置环境等

8.1  将水杯放在常温环境中，使用是否正常
8.2  将水杯放在零下的环境中，使用是否正常
8.3  将水杯放在高于正常温度的环境中，使用是否正常

九、如何执行的兼容性测试？-web兼容和app兼容

1、Web 兼容性测试
（1）首先开展人工测试，测试工程师测试主流浏览器和常用操作系统测试主流程和主界面，看看主流程和主界面是否有问 题，如果存在问题，那么记录下 bug 情况，以及浏览器型号和版本，以及操作系统，准确定位 bug 产生的原因，提交 bug，告知开发人员修改。所有的主流设备都需要进行测试，只关注主流程和主界 面，毕竟每个系统主流程和主界面不是很多，所以这个工作量还是可以承受的。
2、APP 兼容性测试
（1）APP 的兼容性测试和 Web 测试类似，首先开展人工测试，测试工程师借助测试设备对主流程和主功能，主界面进行测试；收集所有的能收集到的不同型号的测试设备测试主流程和主界面，看看主流程和主界面 是否有问题，如果存在问题，综合考虑设备的使用率等因素，看看是否需要调整，如果需要，那么记录下 bug 情况以及测试设备的型号和操作系统，准确定位 bug 产生的原因，提交 bug，告知开发人员修改。
（2）其次借助第三方测试工具，对于 APP 的兼容性测试，推荐的是百度众测平台和云测平台，我经常使用的是云测平台， 这两款测试工具里面包含了安卓和 iOS 的测试；测试很齐全，包括功能测试、深度兼容测试、性能测试、网络环境测试，还可以模拟海量用户测试，，还可以导入自己编写的测试用例进行功能测试，里面还包括测试专家的测试，当然了找专家是要花钱滴。基本进行兼容性测试是不需要花钱的；测试工程师把打包好的 apk 或者 IPA 文件，上传到测试平台，选择需要测试的设备型号，开始任务即可；等待一段时间，在等待的时间你是不需要盯着的，你可以做其他的工 作。测试完成后会生成一份测试报告，可以查看错误页面和错误日志，如果需要调整，那么提交 bug，告知程序员修改即可。

十、你们团队人员比例如何？

没有测试经验的：一般情况下比例不要小于 开发:测试= 5:1 团队人数最好不要超过30；
有测试经验的直接按实际情况说明即可。

十一、需求发生变化，你会如何处理？

1、本次需求变更的内容对应模块还没有进行测试
（1）评估需求变更对应功模所带来的工时是否大于原来该模块的测试工时
（2）如果超过原有模块的测试工时，影响测试计划则需要考虑以下几点，看是否的能在原计划的范围内内部消化：加班、协调资源、根据现有测试过的模块情况来分析是否可以调整一些测试时间、如果所有方式都已经考虑则反馈，给测试负责人或项目经理来进行协商
2、本次需求变更的内容对应模块已经完成了测试

十二、多久做一次版本迭代？如何进行回归测试？

一般分大版本和小版本，大版本主要是产品规划的新功能、新业务，小版本主要是一些历史功能优化和缺陷修复版本。大版本一般2-3个月一次。小版本每周都会有。
1、缺陷回归：触发缺陷查看缺陷是否已经修复；
2、历史功能回归：跟项目经理以及开发确认本次版本迭代影响的功能范围，对于影响的功能范围以及核心业务流程、关键点，挑选正向的用例进行回归测试；同时利用版本迭代的空闲时间，对历史功能回归测试实现UI自动化。

十三、在测试过程中有没有发现过让你记忆犹新的BUG？

问题描述:购物车合计金额和订单的商品合计金额偶尔出现相差0.01；
需求描述:基于商品合计金额结果四舍五入
购物车合计金额 = sum(购买量 * 单价 * 会员折扣率)
订单的合计金额 = sum(购买量 * 单价 * 会员折扣率) + 物流费 - 优惠券 - 积分抵扣
分析问题:
找到对应购物车研发人员确认其计算的方式，每次计算完一个乘法四舍五入；
订单的开发人员计算方式是乘法计算完之后再对于最终结果进行四舍五入，导致偶尔出现相差0.01的情况。
解决方式：找产品确认最终确认进位方式。
这里就提供一个，大家在实际学习过程中也会遇到一些缺陷。可以进行记录和分析。

十四、提交了一个缺陷开发不认为是缺陷你会如何处理？

个人在以前的测试过程中,很少出现这种问题。一般情况下我提交缺陷前都会反复的确认,也会尽量的保障缺陷额有效率和清晰度。如出现该情况，首先我会找到对应的开发人员，询问对方拒绝或不认为是缺陷的理由。如在对方的描述过程中发现明显的问题，且有明确的证据情况会摆明需求甚至当场重新给其确认。如在其阐述理解的过程中,没有问题，或者说其在对于需求的理解中也没有明确的错误，那证明对于需求的理解出现的了歧义，直接找产品或项目经理确认达成共识即可。当然也可能是其它原因导致缺陷的无效，例如垃圾数据、环境问题等，这些情况一般出现很少，一般在我测试过程中对应的测试数据我都会保障其有效性，环境问题也不多,就是有时候测试的版本可能不是最新的代码,一般情况下我们的测试团队每天测试开始前，都会去更新最新的代码来进行测试,但是不能避免有最新更新，这块实时多同步下即可。

十五、测试时间不够了，项目又必须上线，你会如何处理？

这里测试时间不够了，可能导致原因有很多,如开发或缺陷修复质量不高，导致无法顺利执行测试。第二需求的变更导致计划控制不合理等等，但是不管那种原因，客观时间不够了是事实。那我的话一般会做如下方式来进行处理:第一,迅速盘点剩余测试工作量,是否可以通过加班或协调资源的解决问题，保障项目上线。第二，是否可以根据项目各个模块的现有测试情况来调整原有测试计划的分配工时,如部分模块无较大问题，是否在风险可控的情况减少测试工时,第三，是否可以借调产品和开发分摊部分简单的测试任务，第四,原有复杂的业务功能是否有替代上线方案,第五，是否可以占用部分产品验收时间，第六，是否可以裁剪部分功能。

十六、如何保障测试用例的覆盖率？

1、编写测试用例前，先熟悉项目，看看相关需求文档是否有问题（功能描述不清，设计逻辑缺陷），如有问题找相关设计或者开发问清楚。
2、采用测试用例设计方法:如判定表、等价类、边界值、流程图等
3、组织用例评审，进行查漏补缺。

十七、生产环境中有没有出现比较严重的问题？如果有的话有什么的方法可以降低带来的风险？

1、在之前的项目测试经验中,线上暂时没有出现过比较严重的问题。
2、如果出现严重的缺陷的话,我会思考一下的一些问题,看是否能降低风险:
（1）第一:先确认导致问题出现的原因,如果是代码逻辑错误,证明漏测，则需要加强测试力度、加强测试用例评审力度
（2）第二:如果是遗漏代码,测试后提交,加强代码封板把控，而上线前必须同步最新代码，测试确认。
（3）第三:如是需求实现错误,加强需求评审力度。
（4）第四:采用灰度上线,大型版本先只对部分用户开放，稳定后再全面升级。

十八、你们有多少个测试环境，分别有哪些？

之前的项目中有三个测试环境三个， 测试环境，回归环境，预发布环境
（1）测试环境，也就是我们测试同学干活的环境啦，一般会由测试同学自己来部署，然后在此环境进行测试。bug修复后，需要发版更新测试环境来回归bug。
（2）回归环境，回归bug的环境，其实就是我们的测试环境，在测试环境上测试、回归验证bug。
（3）预发布环境，测试环境到生产环境的过渡。测试环境可能会受到一些限制，一些流程或者数据没有测试到，就可以在预发布环境进行验证，从而保证产品上线质量软件测试环境包括硬件环境和软件环境。

十九、有没有部署过测试环境，简单的描述下如何部署的？

有！
在之前的项目中,我们的系统使用的应用服务架构是:Linux+Nginx+Tomcat+Mysql。
在进入测试前,开发已经将整套的服务器架构都已经搭建好，所以对应的中间件和工具环境不需要再重新部署。当时我去部署的过程,主要是更新一些新的测试版本。会从git上面获取到开发的源代码到我的本地电脑,并使用开发提供的编译打包命令，进入到源码所在路径,执行mvn clean install即可获取得到一个可部署的源码包,(TARGET)(可以自己起名,例如叫自己的项目的英文缩写).war文件。 通过SSH远程连接工具MobaXterm将源代码上传到Linux测试服务器。停止测试环境tomcat服务,备份原测试war包。将刚上传的.war移动至tomcat指定的项目部署目录 webapps,重启通过tomcat/bin目录下的startup.sh启动服务器。最后到本地机器访问测试域名地址，如能成功访问则代表部署成功了。
另外我还了解过jenkins可以执行持续构建部署方式，如有需要可以进行简单运用。

二十、了解哪些网络协议，简单描述一下区别?

在之前的测试工作中主要是测试https和http协议，当然简单了解过TCP协议:
1、https协议需要到CA申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl/tls加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的；HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

二十一、常见的响应状态码有哪些？分别表示什么含义？

1、2开头：2xx (成功)表示成功处理了请求的状态代码；如：200 (成功) 服务器已成功处理了请求。
2、3开头：3xx (重定向) 表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。如：304 (未修改) 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容
3、4开头：4xx(请求错误) 这些状态代码表示请求可能出错，妨碍了服务器的处理；如：400 (错误请求) 服务器不理解请求的语法；403 (禁止) 服务器拒绝请求。404 (未找到) 服务器找不到请求的网页。
4、5开头：5xx(服务器错误)这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错；如：500 (服务器内部错误) 服务器遇到错误，无法完成请求。

二十二、系统出现500或白屏，你会如何分析问题？

• 查看系统服务器资源是否占满：磁盘、内存
  1、通过查看磁盘占用状态：df -h；
  2、通过写入缓存信息，导致硬盘空间不足；
  3、查看内存的使用情况：top。
• 内存泄漏：由于开发编写代码过程对于已经分配内存资源使用完毕之后，并不释放内存的资源，导致后面同样业务处 理所占用内存足部累加，最终导致内存不足。
• 内存溢出：现有空闲内存不足以提供服务器处理客户请求。
• 作为测试需要定位信息：
  基于内存泄漏，需要找到占用了资源而不释放具体使用功能是哪个，然后基于功能找到请求地址。

二十三、Fiddler主要用来做什么？如何分析抓取的数据信息是正确的？如果是加密的内容你怎们处理？

1、分析缺陷是前端的问题还是后端的问题。
例如:提交订单的请求地址：
（1）界面组织提交订单商品数据，点击【提交订单】，触发发送请求
（2）后台代码进行处理，处理完成之后，返回订单相关数据。返回的数据由开发者来决定（需求来决定到底返回哪些数据）订单编号、订单金额。
例如订单金额在界面显示错误，抓取提交订单响应数据，查看接口返回信息中订单的总额是否是正确。如果接口中订单总额正确，则是前端的问题，如果是响应信息中订单总额是错误，则是后端的问题。
2、前端对于输入信息做了对应限制，不代表后端代码也做了限制，每个请求地址对应懂IT的人的来讲都是能够直接跳过前端页面进行操作的。验证后端对于异常输入的是否也有做对应限制。
3、接口测试测试每个请求的实现情况。部分公司的开发没有编写接口文档，则可以通过抓包工具获取到具体接口地址。
4、做手机端弱网测试。

二十四、有没有做过弱网测试，简单的说下？

我会让PC端和移动连上相同的网络，Fiddler通过代理连上手机，PC端通过Fiddler工具的选项卡Connerctions设置Fiddler监听端口为8888，移动端修改网络设置将IP地址和端口设置为电脑的IP地址和Fiddler的中的端口号，安装Fiddler证书。移动端就可以打开要进行弱网测试的网页或者APP，Fiddler会自动获取相关的地址，通过修改 customRuler.js文件里的m_SimulateModem的参数来模拟弱网，从而就可以执行弱网测试了。

二十五、Fiddler如何抓取苹果手机包？描述下过程？

基于苹果手机抓包:
1、在Fiddler配置项中要设置勾选抓取HTTPS，自动下载HTTPS证书
2、开启网络服务监听端口:勾选Allow remote computers to connect，端口号可默认为8888
3、打开iphone浏览器，在地址栏输入http://ip(电脑的ip):8888(fiddler中默认的端口)，点击“FiddlerRoot certificate”安装证书
4、设置iphone代理:手机连接wifi后，打开wifi详情，滑动至屏幕底部的http代理，点击进入修改成“手动”，设置ip（电脑的ip）及端口(fiddler中的8888)后保存启用证书方法：设置——通用——关于本机——证书信任设置

二十六、用过哪些类型的数据库，关系型数据库和非关系型数据库有什么区别？

用过MySQL、Orcale了解redis数据库
关系型数据天然就是表格式的，因此存储在数据表的行和列中，数据表可以彼此关联协作存储，也很容易提取数据。
与其相反，非关系性数据不适合存储在数据表的行和列中，而是大块组合在一起，非关系型数据通常存储在数据集中，就像文档，键值对或者图结构，你的数据集体特性是选择数据存储和提取方式的首要影响因素。

二十七、如何使用SQL快速插入100000条数据？

DELIMITER  //	#  使用DELIMITER关键字临时声明修改SQL语句的结束符为//
create  procedure  test()	#  创建存储过程
begin
declare  i  int  default  0;	#  声明一个默认值为0的局部变量i
while  i<100000  do	#  开始循环
insert  into  books(name)value("test");	#  books是表名，  name是字段名  test是字段值
set  i=i+1;  #  使用set为参数赋值
end  while;
end //
DELIMITER  ;	#  将结束符重新定义回结束符为";"
call  test();  #  调用函数

二十八、写过最复杂的SQL语句，表名叫什么？

这个题目不同项目自行准备，3表以上关联、分组、排序查询。

二十九、数据库还可以用来做什么？

1、执行测试用例时，有时需要到数据库验证数据的准确性与完整性
2、进行bug定位时，有时需要到数据库查看数据的详细信息
3、构造某种测试场景时，可以在数据库里直接修改数据，要比使用界面更有效率
4、软件升级过程中，经常会涉及到对历史数据的处理，这种情况需要执行升级sql，并验证结果。

三十、为啥选择做软件测试？不选择IT其它岗位，如开发？

这个题自行发挥，能体现出对测试行业的热爱即可

三十一、有没有制定过测试计划？测试计划包含一些什么内容？依据什么来制定的测试计划？

1、在我们的项目中测试计划主要涵盖：测试范围、测试资源、任务分配、阶段任务完成时间节点，偶尔会加上风险评估、测试环境等相关说明。
2、一般情况下会依据需求文档确认测试范围的测试点拆解文案、开发计划文档、产品/运营的目标上线时间以及当前测试人力资源情况来制定测试计划。

三十二、你们公司是如何管理的缺陷？缺陷处理的过程是怎么样的？

1、测试人员发现并确认缺陷，在禅道记录缺陷，将其指派给指定模块开发人员。如优先级或缺陷等级比较高，同时会直接通知对应开发人员尽早修复。
2、开发人员到禅道领取缺陷，分析缺陷并进行处理。当开发人员进行处理并认为已经解决之后，就可以将这个缺陷的状态设置为:已修复，并将其返还给测试人员。
3、测试人员进入系统查看缺陷，并测试验证缺陷。如果经过再次测试发现缺陷仍然存在的话，测试人员将缺陷再次传递给开发人员，并将缺陷的状态设置为“重新打开”。如果测试人员经过再次测试确认缺陷已经被解决，就将缺陷的状态设置为“已关闭”。
4、如果测试经理收到某缺陷被拒绝通知，验证该缺陷，如果确实不能算作缺陷，关闭缺陷，将缺陷状态设置为“已关闭”。如果认为的确是一个缺陷，修改缺陷描述，并将其重新指派给开发经理，并将缺陷的状态设置为“新建”。

三十三、如何评估缺陷的优先级和严重级别？

• 优先级:指开发修复缺陷的先后顺序,严重级别:指发现的缺陷对产品质量影响的严重程度。
  高（P1）：缺陷严重，影响测试或产品目的，需优先考虑。
  如：产品的版权未更正、技术性的不正确内容等。应用程序包版本不对、无法安装导致无法测试、闪退、崩溃等。
  中（P2）：对产品来说不是那么关键的场景或特性。
  如：在小标题上发现的错误、从历史版本中来的遗留bug等。
  低（P3）：对产品使用没有太大影响。
  如：在低使用频率页面中发现的bug、很少被使用的功能等。文字重叠、错别字等UI方面的缺陷，不易操作等。
• 缺陷的严重级别
  A类（1级）-致命缺陷（Fatal）：造成系统或应用程序崩溃、死机、或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。
  B类（2级）-严重缺陷（critical）：系统的主要功能部分丧失、数据不能保存。如致命的错误声明，程序接口错误等约束条件
  C类（3级）-一般缺陷（major）：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间等， D类-轻微缺陷（Minor）:使操作者不方便，但它不影响功能过的操作和执行，如错别字、界面不规范
  E类（4级）- 意见优化（Enhancemental）：由问题提出人对测试对象的改进意见。
  要注意的是，开发会根据优先级来进行参考，决定修复先后顺序，所以高优先级不一定就是致命的缺陷。

三十四、你们公司测试通过的标准是什么？

1、需求规格说明书中的需求必须全部实现并测试通过；
2、测试用例执行率100%；
3、无一般、严重、致命等级缺陷；
4、遗留缺陷和产品或项目经理沟通可以延迟处理。

三十五、生产环境发现缺陷你会如何处理？

1、在公司的缺陷管理系统（如：禅道）中记录该缺陷
（1）bug等级
（2）提供必要的截图和日志log信息
2、bug信息定位（前端bug还是后端bug，sql问题？）—— 缩小问题的范围
3、在测试环境去复现bug
（1）不能复现：可能是版本升级导致的，（联系运维、产品）是否需要需要回退到上一个安全稳定的版本
（2）能复现：召集开发、产品、运维预估 bug 解决时间
（3）解决时间短：尽快修复，尽快回归，尽快线上验证
（4）解决时间长：联系运维回退到上一个安全稳定的版本
4、bug 分析总结
（1）测试不到位（更新测试用例）
（2）紧急变更（争取测试资源包含测试时间）
（3）环境软硬件差异性（增加线上回归测试用例）

三十六、在你的项目（基于自己的项目）中编写了多少条测试用例？发现了多少缺陷？

1年左右的项目:在上一个项目里我一共是编写1300多条测试用例，其中一共是发现了300条左右的bug

三十七、你们团队是如何同步工作情况？或如何协同作业的？

1、需求变更时如何同步
2、提交产品验收，协助产品测试，遗留缺陷到验收解决
3、和开发对接-开发模块完成的时间（提测时间，提测的方式和标准）
4、提交缺陷如何通知开发，如何处理

三十八、你如何评估一个项目或版本的质量好坏？项目上线的标准是什么？

从功能性、易用性、可靠性、兼容性、可维护性、可移植性这几个维度来判定软件质量的好坏：
1、软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。
2、在验收测试中发现的错误已经得到修改，各级缺陷修复率达到标准
3、所有测试项没有残余紧急、严重级别错误。
4、需求分析文档、设计文档和编码实现一致。
5、验收测试工件齐全（测试计划、测试用例、测试日志、测试通知单、测试分析报告，待验收的软件安装程序。）

三十九、在你们公司是如何执行的需求评审工作？有没有提出过问题？需求评审过程中测试人员应该注意什么？

1、会议前，先明确参与会议的时间，地点和人员，并进行通知， 开发和测试需提前熟悉需求，标记不清楚、 疑问、建议的地方，等待会议时一并提出，提高会议效率；
2、会议中，提出对需求的疑问和建议，并对提出的问题做记录，以免遗漏，按需采纳修改建议，保证参与人员对需求理解一致。当存在的异议点较多时， 考虑是当下解决还是例外安排会议进行解决；
3、会议后，产品按评审意见对需求文档进行修改，最后形成统一的、标准的需求文档发出来确认。 若评审不通过，那么可能就要修改后进行二次评审，保证需求的完整性、准确性、理解一致性；
4、要保证会议的高效进行，注意控制会议时间、讨论重点等，以免进度拖沓，重点问题得不到有效解决。

四十、使用ADB做过什么？举例说明下？如何获取和分析手机日志信息？

1、运行设备的shell（命令行）；
2、管理模拟器或设备的端口映射；
3、计算机和设备之间上传/下载文件；
4、将本地apk软件安装至模拟器或android设备。
adb logcat > fileName.txt，此命令可以直接捕获全局的日志信息，开发人员可以通过分析日志获得自己想要的信息
adb logcat | grep <过滤内容> > fileName.txt，此命令可以过滤内容

四十一、使用monkey测试了什么内容？测试过程中有没有发现问题？

使用monkey验证app在大量随机性操作的下时候是否会崩溃，主要是用于验收测试阶段。
测试过程中是有发现问题的，在我之前的项目中，在使用monke执行第二次压力测试时，app突然崩溃，当我查看日志信息显示NullPointerException ，并记下seed值，将错误复现了一遍，发现依然报错，就截图发给对应的开发确认是什么问题导致的。

四十二、使用ABD如何连接手机？冷热启动如何测试的？你们的app启动时间多长？

用Adb有两种连接手机的方式，在测试过程中，各有优缺点吧。

• 一种是用USB连接：
  优点：插上就可以连接，延迟低。
  缺点：需求借助USB线来连接，做兼容的自动化测试的时候比较麻烦
  1、会在手机上打开开发模式，启用USB调式。
  2、USB线连接手机和电脑
  3、在cmd窗口输入 adb devices（手机上会有一个提示：是否允许此电脑进行调试，确认)
• 另一种是用WIFI连接
  优点：使用无线连接，做自动化的时候可以远程运行
  缺点：需求借助网络，延迟高，速度略慢（并没有感觉到）
  1、先用USB连接手机和电脑
  2、在cmd窗口输入 adb tcpip 5555
  3、拔掉USb线
  4、查看手机IP地址 或者直接在CMD窗口输入命令
  adb connect IP：5555
  冷启动：当进程不存在的时候，从进程创建开始到界面的展示的过程；
  热启动：大部分资源都在，只是应用之间的切换；
  adb shell am start -W 包名/界面名
  冷启动：需要1秒甚至更长；
  热启动：需要<0.5秒；

四十三、你常用的Linux命令有哪些？分别说明下用途和命令？5个以上

ps -aux | grep bin: 查看系统进程,并查找特定应用的程序
-top: 用于实时查看系统进程相关信息
-kill -9 进程号: 强制关闭对应的进程
netstat -anptu |grep mysql: 查看特定进程的端口信息
tail -f 文件名: 实时显示日志的文件信息
tar -zxvf 打包文件.tar.gz -C 目标路径: 解压压缩文件
vim编辑器一定要知道，以及vim中的一些常用快捷键

四十四、在测试环境出现偶尔出现的BUG，你会如何处理？

1、当bug出现时，抓取log或截图，视频留下证据；
2、分析问题严重级别，以及同步开发进行分析修复时长，测试评估测试时长。如果影响范围大且修复时间较长，则建议回滚代码，否则直接修复验证并重新发布；
3、记录前置环境，操作步骤，和使用过的数据，尝试重现bug；
4、若无法重现，则找开发人员协助重现；在开发人员的协助下仍未能重现，则考虑bug的实际影响定义bug的严重级别，是否能延迟到以后的版本再来修复。

四十五、在你的项目中做过UI自动化，简单说说你是如何做的?

该问题根据自己的实际情况还选择实施的程度:
1、只会Selenium基本API编写面向过程脚本；
2、能使用单元测试框架组织测试用例，不需要任何封装；
3、能编写完整的自动化测试框架

• 程度1：有简单的了解过Web自动化脚本的编写，使用的是Selenium工具，在之前的项目里面基于功能编写了一些自动化面向过程的脚本，利用元素定位和常用API实现模拟手工操作。利用这些脚本可以在测试过程中去代替一些手工构造测试数据的过程。对于单元测试框架Unittest/Pytest有一定得了解，可以参考一些文案写出简单的单元测试用例。
• 程度2：在项目中，基于自己所负责的模块有利用自己的时间，使用单元测试框架Pytest+Selenium编写过一些功能的自动化测试脚本，例如实现主流程的自动化测试用例，功能的测试用例。并使用单元测试框架中Parameter实现了参数化，以及assert断言。可以利用Pytest实现批量执行测试用例，结合Allure擦肩生成测试报告。
• 程度3:在项目中，由于经常有版本迭代，回归测试任务还是比较多的。部分核心的功能模块界面也比较稳定，为了提供回归测试效率，团队采用了UI自动化测试技术来解决回归测试的问题。我们使用的实现技术框架为：pytest单元测试框架+Selenium/Appium+PO页面对象的封装模式+Allure测试报告的框架来实现的UI自动化。整个项目过程中，也没有专门规划一段时间去一次性完成整体的自动化，而是测试经理规划好整体实现框架后，在版本迭代空闲时间，分配一些脚本编写的任务。在我离开公司时，UI自动化测试用例库已经基本覆盖到了项目核心功能点和流程。如流程、功能模块。其中是我编写的。

四十六、最常用的元素定位方法是什么？如果元素定位不到你会如何分析？

最常用的元素定位方法是XPATH,当然也会根据实际情况用一些其它的定位方式,例如:CSS等。
定位不到元素无非以下几种情况,一般情况下我会从简单的开始分析:
1、先确认是否定位信息写错；
2、再确认是否有窗口切换；
3、查看元素是否在iframe标签中；
4、元素等待的问题；
5、定位代码前面的步骤就有问题，导致没有到所要定位元素界面等等。
基本上定位不到元素的问题都可以解决掉。

四十七、显示等待和隐式等待的区别是什么？哪个用的多？为什么？

显示等待和隐式等待的核心区别在于：隐式是一个全局设置，显示只针对单个元素；隐式等待受整个页面加载的影响，而显示等待只要所要定位的元素加载到就可以继续运行。还有实现方法、超时异常有区别。
其实都会用，隐式等待本身就只有设置一次，在创建浏览器驱动对象的时候就会加上。而显示等待会基于对Selenium元素定位的方法进行二次封装，后续调用元素定位方法时都会调用二次封装后的元素定位代码，所有的元素定位都会对于显示等待生效。而有隐式等待多了一重元素等待的保障。

四十八、有没有做过二次封装？封装了哪些方法？简单的描述下？

有的!
例如元素定位方法，会进行显示等待，会兼容8种元素定位的方法的封装；如模拟输入：基于原有的send_keys方法输入之前，加上模拟清除的操作；再例如窗口切换、Select下拉框等多行实现的操作方法都会进行二次封装。这些封装的代码我们都会放在一个基类中统一的进行管理。

四十九、桌面应用如何实现的自动化？有没有解决方案？

• 没有桌面应用自动化经验：我之前所实现的项目是web端的项目和APP，暂时还没有测试过桌面应用的相关软件程序。所以基于桌面应用的UI自动化实现方式没有具体实践过。但是我知道市场有可以实现该UI自动化测试解决方案和工具：如QTP就可以实现桌面应用，最新AIRTEST也可以。个人感觉其实现的大体思路和web端的大同小异，只是页面元素换成了桌面元素，如果公司有需要，我可以利用自己的时间去研究。
• 有经验就按照实际情况描述即可。

五十、UI自动化解决了什么问题？你觉得其价值大不大？主要体现在哪里？

个人觉得UI自动化测试核心解决的问题还是解决手工回归测试，基于历史功能或流程进行回归，代替绝大部分的回归测试工具，缩减测试工程的重复的工作。第二：UI自动化的脚本还可以通过运行来准备测试数据，例如我要测试生成订单后的各种流程，就可以通过运行生成订单的测试用例。
我觉得UI自动化测试脚本如果编写的比较全面的话，价值还是很大的。就例如上面说的回归测试和构造数据，不过前提是项目适合做UI自动化。否则就是白白投入。