爱立信测试面试题.docx

上传人:scccc 文档编号:13208073 上传时间:2021-12-18 格式:DOCX 页数:11 大小:26.42KB
返回 下载 相关 举报
爱立信测试面试题.docx_第1页
第1页 / 共11页
爱立信测试面试题.docx_第2页
第2页 / 共11页
爱立信测试面试题.docx_第3页
第3页 / 共11页
爱立信测试面试题.docx_第4页
第4页 / 共11页
爱立信测试面试题.docx_第5页
第5页 / 共11页
点击查看更多>>
资源描述

《爱立信测试面试题.docx》由会员分享,可在线阅读,更多相关《爱立信测试面试题.docx(11页珍藏版)》请在三一文库上搜索。

1、白箱测试和黑箱测试是什么 ?什么是回归测 试?白盒测试1.白盒测试(White-box Testi ng,又称逻辑驱动测试,结构测试)是把测试对象看作一个打开的 盒子。利用白盒测试法进行动态测试时,需要测试软件产品的内部结构和处理过程,不需测试软件产品的功能。 白盒测试又称为结构测试和逻辑驱动测试。白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。 其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定 / 条件覆盖、条件组合覆盖和路径覆盖。 代码的覆盖深度: 从覆盖源程序语句的详尽程度分析, 逻辑覆盖标准包括以下不同的覆盖标 准:语句覆盖、 判定覆盖、 条件覆盖、 条件判定组合覆盖、 多条

2、件覆盖和修正判定条件覆盖。语句覆盖 为了暴露程序中的错误,程序中的每条语句至少应该执行一次。因此语句 覆盖(Statement Coverage)的含义是:选择足够多的测试数据,使被测程序中每条语句至 少执行一次。语句覆盖是很弱的逻辑覆盖。判定覆盖 比语句覆盖稍强的覆盖标准是判定覆盖(Decision Coverage)。判定覆盖的含义是:设计足够的测试用例,使得程序中的每个判定至少都获得一次“真值”或“假值” 或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次,因此判定覆盖又称 为分支覆盖。条件覆盖 在设计程序中,一个判定语句是由多个条件组合而成的复合判定。为了更 彻底地实现逻辑

3、覆盖,可以采用条件覆盖(Condition Coverage)的标准。条件覆盖的含义是:构造一组测试用例,使得每一判定语句中每个逻辑条件的可能值至少满足一次。多条件覆盖 多条件覆盖也称条件组合覆盖,它的含义是:设计足够的测试用例,使 得每个判定中条件的各种可能组合都至少出现一次。 显然满足多条件覆盖的测试用例是一定 满足判定覆盖、条件覆盖和条件判定组合覆盖的。修正条件判定覆盖修正条件判定覆盖是由欧美的航空/航天制造厂商和使用单位联合制定的 “航空运输和装备系统软件认证标准” ,目前在国外的国防、 航空航天领域应用广泛。 这个覆盖度量需要足够的测试用例来确定各个条件能够影响到包含的判定的结果。它

4、要求满足两个条件:首先,每一个程序模块的入口和出口点都要考虑至少要被调用一次,每个程序的判定到所有可能的结果值要至少转换一次;其次,程序的判定被分解为通过逻辑操作符(and、or)连接的布尔条件,每个条件对于判定的结果值是独立的。2.示例六种覆盖方法首先为了下文的举例描述方便,这里先给出一张程序流程图。(本文以1995年软件设计师考试的一道考试题目为例,图中红色字母代表程序执行路径)。1、语句覆盖1)主要特点:语句覆盖是最起码的结构覆盖要求,语句覆盖要求设计足够多的测试用例,使得程序中每条语句至少被执行一次。2)用例设计:(如果此时将 A路径上的语句1T去掉,那么用例如下)XY路径15050O

5、BDE29070OBCE3)优点:可以很直观地从源代码得到测试用例,无须细分每条判定表达式。4)缺点:由于这种测试方法仅仅针对程序逻辑中显式存在的语句,但对于隐藏的条件和可能到达的隐式逻辑分支,是无法测试的。在本例中去掉了语句1T去掉,那么就少了一条测试路径。在if结构中若源代码没有给出else后面的执行分支,那么语句覆盖测试就不会考虑这种情况。 但是我们不能排除这种以外的分支不会被执行,而往往这种错误会经常出现。再如,在 Do-While结构中,语句覆盖执行其中某一个条件分支。那么显然,语句覆盖对于多分支的逻辑运算是无法全面反映的,它只在乎运行一次,而不考虑其他情况。2、判定覆盖1) 主要特

6、点:判定覆盖又称为分支覆盖,它要求设计足够多的测试用例,使得程序中 每个判定至少有一次为真值,有一次为假值 ,即:程序中的每个分支至少执行一次。 每个判 断的取真、取假至少执行一次。2)用例设计:XY路径19090OAE25050OBDE39070OBCE3)优点:判定覆盖比语句覆盖要多几乎一倍的测试路径,当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性,无须细分每个判定就可以得到测试用例。4) 缺点:往往大部分的判定语句是由多个逻辑条件组合而成(如,判定语句中包含 AND、OR、CASE),若仅仅判断其整个最终结果,而忽略每个条件的取值情况,必然会遗漏部分 测试

7、路径。3、条件覆盖1)主要特点:条件覆盖要求设计足够多的测试用例,使得判定中的每个条件获得各种 可能的结果,即每个条件至少有一次为真值,有一次为假值。2)用例设计:XY路径19070OBC240OBD3) 优点:显然条件覆盖比判定覆盖,增加了对符合判定情况的测试,增加了测试路径。4)缺点:要达到条件覆盖, 需要足够多的测试用例, 但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真,而不考虑所有的判定结果。4、判定/条件覆盖1)主要特点:设计足够多的测试用例,使得判定中每个条件的所有可能结果至少出现 一次,每个判定本身所有可能结果也至少出现一次。2)用例设计:XY路径19090

8、OAE25050OBDE39070OBCE47090OBCE3)优点:判定/条件覆盖满足判定覆盖准则和条件覆盖准则,弥补了二者的不足。4)缺点:判定/条件覆盖准则的缺点是未考虑条件的组合情况。5、组合覆盖1)主要特点:要求设计足够多的测试用例,使得每个判定中条件结果的所有可能组合至少出现一次。2)用例设计:1XY路径19090OAE29070OBCE39030OBDE47090OBCE53090OBDE67070OBDE75050OBDE3)优点:多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。更改的判定/条件覆盖要求设计足够多的测试用例,使得判定中每个条件的所有可能结果至少出现一

9、 次,每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果。4)缺点:线性地增加了测试用例的数量。6、路径覆盖1)主要特点:设计足够的测试用例,覆盖程序中所有可能的路径。2)用例设计:XY路径19090OAE25050OBDE39070OBCE47090OBCE3)优点:这种测试方法可以对程序进行彻底的测试,比前面五种的覆盖面都广。4)缺点:由于路径覆盖需要对所有可能的路径进行测试(包括循环、条件组合、分支 选择等),那么需要设计大量、复杂的测试用例,使得工作量呈指数级增长。而在有些情况 下,一些执行路径是不可能被执行的,如:If ( !A ) B+ ;If ( !A

10、 ) D-;这两个语句实际只包括了2条执行路径,即 A为真或假时候对 B和D的处理,真或假不可能都存在,而路径覆盖测试则认为是包含了真与假的4条执行路径。这样不仅降低了测试效率,而且大量的测试结果的累积,也为排错带来麻烦。总结白盒测试是一种被广泛使用的逻辑测试方法,是由程序内部逻辑驱动的一种单元测试方法。只有对程序内部十分了解才能进行适度有效的白盒测试。但是贯穿在程序内部的逻辑存在着不确定性和无穷性,尤其对于大规模复杂软件。因此我们不能穷举所有的逻辑路径,即使穷举也未必会带来好运 (穷举不能查出程序逻辑规则错误,不能查出数据相关错误, 不能查出程序遗漏的路径)。那么正确使用白盒测试, 就要先从

11、代码分析入手, 根据不同的代码逻辑规则、语句执行情况,选用适合的覆盖方法。任何一个高效的测试用例,都是针对具体测试场景的。逻辑测试不是片面的测试正确的结果或是测试错误的结果,而是尽可能全面地覆盖每一个逻辑路 径。黑盒测试2单元测试、集成测试、系统测试的侧重点是什么?单元测试的重点是系统的模块,包括子程序的正确性验证等。集成测试的重点是模块间的衔接以及参数的传递等。系统测试的重点是整个系统的运行以及与其他软件的兼容性。单元测试是在软件开发过程中要进行的最低级别的测试活动,在单元测试活动中,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试,测试重点是系统的模块,包括子程序的正确性验证等。集

12、成测试,也叫组装测试或联合测试。在单元测试的基础上,将所有模块按照设计要求,组装成为子系统或系统,进行集成测试。实践表明,一些模块虽然能够单独地工作,但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题,在全局上很可能暴露出来,影响功能的实现。测试重点是模块间的衔接以及参数的传递等。系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。测试重点是整个系统的运行以及与其他软件的兼容性。单元测试针对的是软件设计的最小单元-程序模块(面向过程中是函数、过程;面向对象中是类。),进行正确性检验的测试工作,在于发现每个程序模块内

13、部可能存在的差错.般有两个步骤:人工静态检查/动态执行跟踪集成测试针对的是通过了单元测试的各个模块所集成起来的组件进行检验,其主要内容是各个单元模块之间的接口,以及各个模块集成后所实现的功能系统测试针对的是集成好的软件系统,作为整个计算机系统的一个元素,与计算机硬件/外设/某些支持软件/数据和人员等其他系统元素结合在一起 ,要在实际的运行环境中,对计算机 系统进行一系列的集成测试和确认测试 3设计用例的方法、依据有那些?白盒测试用例设计有如下方法:基本路径测试等价类划分边界值分析覆盖测试循环测试 数据流测试程序插桩测试变异测试。这时候依据就是详细设计说明书及其代码结构。黑盒测试用例设计方法:基

14、于用户需求的测试功能图分析方法等价类划分方法边界值分 析方法错误推测方法因果图方法判定表驱动分析方法正交实验设计方法。依据是用户需 求规格说明书,详细设计说明书。4一个测试工程师应具备那些素质和技能?5集成测试通常都有那些策略?集成测试通常都有那些策略?大爆炸集成;自顶向下集成;自底向上集成;三明治集成;分层集成;基干集成;基于功能的集成;基于 消息的集成;基于风险的集成;基于进度的集成1、在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失;2、各个子功能组合起来,能否达到预期要求的父功能;3、一个模块的功能是否会对另一个模块的功能产生不利的影响;4、全局数据结构是否有问题;5、单个模块

15、的误差积累起来,是否会放大,从而达到不可接受的程度。9. 软件本地化测试比功能测试都有哪些方面需要注意?软件本地化测试的目的:2.源语软件本地化测试的测试策略:1.本地化软件要在各种本地化操作系统上安装并测试。言软件安装在另一台相同源语言操作系统上,作为对比测试。3.重点测试因本地化引起的软件的功能和软件界面的错误。4.测试本地化软件的翻译质量。5.手工测试和自动测试相结合。6你用过的测试工具的主要功能、性能及其他?白盒测试工具主要有:内存资源泄漏检查:Numega中的bouncechecker ,Rational的Purify等代码覆盖率检杳:Numega 匚的 truecoverage,R

16、ational 的 Purecoverage, Telelogic 公司的logiscope,Macabe 公司的 Macabe 等代码性能检杳:Numega 中的 truetime,Rational 的 Quantify 等代码静态度量分析质量检查工具:logiscope和Macabe等黑盒测试工具主要有:客户端功能测试:Ml 公司的 winrunner ,compuware 的 qarun,Rational 的 SQA robot 等等服务器端压力性能测试:MI公司的winload,compuware的qaload,Rational的SQA load等等Web测试工具:MI公司的Astra

17、系列,rsw公司的e-test suite等等WEB 系统测试工具: TEST, Workberch,Web Appication Stress Tool (WAS)测试管理工具:rational 的 test manager ,compuware 的 qadirector 等等回归测试工具:RationalTeamTest,WinRunner(MI 公司)软件纠错工具:Ratio nalPurity嵌入式测试工具:Logiscope (静态测试工具)、CodeTest系统负荷测试工具:Rati on alPerforma nee此外还有缺陷跟踪工具trackrecord等。数据库测试工具:T

18、estBytes7个缺陷测试报告的组成8基于WEB信息管理系统测试时应考虑的因素有哪些? 表单测试一个缺陷测试报告的组成缺陷的标题,缺陷的基本信息,复现缺陷的操作步骤,缺陷的实际结果描述,期望的正确结果描述,注释文字和截取的缺陷图象。 Cookies测试设计语言测试数据库测试2)性能测试连接速度测试负载测试压力测试3)可用性测试导航测试图形测试内容测试整体界面测试4)客户端兼容性测试平台测试浏览器测试5)安全性测试10. 软件测试项目从什么时候开始,?为什么?软件测试应该在需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发过程中产生的 所有产品都测试,并且软件缺陷存在放大趋势缺

19、陷发现的越晚,修复它所花费的成本就越大.11. 需求测试注意事项有哪些?一个良好的需求应当具有以下特点:完整性:每一项需求都必须将所要实现的功能描述清楚,以使开发人员获得设计和实现这些功能所 需的所有必要信息。正确性:每一项需求都必须准确地陈述其要开发的功能。 一致性:一致性是指与其它软件需求或高层(系统,业务)需求不相矛盾。可行性:每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。无二义性:对所有需求说明的读者都只能有一个明确统一的解释,由于自然语言极易导致二义性,所以尽量把每项需求用简洁明了的用户性的语言表达出来。健壮性:需求的说明中是否对可能岀现的异常进行了分析,并且对这些

20、异常进行了容错处理。必要性:必要性”可以理解为每项需求都是用来授权你编写文档的根源。要使每项需求都能回溯至某项客户的输入,如 Use Case或别的来源。可测试性:每项需求都能通过设计测试用例或其它的验证方法来进行测试。可修改性:每项需求只应在 S R S中出现一次。这样更改时易于保持一致性。另外,使用目录表、 索引和相互参照列表方法将使软件需求规格说明书更容易修改。可跟踪性:应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链,这 种可跟踪性要求每项需求以一种结构化的,粒度好(fi ne-grained)的方式编写并单独标明,而不是大段大段的叙述。12. 简述一下缺陷的生

21、命周期1)新建(打开):当QA人员汇报新的缺陷时2)延后处理:如果这个缺陷跟当前发布的这个版本没有直接关系,或者当前版本无法修复,或者这个缺陷不是很严重, 不需要立刻修复,那么项目经理可以把状态设为“延后处 理”。3)已指派:“指派给”这个值是由项目组长或者项目经理来填,指定给具体的某个开 发人员。4)已解决/已修复:当开发人员做了某些必要的代码改动,并且确认修改之后,那么他/她就可以把状态改为“已修复”,然后就交给测试组进行回归测试。5) 无法重现:如果开发人员根据 QA人员在缺陷报告里面描述的步骤,都无法重现这个缺陷的时候,那么开放人员可以把这个缺陷标为“无法重现”。QA人员需要检查这个缺

22、陷是否可以重现,并且把更为详细的重现步骤提供给开发人员。6) 需要更多信息:如果开发人员认为 QA人员提供的缺陷重现步骤不够清晰, 因而无法 重现缺陷的时候,那么他/她可以把状态标记为“需要更多信息”。在这种情况下,QA人员 需要提供更为详细的重现步骤,并把缺陷返回给开发小组。7)重新打开:如果 QA人员不满意这个修复结果,或者说即使在修复之后,依然出现同 样的问题,那么 QA人员可以把状态标记为“重新打开”,这样的话,开发人员就可以采取 相应的行动了。8) 关闭:如果QA小组已经验证过这个缺陷的修复结果,并且问题是已经得到了解决的, 那么QA人员就可以把状态改为“关闭”。13. 测试分析测试用例注意(事项)?

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 社会民生


经营许可证编号:宁ICP备18001539号-1