软件测试面试题.docx_第1页
软件测试面试题.docx_第2页
软件测试面试题.docx_第3页
软件测试面试题.docx_第4页
软件测试面试题.docx_第5页
已阅读5页,还剩5页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

面试题1.测试用例通常包括那些内容?着重阐述编制测试用例的具体做法不同结构的用例包括的不一样。(版本、编号、项目、设计人员、设计日期、输入、预期输出)软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。用例编号: 测试用例的编号有一定的规则,比如系统测试用例的编号这样定义规则:PROJECT1-ST-001,命名规则是项目名称测试阶段类型(系统测试阶段)编号。定义测试用例编号,便于查找测试用例,便于测试用例的跟踪。测试标题: 对测试用例的描述,测试用例标题应该清楚表达测试用例的用途。比如“测试用户登录时输入错误密码时,软件的响应情况” .重要级别: 定义测试用例的优先级别,可以笼统的分为“高”和“低”两个级别。一般来说,如果软件需求的优先级为“高”,那么针对该需求的测试用例优先级也为“高”;反之亦然,测试输入: 提供测试执行中的各种输入条件。根据需求中的输入条件,确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性,如果软件需求中没有很好的定义需求的输入,那么测试用例设计中会遇到很大的障碍。操作步骤: 提供测试执行过程的步骤。对于复杂的测试用例,测试用例的输入需要分为几个步骤完成,这部分内容在操作步骤中详细列出。预期结果: 提供测试执行的预期结果,预期结果应该根据软件需求中的输出得出。如果在实际测试过程中,得到的实际测试结果与预期结果不符,那么测试不通过;反之则测试通过。2.描述使用bugzilla缺陷管理工具对软件缺陷(BUG)跟踪的管理的流程 1)首先由QA/TESTER 发现bug后,填写bug 报告,bug 的状态设为NEW,提交给管理人员; 2)管理人员会assigned 给对应模块的开发人员,bug 的状态为Assigned; 3)开发人员修复bug,并把bug的处理意见设置为fixed/invalid/wonfix/later/remind/duplicate/worksforme,系统会自动发邮件给bug的reporter人; 4)申报者接到处理意见后,验证该bug是否被修复,若被修复设置bug的状态为 verified,若问题仍然存在则设置为reopened ,若是其他意见设置为resolved。 5)当bug 被verified ,可以由管理人员关闭该bug。3.如果时间不够,无法进行充分的测试怎么办?使用风险分析,确定测试的重点。由于很少有机会对一个应用软件进行所有可能的测试(包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西),对大多数软件开发项目来说,利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由,也可采用正式的方法。需要考虑下列因素:1)对于该项目的用途而言,哪种功能最重要?j2)哪种功能对用户最明显?3)哪种功能对安全影响最大?4)哪种功能对用户最有用?5)对客户来说,该应用软件的哪个部分最重要?6)在开发过程中,该应用软件的哪个部分可以最先测试?7)哪一部分代码最复杂,容易导致出现错误?8)哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?9)哪一部分程序与过去项目中引起问题的部分相类似/有关?10)哪一部分程序与过去项目中需要大量维护的部分相类似/有关?11)需求和设计的那些部分不清楚或不容易读?12)开发人员认为在应用软件中哪些部分是高风险的?13)哪些问题能造成最差的发行?14)哪些问题最能引起用户抱怨?15)哪些测试可以容易地覆盖多种功能?16)哪些测试在覆盖高风险部分的测试时使用时间最少?4. 如果需求一直在变化怎么办?1)如果可能,尽早与承担该项目风险的人接触,以便了解需求会怎样改变,从而可以尽早地改变测试计划和策略。2)如果在对应用程序进行初始设计时多考虑一些适应性,那么以后在发生需求的改变时,就不需要再为改变做很多事情了。3)好的代码注释和好的文档有助于开发人员作出相应的改变。4)只要有可能,就应使用快速原型(rapid prototyping),以帮助用户确认他们的需求,从而减少变更。5)在项目的时间表中应当留出余量,以应付可能出现的变更。6)尽量把新的需求纳入应用软件的“下一版”,而把原始需求作为“第一版”。7)通过谈判,把易于实现的新的变更列入项目,而把难于实现的新需求列入该应用软件的以后的版本。8)要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。9)在应付改变时,应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。10)在设计自动测试剧本时,试图使其有一些灵活性。11)在对应用软件进行自动测试时,要把注意力集中在看来不大会改变的部分。12)对变更进行适当的风险分析,以减少回归测试的要求。13)在设计测试案例时要有一定的灵活性。做到这一点并不容易,所以要降低测试案例的详细程度,或者只建立高级的通用型的测试计划。14)少注意详细的测试计划和测试案例,要把重点放在专门的测试(ad hoc testing)上。5. 集成测试通常都有那些策略?1、在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失;2、各个子功能组合起来,能否达到预期要求的父功能;3、一个模块的功能是否会对另一个模块的功能产生不利的影响;4、全局数据结构是否有问题;5、单个模块的误差积累起来,是否会放大,从而达到不可接受的程度。6.一个缺陷测试报告的组成测试软件项目名称,每个要测试软件项目都有唯一的名称,有的公司对项目还有特定的编号。测试软件版本号,测试周期内,一般需要测试多个软件版本,报告错误时,一定要正确填写产生错误的软件版本号。测试者名称,便于分清责任,便于管理。测试日期与时间,便于分析和统计错误报告信息。测试软件环境,包括操作系统和其他必要的软件程序。测试硬件环境,包括测试计算机和其他测试设备的配置信息。错误描述,简明的描述错误的特征,便于查询和快速浏览。错误标识编号(ID#) ,每个错误都有一个唯一的标识编号,方便查询。错误类型,根据错误类型,分配给适当的人员处理错误。错误级别,错误的严重程度和处理的优先级,优先处理高级别的错误。错误状态,错误状态表明错误是否已经处理和将怎样处理,根据错误状态,采用适当的处理方法。错误处理者名称,便于分清责任,便于管理。重现错误的操作步骤,便于重现错误,修复错误和验证错误。期望的结果,描述满足设计要求的结果。实际测试结果,描述实际测试后得到的结果。必要的附图,便于确认错误的表现形式和错误位置。测试者的建议等注释,便于错误处理者快速和正确处理错误7. 基于WEB信息管理系统测试时应考虑的因素有哪些?一、功能测试 1、链接测试 2、表单测试 3、Cookies测试 4、设计语言测试 5、数据库测试二、性能测试 1、连接速度测试 2、负载测试 3、压力测试三、可用性测试 1、导航测试 2、图形测试 3、内容测试 4、整体界面测试四、客户端兼容性测试 1、平台测试 2、浏览器测试五、安全性测试8. 需求测试注意事项有哪些?一个良好的需求应当具有一下特点:完整性:每一项需求都必须将所要实现的功能描述清楚,以使开发人员获得设计和实现这些功能所需的所有必要信息。正确性:每一项需求都必须准确地陈述其要开发的功能。一致性:一致性是指与其它软件需求或高层(系统,业务)需求不相矛盾。可行性:每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。无二义性:对所有需求说明的读者都只能有一个明确统一的解释,由于自然语言极易导致二义性,所以尽量把每项需求用简洁明了的用户性的语言表达出来。健壮性:需求的说明中是否对可能出现的异常进行了分析,并且对这些异常进行了容错处理。必要性:“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入,如Use Case或别的来源。可测试性:每项需求都能通过设计测试用例或其它的验证方法来进行测试。可修改性:每项需求只应在S R S中出现一次。这样更改时易于保持一致性。另外,使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。可跟踪性:应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链,这种可跟踪性要求每项需求以一种结构化的,粒度好(f i n e - g r a i n e d)的方式编写并单独标明,而不是大段大段的叙述。9.简述一下缺陷的生命周期软件缺陷的生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。简单的软件缺陷生命周期:1、发现打开:测试人员找到软件缺陷并将软件缺陷提交给开发人员;2、打开修复:开发人员再现、修复缺陷,然后提交测试人员去验证;3、修复关闭:测试人员验证修复过的软件,关闭已不存在的缺陷。但是这是一种理想的状态,在实际的工作中是很难有这样的顺利的,需要考虑的各种情况都还是非常多的。复杂的软件缺陷生命周期:1、新建一个软件缺陷,这个软件缺陷是(open)状态,进行bug审查,不是代码问题,就是设计需要修改;2、新建一个软件缺陷,这个软件缺陷是(open)状态,进行bug审查,以后修改的,就可以延期;3、新建一个软件缺陷,这个软件缺陷是(open)状态,进行bug审查,实际没有这个bug,可以将其关闭;4、新建一个软件缺陷,这个软件缺陷是(open)状态,看是否 清楚可重现,如果不能重现,就是缺少信息,需要返回到(open)状态;如果能够重现,就进行修正,修正后关闭,进行回归测试。10.驱动模块:驱动模块在大多数场合称为主程序,它接收测试数据并将这些数据传递到被测试模块.单元测试一个函数单元时,被测单元本身是不能独立运行的,需要为其传送数据,为此写驱动驱动模块主要完成以下事情:1、接受测试输入;2、对输入进行判断;3、将输入传给被测单元,驱动被测单元执行;4、接受被测单元执行结果,并对结果进行判断;5、将判断结果作为用例执行结果输出测试报告。桩模块比如对函数A做单元测试时,被测的函数单元下还包括了一个函数B,为了更好的错误,定位错误,就要为函数B写桩,来模拟函数B的功能,保证其正确。11.单元测试、集成测试、系统测试的侧重点是什么?单元测试是在软件开发过程中要进行的最低级别的测试活动,在单元测试活动中,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试,测试重点是系统的模块,包括子程序的正确性验证等。集成测试,也叫组装测试或联合测试。在单元测试的基础上,将所有模块按照设计要求,组装成为子系统或系统,进行集成测试。实践表明,一些模块虽然能够单独地工作,但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题,在全局上很可能暴露出来,影响功能的实现。测试重点是模块间的衔接(combination between modules)以及参数的传递(parameter passing)等。系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。测试重点是整个系统的运行以及与其他软件的兼容性。12设计用例的方法、依据有那些?白盒测试用例设计有如下方法:基本路径测试等价类划分边界值分析覆盖测试循环测试数据流测试程序插桩测试变异测试.这时候依据就是详细设计说明书及其代码结构黑盒测试用例设计方法:基于用户需求的测试功能图分析方法等价类划分方法边界值分析方法错误推测方法因果图方法判定表驱动分析方法正交实验设计方法.依据是用户需求规格说明书,详细设计说明书。13.软件的缺陷等级应如何划分? 1致命错误,可能导致本模块以及其他相关模块异常,死机等问题; 2严重错误,问题局限在本模块,导致模块功能失效或异常退出 3一般错误,模块功能部分失效; 4建议问题,由问题提出人对测试对象的改进意见;测试退出标准测试退出标准为完成测试需求中列出的所有功能及测试过程中发现缺陷的回归测试。 1.单元测试退出标准 1)单元测试用例设计已经通过评审 2)核心代码100 经过Code Review 3)单元测试功能覆盖率达到100 4)单元测试代码行覆盖率不低于80 5)所有发现缺陷至少60都纳入缺陷追踪系统且各级缺陷修复率达到标准 6)不存在A、B类缺陷 7)C、D、E类缺陷允许存在 8)按照单元测试用例完成了所有规定单元的测试 9)软件单元功能与设计一致 2.集成测试退出标准 1)集成测试用例设计已经通过评审 2)所有源代码和可执行代码已经建立受控基线,纳入配置管理受控库,不经过审批不能随意更改 3)按照集成构件计划及增量集成策略完成了整个系统的集成测试 4)达到了测试计划中关于集成测试所规定的覆盖率的要求 5)集成工作版本满足设计定义的各项功能、性能要求 6)在集成测试中发现的错误已经得到修改,各级缺陷修复率达到标准 7)A、B类BUG不能存在 8)C、D类BUG允许存在,但不能超过单元测试总BUG的50 9)E类BUG允许存在 3.系统测试退出标准 1)系统测试用例设计已经通过评审 2)按照系统测试计划完成了系统测试 3)系统测试的功能覆盖率达100 4)系统的功能和性能满足产品需求规格说明书的要求 5)在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准 6)系统测试后不存在A、B、C类缺陷 7)D类缺陷允许存在,不超过总缺陷的5 8)E类缺陷允许存在,不超过总缺陷的1014.针对缺陷采取怎样的管理措施? 1.要更好的管理缺陷,必须引入缺陷管理工具,商用的或者开源的都可。 2.

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论