软件测试复习

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

第一章

1.软件测试伴随着软件开发,以检查每一个阶段性的成果是否符合质量要求和达到预先定义的目标,尽可能早的发现错误并及时改正。

2.软件测试的正确意义就是:软件测试是由“验证”和“有效性确认”活动构成的整体。“验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。

“有效性检验”是确认所开发的软件是否满足用户真正需求的活动。

3.在V模型中,左边是软件的定义和实现(包括分析、设计和编程),右边是验证(即测试)。如图:

需求分析

和定义验收

测试

系统设计

系统

测试

详细功

能设计

功能

测试

编码

单元

测试

代码验证

功能验证

系统非功能特性

用户验证需求

第二章

1.软件缺陷(Bug)是指计算机系统或者程序中存在的任何一种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷、瑕疵,其结果会导致软件产品在某种程度上不能满足用户的需要。

2.软件缺陷的构成:规格说明书(54%)、设计(25%)、代码(15%)、其他(6%)

2.软件问题发现越早,问题越容易修复,在发布阶段发现所需成本最高。

3.SQA(软件质量保证)与软件测试之间相辅相成,存在包含和交叉的关系。SQA指导、监督软件测试的计划和执行,督促测试工作的结果客观、准确有效,并协助测试流程的改进。

SQA与软件测试的关系:软件测试是SQA的重要手段之一,为SQA提供所需的数据,作为质量评价的客观依据。相同之处在于而这都是贯穿于整个软件开发生命周期的流程。不同之处在于SQA是一项管理工作,侧重于对流程的评审和监控,而测试是一项技术性的工作,侧重对产品的评估和验证。

第三章

1.白盒测试,也称结构测试或逻辑驱动测试,也就是已知产品的内部工作过程。

白盒测试的方法

逻辑覆盖法:

语句覆盖:使程序中的每个可执行语句至少被执行一次。

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

条件覆盖:使每个判断中每个条件的可能取值至少满足一次。(a>0,a<0,b>0,b<0都至少满足一次)。条件覆盖都满足了,也不能保证所有判定覆盖被测试。

判定-条件覆盖:是判定和条件覆盖的交集,设计足够的测试用例,使得判断条件中的所有条件可能取值至少执行一次,同时,所有判断的可能结果至少执行一次。

条件组合覆盖:使得判断中每个条件的所有可能至少出现一次,并且每个判断本身的判定结果也至少出现一次。

路径覆盖:覆盖程序中的所有可能的执行路径。

基本路径测试法:

(1)程序的流程控制图。

(2)计算程序的环路复杂度(可导出程序基本路径集合中的独立路径条数)

环路复杂度=(区域数目)=(边界数目-节点数目+2)=(判断节点数目+1)(3)确定基本路径。

(4)准备测试用例。

2.黑盒测试,也称功能测试或数据驱动测试。把程序看作是一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,测试人员针对软件直接进行测试。

黑盒测试方法

等价类划分法:有效等价类、无效等价类

边界值分析法:边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。如果输入条件定义了数值区间(a,b),那么测试用例应包括a、b、稍微比a大、稍微比b大、稍微比a小和稍微比b小等几种情况. 举个例子,如果a,b是整数, 除在a,b之间取正常点外,a,b,a-1,b-1,a+1,b+1都应被测试。

判定表法:

条件桩:列出问题的所有条件

动作桩:列出可能针对问题所采取的操作。

条件项:针对所列条件的具体赋值。

动作项:可出在条件项(各种取值)组合情况下应该采取的动作。

规则:任何一个条件组合的特定取值及其相应要执行的操作。

判定表制定的一般步骤:

(1)列出所有的条件桩和动作桩

(2)填入条件项

(3)填入动作项,制定初始判定表

(4)简化、合并相似规则或者相同动作

因果图法:是一种形式化的图形语言。利用图解法分析输入的各种组合情况,有时还要依赖所生成的判定表。

场景法:用例场景用来描述流经用例的路径,从用例开始到结束遍历这条路径上所有基本流和备选流。

功能图法:由状态迁移图和逻辑功能表构成

正交实验法、错误推测法

3.静态测试盒动态测试的区别?

根据程序是否运行(被测软件是否被执行),测试可以分为静态测试和动态测试。

静态测试就是静态分析,对模块的源代码进行研读,查找错误或收集一些度量数据,并不需要对代码进行编译和仿真运行。

动态测试是通过真正运行程序发现错误,通过观察代码运行过程,来获取系统行为、变量实时结果、内存、堆栈、线程以及测试覆盖度等各方面的信息,来判断系统是否存在问题,或者通过有效的测试用例,对应的输入输出关系分析被测程序的运行情况,来发现缺陷。第四章

1.W模型由两个V模型组成,分别代表测试与开发过程,图中明确表示出了测试与开发的并行关系。

第五章

1.单元测试是软件测试的最基础。

2.在单元测试中主要采用白盒测试方法,包括对代码的评审、静态分析和结合测试工具进行的动态测试。

3.单元测试的对象可以是软件设计的最小单位——一个具体的函数或一个类的方法,也可以是一个功能模块、组件。

4.单元测试的任务:

(1)单元中所有独立执行路径测试

(2)单元局部数据结构测试

(3)单元接口测试

(4)单元边界条件测试

(5)单元的各条错误处理通路测试

(6)内存分析

5.运行被测试单元,为了隔离单元,根据被测试单元接口,开发相应的驱动程序和桩程序。驱动程序,也称驱动模块,用以模拟被测模块的上级模块,能够调用被测模块。

桩程序,也称桩模块,用以模拟被测模块工作过程中所调用的下层模块。桩模块由被测模块调用,他们一般只进行很少的数据处理,如打印入口和返回,以便检测被测模块与其下级模块的接口。

驱动模块

被测试单元

桩模块1

桩模块2

第七章

1.集成测试的模式:

非渐增式测试模型:先分别测试每个模块,再把所有模块按设计要求放在一起结合成所要的程序,如大棒模式。

渐增式测试模型:把下一个要测试的模块同已经测试好的模块结合起来进行测试,测试完以后再把下一个应该测试的模块结合起来。

2.自顶向下法:从主模块开始,沿着软件的控制层次向下移动,从而逐渐把各个模块结合起来。在组装过程中,可以使用深度优先的策略,或宽度优先的策略。

具体步骤:

(1)对主控模块进行测试,测试时用桩程序代替所有直接附属于主模块的模块

(2)根据选定的结合策略,每次用一个实际模块代替一个桩程序。

(3)在结合下一个模块的同时进行测试

(4)为了保证加入模块没有引进新的错误,可能需要进行回归测试

从第(2)步不断重复进行上述过程,直到完成。

优点:

(1)不需要测试驱动程序;

(2)能够在测试阶段的早期实现并验证系统的主要功能;

(3)能在早期发现上层模块中的接口错误。

缺点:

(1)需要桩程序,要使桩模块能够模拟实际子模块的功能十分困难;

(2)底层验证被推迟;

(3)同时涉及复杂算法,真正输入/输出的模块一般在底层,他们是最容易出问题的模块,到测试和集成的后期才遇到这些模块,一旦发现问题导致过多的回归测试。

3.自底向上法:自顶向上测试从“原子”模块开始集成以进行测试。

具体策略:

相关文档
最新文档