软件测试面试常用问答.docx
《软件测试面试常用问答.docx》由会员分享，可在线阅读，更多相关《软件测试面试常用问答.docx（25页珍藏版）》请在冰点文库上搜索。
软件测试面试常用问答
1.软件测试流程
公司把测试分成五个阶段：
计划、设计、执行、评估、验收
在计划阶段呢，我们主要编写测试计划、对进度的安排、人力物力的分配、总体测试策略的制定以及风险的评估和规避措施都要在计划中体现。
一般测试计划由经理编写。
我也参与过计划的评审工作!
然后就是测试设计，我们主要输出的是测试用例，我们会参考开发人员的需求分析、详细设计、概要设计等文档，如果有需求不明确的地方，我们会及时和开发人员进行沟通。
用例写完之后会进行评审。
用例编写结束之后，会进入到测试执行阶段，发现问题要提交缺陷报告，具体系统测试的轮次，根据开发质量和系统的复杂程度来决定。
执行结束之后进入评审阶段，出测试总结报告，对整个测试过程做一个总结，对当前版本质量做一个评估。
最后是验收阶段，我们会出用户手册，操作指引。
每个阶段都会有严格的评审，以保障输出的有效性。
2.软件测试的目的
一般来说呢，软件测试主要是为了检验出软件中存在的错误，保障软件的质量。
不过从用户和开发者的不同角度，可以分为两个方面：
从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。
从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确的实现了用户的需求，确立人们对软件质量的信心。
（测试的目的是以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件的质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险，）
3.软件测试的概念
软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能的测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估，执行测试用例后需要跟踪故障，以确保开发的产品适合需求。
4.软件测试的对象
软件测试应该贯穿于软件定义与开发的整个期间，并且软件开发整个期间各个阶段所得到的文档，都应成为软件测试的对象。
5.软件测试人员的职责
1.编写测试用例
2.搭建测试环境
3.执行测试并提出问题单
4.模块测试总结
6.B/S和C/S的区别
B/S架构软件：
指浏览器/服务器端软件，如XX、新浪等网站
C/S架构软件：
指客户端/服务器端软件，如腾讯QQ、魔兽世界
7.测试工作的基本原则
1.所有的软件测试都应追溯到用户需求
2.应当把“尽早的和不断地进行软件测试”作为测试者的座右铭
3.完全测试是不可能的，测试需要终止
4.测试无法显示软件潜在的缺陷
5.充分注意测试中的群集现象
6.程序员应该避免检查自己的程序
7.尽量避免测试的随意性
8.什么是UML
UML（UnifiedModelingLanguage）“统一建模语言”
这是一种用于描述，构建软件系统以及商业建模的语言，简单理解就是它以图形的方式直观的表示出一个系统的各项内容
9.常用的开发模型有哪几种各有什么特点
1.瀑布模型
2.快速原型模型
3.增量模型
4.螺旋模型
瀑布模型：
1.阶段间具有顺序性和依赖性
2.推迟实现的观点
快速原型模型：
开发人员应尽可能快的建造出原型系统，以加速软件开发的过程，节约软件开发成本，原型的用途是获知用户的真正需求，一旦需求确定了，原型将被抛弃。
增量模型：
1.能在较短时间内向用户提交可完成部分工作的产品
2.逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。
螺旋模型：
1.对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重用目标
2.减少了过多测试或测试不足所带来的风险
3.在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本职区别。
10.什么是CMM
CMM=性能完善模型（CapabilityMaturityModel），它是一个分5级的。
可以描述结构完善程度的模型，用它来说明所交付的软件的效能。
11.为什么软件会有毛病
1.交流错误或者没有进行交流
2.软件的复杂性
3.编程错误
4.需求改变
5.时间压力
6.代码的文档质量差
7.软件开发工具的自身引入故障
12.简述V模型和W模型
V模型：
它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系
1.每个开发活动都有相应的测试活动对应
2.软件开发过程是一个自顶向下，逐步细化的过程
3.测试过程是依相反顺序安排的自底向上，逐步集成的过程
W模型：
W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。
测试与开发是同步进行的，从而有利于尽早地发现问题。
13.软件测试按阶段划分为哪几个
1.单元测试（白盒测试，测代码）
2.集成测试（介于白盒和黑盒之间，就是测模块与模块之间的接口）
3.系统测试（黑盒测试，测功能）
4.验收测试（分α和β测试，主要是客户验收软件产品的一个过程）
14.α和β测试的区别
1.人员的区别α测试是单个用户，β测试是多个用户
2.环境的区别α测试是模拟线网真实环境，β测试是在实际环境。
α测试：
在系统开发接近完成时对系统的测试，测试后仍然会有少量的设计变更，这种测试一般由程序或测试员完成，不能由最终用户或其他人员完成
β测试：
当开发和测试已基本完成，需要在正式发行之前最后寻找毛病而进行的测试。
通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。
15.黑盒测试和白盒测试的区别
黑盒测试:
不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。
即黑盒测试主要是测功能，又称为结构测试或数据驱动测试。
白盒测试：
利用程序内部的逻辑结构及有关信息，对程序所有逻辑路径进行测试。
即白盒测试主要是测代码，又称为结构测试或逻辑驱动测试。
16.测试什么时候结束，有什么标准
什么时候结束测试：
1.市场压力
2.质量目标
3.客户要求
4.费用约束
5.错误发现率
结束的标准：
1.用例全部执行
2.覆盖率达到标准
3.缺陷率达到标准
4.其他指标达到标准
17.问题太多无法测试你会怎么办
我首先会仔细研究报告，看错误或阻塞型的问题最初出现的地方，并把注意力放在最严重的错误上，寻找问题的根本，试着解决问题，如果不能，就通知管理人员处理，并向他们提供一些证明文件。
18.时间不够不能全部测试你会怎么办
我首先会试着与客户协商，看能否延期发布产品上线时间，如果不能，那么我会再看看能否向上面申请增加人手，如果也不行，那么我会使用风险分析，确定测试的重点，先挑重要的，优先级高的测试。
使用风险分析，确定测试的重点。
由于很少有机会对一个应用软件进行所有可能的测试（包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西），对大多数软件开发项目来说，利用风险分析是适当的。
这需要判断技能、常识、感觉和经验。
如果有正当理由，也可采用正式的方法。
需要考虑下列因素：
1）对于该项目的用途而言，哪种功能最重要?
2）哪种功能对用户最明显?
3）哪种功能对安全影响最大?
4）哪种功能对用户最有用?
5）对客户来说，该应用软件的哪个部分最重要?
6）在开发过程中，该应用软件的哪个部分可以最先测试?
7）哪一部分代码最复杂，容易导致出现错误?
8）哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?
9）哪一部分程序与过去项目中引起问题的部分相类似/有关?
10）哪一部分程序与过去项目中需要大量维护的部分相类似/有关?
11）需求和设计的那些部分不清楚或不容易读?
12）开发人员认为在应用软件中哪些部分是高风险的?
13）哪些问题能造成最差的发行?
14）哪些问题最能引起用户抱怨?
15）哪些测试可以容易地覆盖多种功能?
16）哪些测试在覆盖高风险部分的测试时使用时间最少?
19.开发与测试的关系
1.开发和测试是一个有机的整体，测试依托于开发，测试也能指导开发
2.开发和测试是不可分割的
在产品发布之前，开发和测试是循环进行的，编写测试文档要参考开发文档，测出的缺陷要经开发人员修改后继续测试，两者相辅相成。
20.好的测试人员应该具备的素质
沟通能力，移情能力，技术能力，自信心，外交能力，幽默感，很强的记忆力，耐心，怀疑精神，自我督促，洞察力
21.测试人员需要参加需求分析吗？
需要，越早介入需求分析越好。
因为测试人员对需求理解越深刻，对测试工作的开展越有利。
而且可以尽早的确定测试思路，减少与开发人员的交互，需求理解上的偏差。
22.测试用例的组成
测试用例由用例编号、所属模块、预置条件、输入的数据、详细的操作步骤、预期结果等组成，实际结果和通过与否会在以后标示。
我们还会对用例的优先级别做一个评定。
23.测试用例在实际工作中如何编写
在工作中，我们会参考开发人员编写的需求分析，详细设计，概要设计等文档编写测试用例，如果有需求不明确的地方，及时和产品需求沟通。
在实际工作中，我们还经常会用到等价类、边界值、因果图等黑盒测试方法来设计测试用例。
24.测试用例优先级别的评定标准，为什么要有有限级别
评定标准：
我们会根据用例的重要性把它分为高、中、低三个级别
对于主要功能点的正常流程，也就是软件常用到的功能，我们会定位高级
对于用的较少的功能点或者是主要功能的异常输入，我们一般定为中级
对于特殊情况，如断电、断网等罕见发生的，我们定为低级
为什么要有优先级别：
因为测试执行的时候，我们对用例的执行也有侧重点，随着测试的深入，我们会把重点放在优先级别高的用例，如果时间不够，我们也会挑出级别高的用例进行测试，这样编写时标出优先级别会为后期工作提供便利。
25.什么样的用例是高质量用例
1.覆盖率保障所有的功能点都被覆盖到
2.表述清晰方便执行人员具体操作
3.需求阶段要深入了解，用例写的深入，能发现深层次问题
26.如何编写高质量的测试用例
1.尽早介入需求，在设计阶段深入了解需求
2.公司有严格的评审阶段来保障用例输出的有效性
3.在实际执行过程中，根据项目具体情况修改完善用例
27.什么是评审它有什么意义
评审就是当我们编写完一份测试用例之后，需要通过审核确定此用例是否完整，是否能够实施。
我们可以让同事帮忙检查，指出不足的地方，逐步完善，之后再发起一个评审会，可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加，需获得通过才可以使用。
评审的意义是为了保障每一步的输出都是有效的。
28.什么是回归测试
回归测试也称为回归问题单，当我们接到新的版本时，搭建好测试环境后，首先我们会验证上一次我们提交的bug单是否已经修改，这个验证的过程就叫做回归测试。
29.什么是冒烟测试有什么意义
当我们接到版本，在进行系统测试之前，先挑出一些级别高的用例测试，检测各功能点的主流程是否正常进行，这个过程称之为冒烟测试。
冒烟测试的意义是为了确保当前拿到的版本的可测性，以避免无效用工。
30.常用的黑盒测试方法有哪些
等价类、边界值、因果图、错误推测法、判定表、功能图、场景法
31.有效等价类和无效等价类有什么区别
等价类分有效等价类和无效等价类
有效等价类指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合
无效等价类是指对程序的规格说明是不合理的或无意义的输入数据所构成的集合
它们的主要区别是看它们的输入是否满足需求
32.软件的生命周期
软件的生命周期主要由软件定义、软件开发、运行维护三个周期。
33.软件的质量因素有哪些
正确性与精准性、容错性与可靠性、性能与效率、易用性、可理解性与简洁性、可复用性与可扩展性
34.什么是需求变更它给软件开发带来了什么问题如何克服
需求变更就是指客户不满意最初的需求，要求增加新功能或改变原来的功能。
需求变更会导致重新设计、重定工程进度表、影响其他项目，已经完成的工作需要重新做甚至放弃，对硬件需求的影响等等。
有时候许多小的改变或者一个大的改变，在项目各部分中出现的各项已知或未知的相关问题，可能相互影响并导致出现问题。
克服方法：
可靠的需求，合理的时间表，适当的测试，尽可能的坚持最初的需求，沟通
35.如果需求一直在变怎么办
1.如果可能，尽早的与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早的改变测试计划和策略
2.如果在对程序进行初始设计时多考虑一些适应性，那么在以后发生需求的改变时，就不需要再为改变做很多事情了
3.好的代码注释和好的文档有助于开发人员作出相应的改变
4.在项目的时间表中应当留出余量，以应付可能出现的变更
5.尽量把新的需求纳入软件的下一版本，而把原始需求作为第一版
6.可以会议讨论，把易于实现的新的变更列入项目，把难以实现的新需求列入后续版本
7.要确保让客户和管理人员了解变更对进度表的影响所带来的风险、以及因变更所引起的大量资金消耗
8.在对应软件进行自动测试时，要把注意力集中在看来不大会改变的部分
9.对变更进行适当的风险分析，以减少回归测试的要求
10.少注意详细的测试计划和测试方案，要把重点放在专门的测试上。
36.白盒测试有哪几种方法
白盒测试:
测试证明每种内部操作和过程是否符合设计规格和要求,基于程序结构的逻辑驱动测试.
总体上分为静态方法和动态方法两大类
静态：
关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。
静态举例：
代码走读，代码检视。
动态：
语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
37.集成测试的策略
1.在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失
2.各个子功能组合起来，能否达到预期要求的父功能
3.一个模块的功能是否会对另一个模块的功能产生不利的影响
4.全局数据结构是否有问题
5.单个模块的误差积累起来，是否会放大，从而达到不可接受的程度
38.系统测试的策略
功能测试，性能测试，可靠性测试，负载测试，易用性测试，强度测试，安全测试，配置测试，安装测试，卸载测试，文挡测试，故障恢复测试，界面测试，容量测试，兼容性测试，分布测试，可用性测试
39.测试计划的目的是什么
软件测试计划是指导测试过程的纲领性文件，可以明确测试任务和测试方法，保证测试活动的顺利进行，跟踪和控制测试进度，以便应对测试过程中的各种变更。
40.测试计划包括哪些内容什么是重点
测试计划主要包括测试目标、背景、范围、参考文档、提交文档、进度安排、资源分配、测试总策略的制定、风险的评估和规避措施。
重点为：
进度安排、资源分配、测试总策略的制定、风险的评估和规避措施。
41.制定测试计划之前要做哪些准备工作
1.软件测试计划的目的是什么？
是否所有人都知道？
他们同意这个测试计划过程吗？
2.测试的是什么产品？
是新程序还是维护升级的？
是独立程序还是由多个小程序组成的？
3.产品的质量目标是什么？
产品的功能需求和性能指标必须得到所有人的一致认可。
42.怎样做好测试计划
1.理解系统。
从整个系统的高度了解被测系统必须满足的功能和非功能性需求。
利用涉及整个系统的文档，形成对系统的整体了解。
2.及早介入。
为了深入了解项目，测试人员应该在系统的开始阶段介入，可以增加对客户需求，客户问题，潜在风险，以及最重要的功能方面的理解
3.测试期望。
程序员的期望是什么？
客户的期望是什么？
销售对测试的期望又是什么？
测试目标必须是绝对的，以免说不清楚是否达到目标。
4.吸取教训。
把以前工作中学习到的经验教训运用过来，对确定测试策略很有作用。
5.工作量大小。
完成测试需要多少工作量？
需要多少人员？
6.技术选择。
系统会采取什么技术？
系统会采用什么架构？
这些信息有助于确定测试策略和测试工具。
7.时间表。
系统开发和测试分配的时间有多长？
截止日期是什么时候？
做好测试计划的关键：
1.明确测试目标，增强测试计划的实用性
2.坚持“5W”规则，明确内容与过程
3.采用评审和更新机制，保证测试计划满足实际需求
4.分别创建测试计划和测试详细规格、测试用例
（5W+1H规则：
就是对工作进行科学的分析，对某一工作在调查研究的基础上，就其工作内容（What）、责任者（Who）、工作岗位（Where）、工作时间（When）、怎样操作（How）以及为何这样做（Why），即"5W"、"1H"进行书面描述，并按此描述进行操作，达到完成职务任务的目标。
）
43.在实际测试过程中你会遇到什么问题如何解决
1.市场的压力
2.测试时间不够
3.测试资源的及时到位
4.测试人员的技能需求
5.开发进度的变化
6.开发部门的版本控制
7.需求的变更
8.短时间上线。
这个是已经定好的，没有参考测试人员的意见。
时间短往往不能得到充分的测试，测试策略必须根据可用的时间进行调整。
尽快指出这样的问题非常重要，只有这样才能调整时间表，确定快速开发的风险并制定降低风险的策略。
9.新的设计过程。
引入新的设计过程会增加风险，新的设计过程包括新的工具和设计技术。
如果采用新的技术，能否像我们预期的那样运转，都存在很大的风险
10.程序的复杂性。
我们应该进行一些分析工作来确定哪个功能最复杂，哪个功能最容易出错，错误会对系统的哪些地方造成重大的影响。
11.使用频率。
软件最常用功能中隐藏的问题可能给用户造成严重的损失。
12.不可测试的需求。
不可测试的需求会对系统的成功造成巨大的威胁。
如果测试组在需求阶段就验证了需求的可测试性，对
44.测试资源
计划资源需求是确定测试策略必备条件的过程。
在软件测试之前，要制定一个项目资源计划，包含每一个阶段的任务，所需要的资源，当发生类似到了使用期限或资源共享的事情时，要更新这个计划，在计划中，项目期间可能用到的任何资源都要考虑到，例如：
1.人员：
人数，经验和专长，全职还是兼职。
2.设备：
计算机，测试硬件，测试工具。
3.软件：
应用程序，数据库程序和自定义工具。
4.其它供应：
软盘，电话，参考书，培训资料。
45.缺陷等级划分
按严重级别划分:
严重：
系统崩溃数据丢失
较严重：
功能遗漏功能没有实现
一般：
小问题输入限制错别字布局错误
建议：
不影响使用的问题、易用性
按优先等级划分：
最高：
应该立即修复的问题
次高：
产品发布之前必须修复的问题
一般：
如果时间允许应该修复的问题
建议：
可以再发布版本中存在的问题
46.bug管理流程
测试人员提交新的Bug入库，错误状态为New。
，分配给相应的开发人员，设置状态为Open。
如果不是错误，则拒绝，设置为Declined（拒绝）状态。
开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。
不能解决的Bug，要留下文字说明及保持Bug为Open状态。
对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。
测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。
47.当你提交的bug开发人员说不是bug怎么办
1.首先，要明确软件缺陷的标准原则和客户需求，检查自己提交的报告是否存在不足，保证可以说服自己
2.礼貌的与开发人员交流，对bug的表述要清晰，从多个角度来说明提的是bug的原因，并拿出数据、截图、报错日志等相关证明文件，以理服人。
3.如果不能达成共识，找相关的项目经理讨论这个问题，由项目经理和研发讨论，如果还不行，问题反馈给项目经理由他们商讨。
48.开发人员修改问题后引发新的问题我们怎么办
重新执行测试，并关注相关功能点，如果可能的话增加新用例
49.缺陷报告的组成
软件测试的名称、版本号、提交bug人员、缺陷描述、测试环境、bug状态、严重等级、优先等级、详细的操作步骤及数据、操作预期结果、操作实际结果、必要附图
50.状态为已修改的bug，实际没有修改怎么办
加强项目于质量管理，提高项目执行能力
如果测试发现这样的问题，首先要弄清楚是什么原因导致这种情况，最终还是要督促开发人员，修改掉这些问题。
如果是不能重现的问题或是老版本遗留的问题不能修改的，要做好标示。
51.作为测试人员发现bug时要做什么
因为bug未必一定会重现，所以我们需要做的是
1.报错页面的截图
2.错误日志的备份
52.如何安排时间进度表
首先我们要明确三个时间点：
项目起始时间、项目截止时间、开发提测时间
然后根据以往的经验把整个时间段划分为测试的五个阶段。
一般来说，设计阶段和执行测试阶段会花费较多的时间。
在实际工作中会根据实际项目进展对计划作出适当的调整。
53.如何与开发人员沟通
测试与开发密不可分，我们有共同的目的就是让产品能顺利的交付，在实际工作中，我们会有很多地方和开发人员接触和沟通，尽量做到面对面的沟通，如果只能书面沟通，那么必须对产品特性的理解深刻以及表达清晰。
沟通首先要真诚，然后就是团队精神，最后是在专业上有共同语言。
54.给你一个网站，你应该如何测试
首先，查找需求说明、网站设计等相关文档，分析测试需求。
制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：
功能性测试、界面测试、性能测试、数据库测试、安全性测试、兼容性测试
设计测试用例：
功能性测试可以包括，但不限于以下几个方面：
链接测试。
链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回等。
提交功能的测试。
多媒体元素是否可以正确加载和显示。
多语言支持是否能够正确显示选择的语言等。
界面测试可以包括但不限于一下几个方面：
页面是否风格统一，美观
页面布局是否合理，重点内容和热点内容是否突出
控件是否正常使用
对于必须但为安装的空间，是否提供自动下载并安装的功能
文字检查
性能测试一般从以下两个方面考虑：
压力测试、负载测试、强度测试、数据库测试要具体决定是否需要开展。
数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。
安全性测试：
基本的登录功能的检查
是否存在溢出错误，导致系统崩溃或者权限泄露
相关开发语言的常见安全性问题检查，例如SQL注入等。
如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持
兼容性测试，根据需求说明的内容，确定支持的平台组合：
浏览器的兼容性、操作系统的兼容性、软件平台的兼容性、数据库的兼容性
开展测试，并记录缺陷。
合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。
定期评审，对测试进行评估和总结，调整测试的内容。
55.测试在什么时候进行
如果条件允许，原则上来说是从需求阶段就开始我们的测试工作，越早介入需求分析越好。
因为测试人员对需求理解越深刻，对测试工作的展开越有利，可以尽早的确定测试思路，减少与开发人员的交互，减少对需求理解上的偏差
56.怎么样保证你负责的模块通过了测试
首先是了解用户的需求，设计好的测试用例，严格进行用例的评审，认真的执行测试用例，对自己提交的bug进行详细的描述
反复测试增强测试的准确性，通过冒烟回归
升级会员 