面试必练500题（八年测试经验面试28K公司后）

八年测试经验面试28K公司后#01在项目中如何保证软件质量？❶参考点1、考察对测试工作的理解2、考察求职者有没有对测试工作有一些自己的思考和认识❷面试命中率90%❸参考答案项目质量不仅仅是某个人或某个团队来保障的，而是整个团队一。

#01

❶

参考点

1、考察对测试工作的理解

2、考察求职者有没有对测试工作有一些自己的思考和认识

❷

面试命中率

90%

❸

参考答案

项目质量不仅仅是某个人或某个团队来保障的，而是整个团队一起努力的结果，在公司级别需要有一个规范的项目流程

• 产品，保证迭代过程中的产品逻辑，对于可能的兼容，升级做出预判，并给出方案
• 设计，满足产品表达的同时，保证设计的延续性
• 开发，产品细节的保证，技术方案选择要严谨，考虑兼容，性能，开发完成后要充分自测，严格遵循开发规范操作
• 测试，验证产品逻辑，站在用户角度对交互设计进行系统验证，尽可能多的使用技术手段保证测试质量

#02

❶

参考点

1、是否拥有测试计划的制定经验

2、是否具备合理安排测试的能力

3、是否具备文档输出的能力

❷

面试命中率

95%

❸

参考答案

测试计划包括测试目标、测试范围、测试环境的说明、测试类型的说明（功能，安全，性能，稳定性）、测试工具、模块的划分、测试负责人、测试执行轮次的时间安排、相关文档在文档管理库中的位置、测试的风险 。

其中模块划分需要根据测试人员对于业务的熟悉程度及个人能力进行分配，工作量的估算需要根据以往测试时的经验，结合本次需求的修改，可以大致估算出测试量

#03

❶

参考点

1、考察测试用例编写包含的要素

2、考察测试用例要素的核心要素

❷

面试命中率

99%

❸

参考答案

• 要素一般包括：用例编号、用例优先级、测试目的、所属模块、前提条件、测试环境、输入数据、测试步骤、预期结果、测试脚本等
• 核心要素：用例优先级、测试目的、预期结果

#04

❶

参考点

1、考察对测试基础的理解

2、考察实际工作中问题排查的能力

❷

面试命中率

80%

❸

参考答案

• 抓包分析通过对客户端进行抓包，分析服务端返回的数据是否符合预期，如果服务端数据是正确的，那就是客户端的问题
• 日志分析可以通过查看客户端/服务端的日志，分析有没有异常的日志信息，从而确定具体原因

#05

❶

参考点

沟通，人际关系

❷

面试命中率

99%

❸

参考答案

开发人员说不是bug，有2种情况：

• 一是需求没有确定，所以这个时候可以找来产品经理进行确认，需不需要改动，商量确定好后再看要不要改。
• 二是这种情况不可能发生，所以不需要修改

这个时候可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。如果最终bug被确定不改，那么就要在测试报告里面记录一下，以便以后查阅。

#06

❶

参考点

1、对各种测试类型的掌握程度

2、对测试理论知识的掌握程度

❷

面试命中率

80%

❸

参考答案

Web端测试和移动端测试类型基本相似，都需要进行功能测试、性能测试、安全性测试，他们主要区分web端一般都是b/s架构，基于浏览器的，app是c/s架构，是有客户端的。

• 从系统架构来看的话：web测试只要更新了服务器端，客户端就会同步更新；而如果是app端下修改了服务端，意味着客户端用户所有使用的核心版本都需要进行回归测试一遍。
• 客户端性能方面：Web端可能只会关注响应时间；App则还要关心流量、电量、cpu、等；
• 兼容方面：Web是基于浏览器的，所以更倾向于浏览器（IE、Chrome、firefox）和电脑硬件，电脑系统方向的兼容；App测试则必须依赖于手机或者pad，不仅要看分辨率、频目尺寸、重要看设备系统。

#07

❶

参考点

关于软件测试流程的理解

❷

面试命中率

95%

❸

参考答案

• 需求评审和分析
• 制定测试计划
• 根据需求文档编写测试用例
• 测试用例评审
• 提测后执行冒烟测试
• 执行第一轮测试，找bug
• 执行回归测试，验证bug
• 执行第二轮测试
• 部署项目到预生产环境
• 预生产环境测试
• 发测试报告
• 项目上线
• 线上验证和监控（主流程、主功能点的验证）

#08

❶

参考点

沟通技巧

❷

面试命中率

85%

❸

参考答案

1、就事论事，跟开发沟通时不要携带任何情绪，客观真实的进行沟通

2、不要过渡依赖开发，遇到问题先自己尝试分析下，有一个基本判断后，再去找开发

3、描述问题要简洁、清晰，比如现在在做什么事情，遇到了什么问题，需要开发提供什么帮助

4、测试要有自己的原则和立场，自己认为是正确的事情，要坚定立场和自我判断，不能完全听信开发

5、尽量集中式沟通问题，避免碎片化沟通，导致开发工作频频被中断

6、提升自己的技术能力和认知，用更专业的语言和开发沟通

7、遇到非常难沟通的开发，有必要时，要及时向上反馈，寻求帮助

#09

❶

参考点

自动化测试实际经验

❷

面试命中率

95%

❸

参考答案

分析面试题：想了解自动化测试的实施和落地，考察你的参与度还是项目的主导人，你是负责的是整个项目还是一个简单的demo

• 工具的选型，举例 selenium or appium，组织会议，准备好demo来执行，看下需求的匹配程度 以及项目的推荐程度
• 自动化测试框架的搭建 -- 项目组别扩展补充测试用例
• 将项目的自动化流程，已经框架固化成文档，方便归纳整理
• 等自动化在项目组内有一定的成果，将框架推广到其他项目组，提升公司内部口碑

#10

❶

参考点

1、考察测试用例设计基本功2、考察对于用例设计的理解

❷

面试命中率

95%

❸

参考答案

分析面试题：不管是手工还是自动化，测试用例就是一组按部就班的指令，以验证某些功能是否符合的需求。

我们可以从以下几个角度来思考 -- 你如何设计自动化测试用例？

• 测试环境的准备 -- 测试代码需要频繁的执行，异常处理的能力比较差，需要单独准备环境
• 测试数据准备 -- 数据选择自动生成的方式
• 测试业务 -- 根据业务逻辑关系构建测试用例
• 检查点/测试手段 -- 断言
• 测试环境清理 -- 执行频繁 产生垃圾数据，需要采用环境清理 定期清理数据库

#11

❶

参考点

1、PO模式理论2、PO模式分层思路

❷

面试命中率

99%

❸

参考答案

页面对象模型(PageObject)是一种设计模式，用来编写和维护自动化测试

Po模式的优点：

• PO提供了一种业务流程与页面元素操作分离的模式，这使得测试代码变得更加清晰。
• 页面对象与用例分离，使得我们更好的复用对象。
• 可复用的页面方法代码会变得更加优化
• 更加有效的命名方式使得我们更加清晰的知道方法所操作的UI元素

如何编写PO模式

• 抽象每一个页面
• 页面中元素不暴露,仅报错操作元素的方法
• 页面不应该有繁琐的继承关系
• 页面中不是所有元素都需要涉及到,核型业务元素做建模使用
• 把页面划分功能模块,在Page中实现这些功能方法

#12

❶

参考点

项目的测试思维

❷

面试命中率

90%

❸

参考答案

• iframe元素，当要操作的元素在iframe中是需要先将driver切换至该iframe才能操作，切换方式有四种，通过id、name、索引、iframe元素对象，并且在多iframe切换时还需要进行各种转换
• 新窗口打开，当要操作的元素在一个新窗口打开的页面上时，就需要先将driver切换至新窗口上才能进行操作
• 时间控件，通常时间控件只能选择无法输入，那么可以采用js的方式修改时间控件的只读属性然后再进行输入，或者用js直接修改时间控件的value值
• 元素不在当前视野需要滚动才会出现，可以采用js的方式滚动，但是有时候界面中有多个滚动条js就会无效，则需要先将光标置入到滚动条区域然后模拟键盘的上下左右键来操作

#13

❶

参考点

项目的测试思维

❷

面试命中率

85%

❸

参考答案

自动化方向：

主要分为ui自动化 和 接口自动化

• ui自动化分为两个方向：web端和app端 web端框架的构成：Pythonsleniumpytestallure 报告APP段框架构成：Python appium pytest allure报告
• 接口自动化：Python requests pytest allure报告

#14

❶

参考点

是否具备接口测试实际经验

是否熟悉接口测试的流程

是否熟悉接口测试的具体步骤

是否熟悉接口测试用例设计

❷

面试命中率

90%

❸

参考答案

先了解接口的业务功能、入参出参以及接口对应的数据存储，再依据接口测试用例设计方法完成接口测试的设计，用例设计先业务场景再参数判断；

比如参数的边界值、格式、组合等等，最后依据测试用例使用接口测试工具完成接口测试，并在测试过程中查看日志及数据以确保接口测试结果的正确性

#15

❶

参考点

项目的测试思维

❷

面试命中率

85%

❸

参考答案

• 首先线下必须要有专门的性能测试环境
• 线下环境单台机器配置和线上不能相差很大，可以通过单台的机器性能推算出多台机器性能（需考虑一定的性能损耗）
• 如果线下机器配置很差，只能测试出程序有无性能问题，这样线下测试出来的数据对线上没有太大参考意义
• 如果想获取比较准确的线上性能情况，建议最好做线上的性能测试

#16

❶

参考点

对于优先级和严重程度的理解

❷

面试命中率

95%

❸

参考答案

Priority(优先级)和Severity(严重程度)是提交bug的两个重要属性。

通常，测试人员在提交Bug时，只定义Bug的Severity, 即该Bug的严重程度，而将Priority交给Project Leader 或Team Leader来定义，由他们来决定该Bug被修复的优先等级。某种意义上来说，Priority的定义要依赖于Severity，在大多数情况下，Severity越严重，那这个Bug的Priority就越高。

Severity（严重程度）如下：

• Blocker（有妨碍的）: 即系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定
• Critical（紧要的）：即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性
• Major（严重的）：即界面、性能缺陷、兼容性。
• Minor/Trivial（次要的/不严重的）:即易用性及建议性问题。

Priority（优先级）：Immediate（立刻）、Urgent（紧要、优先）、High（高度重视）、

Normal（正常）、Low（稍缓）

#17

❶

参考点

项目的测试思维

❷

面试命中率

95%

❸

参考答案

• tps：每秒事务量，代表了系统的处理能力，tps越高，性能越好
• 响应时间：从发出请求到接受到系统响应数据所花费的时间，响应时间越短，性能越好
• 吞吐量：网络上行和下行流量的总和，吞吐量是网络瓶颈定位的重要指标
• 错误率：在压测过程中系统出现错误的比例

#18

❶

参考点

是否熟悉jmeter

是否熟悉关联的业务场景

是否熟练关联所用到的组件

❷

面试命中率

85%

❸

参考答案

接口关联指的就是一个接口要使用另一个接口的返回值作为参数，在jmeter中针对不同的响应数据格式都有不同的处理组件，json格式的采用json提取器，xml或者html格式的采用xpath提取器，其他格式的可以采用正则表达式提取器，BeanShell后置处理器也可以从响应结果中提取响应内容，通过这些组件提取所需内容后，在需要关联的接口中引用变量即可完成关联

#19

❶

参考点

考察对企业中接口通信机制的认识

考察同步通信和异步通信的原理

❷

面试命中率

90%

❸

参考答案

同步和异步是一种通讯方式

• 同步：执行一个操作时，需要等待其处理完成，然后再进行下一个操作
• 异步：执行一个操作时，不需要等待返回，就进行下一个操作，一般需要使用消息中间件

举例：

• 下单接口中，需要调用库存接口做库存判断，所以必须等待库存接口返回数据才能进行下一步操作，这是同步；
• 下单接口中，下单成功后需要调用邮件通知接口，不用等待接口返回成功，就可以直接进行下一步操作，这是异步

#20

❶

参考点

考察在工作中是否做过性能测试

考察是否具备一定性能分析能力

考察对于性能分析是否具备清晰的思路

❷

面试命中率

85%

❸

参考答案

• 压力机本身性能瓶颈
• 网络IO瓶颈
• 中间件（tomcat/nginx/mysql）连接数限制
• Java线程的阻塞、等待
• 本系统资源的瓶颈（cpu、内存、磁盘、网络等）
• 其他外部系统响应时间过长，造成本系统的time-wait

#21

❶

参考点

考察性能测试分析思路

考察性能瓶颈的理解

❷

面试命中率

90%

❸

参考答案

性能瓶颈分析参考准则：排除法，从上至下、从局部到整体！

针对不同的瓶颈采用不同的分析方法，一般分为：内存分析方法、处理器分析法、磁盘I/O分析方法、进程分析方法、网络分析方法等等。

• 内存分析方法：内存分析用于判断系统有无内存瓶颈，是否需要通过增加内存等手段提高系统性能表现。
• 处理器分析法：通过处理器性能计数器的值体现服务器整体处理器利用率，判断是否存在处理器瓶颈。
• 磁盘I/O分析方法：通过磁盘I/O性能计数器的值体现服务器整体磁盘I/O使用情况，判断是否存在处理器瓶颈。
• 进程分析方法：通过进程性能指标数据，判断是否存在进程瓶颈。
• 网络分析方法：通过网络性能指标数据，判断是否存在网络瓶颈。