软件测试面试题总结文库.doc

《软件测试面试题总结文库.doc》由会员分享，可在线阅读，更多相关《软件测试面试题总结文库.doc（8页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、 软件测试面试题总结文库软件测试经典面试题(一) 1、为什么要在一个团队中开展软件测试工作? 参考答案： 由于没有经过测试的软件很难在公布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发觉软件中存在的问题，准时让开发人员得知并修改问题，在马上公布时，从测试报告中得出软件的质量状况。 2、您在以往的测试工作中都曾经详细从事过哪些工作?其中最擅长哪局部工作? 参考答案：(依据工程阅历不同，敏捷答复即可) 我曾经做过web测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。最擅长的是功能测试 3、您所

2、熟识的软件测试类型都有哪些?请试着分别比拟这些不同的测试类型的区分与联系(如功能测试、性能测试) 参考答案： 测试类型有：功能测试，性能测试，界面测试。 功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒 测试法进展动态测试时，需要测试软件产品的功能，不需测试软件产品的内部构造和处理过程。采纳黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推想、因果图和综合策略。 性能测试是通过自动化的测试工具模拟多种正常、峰值以及特别负载条件来对系统的各项性能指标进展测试。负载测试和压力测试都属于性能测试，两者可以结合进展。通过负载测试，确定在各种工作负载

3、下系统的性能，目标是测试当负载渐渐增加时，系统各项性能指标的变化状况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能供应的最大效劳级别的测试。 界面测试，界面是软件与用户交互的最直接的层，界面的好坏打算用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面犹如人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和胜利的感觉，相反由于界面设计的失败，让用户有挫败感，再有用强大的功能都可能在用户的畏惧与放弃中付诸东流。 区分在于，功能测试关注产品的全部功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主

4、要关注于产品整体的多用户并发下的稳定性和强健性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否标准(快捷键之类的)，是否美观(能否吸引用户的留意力)，是否安全(尽量在前台避开用户无意输入无效的数据，固然考虑到体验性，不能太粗鲁的弹出警告)?做某共性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试 4、您认为做好测试用例设计工作的关键是什么? 参考答案： 白盒测试用例设计的关键是以较少的用例掩盖尽可能多的内部程序规律结果 黑盒法用例设计的关键同样也是以较少的用例掩盖模块输出和输入接口。不行能做到完全测试，以最少的用例在合理的

5、时间内发觉最多的问题 软件测试经典面试题(二) 1、测试规划工作的目的是什么?测试规划工作的内容都包括什么?其中哪些是最重要的? 参考答案： 软件测试规划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试沟通、风险分析等内容。借助软件测试规划，参加测试的工程成员，尤其是测试治理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和掌握测试进度，应对测试过程中的各种变更。 测试规划和测试具体规格、测试用例之间是战略和战术的关系，测试规划主要从宏观上规划测试活动的范围、方法和资源配置，而测试具体规格、测试用例是完成测试任务的详

6、细战术。所以其中最重要的是测试测试策略和测试方法(最好是能先评审) 2、您所熟识的测试用例设计方法都有哪些?请分别以详细的例子来说明这些方法在测试用例设计工作中的应用。 参考答案： 01 .等价类划分 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的状况:有效等价类和无效等价类. 02.边界值分析法 边界值分析方法是

7、对等价类划分方法的补充。测试工作阅历告知我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界状况设计测试用例,可以查出更多的错误. 使用边界值分析方法设计测试用例,首先应确定边界状况.通常输入和输出等价类的边界,就是应着重测试的边界状况.应中选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据. 03.错误推想法 基于阅历和直觉推想程序中全部可能存在的各种错误, 从而有针对性的设计测试用例的方法. 错误推想方法的根本思想: 列举出程序中全部可能有的错误和简单发生错误的特别状况,依据他们选择测试用例. 例如

8、, 在单元测试时曾列出的很多在模块中常见的错误. 以前产品测试中曾经发觉的错误等, 这些就是阅历的总结. 还有, 输入数据和输出数据为0的状况. 输入表格为空格或输入表格只有一行. 这些都是简单发生错误的状况. 可选择这些状况下的例子作为测试用例. 04.因果图方法 前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的状况. 但要检查输入条件的组合不是一件简单的事情,即使把全部输入条件划分成等价类,他们之间的组合状况也相当多. 因此必需考虑采纳一种适合于描述对于多种条件的组合,相应产生多个动作

9、的形式来考虑设计测试用例. 这就需要利用因果图(规律模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合状况. 软件测试经典面试题(三) 1、你以前工作时的测试流程是什么? 参考答案：(敏捷答复) 公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正(自己总结，吸取同行的方法)后的流程吧。需求评审(有开发人员，产品经理，测试人员，工程经理)-需求确定(出一份确定的需求文档)-开发设计文档(开发人员在开头写代码前就能输出设计文档)-想好测试策略，写出测试用例-发给开发人员和测试经理看看(非正式的评审用例)-接到测试版本-执行测试用例

10、(中间可能会补充用例)-提交bug(有些bug需要开发人员确实定(严峻级别的，或突然发觉的在测试用例范围之外的，难以重现的)，有些可以直接录制进TD)-开发人员修改(可以在测试过程中快速的修改)-回归测试(可能又会发觉新问题，再按流程开头跑)。 2、当开发人员说不是BUG时，你如何应付? 参考答案： 开发人员说不是bug，有2种状况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进展确认，需不需要改动，3方商议确定好后再看要不要改。二是这种状况不行能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么?假如被用户发觉或出了问题，会有什么不良结果?程序员可能会给

11、你许多理由，你可以对他的解释进展反对。假如还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进展确认,假如要修改就改,假如不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，假如开发人员不修改也没有大问题。假如确定是bug的话，肯定要坚持自己的立场，让问题得到最终确实认。 3、软件的构造号与版本号之间的区分?BVT(BuildVerificationTest) 参考答案：版本掌握命名格式: 主版本号.子版本号.修正版本号.编译版本号 Major.Minor .Revision.Build 应依据下面的商定使用这些局部： Major ：具有一样名称但不同主版本号的程序集不

12、行互换。例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。 Minor ：假如两个程序集的名称和主版本号一样，而次版本号不同，这指示显著增加，但照看到了向后兼容性。例如，这适用于产品的修正版或完全向后兼容的新版本。 Build ：内部版本号的不同表示对一样源所作的重新编译。这适合于更改处理器、平台或编译器的状况。 Revision ：名称、主版本号和次版本号都一样但修订号不同的程序集应是完全可互换的。这适用于修复以前公布的程序集中的安全漏洞。 BVT(BuildVerificationTest)： 作为Build的一局部，主要是通过对根本功能、特殊是关键功能的测试，保证新增代码没

13、有导致功能失效，保证版本的持续稳定。实现BVT方式是有以下几种：1、测试人员手工验证关键功能实现的正确性。特点：这是传统开发方法中，通常采纳的方式。无需维护测试脚本的本钱，在测试人力资源充分，测试人员熟识业务、并对系统操作娴熟状况下效率很高，比拟敏捷快速。缺点：人力本钱较高;对测试人员力量有肯定要求;测试人员面对重复的工作，简单产生疲乏懈怠，从而影响测试质量。2、借助基于GUI的自动化功能测试工具来完成，将各根本功能操作录制成测试脚本，每次回放测试脚本验证功能实现的正确性。特点：能够模拟用户操作完成自动的测试，从UI入口到业务实现，每一层的代码实现都经过验证;节省人力本钱;降低测试人员重复劳动的工作量，机器不会疲乏;缺点：对于UI变动比拟频繁的系统来说，这种方式的维护本钱很高，实施起来特别困难。另外，在工程周期较短且后续无连续性或继承的状况下，也不推举使用此方式。3、由开发人员通过自动化测试工具完成业务层的BVT测试。特点：通过对业务层关键功能的持续集成测试，保证系统功能的持续稳定。可以结合DailyBuild，做为Build的一局部，自动实现并输入BVT报告。缺点：仅对业务规章实现的正确性进展了测试，对表现层无法测试到，对于诸如：前台页面控件各种大事响应、页面元素变化等方面的问题无法保证。