软件测试经典面试题总结讲解Word格式.docx
《软件测试经典面试题总结讲解Word格式.docx》由会员分享，可在线阅读，更多相关《软件测试经典面试题总结讲解Word格式.docx（18页珍藏版）》请在冰豆网上搜索。
对需求文档（产品需求文档、软件需求规格说明书等）进行分析需求分析及需求变更的维护工作；
根据需求文档，得出测试需求（功能测试需求、非功能性测试需求）；
根据测试需求设计测试方案，评审测试方案；
方案评审通过后，设计测试用例，再对测试用例进行评审；
6、单元测试的策略有哪些？
自顶向下的单元测试策略：
先对最顶层的单元进行测试，把顶层所调用的单元做成桩模块。
其次对第二层进行测试，使用上面已测试的模单元做驱动模块。
如此类推，直到测试完所有模块。
自底向上的单元测试策略：
先对模块调用层次图上最低层的模块进行单元测试，模拟调用该模块的模块做驱动模块。
然后再对上面一层做单元测试，用下面已被测试过的模块做桩模块。
一次类推，直到测试完所有模块。
孤立的测试策略：
不考虑每个模块与其他模块之间的关系，为每个模块设计桩模块和驱动模块，每个模块独立进行测试。
7、你所熟悉的软件测试类型都有哪些？
请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）？
容量测试
测试系统对不同级别数据容量下的工作能力，意在获取系统的最佳数据处理容量和最大处理容量。
稳定性测试
测试系统的长期稳定运行的能力。
同疲劳强度测试的区别是，稳定性测试的压力强度较小，一般趋向于客户现场日常状态下的压力强度，当然在时间不能保证稳定性的状态下，需要加大压力强度来测试，此时的压力强度则会高于正常值。
压力测试
通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大的服务级别的测试。
8、软件缺陷（或者叫Bug）记录都包含了哪些内容？
如何提交高质量的软件缺陷（Bug）记录？
1.bugID
2.bug类型
3.严重程度
4.bug标题
5.重现步骤
6.所属项目
7.所属产品模块
8.影响版本
9.当前指派人
10.当前状态人
11.提交人/提交日期
12.相关需求
1.认真做好前期的相关需求文档的分析工作
2.设计高质量的测试用例并执行
3.精炼语言，做到言简意赅。
9、Beta测试与Alpha测试有什么区别？
Betatesting（β测试）,测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。
开发者通常不在测试现场.
Alphatesting（α测试）,是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试.
10、什么是桩模块？
什么是驱动模块？
桩模块：
被测模块调用模块
驱动模块：
调用被测模块的模块
11、什么是扇入？
什么是扇出？
扇入：
被调用次数，扇出：
调其它模块数目
12、阐述工作版本的定义？
软件开发过程中，用于内部测试的功能和性能不完善的软件编译版。
工作版本既可以是系统的可操作版本，也可以是要在发布产品中演示的部分功能模块。
13、简述一下缺陷的生命周期？
提交->
确认->
分配->
修复->
验证->
关闭
14、你认为做好测试计划工作的关键是什么？
总的来说，测试计划由以下几个部分组成：
目标和范围，项目估算，风险计划，资源配置，进度安排
跟踪和控制机制
所以，计划工作的关键是做好以下几个任务：
1.认真执行需求文档审查和评审
2.明确测试需求和任务
3.分析测试范围和工作量
4.明确测试资源需求
5.合理安排测试进度
6.测试风险分析
7.制定有效的测试策略
测试计划工作的目的是什么？
测试计划工作的内容都包括什么？
其中哪些是最重要的？
也可以用上面的来回答
15、你认为做好测试用例工作的关键是什么？
需求和设计文档的理解程度，对系统的熟悉程度
16、你觉得软件测试通过的标准应该是什么样的？
缺陷密度值达到客户的要求
17、简述集成测试与系统测试关系？
（1）集成测试的主要依据概要设计说明书，系统测试的主要依据是需求设计说明书；
（2）集成测试是系统模块的测试，系统测试是对整个系统的测试，包括相关的软硬件平台、网络以及相关外设的测试。
18、一套完整的测试应该由哪些阶段组成？
需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估
19、集成测试也叫组装测试或者联合测试，请简述集成测试的主要内容？
集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。
集成测试应该考虑以下问题：
（1）在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
（2）一个模块的功能是否会对另一个模块的功能产生不利的影响；
（3）各个子功能组合起来，能否达到预期要求的父功能；
（4）全局数据结构是否有问题；
（5）单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
20、单元测试主要内容是什么？
1，模块接口测试。
单元测试的基础，只有在数据能正确流入，流出模块的前提下才有意义。
2，局部数据结构测试检查局部数据结构是为了保证临时存储在模块内的数据在程序执行中完整，正确。
重点是一些执行函数是否正确执行，内部是否运行正确。
局部数据结构往往是错误的根源，应仔细设计测试用例。
3，边界条件测试单元测试中最重要的一项任务。
因为软件经常在边界上失败，采用边界值分析，可能发现新的错误。
4，模块中所有独立路径的测试在模块中执行每一条独立执行路径进行测试，单元测试的基本任务保证模块中每条语句执行一次。
5，模块的各条错误处理通路测试：
程序在遇到异常情况时不应该退出，好的程序应能预见各种出错条件，并预设各种出错处理通路。
21、如何理解强度测试？
测试系统在高负载，高强度下的工作能力，意在获取系统在极限状态下运行时的各项性能指数，查看其是否在允许的范围内。
注：
1.疲劳强度测试是一类特殊的强度测试，主要测试系统长时间运行后的性能表现，例如7x24小时的压力测试。
2.
强度测试总是通常模拟系统在异常的资源配置下运行，如人为降低系统工作环境所需要的资源,如网络带宽,系统内存,数据锁等等,以测试系统在资源不足的情况下的工作状态
22、如何理解压力、负载、性能测试测试？
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行的测试，通常包含了负载测试，压力测试等。
b）负载测试
通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。
在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。
负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。
c）压力测试
压力测试是在强负载下的测试，查看应用系统在峰值使用情况下性能行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力，检测系统能提供的最大的服务级别的测试。
压力测试可以看成是强负载下的负载测试。
23、什么是系统瓶颈？
软件系统业务能力起限制，约束，使其不能满足用户特定业务需求的关键因素。
严格的技术角度上讲，所有的系统都会有瓶颈，因为大多数系统的资源配置是不协调的，如cup使用率刚好到达100%时，内存正好耗尽的系统。
但是不多见。
所以我们要从应用角度讨论：
关键是看系统能否满足用户需求。
在用户极限使用系统的情况下，系统的响应仍然正常，可以认为系统没有瓶颈或者瓶颈不影响用户工作。
测试系统瓶颈主要是实现下面两个目的：
--发现表面的瓶颈。
模拟用户的操作，找出用户极限使用系统时的瓶颈，然后解决瓶颈，这是性能测试的基本目标。
--发现潜在的瓶颈并解决，保证系统的长期稳定。
24、软件测试人员就是QA吗？
软件测试人员的职责是尽可能的找出软件缺陷，确保缺陷能被修复。
QA（质量保证人员）主要职责是创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。
测试人员的主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是保证人员的工作对象。
25、什么是软件测试，软件测试的目的？
软件测试就是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，其目的是尽快尽早地发现在软件产品中存在的各种问题—与用户需求、预先的定义不一致的地方。
26、写出bug报告流转的步骤，每步的责任人及主要完成的工作。
测试人员提交新的Bug入库，错误状态为New。
高级测试员/测试经理验证缺陷，如果缺陷已经提交，拒绝，标记为Declined-Duplicated，
如果确认未提交且是缺陷，分配给开发组。
设置状态为Open。
如果不是缺陷，则拒绝，设置为Declined状态。
开发经理分配bug至对应的模块开发人员。
开发人员查询状态为Open的缺陷，如果不可以重现则更新报告，反馈给开发经理。
可以重现则判断是否可以修复，是则修复并置状态为Fixed。
不能解决的Bug，要留下文字说明及保持Bug为Open状态。
对于不能解决和延期解决的缺陷，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。
测试人员查询状态为Fixed的缺陷，然后验证缺陷是否已解决，如解决，置缺陷的状态为Closed，如没有解决,置缺陷状态为Reopen。
查询状态为Declined-Duplicated的缺陷，进行关闭，置缺陷的状态为Closed。
27、画出软件测试的V模型图。
28、请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。
黑盒测试：
已知产品的功能设计规格，可以进行测试证明每个已经实现的功能是否符合需求。
白盒测试：
已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格的要求。
所有内部成分是否经过检查。
黑盒测试要在软件的接口处进行，这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部逻辑和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合太的功能说明。
因此黑盒测试又叫功能测试或者数据驱动测试。
白盒测试是对软件的过程性细节做仔细的检查，这种方法是把测试对象看做一个打开的盒子，太允许测试人员利用程序内部的逻辑结构和有关信息，设计或者选择测试用例，对程序所有逻辑路径进行测试。
通过不同点检查程序的状态，确定实际状态是否与预期的状态一致。
因此，白盒测试又叫逻辑驱动测试或者结构测试。
单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的，很明确的功能是否正确。
通常而言，一个单元测试用于判断某个特定条件下某个特定函数的行为，由程序员自己完成。
集成测试（组装测试，联合测试）是单元测试的逻辑扩展。
它的最简单形式：
两个已经测试过的单元组合成一个组件，并且测试他们之间的接口。
方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试，最后，将构成进程的所有模块一起测试。
系统测试：
将经过测试的子系统装配成一个完整的系统来测试。
目的是对最终软件系统进行全面的测试，确保
最终软件系统满足产品需求并且遵循系统设计。
验收测试：
目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试向用户表面系统能够像预定需求那样工作。
29、测试用例通常包括那些内容？
着重阐述编制测试用例的具体做法
标识符ID
测试项
测试需求
测试环境
测试前提
输入数据
操作步骤:
预期输出
实际输出
测试用例之间的关联
其他元素:
优先级
所在模块
测试时间
测试人
编制人
审评人
版本号
测试阶段
测试类型
30、集成测试通常都有那些策略？
自顶向下测试
自顶向下集成（Top-DownIntegration）方式是一个递增的组装软件结构的方法。
从主控模块（主程序）开始沿控制层向下移动，把模块一一组合起来。
分两种方法：
第一：
先深度：
按照结构，用一条主控制路径将所有模块组合起来；
第二：
先宽度：
逐层组合所有下属模块，在每一层水平地
步骤一：
用主控模块作为测试驱动程序，其直接下属模块用承接模块来代替；
步骤二：
根据所选择的集成测试法（先深度或先宽度），每次用实际模块代替下属的承接模块
步骤三：
在组合每个实际模块时都要进行测试；
步骤四：
完成一组测试后再用一个实际模块代替另一个承接模块；
步骤五：
可以进行回归测试（即重新再做所有的或者部分已做过的测试），以保证不引入新的错误。
自底向上测试
自底向上的集成（Bottom-UpIntegration）方式是最常使用的方法。
其他集成方法都或多或少地继承、吸收了这种集成方式的思想。
自底向上集成方式从程序模块结构中最底层的模块开始组装和测试。
因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）事前已经完成组装并经过测试，所以不再需要编制桩模块（一种能模拟真实模块，给待测模块提供调用接口或数据的测试用软件模块）。
自底向上集成测试的步骤大致如下：
按照概要设计规格说明，明确有哪些被测模块。
在熟悉被测模块性质的基础上对被测模块进行分层，在同一层次上的测试可以并行进行，然后排出测试活动的先后关系，制定测试进度计划。
，可以排出各活动之间的时间序列关系，处于同一层次的测试活动可以同时进行，而不会相互影响。
在步骤一的基础上，按时间线序关系，将软件单元集成为模块，并测试在集成过程中出现的问题。
这里，可能需要测试人员开发一些驱动模块来驱动集成活动中形成的被测模块。
对于比较大的模块，可以先将其中的某几个软件单元集成为子模块，然后再集成为一个较大的模块。
将各软件模块集成为子系统（或分系统）。
检测各自子系统是否能正常工作。
同样，可能需要测试人员开发少量的驱动模块来驱动被测子系统。
将各子系统集成为最终用户系统，测试是否存在各分系统能否在最终用户系统中正常工作。
方案点评：
自底向上的集成测试方案是工程实践中最常用的测试方法。
相关技术也较为成熟。
它的优点很明显：
管理方便、测试人员能较好地锁定软件故障所在位置。
但它对于某些开发模式不适用，如使用XP开发方法，它会要求测试人员在全部软件单元实现之前完成核心软件部件的集成测试。
尽管如此，自底向上的集成测试方法仍不失为一个可供参考的集成测试方案。
核心系统测试
核心系统先行集成测试法的思想是先对核心软件部件进行集成测试，在测试通过的基础上再按各外围软件部件的重要程度逐个集成到核心系统中。
每次加入一个外围软件部件都产生一个产品基线，直至最后形成稳定的软件产品。
核心系统先行集成测试法对应的集成过程是一个逐渐趋于闭合的螺旋形曲线，代表产品逐步定型的过程。
其步骤如下：
对核心系统中的每个模块进行单独的、充分的测试，必要时使用驱动模块和桩模块；
对于核心系统中的所有模块一次性集合到被测系统中，解决集成中出现的各类问题。
在核心系统规模相对较大的情况下，也可以按照自底向上的步骤，集成核心系统的各组成模块。
按照各外围软件部件的重要程度以及模块间的相互制约关系，拟定外围软件部件集成到核心系统中的顺序方案。
方案经评审以后，即可进行外围软件部件的集成。
在外围软件部件添加到核心系统以前，外围软件部件应先完成内部的模块级集成测试。
按顺序不断加入外围软件部件，排除外围软件部件集成中出现的问题，形成最终的用户系统。
该集成测试方法对于快速软件开发很有效果，适合较复杂系统的集成测试，能保证一些重要的功能和服务的实现。
缺点是采用此法的系统一般应能明确区分核心软件部件和外围软件部件，核心软件部件应具有较高的耦合度，外围软件部件内部也应具有较高的耦合度，但各外围软件部件之间应具有较低的耦合度。
高频集成测试
高频集成测试是指同步于软件开发过程，每隔一段时间对开发团队的现有代码进行一次集成测试。
如某些自动化集成测试工具能实现每日深夜对开发团队的现有代码进行一次集成测试，然后将测试结果发到各开发人员的电子邮箱中。
该集成测试方法频繁地将新代码加入到一个已经稳定的基线中，以免集成故障难以发现，同时控制可能出现的基线偏差。
使用高频集成测试需要具备一定的条件：
可以持续获得一个稳定的增量，并且该增量内部已被验证没有问题；
大部分有意义的功能增加可以在一个相对稳定的时间间隔（如每个工作日）内获得；
测试包和代码的开发工作必须是并行进行的，并且需要版本控制工具来保证始终维护的是测试脚本和代码的最新版本；
必须借助于使用自动化工具来完成。
高频集成一个显著的特点就是集成次数频繁，显然，人工的方法是不胜任的。
高频集成测试一般采用如下步骤来完成：
选择集成测试自动化工具。
如很多Java项目采用Junit+Ant方案来实现集成测试的自动化，也有一些商业集成测试工具可供选择。
设置版本控制工具，以确保集成测试自动化工具所获得的版本是最新版本。
如使用CVS进行版本控制。
测试人员和开发人员负责编写对应程序代码的测试脚本。
设置自动化集成测试工具，每隔一段时间对配置管理库的新添加的代码进行自动化的集成测试，并将测试报告汇报给开发人员和测试人员。
测试人员监督代码开发人员及时关闭不合格项。
按照步骤三至步骤五不断循环，直至形成最终软件产品。
该测试方案能在开发过程中及时发现代码错误，能直观地看到开发团队的有效工程进度。
在此方案中，开发维护源代码与开发维护软件测试包被赋予了同等的重要性，这对有效防止错误、及时纠正错误都很有帮助。
该方案的缺点在于测试包有时候可能不能暴露深层次的编码错误和图形界面错误。
以上我们介绍了几种常见的集成测试方案，一般来讲，在现代复杂软件项目集成测试过程中，通常采用核心系统先行集成测试和高频集成测试相结合的方式进行，自底向上的集成测试方案在采用传统瀑布式开发模式的软件项目集成过程中较为常见。
读者应该结合项目的实际工程环境及各测试方案适用的范围进行合理的选型。
31、阶段评审与项目评审有什么区别？
标记
阶段评审对项目各阶段评审：
对阶段成果和工作
项目评审对项目总体评审：
对工作和产品
32、测试产品与测试项目的区别是什么？
习惯上把开发完成进行商业化，几乎不进行代码修改就可以售给用户使用的软件称为软件产品。
把针对一个或几个特定的用户而开发的软件称为软件项目，软件项目是一种个性化的产品，可以是按照用户要求全部重新开发，也可以修改已有的软件产品来满足特定的用户需求。
区别：
1.质量不同，产品的质量要求高一些，修复发布后产品的缺陷成本较高，甚至带来很多负面的影响。
而项目通常面向某一个用户，虽然质量越高越好，但是一般只要满足用户要求就可以。
2.测试资源投入多少不同。
软件产品通常是研发中心来开发，进度压力要小些，同时由于质量要求高，因此会投入较多的人力，物力资源。
33、和用户共同测试（UAT测试）的注意点有哪些？
软件产品在投产前，通常都会进行用户验收测试。
如果用户验收测试没有通过，直接结果就是拿不报酬，间接影响是损害了公司的形象，而后者的影响往往更严重。
根据作者的经验，用户验收测试一定要让用户满意。
实际上用户现场测试更趋于是一种演示。
在不欺骗用户的前提下，我们向用户展示我们软件的优点，最后让“用户”满意并欣然支付酬劳才是我们的目标。
因此用户测试要注意下面的事项：
（1）用户现场测试不可能测试全部功能，因此要测试核心功能。
这需要提前做好准备，这些核心功能一定要预先经过测试，证明没有问题才可以和用户共同进行测试。
测试核心模块的目的是建立用户对软件的信心。
当然如果这些模块如果问题较多，不应该进行演示。
（2）如果某些模块确实有问题，我们可以演示其它重要的业务功能模块，必要时要向用户做成合理的解释。
争得时间后，及时修改缺陷来弥补。
（3）永远不能欺骗用户，蒙混过关。
道理很简单，因为软件是要给用户用的，问题早晚会暴露出来，除非你可以马上修改。
和用户进行测试还要注意各种交流技巧，争取不但短期利益得到了满足，还要为后面得合作打好基础。
34、您所熟悉的测试用例设计方法都有哪些？
请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
1．等价类划分
划分等价类:
等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:
测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:
有效等价类和无效等价类.
2．边界值分析法
边界值分析方法是对等价类划分方法的补充。
测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
3．错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法.
错误推测方法的基本思想:
列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例.例如,在单元测试时曾列出的许多在模块中常见的错误.以前
升级会员 