软件测试经典面试题

利哥面试混迹于软件测试行业十几年了，在面试经验方面也是比较有经验，那么也整理过很多面试题，今天暴露给大家看看，学习学习！

测试面试题目：
1、 软件的定义：与计算机系统操作有关的计算机程序、规程、规则，以及可能有的文件、文档及数据。

2、 软件测试的定义：通过手工 或工具找出软件中存在的缺陷，保证软件的质量。

3、 黑盒测试：黑盒测试就是我们把要测试的软件当做一个没有打开的盒子，我们不需要了解盒子里边的内部构造以及逻辑，我们只需要依据软件的需求规格说明书，检查它的功能是否符合它的功能说明。

4、 白盒测试：白盒测试就是我们把要测试的软件当做一个打开的盒子，我们可以通过看这里边的内部逻辑和结构特性，选择或设计测试用例，通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。

5、 如何制定测试计划：

a) 认真做好测试资料的搜集整理工作；

b) 明确测试的目标，增强测试计划的实用性；

c) 坚持“5W”规则，明确内容与过程；

d) 采用评审和更新机制，保证测试计划满足实际需求

6、 黑、白（动态静态）盒测试区别：黑盒测试与白盒测试最大的区别应该就是测试对象不一样，白盒测试主要针对的是程序代码逻辑，黑盒测试主要针对的是程序所展现给用户的功能，简单的说就是前者测试后台程序后者测试前台展示功能。

7、 软件开发流程：计划 需求分析 设计 编码 测试 运行 维护 升级 废弃。

8、 软件测试流程：需求分析 编写测试方案 测试用例 执行测试用例 生成测试报告。

9、 测试阶段分为：单元测试、集成测试、系统测试、验收测试。

10、 单元测试的策略：逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析。

11、 单元测试包括：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试。

12、 冒烟测试：对软件基本功能进行确认验证的手段，并非对软件版本包的深入测试。冒烟测试也是针+ 对软件版本包进行详细测试之前的预测试，执行冒烟测试的主要目的是快速验证软件基本功能是否有缺陷。如果冒烟测试的测试例不能通过，则不必做进一步的测试。

13、 集成测试：（1）在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；（2）一个模块的功能是否会对另一个模块的功能产生不利的影响；（3）各个子功能组合起来，能否达到预期要求的父功能；（4）全局数据结构是否有问题；（5）单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。

14、 集成测试和系统测试区别：（1）集成测试的主要依据概要设计说明书，系统测试的主要依据是需求设计说明书；（2）集成测试是系统模块的测试，系统测试是对整个系统的测 试，包括相关的软硬件平台、网络以及相关外设的测试。

15、 回归测试：回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

16、 为什么要做回归测试：1,避免在回归测试中应各种操作误差所引起的测试结果异常。2.可以保持和原始测试一直性。3.可以提高测试效率。4.测试经理可以更好的掌握测试存在的问题

17、 Bug的生命周期：发现 提交 确认 分配 修改 验证 关闭。

18、 Bug的严重等级：①，一级 主流程无法跑通，系统无法运行、崩溃或者严重资源不足、应用无法启动或者异常退出，主要问题缺失、造成人身、财产安全问题。②，二级 影响系统功能或者操作、主要功能存在严重缺陷，次要功能丢失 但不会影响到系统稳定性 比如 计算错误。③，三级 界面、功能性缺陷、次要模块存在缺陷但不影响程序运行 比如 大数据下不容易响应。④，四级 建议性

19、 Bug的严重等级和优先级的区别：一般来说严重等级越高优先级越高，但是严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。例如公司名称写错，单词拼写错误

20、 bug单的内容：Bug单的内容：首先是bug单的标题，然后有一个模块路径（bug是在什么地方出现的），接着有一个如何发现（是怎么发现这个bug的），然后是指派人员（指派给相应的开发人员去解决），bug的严重等级，bug的优先级，前置条件（测试的前置条件），测试步骤（重现bug的测试步骤），实际结果（执行测试用例时的实际输出结果）附件（如果文字表达不清楚，过于冗长，可以上传视频或者截图等附件）。

21、 偶发的bug：判断是不是bug 提交到管理工具 ，严重问题 场景 步骤 反馈开发人员代码走查 反馈经理 尽量模拟

22、 禅道和bugfree的区别：一个公司的 bugfree免费，禅道比bugfree更强大 bugfree只是一个bug管理工具 禅道是项目管理工具 测试人员可以发布文档 测试用例 测试bug单。

23、 如何提高质量的bug记录？： 首先是提交的bug可重现，尽可能找到重现规律；然后是Bug描述简明准确，对于问题的描述，应该尽可能简明、准确；然后是一个bug记录只描述一条bug；最后是Bug的唯一性，在提交Bug report之前，要先确认这个Bug是否已经被其它人发现并报告。

24、 难以复现的BUG怎么处理：1、首先出现难以复现的bug一定要截图提交bug 2、首先评估bug的重要程度以及对整个项目的影响，如果影响小，就记录下来，继续跟踪3、如果对项目影响较大，范围较广，则要及时解决。尽量复现当时bug出现的场景：环境、数据等，跟组内其他的测试同事交流下，再多尝试几次（20次到30次）如果还是不能复现，就把这个问题反馈给开发，让开发进行代码走查，看能不能找到原因。如果开发这也不能发现，就把问题反馈给项目经理，请项目经理组织更多开发测试同事参与解决这个问题

25、 测试计划的包含内容：产品概述、测试策略、测试方法、测试内容、测试配置、测试周期、测试资源、风险分析，输出文档。

26、 编写好测试用例的依据：需求规格说明书，项目原型图。

27、 测试用例包括：编号 功能点 功能模块 测试步骤 输入数据 预期结果 实际结果。

28、 测试用例的流程：需求分析 得出测试需求；设计测试方案，评审测试方案；方案评审通过后，设计测试用例，再对测试用例进行评审。

29、 测试用例编写要求：

（1）测试用例本身的描述是否清晰，是否存在二义性；

（2）是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下；

（3）是否针对需求变更进行跟着，覆盖了所有的软件需求；

（4）是否尽可能多的覆盖了异常流程和异常测试点。

30、 如何保证测试用例的质量：测试用例是软件测试的准则，但它并不是编制完成后就直接成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。所以我们要进行用例的评审，评审时 责任人覆盖到了全部的测试点之外，针对关键功能或业务流程提出疑问和建议，以提高测试点的覆盖面和测试用例的质量，从而提升任务的完成质量。

31、 测试用例评审要求：

1.用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。

2.优先极安排是否合理。

3.是否覆盖测试需求上的所有功能点。

4. 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。

5. 是否已经删除了冗余的用例。

6.是否包含充分的负面测试用例。

7. 是否从用户层面来设计用户使用场景和使用流程的测试用例。

8. 是否简洁，复用性强。

32、 （黑盒测试的方法）编写测试用例的方法：等价类划分法 判定表（条件桩 条件项 动作桩 动作项） 边界值 因果图 错误推断法，场景法、正交实验法

33、 测试报告包含：测试背景 、测试范围、测试环境、测试方法、测试结果（用例执行、bug修复、bug遗留、功能覆盖率）、质量与风险评估。

34、 项目验收的标准？

a) 测试用例不通过的比例<3%;

b) 不存在错误等级为1，2,3的错误；

c) 错误等级为4的错误数量≤20；

d) 所有提交的错误已得到更正；

e