软件测试期末总结.docx
《软件测试期末总结.docx》由会员分享,可在线阅读,更多相关《软件测试期末总结.docx(19页珍藏版)》请在冰豆网上搜索。
软件测试期末总结
软件测试期末总结
第一章
1:
软件缺陷的定义
bug:
描述软件失败的词汇很多,总之都是因软件运行没有达到预期的效果,我们统称为bug
bug定义:
(1)软件未达到产品说明书中已经标明的功能;
(2)软件出现了产品说明书中指明不会出现的错误;
(3)软件未达到产品说明书中虽未指出但应当达到的目标;
(4)软件功能超出了产品说明书中指明的范围;
(5)软件测试人员认为软件难以理解、不易使用,或者最终用户认为该软件使用效果不良。
软件缺陷特征:
“看不到”——软件的特殊性决定了缺陷不易看到
“看到但是抓不到——发现了缺陷,但不易找到问题发生的原因所在
软件缺陷产生原因:
软件产品说明书(需求)56%;设计27%;
编写代码7%;其他10%。
(圆饼图)
2:
IEEE将软件可靠性定义为:
系统在特定环境下,在给定的时间内无故障运行的概率。
3软件测试的定义
在IEEE提出的软件工程标准术语中,软件测试被定义为:
使用人工或自动手段运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果之间的差别。
4:
软件生命周期:
一个软件生命周期包括制定计划、需求分析定义、软件设计、程序编码、软件测试、软件运行、软件维护、软件停用等8个阶段。
5软件测试的对象:
软件测试不只是对程序的测试。
软件测试贯串于软件定义和开发的整个过程。
软件开发过程中所产生的需求规格说明、概要设计规格说明、详细设计规格说明以及源程序都是软件测试的对象。
6:
软件测试的基本问题软件测试应回答4个问题(H):
(1)测试由谁来执行(Who)。
(2)测试什么(What)。
(3)什么时候进行测试(When)。
(4)怎样进行测试(How)。
7:
软件测试的目的
(1)测试是程序的执行过程,目的在于发现错误;不能证明程序不存在错误(除非仅处理有限种情况)。
(2)检查系统是否满足设计要求。
(3)一个好的测试用例在于发现了还未曾发现的错误;一次成功的测试则是发现了错误的测试。
8:
软件测试的周期是“测试->改错->再测试->再改错”这样一个循环过程。
9:
测试停止的依据(标准)第一类标准:
测试超过了预定时间,则停止测试。
第二类标准:
执行了所有的测试用例,但并没有发现故障,则停止测试。
第三类标准:
使用特定的测试用例设计方案作为判断测试停止的基础。
第四类标准:
正面指出停止测试的具体要求,即停止测试的标准可定义为查出某一预订数目的故障。
第五类标准:
根据单位时间内查出故障的数量决定是否停止测试。
10软件开发几种模式及其优缺点
(1)大棒开发法
源于能量爆发创造宇宙,万物都由能量和物质积聚而成的理论,但如果不是遵循某种正确的排列和组合,形成的将不是预先期望的事物。
大棒模式与上述理论一样:
一大堆能量(这里指开发软件所需的人力和物力)放在一起,巨大的能量进行释放,通常的结果可能是产生了优秀的软件产品或成为一堆“废品”(不成功的软件)。
优点:
思路简单,通常可能是开发者的“突发奇想”
1
缺点:
开发过程是非工程化的,随意性大
关于测试:
有的较简单,有的则非常困难
(2)边写边改法采用边写边改法的软件开发通常只是有了比较粗略的想法就开始进行简单的设计、然后进行较长的反复编写、测试与修复这样一个循环的过程。
在认为无法更精细的描述软件产品要求时,就发布产品。
优点:
能够较为迅速的展现成果,适合需要快速制作而且用完就扔的小项目,如示范程序、演示程序等。
缺点:
其编码和测试可能将是长期的循环往复的过程。
(3)瀑布法瀑布模式是将软件生命周期的各项活动,规定为按照固定顺序相连的若干个阶段性工作,形如瀑布流水,最终得到软件产品。
优点:
易于理解;调研开发的阶段性;强调早期计划及需求调查;确定何时能够交付产品及何时进行评审与测试。
缺点:
需求调查分析只进行一次,不能适应需求变化;顺序的开发流程,使得开发中的经验教训不能反馈到该项目的开发中去;不能反映出软件开发过程的反复与迭代性;没有包含任何类型的风险评估;开发中出现的问题直到开发后期才能够显露,因此失去及早纠正的机会。
(4)快速原型法
根据客户需求在较短的时间内解决用户最迫切解决的问题,完成可演示的产品。
这个产品只实现最重要功能,在得到用户的更加明确的需求之后,原型将丢弃。
(5)螺旋模式法螺旋模式是瀑布模式与边写边改演化模式相结合,并加入风险评估所建立的软件开发模式。
主要思想是在开始时不必详细定义所有细节,而是从小开始,定义重要功能,尽量实现,接受客户反馈,进入下一阶段,并重复上述过程,直到获得最终产品。
每一螺旋(开发阶段)包括5个步骤:
①确定目标,选择方案和限制条件。
②对方案风险进行评估,并能解决风险。
③进行本阶段的开发和测试。
④计划下一阶段。
⑤确定进入下阶段的方法。
优点:
严格的全过程风险管理;强调各开发阶段的质量;提供机会评估项目是否有价值继续下去。
11测试执行过程的三个阶段
(1)初测期
——测试主要功能和关键的执行路径,排除主要障碍。
(2)细测期
——依据测试计划和测试大纲、测试用例,逐一测试大大小小的功能、方方面面的特性、性能、用户界面、兼容性、可用性等等;预期可发现大量不同性质、不同严重程度的错误和问题。
(3)回归测试期
——系统已达到稳定,在一轮测试中发现的错误已十分有限;复查已知错误的纠正情况,确认未引发任何新的错误时,终结回归测试。
第二章
1:
软件测试和缺陷修复的代价:
(1)不能修复所有的软件故障
——原因:
①没有足够的时间;②修复的风险太大;③不值得修复;④不算真正的软件缺陷;。
——结论:
关键是要进行正确的判断、合理的取舍,根据商业风险分析决定哪些故障必须修复,哪些故障可以不修复。
(2)软件测试的代价
——工作原则:
就是如何将无边无际的可能性减小到一个可以控制的范围,以及如何针对软件风险做出恰当选择,去粗存精,找到最佳的测试量,使得测试工作量不多也不少,既能达到测试的目的,又能较为经济。
2:
什么是软件测试策略?
——是软件工程为完成测试过程定义的一个模板。
该模板应该提供可以用来检验一小段源代码是否得以正确实现的底层测试,同时也要提供能够验证整个系统功能是否符合用户需求的高层测试。
某种测试策略必须为管理者提供一系列重要的阶段标志(里程碑)。
测试的进度必须是可测量的。
2
3:
静态测试与动态测试
(1)静态测试:
静态测试不实际运行软件,主要是对软件的编程格式、结构等方面进行评估。
静态测试包括代码检查、静态结构分析、代码质量度量等。
它可以由人工进行,也可以借助软件工具自动进行。
静态测试方法也可利用计算机作为对被测程序进行特性分析的工具,但与人工测试方式有着根本区别。
另一方面,因它并不真正运行被测程序,只进行特性分析,这又与动态方法不同。
所以,静态方法常常称为“分析”,静态测试是对被测程序进行特性分析方法的总称。
(2)动态测试
动态测试的主要特征是:
——计算机必须真正运行被测试的程序,通过输入测试用例,对其运行情况即输入与输出的对应关系进行分析,以达到检测的目的。
动态测试包括:
(
(1))功能确认与接口测试
(
(2))覆盖率分析
((3))性能分析
((4))内存分析
4:
按照测试规划的不同出发点,软件测试方法可以分为黑盒测试和白盒测试两大类
基于产品功能的测试,目的是检查程序各个功能是否能够实现,并检查其中的功能错误,这种测试方法称为黑盒测试(Black-boxTesting)方法。
——黑盒测试又称为功能测试、数据驱动测试和基于规格说明的测试。
它是一种从用户观点出发的测试,一般被用来确认软件功能的正确性和可操作性。
基于产品内部结构的测试,目的是检查内部操作是否按规定执行,软件各个部分功能是否得到充分使用,这种测试方法称为白盒测试(White-boxTesting)方法。
——白盒测试又称为结构测试、逻辑驱动测试或基于程序的测试,一般用来分析程序的内部结构5:
软件测试过程流程(图
6:
单元测试针对每个程序的模块,主要测试5个方面的问题:
——模块接口、局部数据结构、边界条件、独立的路径和错误处理。
(图
单元测试的执行过程:
在单元测试时,如果模块不是独立的程序,需要设置一些辅助测试模块。
辅助测试模块有两种:
(1)驱动模块(Drive)用来模拟被测试模块的上一级模块,相当于被测模块的主程序。
它接收数据,将相关数据传送给被测模块,启动被测模块,并打印出相应的结果。
2)桩模块(Stub)用来模拟被测模块工作过程中所调用的模块。
它们一般只进行很少的数据处
理。
驱动模块和桩模块都是额外的开销,虽然在单元测试中必须编写,但并不需要作为最终的产品提供给用户(图)
7:
集成测试
(1)、非增量式测试与增量式测试的比较
非增量式测试的方法是先分散测试,然后集中起来再一次完成集成测试。
假如在模块的接口处存在错误,只会在最后的集成测试时一下子暴露出来。
增量式测试是逐步集成和逐步测试的方法,把可能出现的差错分散暴露出来,便于找出问题和修改。
而且一些模块在逐步集成的测试中,得到了较多次的考验,因此,可能会取得较好的测试效果。
(2)、自顶向下与自底向上增量式测试的比较
自顶向下增量式测试:
——主要优点在于它可以自然的做到逐步求精,一开始就能让测试者看到系统的框架。
——主要缺点是需要提供桩模块,并且在输入/输出模块接入系统以前,在桩模块中表示测试数
据有一定困难。
自底向上增量式测试:
——优点在于,由于驱动模块模拟了所有调用参数,即使数据流并未构成有向的非环状图,生
成测试数据也无困难。
——主要缺点在于,直到最后一个模块被加进去之后才能看到整个程序(系统)的框架。
8:
什么是回归测试?
——在集成测试策略的环境中,回归测试是对某些已经进行过的测试的某些子集再重新进行一遍,以保证上述改变不会传播无法预料的副作用或引发新的问题
——在更广的环境里,回归测试就是用来保证(由于测试或其他原因的)改动不会带来不可预料的行为或另外的错误。
回归测试可以通过重新执行所有的测试用例的一个子集人工地进行,也可以使用自动化的捕获回放工具来进行
第三章
1:
等价类划分法是一种重要的、常用的黑盒测试测试用例设计方法,它将不能穷举的测试过程进行合理分类,从而保证设计出来的测试用例具有完整性和代表性
使用等价类测试主要有两个动机:
希望进行完备的测试尽可能的避免冗余
对于测试来讲:
整个集合就提供了一种完备性,而互不相交可保证一种形式的无冗余性。
(1)
(2)弱一般等价类测试—基于单缺陷假设定义:
通过选择每个等价类(区间)中的一个变量实现,确定测试用例的个数。
(图强一般等价类测试—基于多缺陷假设定义:
通过选择每个等价类(区间)的笛卡尔积的
每个元素确定测试用例的个数。
(图
(3)弱健壮等价类测试——健壮体现在它考虑了无效值,弱是因为它基于单缺陷
假设。
定义:
①对于有效输入,确定有效类中的一个值;②对于无效输入,
确定测试用例中拥有一个无效值,并保持其余的值都是有效
强健壮等价类测试——健壮要考虑无效值,强是指多缺陷假设。
定义:
从所有等价类笛
卡尔积的每个元素中确定测试用例。
.(4)
2测试用例的定义:
(1)测试用例是为特定的目的而设计的一组输入、执行条件和预期结果的信息组合。
(2)测试用例是测试执行的最小实体
3:
测试用例设计书写标准
标识符——惟一标识每一个测试用例测试项——准确的描述被测试的对象及其特征测试环境要求——执行该测试用例需要的测试环境输入标准——执行测试用例的输入需求(这些输入可能包括数据、文件或者操作)输出标准——按照指定的环境和输入标准得到的期望输出结果测试用例之间的关联——标识该测试用例与其它的测试(或其它测试用例)之间的依赖关系
4:
NextDate函数的等价类划分
再将NextDate函数的有效等价类细分如下:
month变量的有效等价类:
M1:
{month=4,6,9,11}M2:
{month=1,3,5,7,8,10}
M3:
{month=12}M4:
{month=2}
day变量的有效等价类:
D1:
{1≤day≤28}D2:
{day=29}D3:
{day=30}D4:
{day=31}
year变量的有效等价类:
Y1:
{year是闰年}Y2:
{year不是闰年}
考虑各种有效的输入情况,程序中可能采取的操作有以下六种:
a:
1day+1
a:
2day=
a:
3month+1
a:
4month=1
a:
5year+1
5:
边界析法就是重点对输入或输出的边界值进行测试的一种黑盒测试方法。
通常边界值分析法是对等价类划分法的补充,其测试用例等价类的边界。
怎样用边界值分析法设计测试用例?
(1)首先确定边界情况。
通常输入或输出等价类的边界就是应该着重测试的边界情况。
(2)选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值。
6:
边界值法选择测试用例的原则:
(1)如果输入条件规定了值的范围,则应取刚达到这个范围的边界值以及刚刚超过这个范围边界的值作为测试输入数据。
(2)如果输入条件规定了值的个数,则用最大个数、最小个数和比最大个数多1个、比最小个数少
1个的数作为测试数据。
(3)根据程序规格说明的每个输出条件,使用原则
(1)。
(4)根据程序规格说明的每个输出条件,使用原则
(2)。
(5)如果程序的规格说明给出的输入域或输出域是有序集合(如有序表、顺序文件等),则
应选取集合中的第一个和最后一个元素作为测试用例。
(6)如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测
试用例。
(7)分析程序规格说明,找出其它可能的边界条件。
7:
构造决策表步骤:
(1)确定规则的个数。
有n个条件的决策表有2n个规则(每个条件取真、假值)。
(2)列出所有的条件桩和动作桩。
(3)填入条件项。
(4)填入动作项,得到初始决策表。
(5)简化决策表,合并相似规则。
若表中有两条以上规则具有相同的动作,并且在条件项之间存在极为相似的关系,便可以合并。
合并后的条件项用符号“-”表示,说明执行的动作与该条件的取值无关,称为无关条件。
第四章
白盒测试也称结构测试或逻辑驱动测试,是针对被测单元内部是如何进行工作的测试。
它根据程序的控制结构设计测试用例,主要用于软件或程序验证。
1测试人员图论
一、图(又叫线性图)
是一种由两个集合定义的抽象数学结构,即一个节点集合和一个构成节点之间连接的边的集合。
(1)图的定义:
G=(V,E)V={n1,n2,,nm},E={e1,e2,,ep}其中每条边ek={ni,nj}是一个无序对偶,ni,nj∈V我们通常把节点看做是程序语句,边表示控制流。
对于测试:
2)节点的度
定义:
节点的度是以该节点作为端点的边的条数。
我们把节点n的度记做deg(n)。
如果节点表示对象,边表示消息,则节点(对象)的度表示适合该对象的集成测试范围。
3)路径
路径的定义:
路径是一系列的边,对于序列中的任何相邻边都拥有相同的端点(节点)。
路径可以描述为一系列的边,也可以描述为一系列的节点。
一般更常见的是节点序列。
定义:
节点ni和nj是连接的,当且仅当它们都在同一条路径上。
“连接性”是一种图的节点集合上的等价关系。
它有三个特性:
自反性:
每个节点都在到其本身长度为“0”的路径上
对称性:
如果(ni,nj)在一条路径上,则(nj,ni)也在同一条
5)组件
定义:
图的组件是相连节点的最大集合压缩图是为测试人员建立的一个简化机制。
定义:
给定图G=(V,E),其压缩图是用压缩节点替代每个组件后构成的图。
性质:
给定图的压缩图是唯一的。
对于测试的意义:
组件是相对独立的,因此可以单独测试定义:
图G的圈数V(G)=e-n+2p,其中:
e是G中的边数n是G中的节点数p是G中的组件数(区域数)6)压缩图路径上path传递性:
if(ni,nj)pathand(nj,nw)path,then(ni,nw)4)连接性(7)圈数(圈复杂度)V(G)的值给出了组成基本集的独立路径上界,也就是覆盖所有基本路径所需的测试用例上界。
其他圈复杂度计算办法:
1流图中区域的数量对应于环型的复杂性;2给定流图G的圈复杂度V(G),定义为V(G)=E-N+2,E是流图中边的数量,N是流图中结点的数量;3,给定流图G的圈复杂度V(G),定义为V(G)=P+1,P是流图G中判定结点的数量。
2有向图(控制流图)
有向图对一般图稍微做了改进:
边有了方向的含义。
(1)有向图的定义:
D=(V,E)V={n1,n2,,nm},E={e1,e2,,ep}其中每条边ek=是一个有序对偶,ni,nj∈V在有向边ek=中,ni是开始节点,nj是终止节点。
)路径和半路径
定义:
(有向)路经是一系列的边,使得对于该序列中的所有相邻边对偶ei,ej来说,第一条边的终止节点是第二条边的初始节点。
环路是在同一个节点上开始和结束的有向路经。
(有向)半路经是一系列的边,使得对于该序列中至少有一个相邻边对偶ei,ej来说,第一条边的初始节点也是第二条边的初始节点。
或第一条边的终止节点也是第二条边的终止节点。
3试覆盖率:
用于确定测试所执行到的覆盖项的百分比。
测试覆盖率可以表示出测试的充分性,在测试分析报告中可以作为量化指标的依据,测试覆盖率越高效果越好。
测试覆盖率包括功能点覆盖率和结构覆盖率
白盒测试中的逻辑覆盖方法有以下6种:
1)语句覆盖
2)判定覆盖
3)条件覆盖
4)判定-条件覆盖
5)组合覆盖
6)路径覆盖
4路径测试方法是在控制流图的基础上,通过分析控制结构的环形复杂度,导出执行路径的基本集,再从该基本集设计测试用例。
基本路径测试方法包括以下4个步骤:
(1)画出程序的控制流图。
(2)计算程序的环形复杂度,确定独立路径条数。
(3)导出基本路径集,确定程序的独立路径。
(4)根据(3)中的独立路径,设计测试用例的输入数据和预期输出。
基本路径测试方法是在控制流图的基础上,通过分析控制结构的环形复杂度,导出执行路径的基本集,再从该基本集设计测试用例。
基本路径测试方法包括以下4个步骤:
(1)画出程序的控制流图。
(2)计算程序的环形复杂度,确定独立路径条数。
(3)导出基本路径集,确定程序的独立路径。
(4)根据(3)中的独立路径,设计测试用例的输入数据和预期输出。
画出控制流图:
如右图所示
计算环形复杂度:
V(G)=e-n+2p
10(条边)-8(个节点)+2X1=4
导出独立路径(用语句编号表示)
路径1:
4→6→9→12→13→4→14
路径2:
4→14
路径3:
4→6→7→14
路径4:
4→6→9→10→13→4→14
1.基本概念
控制流测试是面向程序结构的测试,控制流图和测试覆盖准则一旦确定,即可产生测试用例。
数据流测试是面向程序中的变量。
程序变量的作用:
(1)存储数据
(2)引用数据
形如:
y=X+Z,ifPthenSelseT
软件测试期末总结[篇2]
工作刚满三个月,在这三个月的时间内,我主要做了以下几个方面的工作:
1.对软件的熟悉与理解
2.跟随开发人员对软件的改进进行了跟踪测试,利用功能组合的方法,对各种工具进行了测试,提交Bug共计405个,已验证关闭268个。
3.对软件用户手册和管-理-员手册的一部分进行了测试与更改,期间也加深了对该软件各个功能的理解
对已经实现的功能基本上都进行了测试,对软件使用上的改进也提出了自己的建议。
期间也了解了软件的功能需求,主要是对客户端服务器端及方案设计器进行了功能测试。
在这段时间里学到了不少东西。
在这段期间软件根据用户的反馈一直在不断的改进,基本上每天都会有变化,我跟据开发的进度一直在不断的测试,对新增加的工具边使用边学习,提交缺陷报告,并及时与开发人员进行沟通处理有歧异的缺陷报告,反复验证修复后的缺陷。
直到上一周利用他们出差的时间,我有对以前测试过的工具重新进行了更深一层的的组合测试。
通过这段时间的改进,软件的各项功能已经越来越全面,
目前软件的基本功能都已实现,致命错误越来越少,
期间也试用了自动化性能测试工具LoadRunner,由于软件还没有整体完成,在使用中不好匹配协议,现在正在熟悉另一个自动化工具RationalRobot来进行性能测试。
下半年,主要工作时是:
1.随着软件的逐步完成,将细化功能测试并及早的着手准备性能测试,界面测试,易用性等其他方面的总体测试,
2.测试所有与本软件有关的文档
3.解决所有遗留的有歧异的缺陷报告,参照提交的缺陷报告进行回归测试。
4.随着其他项目的开展着手准备测试前期的工作。
具体的工作实施安排还将根据项目组的工作进展和规划进行调整。
软件测试期末总结[篇3]
时光荏苒,如今12年的帷幕已经谢下,13年的钟声已经敲响,在公司高层的正确领导下,我们佰腾科技又走过了一年。
而我也在自己的努力以及同事的帮助下完成了xx年我所负责的工作,以下就是我对过去这一年的工作总结:
一、测试工作及经验
作为软件部测试组的一员,首先要做好的就是自己的本职工作,我在xx年中所做的工作主要有:
1.XXXXXXXX测试用例的编写,对系统的测试、跟踪;
2.XXXXXXXX需求、高保图、界面和功能的测试;
3.XXXXXXXX功能测试用例的编写,高保图、系统的测试;
4.XXXXXXXX的静态页面测试和功能测试;
5.XXXXXXXX的功能测试;
6.XXXXXXXX第一、二、三迭代高保图测试,测试用例编写,静态页面和功能测试,并主持参与测试用例评审;
7.XXXXXXXX平台高保图的测试和系统静态页面、功能的测试;
8.XXXXXXXX的高保图测试和测试用例的编写;
9.XXXXXXXX的静态页面和功能测试,参与测试用例的评审;
10.XXXXXXXX的高保图测试、静态页面和功能测试;
11.XXXXXXXX用户使用手册的编写;
一年的工作,让我获得很多方面的经验:
1.编写逻辑覆盖率全的测试用例甚为重要。
在理解需求的前提下编写测试用例,使得我掌握了多种测试用例编写方法,更让我对产品的需求有更加深入的理解,须知对需求是否理解透彻决定了能否有效、全面地对产品进行测试;
2.要站在用户角度对系统进行测试。
从一些项目中出现的未能及时发现的bug中,我认识到用户体验的重要性,现在能够越来越多的从这方面来执行测试;
3.对拿到手的项目有较清晰的思路,能够更加快速、准确地发现问题;
4.越来越规范的工作流程的让我们的工作有条不紊的进行,让我深刻认识到工作的规范性是多么的重要,并且从中学习如何从文档和流程上规范工作。
5.同事间的沟通很重要。
现在不管遇到什么