关于软测面试的20个终极问题，春招软测人快来看..

金三银四已经到了，想要找工作，或者是想要跳槽的小伙伴们可要做好准备了，给大家总结了软测面试必问的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.按照测试用例测试执行过程中，难免出现用例覆盖不到的，会做好用例补充；

最后： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取 【保证100%免费】

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！