想要找工作,或者是想要跳槽的小伙伴们可要做好准备了,给大家总结了软测面试必问的20到面试题,背完面试不用慌!
1. 项目测试流程你是怎么开展的?
【参考回答】
首先,需求分析阶段,主要参与需求评审会议,阅读理解业务需求,分析需求点。
需求确定后,进入测试计划阶段,参考软件需求规格说明书及项目总体计划,进行测试计划编写。 明确测什么,怎么测,时间安排、人员任务分配,风险评估。
接着,进入测试设计阶段,依据需求文档及原型图编写测试用例,并进行用例评审。
第四,进入测试执行阶段。我们需要搭建测试环境,执行冒烟测试,进入正式测试;并且将测试缺陷进行提交及跟踪。经过多轮回归测试,直到测试版本结束。
最后,进入测试评估阶段,对软件版本质量进行评估,输出
测试报告,确认是否上线。
2. 接口测试用例的编写要点有哪些?
【参考回答】
第一:考虑接口的正常调用
第二:业务约束规则验证;包括鉴权,逻辑约束
第三:考虑请求参数必填字段;参数长度边界值验证,类型异常、null;参数名错误、参数个数+1,参数个数-1 情况
第四:参数组合验证
第五:容错能力。大容量数据、频繁请求、重复请求(如:订单)
第六:性能。对接口模拟并发测试,逐步加压,分析瓶颈点。
第七:安全性。敏感信息是否加密,构造恶意的字符请求,SQL 注入等
3. 怎么定位是前端 bug 还是后端 bug?
【参考回答】
第 1,基于经验;如果这个 bug 是界面排版布局错误,像兼容性问题,则很明显是前端 bug;对于网络不稳定下导致的 js/css 未加载完全或请求超时问题,也是前端 bug
第 2,对于数据或逻辑处理上的问题,则可以通过抓包工具fiddler、charles,或者查看日志分析
第 1 种通过抓包工具,检查请求地址、参数的正确性,
1)若不正确,则为前端 bug;若正确则进一步检查服务器返回的响应,若响应内容不正确,则是后端处理出错;
2)若请求、响应都正确,那就是前端渲染响应的数据出错,则前端 bug
第 2 种,可以查看报错日志、分析日志里面的异常报错信息,查看数据库数据判断前端还是后端问题
4. 项目上线后发现的 bug,你们会怎么处理呢?
【参考回答】
当发现线上的 bug,项目组应快速响应处理,先积极配合开发重现 bug 定位问题;如果是严重 bug,则需积极解决,更新版本;若 bug 不是那么严重,一般会放到下一个迭代版本中处理。然后,更重要的是经验总结,反思 bug 出现的原因和规避方案。
总结一下常见的线上 bug 原因及规避方案:
第一,测试用例覆盖不全面,尤其用户不可控的使用场景,导致出现漏测。 解决方案:优化测试用例,增加用例评审。
第二,测试的时间不充分,导致一些次要功能点在测试的过程中被忽略。解决方案:规划充分的测试时间,严格按照时间节点完成测试工作
第三、测试的环境或者测试的数据受限,导致了测试不到位。解决方案:考虑 mock 测试,或者在真实环境下覆盖测试
第四,开发人员修复其他问题时,引入了新 bug。解决方案:明确测试范围,尤其是代码修改的功能部分。回归测试时,主流程必须回归,必须必须一个完整流程。
5. http 协议有哪些响应状态码?
【参考回答】
常用的状态码有如下几种:
1xx(临时响应):表示临时响应并需要请求者继续执行操作的状态代码。
2xx (成功):表示成功处理了请求的状态代码。
3xx (重定向):表示要完成请求,需要进一步操作。 通常,这些状态代码用来重定向。
4xx(请求错误):这些状态代码表示请求可能出错,妨碍了服务器的处理。
5xx(服务器错误):这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误,而不是请求出错。
6. 说一下 TCP 协议的三次握手过程?
【参考回答】
TCP 协议要建立连接的时候,需要经历三次握手的过程:
第一次握手: 是客户端向服务器发起的,用来申请建立连接的,这个报文中的 SYN 标志位标记为 1,所以我们也叫作SYN 包;
第二次握手:是服务器回复客户端的,用来确认并接受连接请求的,这个报文中的 SYN 位和 ACK 位都标记为 1,所以叫做 SYN-ACK 报文;
第三次握手:仍然是客户端发给服务器的,用来确认服务器的回复消息,这个报文中的 ACK 标志位标记为 1,所以我们也叫作 ACK 包。
这就是 TCP 协议的三次握手过程。
7. 项目页面无法访问,如何定位问题?
【参考回答】
首先我会判断一下这个页面的域名是都可以正常解析到,避免域名解析的问题;
然后,可以用 ping 命令判断一下服务器是否可达;如果不可达,可以用 tranceroute 命令,查看一下是哪个节点出的问题;
如果不是网络的问题,再去后台服务器查看服务进程有无开启,数据库服务有没有开启。
这样子,基本可以找到问题所在。
8. 给你一个产品你是怎么开展测试的?
【参考回答】
首先拿到项目后,要先熟悉需求、原型图,了解被测功能和各个功能的业务逻辑;
针对以上需要测试的内容进行大概的测试规划,然后逐个细化去设计测试用例。
整个过程中存在疑问的及时跟开发产品沟通确认。
开发提测后,按照用例执行测试,提交 bug,并有效进行回归测试完成 bug 跟踪;
测试完毕后,及时汇报测试结果,输出测试报告
9. 编写测试用例的流程
【参考回答】
1、熟悉并分析项目业务需求
2、依据功能模块划分,使用等价类、边界值、场景法等用例设计方法,先整理功能正常的用例,再到功能中每一个操作的异常用例的覆盖,补充业务约束,及功能交互项、数据验证项等
3、每个功能模块分别写完用例后,从项目的业务流程考虑,是否都进行了用例的覆盖,没有进行用例补充
4、另外还补充到界面测试用例
5、编写完成后,提交评审
10. 讲下你印象中最深刻的 bug 吧?
【参考回答】
这个问题面试前需要提前准备好。确实一时想不起来,可以跟面试官说容我思考一下,然后从以下方面切入:
首先、找一个自己工作中很熟悉的项目,
然后、思考下如何对这个项目进行测试的,
比如,在某一个功能测试中,发现了什么 bug,主要讲清楚测试过程,排查过程和验证过程,中间多讲讲怎么帮助研发排查问题的就可以了。
11. 怎么判断一个接口是否有 bug
【参考回答】
一般呢,先确认自己传参时的接口地址,请求方式,请求头和请求体是否是正确的,如果是正确的,那么就查看返回结果,和接口文档做对比,一致则继续判断数据库中的数据是有问题。都没有那么就说明接口是 OK 的
如果接口返回是结果和文档不一致,就是有 bug。并且数据库存储如果也有问题,那也是 bug
12. fiddler 如何构造弱网测试?
【参考回答】
1 、 在 Fiddler 中 Rules 右 键 Customize Rules , 打 开CustomRules.js 文档;
2、修改文档中,每上传或下载 1kb 数据需要的时间来模拟弱网场景(剪辑右图)
3 、 然 后 Rules->Performance-> 点 击 Simulate ModemSpeeds,开启弱网模拟。
通过以上 3 步就可以实现弱网测试场景的构造。
另外呢,像腾讯的 Qnet 也可以构造各种网络场景进行测试,也可以去补充下了解。
13. https 协议比 http 安全,是如何实现的呢?
【参考回答】
https 协议通过 SSL 协议外壳来实现它的安全性,主要体现在三个方面:
第一: 数据是加密的,SSL 协议通过非对称秘钥分发的方式完成秘钥的协商,然后通过对称秘钥的加密方式完成数据的加密;
第二:会验证对方身份。服务端和客户端双方会需要向 CA机构申请证书,再 SSL 握手阶段会验证双方证书是否可信,从而验证双方的身份,防止第三方冒充;
第三:保证数据的完整性。每次的数据都会加上 MAC 摘要并签名,接收的数据和发送的数据这个摘要信息一致的,就表示数据没有被篡改过。
14. 如果让你单独负责一个项目,需要注意什么呢?
【参考回答】
1.首先,评估项目的测试范围和周期,能否单独完成,若不能,及时反馈并协调人手
2.做好测试策略和计划安排,尽量保证每个环节按时完成
3.在上手测试前,梳理大致的测试点,先做冒烟
4.测试中,尽量通过一些技术手段提升测试效率
5.项目中,若碰到自己解决不了问题,要及时向外抛出并积极寻求解决方案
6.及时对 bug 进行追踪,推动开发尽快解决 bug
7.把控发布标准,测试报告中标明上线风险
15. 给你一个微信上一个聊天的窗口你是怎么测试的?
【参考回答】
微信聊天框的主要功能就是发送消息和接收别人发过来的消息。
消息的分类:纯文字,图片,文件,表情,语音、视频,文字+表情
聊天的特殊功能:@符号,撤回功能,加好友功能,消息重发,发红包,转账,发送位置信息、发送名片、群聊等功能
16. 偶发性 bug,作为测试该怎么处理?
【参考回答】
a.首先,在遇到复现率低的 bug,一定要提 bug,描述清楚当时出现问题的步骤、操作环境、账号及测试数据、及必要的日志信息。
b.在发现 bug 时,要分析产生的原因,尽量多尝试可能出现的步骤,排除环境和自己电脑配置的原因,比如浏览器的版本等。甚至可以让开发对相应地方的代码进行检查,看一下是否可以通过代码层面检查问题。
c.如果未复现,在接下来的测试中,时刻保持关注,每次执行同样或者相近的步骤的时候,看下是否能够复现之前的 bug。
d.那些一直未能复现的 bug,需要测试经理定期将这些 bug 汇总,选择优先级高的缺陷,组织开发人员和测试人员专门投入到复现问题。如果经过这样的专门复现依然不能复现,可以降低问题的优先级。
e、另外,项目发布后,跟踪至少 3 个版本,及时关注用户的使用反馈,如果仍然无复现,可以暂时关闭该bug,备注说明并不是因为修复关闭,而是经过 n 个版本后不复现了。
17. 你们公司版本上线标准是怎样的?
【参考回答】
1、测试用例是否执行完成。对于覆盖产品需求点的用例要达到 100%执行,若不能全部执行,需要标明未执行原因,例如时间原因或优先级比较低的易用性测试用例;
2、剩余 bug 的数量和严重等级要达到标准。
2.1 不存在 1、2 级严重等级的 bug
2.2 遗留的 3、4 级 bug 数量需要经过产品经理和测试经理协同决定可遗漏数量
3、上线前的最后一轮回归测试是否完成。最后一个版本也就是上线的版本一定要经过一轮完整的回归。
以上是公司规定的上线标准,不同的公司规定不同标准不同,不同项目也会依据实际情况,对以上 3 个上线标准存在灵活的调整
18. 测试进行不下去的时候,怎么办?
【参考回答】
这个就需要分析一下是什么原因导致测试工作进行不下去
1、如果因为 bug 导致测试阻塞的话,需要将 bug 及时反馈给开发并协助解决,且需及时向领导汇报测试阻断原因。
2、如果是测试时间紧张导致的话,也需及时汇报领导,是否调配人手或通过自动化手段提高效率,不要一个人盲目的承担。
3、因为测试数据不好造导致的,可以通过数据库或者接口去制造测试数据,实在是太难的可以请求开发的帮助。
4、若是因为测试环境导致的,及时排查环境原因,且及时向领导反馈问题
19. 你讲一下登录功能,你会考虑哪些测试点呢?
【参考回答】
功能测试:检查系统登录功能是否满足需求。
界面测试:检查登录界面元素、风格是否符合需求,有没有分辨率不清晰、页面错乱或遮挡等情况。
性能测试:检查系统响应时间,大数据并发响应时间。
本地化测试:系统需要支持多种语言或多个国家上线时,切换语言时系统功能稳定性。
兼容性测试:对不同操作系统、浏览器是否可以正常工作。
可用性测试:检查系统的有效性、效率、易用性以及容错能力。
安全测试:输入框是否屏蔽sql注入、xss攻击、输入错误密码次数限制等。
20. 怎么保证测试用例的覆盖率?
【参考回答】
测试用例的覆盖率,可以从分析-编写-执行 3 个部分来讲
1.从需求阶段开始,尽量理清楚产品的大致功能及功能模块的联系,同时参考同类型已成熟的产品,去熟悉需求细节,把需求,不明确的部分及时跟产品及开发沟通;
2.需求确定后,时间紧张的话,按功能模块去整理测试点,运用科学合理的用例设计方法比如等价类、边界值、场景法、决,策表来进行设计;整理完成后,我们测试内部会进行测试点的评审,进而保证对于需求覆盖的完整性;
3.按照测试用例测试执行过程中,难免出现用例覆盖不到的,会做好用例补充;
感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取