软件测试常见面试题合集（内附详细答案）

最近看到网上流传着各种面试经验及面试题，往往都是一大堆技术题目贴上去，但是没有答案。

为此我业余时间整理了这份软件测试基础常见的面试题及详细答案，望各路大牛发现不对的地方不吝赐教，留言即可。

01 软件测试理论部分

1.1 测试概念

1. 请你分别介绍一下单元测试、集成测试、系统测试、验收测试、回归测试

• 单元测试：完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确的编码
• 集成测试：通过测试发现与模块接口有关的问题
• 系统测试：是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件
• 回归测试：回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性
• 验收测试：这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。验收测试包括Alpha测试和Beta测试。
• Alpha测试：是由用户在开发者的场所来进行的，在一个受控的环境中进行。并且在开发者对用户的指导下进行测试，开发者负责记录发现的错误和使用中遇到的问题
• Beta测试 ：由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场。由用户记录在测试中遇到的一系列问题，并定期报给开发者。

2. 什么是黑盒？什么是白盒？黑盒和白盒的测试方法分别有哪些？

• 黑盒:黑盒测试也称功能测试或数据驱动测试。把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，对程序接口进行测试。“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试
• 常用的黑盒测试方法：等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。
• 白盒测试:也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试
• 常用白盒测试方法

1. 静态测试：不用运行程序的测试;
2. 动态测试：需要执行代码，通过运行程序找到问题;

• 逻辑覆盖包括:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖
• 1.语句覆盖每条语句至少执行一次。
• 2.判定覆盖每个判定的每个分支至少执行一次。
• 3.条件覆盖每个判定的每个条件应取到各种可能的值。
• 4.判定/条件覆盖同时满足判定覆盖条件覆盖。
• 5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
• 6.路径覆盖使程序中每一条可能的路径至少执行一次。

3. 测试流程：

需求测试->概要设计测试->详细设计测试->单元测试->集成测试->系统测试->验收测试

4. app测试性能指标

• 内存
• cpu
• 流量
• 启动速度

5. web测试和app测试不同点

系统架构方面：

• web项目，一般都是b/s架构，基于浏览器的
• app项目，则是c/s的，必须要有客户端，用户需要安装客户端。
• web测试只要更新了服务器端，客户端就会同步会更新。App项目 则需要客户端和服务器都更新。

性能方面:

• web页面主要会关注响应时间
• 而app则还需要关心流量、电量、CPU、GPU、Memory等。

兼容方面：

• web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统方面的兼容
• app测试则要看分辨率，屏幕尺寸，操作系统、网络。
• web测试是基于浏览器的所以不必考虑安装卸载。
• 而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景:包括安装时的中断、弱网、安装后删除安装文件 。

6. 缺陷按优先级分为哪些类型？ p1-p5 面试重点

• 缺陷必须立即解决
• 缺陷要求正常排队等待修复
• 缺陷可以在方便时被纠正
• 下一个版本修复
• 不修复

7. 测试用例的内容是什么？ 面试重点

• 用例编号
• 测试概述或用例标题
• 测试步骤
• 预期结果
• 输入数据
• 优先级
• 前置条件等

8. 测试结束的标准是什么？ 面试重点

• 全部测试用例都被执行完成
• 未修改bug都被确认或置为应有状态，暂缓修改的问题都有详尽的解析
• 测试报告编写完成
• 测试收尾工作结束
• 测试总结完成
• 项目处于试运行或上线阶段
• 在测试计划中定义结束的标准：在一定性能下平稳运行多少天、本版本没有严重bug，普通buh数量在多少个以下，bug修复百分之多少以上
• 实际测试达到上述要求，由项目、开发、测试经理共同签字，认同测试结束，版本即可发布。

1.2 软件开发模型

软件生命周期： 从软件最初构思到最终消亡(退役)的过程。

1. 软件生命周期
立项 ---需求分析 ---设计、编码、测试 ---发布 ---运行维护 ---淘汰
软件立项===》可行性研究 ===》需求分析 ===》概要设计 ===》详细设计 ===》编码实现 ===》单元测试 ===》集成测试 ===》系统测试 ===》验收测试 ==》运行维护

2. 瀑布模型

缺点：

1. 各阶段划分完全固定，阶段之间产生大量文档，极大增加工作量
2. 由于开发模型是线性的，用户只有等到整个过程的末期才能看到开发结果，增加开发风险
3. 不适应用户需求变化

3 . 快速原型模型(现在特别流行模式) Axure 软件

1. 原理：迅速搭建一个可以运行的软件原型，以便理解和澄清问题，使开发人员与用户达成共识，最后在确定需求基础上开发客户满意的软件产品
2. 特点：`适合预先不能确切定义需求的软件系统的开发`
3. 优点： ` 克服瀑布模型缺点，减少由于软件需求不明确带来的开发风险 `

4. 增量模型(最常用开发模型之一)

分批次地分析、设计、编码和测试这些增量组件。

5. 迭代模型 开发进度快

 

1. 原理
`强调开发的深入 ---优化过程
`开发迭代是一次完整地经过所有工作流程的过程：需求分析、设计、实施和测试工作流程
2. 优点
降低在一个增量上的开支风险
降低产品无法按照既定进度进入市场的风险
加快开发工作进度`
适应需求变化快的场景`

6. 螺旋模型

 

 

1. 原理：
兼顾了快速模型的迭代的特征以及瀑布模型的系统化与严格监控
2. 优点
最大特点：引入其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减少损失
适合大型昂贵的系统级的软件应用

1.3 软件测试模型

1. v模型

 

1. 原理：揭示开发过程和测试过程中各阶段的对应关系
2. 缺点与不足：
仅把测试过程作为需求分析、系统设计及编码之后的一个阶段，忽略了测试对需求分析、系统设计的验证
需求的满足情况一直到后期验收测试才被验证

2. w模型

1. 由两个 v 字模型组成，分别代表测试与开发过程，明确表示了测试与开发并行关系
2. 优点：
测试活动与软件开发同步进行
测试对象不仅是程序，包括需求与设计
尽早发现软件缺陷可降低软件开发成本
3. 局限性：无法支持迭代开发模型（没有循环过程）

3. h模型

 

1. 将测试活动完全独立出来，形成一个完全独立的流程
2. 只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了
3. 软件测试要尽早准备，尽早执行，不同测试活动可按某个次序先后进行，也可反复进行（迭代）

4. x模型

1. 针对单独的程序片段进行相互分离的编码和测试；
2. 定位了探索性测试，这是不进行事先计划的特殊类型的测试；

5. 软件测试生命周期

• 获取测试需求
• 编写测试计划
• 制定测试方案
• 开发与设计测试用例
• 执行测试
• 提交缺陷报告
• 测试分析与评审
• 提交测试总结
• 准备下一版本测试

6. 简述缺陷的生命周期？ 面试重点

• 软件测试人员提交缺陷报告；
• 测试负责人审核后将缺陷分配给相关开发人员修复
• 缺陷被修改后有测试人员根据缺陷报告中修改记录进行返测
• 返测通过的缺陷由负责人关闭；
• 返测未通过的缺陷直接返回给开发人员重新修改，然后再由测试人员返测，直到测试和开发达成一致处理意见。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

 

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取