软件测试面试题合集（一）

1、软件测试的理解、软件测试的重要性、软件测试在软件生命的地位、软件测试的意义、为什么选择软件测试这个行业

软件测试主要是为了保障软件的质量，质量保证在生活中是随处可见的。有了软件测试这一阶段，可以验证软件是否符合需求说明书、设计文档，可以为软件的质量提供评估依据，同时也能找出软件的缺陷，改进开发流程，降低软件缺陷风险

所以我认为软件测试是软件生命周期不可或缺的一环

2、软件测试流程

需求分析、评审--负责人编写测试计划--测试员编写测试用例--评审测试计划--评审测试用例

--搭建测试环境--执行测试--发现bug就提交bug，bug完成闭环--回归测试--完成测试，统计测试用例执行的结果，编写测试报告--bug汇总分析，各个等级的bug如果都关闭--测试负责人评估是否可以发布版本

3、 常见测试工具

postman：接口调试，一般用于初级人员接口测试

jmeter：接口和性能测试

软件缺陷管理平台：JIRA、禅道

fiddler：抓包工具

4、设计功能测试用例的方法、黑盒测试方法

等价类：有效等价和无效等价类

边界值：假设输入框规定1-10位数一下，边界值为0、1、5、10、11

因果图：程序输入为因，程序输出为果，不同条件不同结果

判定表：条件组合多，输出结果也多时使用。确认所有条件以及对应结果，列出所有条件以及结果，填入输入输出，合并规则减少冗余

场景法：根据事务的正确流程得到正确结果称为基本流，其他阻塞或故障情况称为备选流

正交排列：用于情况特别多的情况，选出一部分情况来代表统一水平

可使用正交设计助手，https://www.jb51.net/softjc/628400.html

错误推测：凭借以往的测试经验、对业务的理解来推测可能出现bug的地方

5、如何进行需求分析、怎么快速理解需求、你对需求有疑问时如何处理

根据产品经理下发的需求说明书文档，熟悉并通读一遍，根据自己的理解编写XMind，如果条件允许可以借开发人员的开发环境进行适当的操作，对需求不清楚、有疑问、有歧义、感觉不符合用户操作、有遗漏、不完整的先记录，在需求评审会议上提出，根据产品经理的答复，达成需求理解一致

需求评审的的目的：为了检查是否有需求遗漏、需求错误、需求冗余，最后产品、研发、测试三方需求理解一致

6、测试计划的内容

概述：此次测试的目的及相关项目文档

测试范围或对象：测试项目的版本模块，系统架构、组网图

测试资源需求：人力、软硬件资源

测试排期：每个测试活动的时间安排

测试准入准出条件：测试项目的启动、暂时挂起、停止的准则

测试用例执行规则：测试用例失败、成功、阻塞blocked、WIP的规则，回归测试的规则

测试策略：设计测试用例使用的测试方法、规定测试优先级

测试风险分析：预判测试可能出现的风险以及如何解决风险

测试交付：什么时候提交测试计划

7、测试用例的内容

编号、标题、版本、模块、前置条件、测试数据、测试步骤、预期结果、优先级、测试人员

8、bug的内容

编号、标题、模块、测试步骤、预期结果、实际结果、测试环境、影响版本、处理优先级、严重等级、测试执行人、经办人、时间

9、是否搭建过测试环境

会，之前工作时使用过devops20.8.1，搭建环境，使用的系统是centos7.5

根据部署文档部署：

安装devops

集群配置

加密狗配置

镜像导入

安装服务、导入、部署

到处devops集群信息

10、执行过多少测试用例、测试用例执行怎么提高效率

至少执行了2000条

收到测试用例执行的任务，先规划每日、每周需要执行多少条，提前规避时间风险

根据需求业务理解，分不同模块执行，对有相同功能或类似的测用例一起执行

对有阻塞较多的模块，提前告知测试负责人，每日汇报测试执行进度

11、bug的生命周期、bug有哪些阶段、你发现了bug会怎么做

提交bug给开发负责人，然后分配给指定的开发人员   new--open

开发人员收到bug，处理bug后为已解决      open--fixed

bug流转到测试人员，测试人员验证bug是否修复

        修复bug成功，关闭bug      fixed--closed

        修复bug失败，重新打开bug  fixed--reopene

开发人员继续修复bug   reopen--fixed

测试人员再次严重bug是否修复成功 ，直到bug修复成功后关闭

开发人员收到bug，认定为不是bug的情况，bug状态为rejected

开发人员收到bug，觉得可以暂时不修复或下个版本修复，delay

12、作为测试人员如何定义一个bug

主要依据为需求说明书、个人对业务理解、测试经验

需求实现错误

需求实现遗漏

需求实现的方式不符合说明书

实现了冗余功能

未到达需求定义的指标

不符合用户操作习惯

用户觉得难操作

13、以你的经历 ，阐述一下产生bug的主要原因

我认为主要是需求方面的原因，需求变更频繁容易导致bug

沟通不良，导致需求理解不一致

其他：时间紧任务重，前后端联调未完全，开发自测程度低，开发人员人力缺失、产品人员缺失、开发人员技术能力或经验不足

14、回归测试的概念、回归测试的作用和目的、如何做回归测试

回归测试：当bug修复好，目的1要验证bug，还要验证之前好的功能是否还是好的，目的2是bug修复导致原先好的功能出现新bug

15、各个测试阶段概念及描述

单元测试：属于开发人员测试，对各个独立代码单元模块的正确性进行测试

集成测试：将各个单元模块组装，形成子系统，对子系统进行测试，主要是为了测试程序模块之间的调用的正确性

系统测试：将人员、软件、硬件、操作平台、数据等结合在一起，形成一个系统，在实际允许环境下，对整个系统进行全面的测试

验收测试：模拟实际用户环境（试运行环境），测试人员或者和实际用户一起进行全面测试

16、tcp  udp

tcp：面向连接的传输服务、可靠数据传输（无差错、无失序、无丢失、无重复）

可靠性保证，通信钱建立连接，应答机制，通信结束正常连接断开

udp：无连接的传输服务，数据传输可能会丢失，但是传输过程简单，实现容易，以数据包形式传输，传输效率高

都属于OSI七层模型的传输层协议

区别：

1、需要建立连接    无连接

2、数据传输可靠    数据传输不可靠

3、字节流      数据表

4、数据量大且可靠的场景    数据量小可靠性要求低的场景

文件传输、邮件收发、点对点传输        视频流（直播、视频聊天）、广播、游戏画面

17、tcp三次握手

1、客户端向服务端发送 建立连接请求

2、服务端收到请求后响应，可以连接

3、客户端收到回复后，发送最终报文建立连接

18、tcp四次挥手

客户端和服务端都可以是主动方，另一方就是被动方

1、主动方发起断开连接的请求

2、被动方收到请求后，立即回复，准备断开连接

3、被动方准备好了后，再次发送报文，表示可以断开连接

4、主动方收到消息后，发送最终报文，完成断开

19、tcp沾包、原因、解决

tcp协议的传输方式是 字节流，没有消息边界

数据传输的过程中，收发数据的速度不一致

解决：人为控制，添加消息边界，分割消息，控制收发数据的速度

20、测试报告的内容

xxx公司

xxx产品测试报告

1、概述

        测试目的、项目背景

2、测试环境

        硬件环境、软件环境

3、测试人员

        参与此次测试的人员

4、实际进度

        排期表、实际到哪一个测试阶段，是否有时间风险

5、测试参考文档

        测试计划书、测试用例

6、测试结果的各种数据

        测试用例执行情况

        bug统计情况

        是否存在p1、p0级问题

        列出比较重要的或者严重等级高的未解决bug，@相关人员，跟进bug解决进度

7、项目总结

        测试是否通过，通过或者失败的依据

8、意见和建议

        对本次测试工作提出自己的意见或者建议