软件测试常见⾯试题合集（内附详细答案）
最近看到⽹上流传着各种⾯试经验及⾯试题，往往都是⼀⼤堆技术题⽬贴上去，但是没有答案。
为此我业余时间整理了这份软件测试基础常见的⾯试题及详细答案，望各路⼤⽜发现不对的地⽅不吝赐教，留⾔即可。
01 软件测试理论部分
1.1 测试概念
1. 请你分别介绍⼀下单元测试、集成测试、系统测试、验收测试、回归测试
单元测试：完成最⼩的软件设计单元（模块）的验证⼯作，⽬标是确保模块被正确的编码
集成测试：通过测试发现与模块接⼝有关的问题
系统测试：是基于系统整体需求说明书的⿊盒类测试，应覆盖系统所有联合的部件
回归测试：回归测试是指在发⽣修改之后重新测试先前的测试⽤例以保证修改的正确性
验收测试：这时相关的⽤户或独⽴测试⼈员根据测试计划和结果对系统进⾏测试和接收。验收测试包括Alpha测试和Beta测试。
Alpha测试：是由⽤户在开发者的场所来进⾏的，在⼀个受控的环境中进⾏。并且在开发者对⽤户的指导下进⾏测试，开发者负责记录发现的错误和使⽤中遇到的问题
Beta测试 ：由软件的最终⽤户在⼀个或多个⽤户场所来进⾏的，开发者通常不在现场。由⽤户记录在测试中遇到的⼀系列问题，并定期报给开发者。
2. 什么是⿊盒？什么是⽩盒？⿊盒和⽩盒的测试⽅法分别有哪些？
⿊盒:⿊盒测试也称功能测试或数据驱动测试。把程序看作⼀个不能打开的⿊盆⼦，在完全不考虑程序内部结构和内部特性的情况下，对程序接⼝进⾏测试。“⿊盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界⾯和软件功能进⾏测试
常⽤的⿊盒测试⽅法：等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。
⽩盒测试：也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进⾏⼯作的测试
常⽤⽩盒测试⽅法
软件测试app
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模型

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。