参考地址 http://www.docin.com/p-297467364.html

第一章:软件测试基础(18%)

1、学习目标
1.1 为什么需要软件测试? (K2)

① 通过具体的例子,来描述软件中的缺陷会以什么样的方式损害个人、损害环境或者损 害公司利益(K2)。

② 区分引起缺陷的根本原因及其影响(K2)。

●由人设计的程序代码或文档中会引入缺陷。时间,人员,代码,系统,技术,环境都会引起软件缺陷。

③ 通过举例的方式说明为什么需要测试(K2)。

●可以减少软件系统在运行环境中的风险,可以提高软件系统的质量。

④ 描述为什么测试是质量保证(quality assurance)的一部分,通过举例说明测试是如何来提高软件质量的(K2)。

●测试就会帮助树立对于软件质量的信心。一个设计合理的测试过程完成并顺利通过,可以降低整个系统存在问题的风险。

⑤ 理解术语错误(error,mistake)、缺陷(defect,bug)、故障(fault)、失效(failure)的概念以及相应的定义(K1)。

●错误(mistake):产生不正确结果的人为行为。人为的原因导致一个不正确的结果。它可以是程序内的内部错误,也可能是文档内的错误。甚至是环境方面的问题。

●错误(error):计算机计算得到的、观察到的、测量到的数值或者条件和理论上得到的正确的数值或者条件之间存在的差异。

●缺陷(defect):程序或者软件中不正确的步骤、过程或者数据定义等。比如错误的语句或者错误的标量定义等。缺陷是错误的具体表现,可以是不正确的文档、程序段以及指令或者数据定义。

●失效/失败(failure/fail):软件系统或单元无法实现需求文档中规定的功能特性或者非功能特性。或者说单元/系统产生的结果与期望交付的服务或者结果存在偏差。http://www.51testing.com/html/91/n-229691.html

1.2 什么是测试 (K2)

●测试活动包含了测试执行之前和之后的一些活动,包括计划和控制、选择测试条件、设计和执行测试用例、检查测试结果、评估出口准则、报告测试过程及被测系统、在一个测试阶段完成后要进行测试结束或总结工作

① 认识测试的总体目标(K1)。

●发现缺陷;增加对质量的信心;为决策提供信息;预防缺陷。

② 描述在软件开发、软件维护和软件运行过程中,测试作为发现缺陷、提供信息和信心 以及预防缺陷的一种手段(K2)。

●不同的测试阶段,需要考虑不同的测试目标。

●组件测试、集成测试和系统测试等,测试的主要目标是尽可能的发现失效;

●在验收测试中,测试的主要目标是确认系统是否按照预期工作,是建立满足了需求的信心;

●在运行测试阶段,测试的主要目标是为了评估系统的特征;

1.3 软件测试的基本原则 (K2)

说明测试的基本原则(K2)。

●测试显示存在缺陷

●穷尽测试是不可行的

●测试尽早介入

●缺陷集群性

●杀虫剂悖论

●测试活动依赖于测试背景

●不存在缺陷(就是有用系统)的谬论

1.4 基本的测试过程 (K1)

① 认识从计划到测试结束过程中测试的基本活动,以及在每个测试活动中的主要任务 (K1)。

基本的测试过程主要由下面一些活动组成:

●测试计划和控制;

●测试分析和设计;

●测试实现和执行;

●评估出口准则和报告;

●测试结束活动。

1.5 测试的心理学 (K2)

① 认识测试的成功与否,会受测试心理因素的影响(K1):

●清晰的测试目标决定了测试人员效率;

●人们往往会忽视自己的错误;

●认识到就事论事的交流方式以及反馈与问题相关信息的重要性。

② 对比测试人员(tester)和开发人员(developer)的思维方式的差异(K2)。

●在系统中发现失效需要测试员具有一颗好奇心、专业的怀疑态度、一双挑剔的眼睛、对细节的关注、与开发人员良好的沟通能力以及对常见的错误进行判断的经验。

2、练习题

2.1 下列术语中哪一个是ISTQB术语表中缺陷(Defect)的同义词:B

a)Incident    b)Bug   c)Mistake   d)Error

2.2 软件测试目的可以是:B

A.发现缺陷

B.确认软件能够正常运行

C.预防缺陷

D.直接提高产品的售价

E.减少整个产品开发周期时间

a)A, B   b)A, B, C   c)A, B, C 和 D   d)所有选项

2.3 根据ISTQB 定义的术语, “风险”是与下列哪一个选项关联的?C

a)对测试者否定的反馈意见   b)将产生负面影响及其连锁效应的因素

c)可能产生负面影响及其连锁效应的因素   d)将对被测对象产生负面影响及其连锁效应的因素

2.4 确认系统是否按照预期工作,从而在系统是否满足系统需求方面获取信心。这样的测试目的最可能适用下面的哪个测试阶段:C

a)组件测试   b)集成测试   c)系统测试   d)回归测试

2.5 识别测试的任务、定义测试的目标以及为实现测试目标和任务的测试活动规格说明。上述行为主要发生在: A

a)计划和控制   b)分析和设计   c)实现和执行   d)测试结束活动

2.6 ISTQB术语中的回归测试的目的是:C

a)验证修改的成功   b)预防功能编写的不完善或疏漏

c)确保修正过程中没有引入新的缺陷   d)帮助程序员更好地进行单元测试

2.7 下列方式可以提高和改善测试人员和开发人员关系的是:B

a)理解项目经理工作的重要性   b)对所发现的可能的缺陷以一种中立的方式进行沟通

c)单元测试、集成测试和系统测试都由同一批测试人员来完成   d)测试人员参加代码调试

2.8 基本的测试过程主要由下面哪些活动组成:D

A.计划和控制(control)

B.分析和设计

C.实现和执行

D.评估出口准则和测试报告

E.测试结束活动

a)A, B 和 C   b)A, B, C 和 D   c)除 E 以外所有选项   d)所有选项

2.9 对实现软件测试组的独立的方式,可以采用的是:B

A.测试的设计由开发队伍的其他开发人员完成;

B.测试的设计由开发人员自己完成;

C.测试的设计独立于本项目的开发队伍;

D.测试的设计独立于本开发企业,来自于独立的第三方测试机构。

E.所有测试活动由开发人员来完成

a)A, B, C   b)A, B, C, D   c)A, C, E   d)所有选项

2.10 以下关于测试原则的描述,正确的是: B

a)所有的软件测试不需要追溯到用户需求;

b)完全测试是不可能的;

c)测试可以显示软件潜在的缺陷;

d)程序员不需要避免检查自己的程序。

2.11 软件测试工作应该开始于:B

a)Coding之后;   b)需求分析阶段;   c)概要设计阶段;  d)详细设计阶段。

2.12 作为一个软件测试员,应具备哪些能力?D

A.具有好奇心;

B.职业悲观心态;

C.批评的眼光;

D.关注系统的细节的能力

E.测试技能;

F.良好的沟通能力

a)A+B+C ;   b)D+E+F ;   c)E+F;   d)以上都是。

2.13 以下可能导致缺陷的原因有:D

A.环境因素;(可能导致失效)

B.开发技术;

C.过程管理规范性;

D.个人能力

E.软件的复杂性;

F.开发的周期长短

a)以上都是;   b)以上都不是;   c)A+B+C;   d)D+E+F。

2.14 关于软件质量保证和软件测试的描述,不正确的是 D

a)软件质量保证和软件测试是软件质量工程的两个不同层面的工作;

b)在软件质量保证的活动中也有一些测试活动;

c)软件测试是保证软件质量的一个重要环节;

d)软件测试人员就是软件质量保证人员。

2.15 关于测试充分性的描述,正确的是:B

a)只有进行完全的测试才充分;

b)在有限的时间和资源条件下,找出所有的软件的错误,使软件趋于完美,是不可能的;

c)当继续测试没有发现新缺陷时;

d)当全部测试用例都执行完后。

2.16 以下关于测试目的的观点,不正确的是:B

a)软件测试的目的是寻找错误,并且尽最大的可能找出最多的错误;

b)找出软件开发人员的问题并评价开发人员能力;

c)一个成功的测试是发现了至今未发现的错误的测试;

d)测试的目的,是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷,通过修正各种错误和缺陷提高软件质量,避免软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。

2.17 以下关于测试作用的描述,不正确的是:B

a)测试无法显示软件潜在的缺陷;

b)测试能保证软件的缺陷和错误全部找到;

c)测试只能证明软件存在错误而不能证明软件没有错误;

d)所有的软件测试都应追溯到用户需求。

第二章:软件生命周期中的测试(15%)

1、学习目标
1.1 软件开发模型 (K2)

① 明白在开发生命周期中的软件开发、测试活动和工作产品之间的相互关系,并根据项目和产品的特征以及它们的背景提供相应的例子(K2)。

●V-模型

② 知道必须根据项目背景和产品特征来选择软件开发的模型(K1)。

●原型开发、快速应用开发(RAD)、统一软件开发过程(RUP)和敏捷开发模型

③ 理解在软件测试中采用不同测试级别的原因,以及在任何生命周期模型中一个良好的 测试应该具备的特征(K1)。

●每个开发活动都有相对应的测试活动;

●每个测试级别都有其特有的测试目标;

●对于每个测试级别,需要在相应的开发活动过程中进行相应的测试分析和设计;

●在开发生命周期中,测试员在文档初稿阶段就应该参与文档的评审。

1.2 测试级别(K2)

① 比较不同测试级别之间的区别:测试的主要目的、典型的测试对象、典型的测试目标 (功能性的或结构性的)、相关的工作产品、测试的人员、识别缺陷和失效的种类(K2)。

●单元测试

●测试依据:1.组件需求说明;2.详细设计文档;3.代码。

●典型测试对象:1.组件;2. 程序;3. 数据转换/移植程序;4. 数据库模型。

●组件测试可能包括功能测试和特定的非功能特征测试。

●集成测试/系统测试/验收测试(用户验收测试、操作(验收)测试、合同和法规性验收测试、Alpha和Beta(或现场)测试)

1.3 测试类型(K2)

① 通过举例比较四种不同的软件测试类型(功能测试、非功能测试、结构测试和与变更 相关的测试)(K2)。

② 明白功能测试和结构测试可以应用在任何测试级别(K1)。

●功能测试主要是考虑软件的外部表现行为(黑盒测试)。

③ 根据非功能需求来识别和描述非功能测试的类型。(K2)。

●非功能性测试就是测试系统运行的表现如何。术语“非功能测试”是指:为了测量系统和软件的特征,需要进行的测试。非功能测试关注的是软件的外部行为表现,通常采用黑盒测试设计技术来实现测试用例。

④ 根据对软件系统结构或构架的分析来识别和描述测试的类型(K2)。

●可以在任何测试级别上进行结构测试(白盒测试)。

●结构测试技术最好在进行基于规格说明的测试之后使用,以便通过评估结构类型的覆盖来测量测试的完整性。

●结构测试方法也同样可以运用到系统、系统集成或验收测试级别(比如业务模型或菜单结构)。

⑤ 描述确认测试和回归测试的目的(K2)。

●确认测试和回归测试应该可以重复进行。将回归测试自动化是很好的选择。

1.4 维护测试 (K2)

① 比较维护测试(一个现存系统的测试)与一个新的应用软件的测试在测试类型、测试 的触发和测试规模等方面的区别(K2)。

●一旦对软件或系统进行修改、移植或退役处理时,就需要进行维护测试。

② 识别维护测试的原因(由于修改、移植或退役等因素)(K1)。

●修改可以是计划中的功能增加。为移植(如从一个平台移植到另外一个平台)。为系统退役而进行的维护测试应该包括数据移植测试。

③ 描述回归测试和变更的影响度分析在软件维护中的作用(K2)。

●维护测试的范围取决于变更的风险、现有系统的规模和变更的大小。确定变更如何影响现有系统的过程,称之为影响分析,它有助于决定实施回归测试的广度和深度。

2、练习题

2.1 可维护性测试属于:D

a)非功能测试   b)功能测试   c)结构测试   d)确认和回归测试

2.2 有一个系统已经在市场上运行了,这种情况对系统进行修改,然后进行的测试: A

a)维护测试   b)验收测试   c)组件测试   d)系统测试

2.3 下面哪些是一个好的测试的特点:C

A.每个开发活动都有相对应的测试行为

B.每个测试级别都有其特有的测试目标

C.对于每个测试级别,需要在相应的开发活动过程中进行相应的测试分析和设计

D.软件测试的工作重点应该集中在系统测试上

a)C,D   b)A,B   c)A,B,C   d)A,B,C,D

2.4 下面可以作为组件测试的测试对象的是:A

a)模块、对象和类   b)程序中的某个子系统   c)整个软件系统   d)模块间的接口

2.5 组件测试的用例设计主要参考的工作产品是:A

a)组件规格说明   b)系统需求规格说明   c)用户手册   d)代码

2.6 下面关于回归测试叙述正确的是: D

a)回归测试只能在系统测试这个级别进行,不能用于单元测试和集成测试

b)回归测试只适用于功能测试,不适用于非功能测试

c)回归测试都是自动化执行的

d)回归测试是对已被测过的程序实体在修改缺陷后进行的重复测试,以此来确认在这些变更后是否有新的缺陷引入系统

2.7 语句的覆盖率主要在下面哪个测试级别的测试设计中考虑:C

a)系统测试   b)集成测试  c)组件测试   d)验收测试

2.8 传统的或面向对象的单元测试,需要的开发工作:D

a)只要开发测试stub;

b)只要开发测试driver;

c)可能要同时开发一个stub和多个driver;

d)可能要同时开发一个driver和多个stub。(一个入口,多个输出)

2.9 目前大部分的软件错误来源于____。D

a)程序错误;   b)分析和设计错误;   c)测试本身的错误;   d)需求错误。

第三章:静态技术(7%)

1、学习目标
1.1 静态技术和测试过程(K2)

① 了解可以通过不同的静态技术来检查并确认软件工作产品的质量(K1)。

●静态测试技术通过手工检查(评审)或自动化分析(静态分析)的方式对代码或者其他的项目文档进行检查而不需要执行代码。

② 描述了在评估软件工作产品中运用静态技术的重要性和它的价值(K2)。

③ 解释静态技术和动态技术之间的区别(K2)。

●与动态测试相比,静态技术发现的是软件失效的原因(缺陷)而不是失效本身。

④ 描述静态分析和评审的目标,并且和动态测试进行对比(K2)。

●评审、静态分析和动态测试具有共同的目标:识别缺陷。

●软件评审的主要好处有:尽早发现和修改缺陷、改善开发能力、缩短开发时间、缩减测试成本和时间、减少产品生命周期成本、减少缺陷以及改善沟通等

1.2 评审过程(K2)

① 理解典型的正式评审过程中的阶段、角色和职责定义(K1)。

●计划阶段

●预备会阶段

●个人准备阶段

●检查/评价/记录结果(评审会议阶段)

●返回阶段

●跟踪结果阶段

② 解释不同类型评审的区别:非正式评审(informal review)、技术评审(technical review)、走查(walkthrough)和审查(inspection)(K2)。

●非正式评审 主要目的:以较低的成本获得收益。

●走查 主要目的:学习、增加理解、发现缺陷。

●技术评审 主要目的:讨论、作决策、评估候选方案、发现缺陷、解决技术问题、检查与规格及标准的符合程度。

③ 解释影响评审成功的主要因素(K2)。

●每次评审都有预先明确定义的目标;

●针对评审目标,有合适的评审人员的参与; 测试人员参加评审不但有利于提高评审质量,还可以通过评审了解产品,为测试尽早开始做准备;

●对发现的缺陷持欢迎态度,并客观地描述缺陷;

●能够正确处理人员之间的问题以及心理方面的问题;

●评审应该在一种信任的气氛中进行;并且结果不应用于对参与者的评价;

●采用的评审技术适合于要达到的目标、软件工作产品的类型和级别以及参与评审的人员;

●选用合适的检查表或定义合适角色,可以提高缺陷识别的有效性;

●提供评审技术方面的培训,特别是针对正式的评审技术,比如审查;

●管理层对良好评审过程的支持;

●强调学习和过程的改进。

1.3 静态分析的工具支持(K2)

① 理解通过静态分析能够识别的典型缺陷和错误,并与评审和动态测试之间进行比 较(K1)。

●静态分析的执行并不需要使用工具去实际运行被测软件。

●动态测试是真正运行软件的代码。静态分析可以定位那些在测试过程很难发现的缺陷。与评审一样,静态分析通常发现的是缺陷而不是失效。

② 列出静态分析的典型优点(K1)。

●在测试执行之前尽早发现缺陷;

●通过度量的计算(比如高复杂性测量),早期警示代码和设计可能存在问题的方面;

●可以发现在动态测试过程不容易发现的一些缺陷;

●可以发现软件模块之间的相互依赖性和不一致性,例如链接;

●改进代码和设计的可维护性;

●在开发过程中学习经验教训,从而预防缺陷。

③ 列出通过静态分析工具识别的典型的代码缺陷和设计缺陷(K1)。

●引用一个没有定义值的变量;

●模块和组件之间接口不一致;从未使用的变量;

●不可达代码或死代码;逻辑上的遗漏与错误(潜在的无限循环);

●过于复杂的结构;违背编程规则;

●安全漏洞;

●代码和软件模型的语法错误。

2、练习题

2.1 多出口函数可能会发生__B____问题

a)产生逻辑错误   b)降低可靠性   c)产生内存泄漏   d)降低运行性能

2.2 使用静态测试中的函数调用关系图不能够C

a)检查函数的调用关系是否正确

b)发现是否存在孤立函数

c)明确函数被调用频度,并对这些函数进行重点检查

d)发现函数内部结构

2.3 下面对静态测试和动态测试的区别描述正确的是:A

a)静态测试并没有真正的运行软件,而动态测试需要运行软件

b)静态测试需要借助于专门的测试工具,而动态测试不需要

c)静态测试是由开发人员执行的,而动态测试是由专门的测试人员完成

d)静态测试是主要是为了增加测试人员对软件的理解,而动态测试是为了发现缺陷

2.4 下面那个不属于静态分析:D

a)编码规则的检查   b)程序结构分析   c)程序复杂度分析   d)内存泄漏

2.5 技术评审的目的是:D

a)保证软件在独立的模式下进行开发

b)发现软件业务错误

c)与项目管理无关

d)确认软件符合预先定义的开发规范和标准

第四章:测试设计技术(30%)

1、学习目标
1.1 测试开发过程(K3)

① 区别:测试设计规格说明(test design specification)、测试用例规格说明(test case specification)和测试规程规格说明(test procedure specification) (K2)。

② 比较术语:测试条件、测试用例和测试规程(test procedure)(K2)。

③ 评估测试用例的质量(K3),它们是否满足:

●显示明确的与需求的可追溯性(traceability);

●包含预期的结果。

④ 根据测试人员的理解水平,将测试用例转换为不同详细程度的结构合理的测试规 程规格说明(K3)。

1.2 测试设计技术的种类(K2)

① 复述在测试用例设计中,为什么需要采用基于规格说明的测试(黒盒测试)和基 于结构的测试(白盒测试)的方法?列举出各自比较常用的技术(K1)。

●黑盒测试,顾名思义,不需要使用任何关于被测组件或系统的内部结构信息。

●白盒测试设计技术(也称为结构化或基于结构的测试技术)是基于分析被测组件或系统的结构的测试技术。

② 解释基于规格说明的测试、基于结构的测试和基于经验的测试三者的特征和区别 (K2)。

●基于规格说明的测试技术具有以下共同特点:

  • 使用正式或非正式的模型来描述需要解决的问题、软件或其组件等;
  • 根据这些模型,可以系统地导出测试用例。

●基于结构的技术的共同特点:

  • 根据软件的结构信息设计测试用例,比如软件代码和详细设计信息;
  • 可以通过已有的测试用例测量软件的测试覆盖率,并通过系统化的导出设计用例来提高覆盖率。

●基于经验的方法具有以下共同特点:

  • 测试用例根据参与人员的经验和知识来编写;
  • 测试人员、开发人员、用户和其他的利益相关者对软件、软件使用和环境等方面所掌握的知识作为信息来源之一;
  • 对可能存在的缺陷及其分布情况的了解作为另一个信息来源。
1.3 基于规格说明的或黒盒测试技术(K3)

① 使用下列测试设计技术,对指定的软件模块编写测试用例:(K3)

●等价类划分(equivalence partitioning);

●边界值分析(boundary value analysis);

●决策表测试(decision table testing);

●状态转换测试(state transition testingm);

② 理解这四种测试设计技术各自的主要目的,这些技术可以应用于什么测试级别和 测试类型,以及如何测量测试覆盖(test coverage)(K2)。

③ 理解用例测试(use case testing)的概念和应用这种技术的优点(K2)。

●每个用例都有测试的前置条件,这是用例成功执行的必要条件

●每个用例结束后都存在后置条件,这是在用例执行完成后能观察到的结果和系统的结束状态。

●用例通常有一个主场景(即最有可能发生的场景)和可选场景。

1.4 基于结构的技术或白盒技术(K3)

① 描述代码覆盖(code coverage)的概念及其重要性(K2)。

② 解释语句覆盖(statement coverage)和判定覆盖(decision coverage)等概念, 理解这些概念除了可以应用在组件测试(component testing)外,还可以应用在其 他任何测试级别上(比如系统级别上的业务过程测试)(K2)。

●判定覆盖,和分支测试相关,是指评价在一个测试用例套中已经执行的判定(例如if语句的true和false选项)输出的百分比。

③ 根据给定的控制流,使用下面的测试设计技术设计测试用例(K3):

●语句测试;

●判定测试;

④ 评估语句覆盖和判定覆盖的完整性(K3)。

●覆盖的概念也可以用于其他的测试级别(比如集成测试级别等),在一个测试用例套件中被执行的模块、组件或类覆盖的百分比可以分别称为模块覆盖、组件覆盖或类的覆盖。

1.5 基于经验的技术(K2)

① 复述在哪些情况下使用基于直觉、基于经验和知识、基于对常见缺陷的认识来编 写测试用例(K1)。

●错误推测法

●探索性测试

② 比较基于经验的方法和基于规格说明的方法之间的区别(K2)。

1.6 选择测试技术(K2)

① 针对不同类型的问题选择不同的测试用例设计技术,列举出会影响设计技术选择 的因素,比如系统的类型、风险、客户

2、练习题

2.1 关于边界值的说法不正确的是: D

a)边界值分析是一种补充等价划分的测试用例技术

b)它不是选择等价类的任意元素,而是选择等价类边界的测试用例

c)程序在处理大量中间数值时都是对的,但是在边界处极可能出现错误

d)边界值分析法考虑了输入变量之间的依赖关系

2.2 对于测试错误的说法是:B

a)测试的设计可以用80-20规则作为指导。

b)测试后程序中残存的错误数目与该程序中已发现的错误数目成正比

c)应该在测试工作真正开始前的较长时间内进行测试计划

d)测试的效果由测试用例的多少及规定的覆盖指标确定

2.3 根据测试章程中包含的测试目标,同时进行测试设计、测试执行的是: A

a)探索性测试   b)错误推测   c)白盒测试   d)黑盒测试

2.4 下面哪个属于静态分析:D

A.编码规则的检查

B.程序结构分析

C.程序复杂度分析

D.内存泄漏

a)除C以外   b)除A和C以外   c)除C和D以外   d)除D以外

2.5 如果程序的功能说明中含有输入条件的组合情况,则一开始就可以选用__B__和判定表法。

a)等价类划分法   b)因果图法   c)正交试验法   d)场景法

2.6 通常情况下基本功能测试和性能测试的执行顺序是:C

a)基本功能的测试和性能测试同时进行

b)先执行性能测试,然后再进行基本功能的测试

c)先进行基本功能的测试,然后再执行性能测试

d)基本功能测试和性能测试哪个先执行都无所谓

2.7 如果一个4变量函数,使除一个以外的所有变量取正常值,使剩余变量取最小值、略高于最小值、正常值、略低于最大值和最大值,对每个变量都重复进行。这样,对于一个4变量函数,边界值分析产生的测试用例数为:B

a)15   b)17   c)18   d)20

2.8 一个参数的取值范围是正整数,那么这个参数的有效边界值的数目是: A

a)一个   b)二个   c)三个   d)四个

2.9 某个程序有三个输入参数A,B和C,输入参数的有效条件是A<B 和 C>B,如果应用等价类划分的技术,可以生成的等价类有:

A、A>=B,C>=B   B、A<B,C<=B

C、A<=B,C>B     D、A<B,C>B

a)A,C   b)A,B,C   c)C,D  d)A,B,C,D

2.10 判定覆盖和语句覆盖之间的比较:A

a)100%的判定覆盖可以保证100%的语句覆盖,反之则不行

b)100%的语句覆盖可以保证100%的判定覆盖,反之则不行

c)100%的语句覆盖可以保证100%的判定覆盖,反之亦然

d)100%的语句覆盖和100%的判定覆盖之间没有直接的联系

2.11 在规格说明不完全的情况,最适合采用的测试技术是:B

a)基于结构的测试技术(白盒测试)

b)基于经验的测试技术

c)基于规格说明的测试技术

d)以上都适合

2.12 什么是等价类划分C

A.将测试对象的输入或输出域划分成若干部分

B.从每一个子集中选取少数具有代表性的数据

C.是一种白盒测试方法

D.有效值的等价类

E.无效值的等价类

a)A,B,C,D   b)A,B,C   c)A,B,D,E   d)D,E

2.13 描述黑盒测试和白盒测试过程的不同:A

A.黑盒测试在测试对象的表面进行

B.白盒测试是在源代码已知的情况下进行

C.黑盒测试用例是通过测试对象的使用说明或需求设计

D.黑盒测试包括语句覆盖和分支覆盖方法

E.白盒测试是通过因果图的分析方法进行的

a)A,B,C   b)A,C   c)A,B,C,D,E   d)D,E

2.14 状态转换测试用例设计的完全定义内容:C

A.测试对象的初始化状态

B.测试对象的输入

C.预期结果或预期的行为

D.预期的最终状态

a)A,B,C   b)A,C   c)A,B,C,D   d)C,D

2.15 根据黑盒测试方法可以设计变量0 <= X <= 100的测试用例:C

a)0,20,100   b)20,50,100   c)-1,0,1,50,99,100,101   d)-100,30,100,200

2.16 根据以下流程图设计语句覆盖的测试用例:D

a)测试用例a=5,c=7;a=10,c=12

b)测试用例a=11,c=6;a=0,c=2

c)测试用例a=9,c=11;a=15, c=11

d)测试用例a=5,c=7;a=11,c=6

2.17 请根据条件(x>3,y<5)设计条件组合覆盖测试用例:A

A.x=6,y=3

B.x=6,y=8

C.x=2,y=3

D.x=2,y=8

a)A,B,C,D   b)A,B,C   c)A,B,D   d)C,D

2.18 黑盒测试技术包括C

a)边界值分析、判定表、等价类划分、经验法

b)判定覆盖、语句覆盖、用例分析

c)边界值分析、等价类划分、因果图分析、随机法

d)判定表技术、路径覆盖、条件覆盖

2.19 语句覆盖和判定覆盖有什么不同 D

A.语句覆盖程序中每一个判断至少要执行一次

B.判定覆盖程序中每个判断的取真分支和取假分支至少经历一次。

C.判定覆盖程序中各种组合至少执行一次

D.语句覆盖是指程序中每一条语句至少被执行一次

a)A,C   b)A,B   c)C,D   d)B,D

第五章:测试管理(20%)

1、学习目标
1.1 测试的组织结构(K2)

① 认识独立测试的重要性(K1)。

●通过独立的测试员进行测试和评审,发现缺陷的效率会提高。

② 列出在组织内进行独立测试的优点和缺点(K2)。

独立测试的优点:

●独立的测试员是公正的,可以发现一些其他不同的缺陷。;

●一个独立的测试员可以验证在系统规格说明和实现阶段所做的一些假设。

独立测试的缺点:

●与开发小组脱离(如果完全独立);

●开发人员可能丧失对软件质量的责任感;

●独立的测试员可能被视为瓶颈或者成为延时发布而被责备的对象。

③ 考虑使用不同团队的成员来成立测试小组(K1)。

④ 了解测试领导人(test leader)和测试员的任务(K1)。

1.2 测试计划和估算(K2)

① 认识测试计划的不同级别和目标(K1)。

② 根据“软件测试文档标准(IEEE 829)” 总结《测试计划》、《测试设计规格说明》 和《测试规程》的目的及内容(K2)。

③ 区分属于二类不同概念(预防型Preventative 和应对型Reactive)的各种测试 方法,如基于分析、基于模型、基于方法、符合过程/标准的、动态/启发式的、 咨询式或基于面向可重用的方法(K2)。

入口准则主要包含:●测试环境已经准备就绪并可用;●测试工具在测试环境中已经准备就绪;●可测的代码可用;●测试数据可用。

出口准则主要包含:●完整性测量,比如代码、功能或风险的覆盖率;●对缺陷密度或可靠性度量的估算;●成本;● 遗留风险,例如没有被修改的缺陷或在某些部分测试覆盖不足;●进度表,例如基于交付到市场的时间。

④ 区分为系统而做测试计划和为安排测试执行做测试计划的内容上的不同之处 (K2)。

⑤ 在综合考虑优先级、技术和逻辑依赖后,为给定的测试用例集编写测试执行计划 (K3)。

⑥ 列出在测试计划时应该考虑的测试准备和执行活动(K1)。

⑦ 认识影响测试开销的主要因素(K1)。

⑧ 从概念上区别两种不同的估算方法:基于度量的方法和基于专家的方法(K2)。

⑨ 理解/解释针对特定测试级别和测试用例组所定义的恰当的出口准则(例如对于集 成测试、验收测试或可用性测试的测试用例)(K2)。

1.3 测试进度监控(K2)

① 认识用于监督测试准备和执行的常见度量项(K1)。

常用的测试度量项有:

●测试用例准备工作完成的百分比(或按计划已编写的测试用例的百分比);

●测试环境准备工作完成的百分比;

●测试用例执行情况(例如:执行/没有执行的测试用例数,通过/失败的测试用例数);

●缺陷信息(例如:缺陷密度、发现并修改的缺陷、失效率、重新测试的结果);

●需求、风险或代码的测试覆盖率;

●测试员对产品的主观信心;

●测试里程碑的日期;

●测试成本,包括寻找下一个缺陷或执行下一轮测试所需成本与收益的比较。

② 理解和解释针对测试报告和测试控制的测试度量(例如已发现和已修复的缺陷、已通过或失败的测试)(K2)。

③ 根据“软件测试文档标准(IEEE 829)”总结测试报告的目的和内容(K2)。

1.4 配置管理(K2)

① 总结配置管理如何支持测试(K2)。

●配置管理可以帮助他们唯一地标识(并且复制)测试项、测试文档、测试用例和测试用具。

1.5 风险和测试(K2)

① 将可能会威胁一个或多个利益相关者实现项目目标的可能问题描述为风险(K2)。

② 知道风险是由可能性(发生的可能性)和影响力(发生后所造成的危害)来决定 的(K1)。

③ 区别项目风险和产品风险(K2)。

●项目风险是围绕项目按目标交付的能力的一系列风险。在软件或系统中的潜在失效部分(即将来可能发生不利事件或危险)称之为产品风险

④ 了解典型的产品风险和项目风险(K1)。

⑤ 通过例子来描述在测试计划中如何进行风险分析和风险管理(K2)。

1.6 事件管理(K3)

① 按照“软件测试文档标准(IEEE 829)”认识事件报告的内容(K1)。

② 针对测试过程中发现的失效编写事件报告(K3)。

事件报告的主要目标如下:

●为开发人员和其他人员提供问题反馈,在需要的时候可以进行识别、隔离和纠正;

●为测试组长提供一种有效跟踪被测系统质量和测试进度的方法;

●为测试过程改进提供资料。

事件报告的具体内容主要包括:

●提交事件的时间,提交的组织和作者;

●预期和实际的结果;

●识别测试项(配置项)和环境;

●发现事件时软件或系统所处的生命周期阶段;

●为了能确保重现和解决事件需要描述事件(包括日志、数据库备份或截屏);

●对利益相关者的影响范围和程度;

●对系统影响的严重程度;

●修复的紧迫性/优先级;

●事件状态(例如:打开的、延期的、重复的、待修复的、修复后待重测的或关闭的等);

●结论、建议和批准;

●全局的影响,比如事件引起的变更可能会对系统的其他部分产生影响;

●变更历史记录,比如针对事件的隔离、修改和已修改的确认,项目组成员所采取的行动顺序;

●参考,包括发现问题所用的测试用例规格说明的标识号。

2、练习题

2.1 测试计划主要由哪个角色负责制定:D

a)测试人员   b)项目经理   c)开发人员   d)测试经理

2.2 对于监控测试周期时采用的度量方法,下列叙述中不当的是: c

a)基于故障和基于失效的度量:统计特定软件版本中的故障数。

b)基于测试用例的度量:统计各优先级的测试用例数量。

c)基于测试对象的度量:统计代码和安装平台等覆盖情况。

d)基于成本的度量:统计已经花费的测试成本,下一测试周期的成本与预期收益的关系。

2.3 通常情况下,承担测试监控任务的人员是: A

a)测试系统管理员   b)测试经理  c)测试执行人员   d)测试设计人员

2.4 下列哪个是测试组独立的缺点?c

a)测试人员需要额外的培训

b)测试人员需要花时间了解所要测试的产品的需要、架构、代码等

c)开发人员可能会失去对产品质量的责任心

d)设立独立测试组会花费更多成本

2.5 如果没有做好配置管理工作,那么可能会导致:d

a)开发人员相互篡改各自编写的代码

b)集成工作难以开展

c)问题分析和故障修正工作被复杂化

d)测试评估工作受阻

2.6 对于测试过程来说,哪些工作产品要纳入配置管理?A

a)测试对象(The test object)、测试材料(the test material)和测试环境

b)问题报告和测试材料

c)测试对象

d)测试对象和测试材料

2.7 下面有关基于风险的方法的描述哪个是不正确的?C

a)识别的风险经常用于决定哪些需要更多测试,哪些可以减少测试

b)识别的风险经常用于决定多少测试服务

c)识别的风险经常用于决定使用何种测试工具

d)识别的风险经常用于决定使用何种测试技术

2.8 下列活动中,不属于测试计划活动的是:A

a)设计测试用例   b)确定测试环境   c)定义测试级别   d)估算测试成本

2.9 事件报告中可能包括的错误有:D

A.程序错误

B.规格说明中的错误

C.用户手册中的错误

a)A   b)A、C   c)B、C   d)A、B、C

2.10 下列风险中,属于产品风险的是:B

a)软件需求不明确

b)由于使用软件产品而导致人员伤亡

c)软件测试人员和软件开发人员沟通不畅

d)软件源代码质量低下

2.11 软件测试团队的组织一般可分为:___A___和基于项目的组织模式。

a)基于测试的组织模式;

b)基于技能的组织模式;

c)基于团队的组织模式;

d)基于软件的组织模式。

2.12 测试报告不包含的内容有:D

a)测试时间、人员、产品、版本;

b)测试环境配置;

c)测试结果统计;

d)测试通过/失败的标准。

2.13 测试人员(Tester)在软件配置管理中工作主要是:A

a)根据配置管理计划和相关规定,提交测试配置项和测试基线;

b)建立配置管理系统;

c)提供测试的配置审计报告;

d)建立基线。

2.14 测试经理的任务通常不包括: C

a)编写测试计划

b)选择合适的测试策略和方法

c)建立和维护测试环境

d)选择和引入合适的测试工具

第六章:软件测试工具(10%)

1、学习目标
1.1 测试工具的类型(K2)

① 根据测试过程活动,对不同类型的测试工具进行分类(K2)。

② 了解能够帮助开发者进行测试的工具(K1)。

1.2 有效使用工具:潜在的利益和风险(K2)

① 总结测试自动化和使用测试工具的潜在利益和风险(K2)。

使用工具的潜在收益包括:

●减少重复性的工作;

●更好的一致性和可重复性;

●客观的评;

●容易得到测试和测试的相关信息。

使用工具存在的风险:

●对工具抱有不切实际的期望(包括功能性和易用性);

●低估首次引入工具所需的时间、成本和工作量;

●低估从工具中获得较大和持续性收益需要付出的时间和工作量;

●低估了对工具生成的结果进行维护所需的工作量;

●对工具过分依赖;●忽视了在工具中对测试对象的版本控制;

●忽视了多个重要工具之间的关联和互操作性;

●工具供应商破产、 停止维护工具或将工具卖给其他供应商的风险;

●供应商对工具的支持、 升级和缺陷修复反应不力;

●开源/免费工具项目中止的风险;

●其他不可预知的风险,例如不能支持新平台。

② 了解测试执行工具可以有包括数据驱动和关键字驱动的不同脚本技术(K1)。

●数据驱动的方法是将测试输入(数据) 与测试用例分离,并将测试输入存放在一个电子表格中,这样可以使用不同的数据进行相同的测试。

1.3 组织中工具的引入(K1)

① 阐述将工具引入组织中的主要步骤(K1)。

② 阐述为评估工具所进行的学习调查/试点项目阶段的目的(K1)。

●对工具有更多的认识;

●评估工具与现有的过程以及实践的配合程度,确定哪些方面需要作修改;

●定义一套标准的方法来使用、管理、储存 和维护工具及测试资产;

●评估在付出合理的成本后能否得到预期的收益。

③ 了解要获得好的工具支持,仅靠购置工具是不够的,还需要考虑其他因素(K1)

●逐步在组织的其余部分将工具推广到测试中;

●调整并改进过程来配合工具的使用;

●为新使用者提供培训和指导;

●定义使用指南;

●实施一种在实际运用中收集工具使用情况的方法;

●监控工具的使用和收益情况;

●为测试团队使用工具提供支持;

●在所有团队内收集经验和教训。

2、练习题

2.1 测试管理工具可能包括的功能:D

A.管理软件需求   B.管理测试计划   C.缺陷跟踪   D.测试过程中各类数据的统计和汇总

2.2 下列关于自动化测试工具的说法中,错误的是 D

a)录制/回放可能是不足够的,还需要进行脚本编程

b)既可用于功能测试,也可用于非功能测试

c)自动化测试工具适用于回归测试

d)自动化测试关键的时候能代替手工测试

2.3 测试用具(test harness)主要可用于D

a)组件测试、集成测试

b)集成测试、系统测试

c)组件测试、部分系统测试

d)组件测试、集成测试、部分系统测试

2.4 下列关于工具使用风险的说法中,不恰当的是:A

a)工具能够或多或少提高测试效率

b)没有好的测试过程或成熟的测试方法,工具并不能像预期的那样降低成本

c)与手工测试相比较,使用自动化工具也可能会增加测试成本

d)培训和指导有助于降低工具使用的风险

2.5 在下列测试类型中,不适合采用手工测试的是b

a)安全测试   b)负载测试   c)集成测试   d)再测试

最新文章

  1. iOS 视图:重绘与UIScrollView(内容根据iOS编程编写)
  2. Yocto开发笔记之《快速入门,环境搭建 &amp; 编译》(QQ交流群:519230208)
  3. JavaScript原型链问题
  4. Java开发高薪之路__大纲篇
  5. await和async关键字来写异步程序
  6. javascript笔记——前端实现分页和查询
  7. 方法的可变长参数 传入参数个数不确定可用(Type ... values)
  8. OD: Windows Driver Fuzz
  9. go:挂webserver
  10. 杂谈--DML触发器学习
  11. root cause org.apache.ibatis.ognl.OgnlException: source is null for getProperty(null, &quot;XXX&quot;)
  12. Python replace()方法
  13. lua tonumber
  14. git 提交的步骤
  15. CF739E Gosha is hunting
  16. HTTP之Content-Type
  17. ubuntu安装git
  18. vue 自学笔记(三) 计算属性与侦听器
  19. Ansible安装 入门教程
  20. [No0000109]Git2/9-安装Git

热门文章

  1. [Unity]关于Unity中的触摸类Input.Touch以及简单的虚拟摇杆实现
  2. 数据类型之字符串(string)(二)
  3. golang运算符
  4. Java密码加密的两种保存方式
  5. Web学习篇—Http协议
  6. 堆QAQ
  7. 2022-6,flask+vue+uwsgi+nginx,线上部署完整流程打包配置文件
  8. python函数传参是传值还是指针
  9. 开启wamp依旧使用已下载的mysql
  10. 代码格式 linux