文档库 最新最全的文档下载
当前位置:文档库 › 软件测试考试资料

软件测试考试资料

软件测试考试资料
软件测试考试资料

1、判断题

代码评审是检察院代码是否达到模块设计的要求×代码评审员一般由测试员担任×

项目立项前测试人员不需要提交任何工件√集成测试计划在需求分析阶段末提交×

自底向上集成需要测试员编写驱动程序√Beta测试时验收测试的一种√

代码评审是检查源代码是否达到模块设计的要求。×

2、软件测试:软件测试是为了发现错误而执行程序的过程。//软件质量保证的关键元素,代表了规约、设计和编码的最终检查。

2)软件测试的目的:从用户的角度出发,普遍希望通过软件测试暴露软件中隐藏的错误和缺陷,以考虑是否可接受该产品;从软件开发者的角度出发,则希望测试成为表明软件产品中不存在错误的过程,验证该软件已正确地实现了用户的要求,确立人们对软件质量的信心。3)软件测试的任务:(1)寻找Bug;(2)避免软件开发过程中的缺陷;(3)衡量软件的质量;(4)关注用户的需求。

软件测试的对象:需求规格说明,概要设计规格说明,详细设计规格说明,源程序

4)软件测试的基本原则:①应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。②测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。③程序员应避免检查自己的程序。④在设计测试用例时,应当包括合理的输入条件和不合理的输入条件。⑤充分注意测试中的群集现象。⑥严格执行测试计划,排除测试的随意性。⑦应当对每一个测试结果做全面检查。⑧妥善保存测试计划,测试用例,出错统计和最终分析报告,为维护提供方便。

3、软件测试的分类:

按代码和用户使用的角度:覆盖测试、使用测试。

按是否查看源代码:白盒测试(玻璃盒测试)、黑盒测试、灰盒测试。

按是否使用工具:手工测试、自动测试。

按代码是否执行:静态测试、动态测试。

按测试阶段:单元测试、集成测试、确认测试、系统测试、验收测试。

4、白盒测试:又称结构测试,透明盒测试,逻辑测试或基于代码的测试。白盒测试是测试被测单元内部如何工作的一种方法,对软件中的逻辑路径进行覆盖测试。

黑盒测试(数据驱动测试):又叫功能测试或数据驱动测试。把被测的软件看做是一个黑盒子,我们不去关心盒子里面的结构是什么样子的,只关心软件的输入数据和输出结果。

功能测试是黑盒测试的一方面,它检查实际软件的功能是否符合用户的需求。

性能测试是为描述测试对象与性能相关的特征并对其进行评价,而实施和执行的一类测试。单元测试是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。

集成测试也叫组装测试或联合测试。在单元测试的基础上,将所有模块按照设计要求组装成为子系统或系统,进行集成测试。

系统测试,是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法

验收测试指的是在系统测试的后期,以用户测试为主,或有测试人员等质量保障人员共同参与的测试,它也是软件正式交给用户使用的最后一道工序

自顶向下测试,是从程序的顶部或初始模块开始。

自底向上测试,是开始于程序的终端模块,此类模块不再调用其他任何模块。

回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

灰盒测试,是介于白盒测试与黑盒测试之间的,是将根据需求规范说明语言(RSL)产生的基于测试用例的要求(RBTC),用测试单元的接口参数加到受测单元,检验软件在测试执行环境控制下的执行情况。

边界条件测试也是一种黑盒测试方法,适度等价类分析方法的一种补充,由长期的测试工作经验得知,大量的错误时发生在输入或输出的边界上,因此针对各种边界情况设计测试用例,可以查出更多的错误。

测试计划:描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。

测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。

动态测试指实际运行被测程序,输入相应得测试数据,检查实际输出结果和预期结果是否相符的过程。

静态测试是指不实际运行被测试软件,而只是静态地查看程序代码、界面或文档中可能存在的错误过程。

可靠性测试:在有使用代表性的环境中,为进行软件可靠性估计对该软件进行的功能测试路径测试就是设计足够多的测试用例,覆盖被测试对象中的所有可能路径。

排错测试:排错过程开始于一个测试程序的执行.若测试结果与期望结果有出入,即出现了错误征兆,排错过程中首先要找出错误原因,然后对错误进行修改。

人工测试:是人为测试和手工测试的统称.手工测试是指依靠人力来查找BUG。

自动测试是指编写一些测试工具,让它们自动运行来查找BUG。

5、软件测试流程:需求分析、测试计划、测试设计、测试环境搭建、测试执行、测试记录、缺陷管理、软件评估、测试维护。

6、软件测试流程图:

7、黑盒测试的优缺点

优点:1)对较大的代码单元来说,黑盒测试比白盒测试的效率高2)测试人员不需要了解实现细节,包括特定的编程语言3)测试人员和编程人员是相互独立的4)从用户的角度进行测试,很容易被接受和理解5)有助于暴露任何与规格不一致或者歧义的地方6)测试用例可以在规格完成之后马上进行7)相同动作可重复执行,最枯燥的部分可由机器完成。

缺点:a代码得不到测试。b如果规格说明设计有误,很难发现。c测试不能充分地进行。

d结果的准确性取决于测试用例的设计。

方法:等价类划分法,边界值分析法,因果图法,正交实验法,功能图分析方法

8、白盒测试

依据:软件需求报告;软件需求规格说明;程序设计文档;软件界面设计;编码规范;

开发命名标准。

流程:白盒测试的流程分为界面对象和业务对象两种方式。

(1)界面对象测试

(2) 业务对象流程测试

方法:白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、Z路径覆盖、程序变异。

9、白盒、黑盒、灰盒测试之间的比较:

灰盒测试和白盒测试的区别:1)测试的时段不同,白盒测试在单元测试阶段进行,灰盒测试在集成测试前期进行。2)测试的关注对象不同,白盒测试更关注内部实现是否按照规格说明书进行,灰盒测试除了需要关注白盒测试关注的内容,还更多从业务层面去考虑问题,考虑更多的组合测试业务场景。3)范围不同,白盒测试更关注单个代码段,函数的正确性,灰盒测试的对象已经基本能完成一个完整的业务功能。

灰盒测试的代码比较独立,不响白盒测试基本上和程序代码需要坐到一一对应。

灰盒测试和白盒测试的相同点:

1)目的相同。2)方法相同,都是需要通过代码来实现。3)对测试人员素质要求相同。

灰盒测试和黑盒测试的不同点:

1)测试的方法不同。2)对测试人员要求不同。灰盒测试要求比较强的编程能力。

3)范围不同,关注的对象不同。黑盒测试是覆盖产品范围最广的测试,是灰盒测试无法取代的;但灰盒测试是可以被黑盒替代的,只是代价比较大,需要很多的测试用例。

灰盒测试和黑盒测试的相同点:1)目的相同。2)测试所处的时间段相近。

10、软件缺陷,即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷。

缺陷定义为:1)软件没有达到产品说明书表明的功能;2)程序中存在语法错误;

3)程序中存在拼写错误;4)程序中存在不正确的程序语句;

5)软件出现了产品说明书中不一致的表现;6)软件功能超出产品说明书的范围;

7)软件没有达到用户期望的目标;8)测试员或用户认为软件的易用性差。

根据定义,缺陷分类:文档缺陷,代码缺陷,测试缺陷,过程缺陷

2)软件缺陷的特征:

A、单一准确:每个报告只针对一个软件缺陷。

B、可以再现:提供缺陷的精确操作步骤,容易看懂再现这个缺陷。

C、完整统一:提供完整、前后统一的软件缺陷的步骤和信息,如图片信息、Log文件等。

D、短小简练:通过使用关键词,使软件缺陷的标题的描述简练,准确解释产生缺陷的现象。

E、特定条件:条件功能在通常情况下没有问题,而是在某种特定条件下会存在缺陷,所以软件缺陷描述不要忽视特定条件,如特定的操作系统等。

F、补充完整:测试人员发现BUG,要保证它被正确的报告,并且得到应有的重视,继续监

视其修复的全过程。

H、不做评价:在软件缺陷描述不要带有个人观点,对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身,将事实或现象客观的描述出来就可以,不需要任何评价或议论。3)软件缺陷的类型:

功能类、性能类、系统/模块接口类、用户界面类、数据处理类、流程类、提示信息类、软件包类、建议类、常识类、文档

11、集成测试的过程

①计划集成测试②设计集成测试③执行集成测试④分析测试结果并提交测试报告

12、系统测试的内容

功能测试:恢复性测试(灾难测试、容错测试)、敏感性测试、安全性测试、接口测试、用户界面测试、安装/升级测试、配置测试/兼容性测试、国际化(语言)测试、用户文档测试、……性能测试:强度测试、容量测试、可靠性测试、边界测试、……

冒烟测试;回归测试;随机测试;

硬件系统专有测试:可靠性测试、可生产性测试、可维护性测试

2)系统测试的测试类型:

功能测试;性能测试;负载测试;强度测试;容量测试;安全性测试;配置测试;故障恢复测试;安装测试;文档测试;用户界面测试;

3)系统测试的过程:

系统测试计划阶段;系统测试设计和开发阶段;系统测试执行和评估阶段

13、验收测试的内容

1)对功能测试、网络测试、软件安装测试、性能测试、集成测试、系统测试的测试用例进行回归测试;

2)验收测试组依据系统设计说明书的内容,系统使用说明书,系统维护手册在新建系

统产品演示一遍,捕捉不足之处。

14、软件测试人员需要有一下素质:

专心、细心、耐心、责任心、自信心,恒心,平常心

知识:测试专业技能、软件编程技能、网络、操作系统、数据库、中间件等知识:行业知识职责:1)在项目的前景、需求文档确立基线前对文档进行测试,从用户体验和测试的角度提出自己的看法

2)编写合理的测试计划,并与项目整体计划有机地整合在一起

3)编写覆盖率高的测试用例

4)针对测试需求进行相关测试技术的研究

5)认真仔细地实施测试工作

6)进行缺陷跟踪与分析

7)提交测试分析报告

15、(软件缺陷)BUG 的等级划分与优先级

把发现的错误(Bug)/缺陷(Defect)按严重性分为4类:

1.严重:系统崩溃或挂起等导致系统不能继续运行;

2.主要:使系统不稳定、或破坏数据、或产生错误结果,而且是常规操作中经常发生或非常规操作中不可避免的主要问题;

3.次要:系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题,如:显示不正确但输出正确;

4.轻微:界面拼写错误或用户使用不方便等小问题或需要完善的问题。

BUG 的优先级(一般与BUG 等级挂钩)

1级(严重):立即解决。缺陷导致系统几乎不能使用或测试不能继续,需立即修复。

2级(较高):缺陷严重,影响测试,需要优先考虑。

3级(一般):正常排队缺陷需要正常排队等待修复。

4级(轻微):缺陷可以在开发人员有时间的时候被纠正。

BUG状态:已提交、已修改、不修改、延迟、待讨论、已验证、关闭、重新打开

16、缺陷的起源:是指缺陷引起的故障或事件第一次被检测到的阶段。

给软件带来缺陷的原因有很多,这里列举几点:

需求:参与人员的过度自信,在需求阶段产生的错误;

构架:人员之间的沟通交流不够,交流上有误解或者根本不进行交流,在系统构架设计阶段产生的错误;设计:工期短,任务重,时间压力大,在程序设计阶段产生的错误;

编码:在编码阶段程序设计本身有错误产生的错误;

测试:在测试阶段发现的缺陷;用户:在用户使用阶段发现的错误。

软件缺陷的来源:需求说明书、设计文档、系统集成接口、数据流(库)、程序代码

需求说明书:需求说明书的错误或不清楚引起的问题;

设计文档:设计文档描述不准确。和需求说明书不一致的问题;

系统集成接口:系统个模块参数不匹配、开发组之间缺乏协调引起的缺陷;

数据流(库):由于数据字典、数据库中的错误引起的缺陷;

程序代码:纯粹在编码中的问题所引起的缺陷

缺陷的根源:是指造成软件错误的根本因素,如测试策略、过程工具和方法、团队/人、缺乏组织和通讯、硬件、软件、工作环境等。

测试策略:错误的测试范围,误解测试目标,超越测试能力等;

过程工具和方法:无效的需求收集过程,果实的风险管理过程,不使用的项目管理方法,没有估算规程,无效的变更控制过程等;

团队/人:项目团队职责交叉,缺乏培训。没有经验的项目团队,缺乏士气和动机不纯等;缺乏组织和通讯:缺乏用户参与,职责不明确、管理失败等;

硬件:硬件配置不对、缺乏、或处理器缺陷导致算术精度丢失,内存溢出等;

软件:软件设置不对、缺乏,或操作系统错误导致无法解放资源,工具软件的错误,编译器的错误等;

工作环境:组织机构调整,预算改变,工作环境恶劣。

17、软件错误的分类:

1)Goodenough和Gerhart把软件错误分为:性能错误和逻辑错误

2)Beitzer从软件测试的角度把软件错误分为:功能错误,系统错误,过程错误,文档错误和其他错误。

3)Geol软件分类法是按错误性质分类的方法,把软件错误分为:语法错误,语义错误,运行时错误,说明错误,性能错误。

4)Thayer把软件错误分为16类:计算错误,逻辑错误,输入输出错误,资料加工错误,操作系统及系统支持软件的错误,配置错误,接口错误,用户要求改变,域指数据库错误,全程变量错误,重复错误,文档错误,要求一致性错误,性质不明的错误,操作员错误,问题。5)按照软件产品的逆过程,把软件错误分为:模块实现错误,模块结合错误,功能错误和系统错误。

6)从独立性上看,可分为独立错误和相关错误。

18、缺陷的发现率是将发现的缺陷数量作为时间的函数来评估,创建缺陷趋势图或报告。缺陷发现率随着测试时间和修复进度而减少:缺陷发现率将随着测试时间而测试成本增加。

19、测试用例的设计方法:

等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例

20、软件测试评估是指对未正式投入商业化使用的软件进行预先的小规模试验,又称小试。主要是由代码审查和合理性分析组成。

测试的主要评测方法:测试覆盖评估、质量评估、缺陷评估、性能测试评估。

21、覆盖率等于覆盖面积/总面积

测试覆盖通过以下公式计算:测试覆盖=T(p,i,x,x)/RfT

测试覆盖率:用于确定测试所执行到的覆盖项的百分比,其中覆盖项是指作为测试基础的一个入口或属性,比如语句、分支、条件等。

通过以下公式计算:基于需求的测试覆盖率=T(p, i, x, s)/RfT %

其中,T是用测试过程或测试用例表示的测试(Test)数(已计划的、已实施的或成功的),RfT是测试需求(Requirement for Test)的总数。

通过以下公式计算:已计划的测试覆盖率=Tp/RfT %

其中,Tp是用测试过程或测试用例表示的计划测试需求数,RfT是测试需求的总数。

通过以下公式计算:已实施的测试覆盖率=Ti/RfT%

其中,Ti是用测试过程或测试用例表示的已执行的测试需求数,RfT是测试需求的总数。通过以下公式计算:已执行成功的测试覆盖率=Ts/RfT%

Ts是用完全成功、没有缺陷的测试过程或测试用例表示的已执行测试需求数,RfT是测试需求的总数。

通过以下公式计算:基于代码的测试覆盖率=le/Tlic%

其中,le是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行代码数,Tlic是代码中的项目总数。

基于需求的测试覆盖在测试生命周期中要评测多次,并在测试生命周期的里程碑处提供测试覆盖的标识(如已计划的、已实施的、已执行的和成功的测试覆盖)。

基于代码的测试覆盖评测测试过程中已经执行的代码的多少,与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流(语句、分支或路径)或数据流的基础上。

具体而言代码覆盖率分析是这样一个过程:1、找出程序经过一系列测试而没有执行的部分代码 2、创建一个附加的测试用例来增加覆盖率 3、决定代码覆盖的定量度量。

22、三角形测试用例:

(1)一、等价类划分:三角形三条边A、B、C的数据类型不同

二、边界值分析:由于三角形的边长可以是正整数或正小数,所以就不对长度进行测试,那么边界值分析就不用了三、因果图法:三角形的三条边数据输入组合

我们再分析一下三角形的等价类:

有效等价类:输入3个正整数或正小数:

1、两数之和大于第三数,如A

2、两数之和不大于第三数

3、两数相等,如A=B或B=C或C=A

4、三数相等,如A=B=C

5、三数不相等,如A!=B,B!=C,C!=A

无效等价类:1、空 2、负整数 3、非数字 4、少于三个数

三角形测试用例类别

输入条件有效等价类无效等价类

是否是三角形(A>0)(1)(B>0)(2)

(C>0)(3)(A+B>C)(4)

(B+C>A)(5)(C+A>B)(6)(A<=0)(7)(B<=0)(8)(C<=0)(9)(A+B<=C)(10)(B+C<=A)(11)(C+A<=B)(12)

是否是等腰三角形(A=B)(13)(B=C)(14)(C=A)(15) (A!=B)and(B!=C)and(C!=A) (16)

是否是等腰直角三角形(A=B)and(A2+B2=C2)(17)

(B=C)and(A2+C2=B2)(18)

(C=A)and(C2+A2=B2)(19)

(A!=B)and(B!=C)and(C!=A) (20)

是否是等边三角形(A=B)and(B=C)and(C=A)(21) (A!=B) (22)(B!=C) (23)(C!=A) (24)

三角形测试用例:

序号[A,B,C] 覆盖等价类输出

1 [3,4,5] (1)(2)(3)(4)(5)(6) 是三角形

2 [0,1,2] (7) 非三角形

3 [1,0,2] (8) 非三角形

4 [1,2,0] (9) 非三角形

5 [1,2,3] (10) 非三角形

6 [1,3,2] (11) 非三角形

7 [3,1,2] (12) 非三角形

8 [3,3,4] (1)(2)(3)(4)(5)(6)(13) 等腰三角形

9 [3,4,4] (1)(2)(3)(4)(5)(6)(14) 等腰三角形

10 [3,4,3] (1)(2)(3)(4)(5)(6)(15) 等腰三角形

11

[22,22,4]

(1)(2)(3)(4)(5)(6)(17) 等腰直角三角形

12

[4,22,22]

(1)(2)(3)(4)(5)(6)(18) 等腰直角三角形

13 [22,4,22]

(1)(2)(3)(4)(5)(6)(19) 等腰直角三角形

14 [3,4,5] (1)(2)(3)(4)(5)(6)(16)(20)(22)(23)(24) 是三角形

15 [3,3,3] (1)(2)(3)(4)(5)(6)(16)(21) 等边三角形

16 [, , ,] 无效等价类错误提示

17 [-3,4,5] 无效等价类错误提示

18 [a,4,@] 无效等价类错误提示

19 [3,4] 无效等价类错误提示

(2).某程序规定:"输入三个整数 a 、 b 、 c 分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型,当此三角形为一般三角形、等腰三角形及等边三角形时,分别作计算… "。用等价类划分方法为该程序进行测试用例设计。(三角形问题的复杂之处在于输入与输出之间的关系比较复杂。)

分析题目中给出和隐含的对输入条件的要求:

1)整数 2)三个数(3)非零数(4)正数 5)两边之和大于第三边(6)等腰(7)等边如果a 、b 、c 满足条件(1 )~ (4 ),则输出下列四种情况之一:

1)如果不满足条件(5),则程序输出为" 非三角形" 。

2)如果三条边相等即满足条件(7),则程序输出为" 等边三角形" 。

3)如果只有两条边相等、即满足条件(6),则程序输出为" 等腰三角形" 。

4)如果三条边都不相等,则程序输出为" 一般三角形" 。

列出等价类表并编号:

覆盖有效等价类的测试用例:

a b c 覆盖等价类号码

3 4 5 (1)--(7)

4 4

5 (1)--(7),(8)

4 5 5 (1)--(7),(9)

5 4 5 (1)--(7),(10)

4 4 4 (1)--(7),(11)覆盖无效等价类的测试用例:

(3)有关判断三角形测试用例:

综合使用边界值分析、等价类划分和错误推断等方法,设计出下列测试的情况:(1) 一般直角三

角形(2) 等边三角形(3) 等腰锐角三角形(4) 一般三角形(5) 不能构成三角形的情况(6) 一般

锐角三角形(7) 等腰钝角三角形(8) 等腰直角三角形(9) 边长为0的情况(10)边长有负数的情

况(11) 边长有特殊符号的情况(12)边长有汉字的情况(13)输入数据不全(只知道2边的长度

不知道第三边)(14) 点了根号选框,但里面的数是小数的情况(15)带%号的数字的情况

下表为程序测试的数据:

判断三角形形状软件测试

用例编

输入三边数据预期结果执行结果号

1 3,4,5 一般直角三角形一般直角三角形正确

2 2,2,2 等边三角形等边三角形正确

3 8,10,8 等腰锐角三角形等腰锐角三角形正确

4 2,3,4 一般三角形一般钝角三角形正确

5 1,2,3 不能构成三角形不能构成三角形正确

6 5,6,

7 一般锐角三角形一般锐角三角形正确

7 8,8,15 等腰钝角三角形等腰钝角三角形正确

8 4,4,32等腰直角三角形等腰直角三角形正确

9 0,0,0 边长必须大于零边长必须大于零正确

10 -1,-2,-3 边长必须大于零边长必须大于零正确

11 *,^,% 请输入数字请正确输入三角形的三边良好

12 我,A,R 请输入数字请正确输入三角形的三边良好

13 2,3 请正确输入完整三边请正确输入三角形的三边良好

14 3.5,5.3,8.3根号里不能输入小数根号里不能输入小数正确

15 34%,34%,23% 不能输入百分号请正确输入三角形的三边良好

相关文档