第讲软件测试_第1页
第讲软件测试_第2页
第讲软件测试_第3页
第讲软件测试_第4页
第讲软件测试_第5页
已阅读5页,还剩82页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

课题内容软件测试教学目的1\掌握软件测试的概念、目标,2\掌握软件测试技术3\理解软件测试策略4\掌握基于CASE的软件测试和排错教学方法理论加实例重点1、软件测试的概念、目标,2、软件测试技术掌握《软件测试说明书》编写课堂类型讲授课教具电脑、投影仪2024/5/101软件测试

2024/5/102主讲内容基本概念软件测试的概念、目标,方法和过程等软件测试技术软件测试策略基于CASE的软件测试和排错2024/5/103软件生命周期可行性研究需求分析概要设计详细设计实现集成测试确认测试使用与维护退役软件定义软件开发维护4软件测试初步的软件系统存在错误,如何发现错误?软件测试:为了发现错误而执行程序的过程。软件测试在软件生存期中横跨两个阶段编码阶段(单元测试)测试阶段(综合测试)2024/5/105软件测试(续)软件测试是软件质量保证活动中的关键步骤对SRS、设计规格说明书及编码的最后复审工作量:占软件开发总工作量的40%以上确保软件质量的一种有效手段(可操作)2024/5/1061.1软件测试的基本概念软件错误软件系统的功能和性能与预期的功能和性能不一致软件测试根据软件开发各阶段的规格说明和程序的内部结构,设计一批测试用例(即输入数据及其预期的输出结果),并利用这些测试用例去运行程序,以发现程序错误的过程。2024/5/1071.2软件测试的目的基于不同的立场用户的角度:希望通过软件测试暴露软件中隐藏的错误和缺陷,以考虑是否可接受该产品。软件开发者的角度:希望测试成为表明软件产品中不存在错误的过程,验证该软件已正确地实现了用户的要求,确立人们对软件质量的信心。2024/5/108软件测试的目的〔GlenMyers〕(1)测试是程序的执行过程,目的在于发现错误;(2)一个好的测试用例在于能发现至今未发现的错误;(3)一个成功的测试是发现了至今未发现的错误的测试。

测试无法说明错误不存在,而只能表示软件错误已经出现。2024/5/1091.3软件测试的原则〔Davie〕1.所有的测试都应追溯到用户需求。2.尽早地和不断地进行软件测试。3.Pareto原则应用于软件测试: 测试中发现的错误中的80%很可能起源于程序模块中的20%。2024/5/10104.从“小规模”开始,逐步转向“大规模”。5.穷举测试是不可能的。6.应由第三方来测试。软件测试的原则(续)2024/5/1011

1.4软件测试的对象软件测试并不等于程序测试软件测试应贯穿于软件定义与开发的整个期间。需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档,包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序,都应成为软件测试的对象。2024/5/1012为把握软件开发各个环节的正确性,需要确认和验证工作确认(Validation)目的:证实在一个给定的外部环境中,软件的逻辑正确性。需求规格说明的确认;程序的确认(静态确认、动态确认)验证(Verification)目的:试图证明在软件生存期各个阶段,以及阶段间的逻辑协调性、完备性和正确性。

1.4软件测试的对象(续)2024/5/10132024/5/10141.5软件测试的信息流程软件测试思想数据处理

设计测试用例

判断结果2024/5/1015测试信息流输入软件配置软件需求规格说明、软件设计规格说明、源代码等;测试配置测试计划、测试用例、测试程序等;测试工具测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的测试数据库等等。2024/5/1016测试结果分析比较实测结果与预期结果,评价错误是否发生。排错(调试)对已经发现的错误进行错误定位和确定出错性质,并改正这些错误,同时修改相关的文档。修正后的文档再测试建立可靠性模型利用可靠性分析,评价软件质量。测试信息流(续)2024/5/10171.6测试用例的设计

二种测试用例设计方法

白盒测试

黑盒测试2024/5/10181.6.1白盒测试思想把测试对象看做一个透明的盒子;利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。又称为结构测试或逻辑驱动测试。2024/5/10191.6.1白盒测试(续)使用白盒测试方法,对程序模块进行如下的检查:对程序模块的所有独立路径至少测试一次;对所有的逻辑判定,均需测试true和false;在循环的边界和运行界限内执行循环体;测试内部数据结构的有效性。2024/5/10201.6.2黑盒测试

思想把测试对象看做一个黑盒子;完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。又叫功能测试或数据驱动测试。

2024/5/10211.6.2黑盒测试(续)黑盒测试是在程序接口上进行测试,主要是为了发现:不正确或遗漏了的功能;界面错误;数据结构错误或外部信息访问错误;性能错误;初始化或终止错误。2024/5/10221.7软件测试步骤软件开发:从高抽象层次向低层次抽象过渡软件测试:从低层次抽象向高层次抽象过渡单元测试:测试程序中每个模块是否有错误 (白盒)集成测试:测试软件总体结构是否有错误 (黑盒)确认测试:测试软件是否满足用户需求 (黑盒)2024/5/1023需求分析概要设计详细设计编码单元测试集成测试确认分析软件开发过程软件测试过程软件开发和软件测试间的关系2024/5/10242软件测试技术

2.1白盒测试根据程序的控制结构来设计测试用例

要设计多少测试用例?覆盖准则:

语句覆盖分支覆盖路径覆盖基本路径覆盖2024/5/1025基本路径测试目标把覆盖的路径数压缩到一定限度内;保证程序的每一个可执行语句至少执行一次。

设计测试用例的方法在程序控制流图的基础上,通过分析环路复杂性,导出基本可执行路径集合,从而设计测试用例。2024/5/1026步骤1.根据流程图画出流图

流图刻画了程序的控制结构但不涉及程序的过程性细节。要素节点(过程块,结合点,判定点),有向边任何过程设计表示法都可被翻译成流图2024/5/1027流程图和流图2024/5/1028流图

判定点不含复合条件,否则应按照下列方式增加判定点2024/5/1029流程图 流图2024/5/1030流程图 流图2024/5/1031步骤2.计算程序的环路复杂性,

确定基本路径集合环路复杂性一种为程序逻辑复杂性提供定量测度的软件度量;给出程序基本路径集合中的独立路径条数,是确保每个语句至少执行一次的测试数量的上界。2024/5/1032步骤2.计算程序的环路复杂性,

确定基本路径集合(续)独立路径程序中至少引进一个新的处理语句集合或一个新条件的任一路径。在流图中,必须至少包含一条在定义此路径前不曾用到的边。2024/5/1033独立路径2024/5/1034独立路径(续)一个独立路径集合路径1: 1-11路径2: 1-2,3-6-7-9-10-1-11路径3: 1-2,3-4,5-10-1-11路径4: 1-2,3-6-8-9-10-1-11基本路径集不唯一2024/5/1035步骤2.计算程序的环路复杂性,

确定基本路径集合(续)多少条路径?环路复杂性V(G)(1)流图G中的区域数;(2)V(G)=E–N+2E-流图G的边数;N-流图的节点数(3)V(G)=P+1P-流图G中的判定节点数2024/5/1036环路复杂性2024/5/1037环路复杂性(续)计算V(G)(1)4个区域(2)V(G)=11条边-9个节点+2=4(3)V(G)=3个判定节点+1=4V(G)提供了组成基本集的独立路径的上界;并由此得出覆盖所有程序语句所需的测试用例的上界。2024/5/1038步骤3.导出测试用例针对每条测试路径设计测试用例,强制执行基本集中所有路径执行每个测试用例,并和期望值比较2024/5/10392.2黑盒测试黑盒测试主要测试软件是否满足功能和性能要求,不涉及模块的内部过程性细节黑盒测试的测试用例设计等价类划分边界值分析2024/5/10402.2.1等价分类法(1)

思想把所有可能的输入数据,即程序的输入域划分成若干部分,然后从每一部分中选取少数有代表性的数据做为测试用例。优点减少测试次数,不丢失发现错误的机会2024/5/1041

2.2.1等价分类法(2)

设计测试用例的步骤(1)在输入域中划分等价类;(2)选取测试用例。等价类输入域的子集。在该子集中,各个输入数据对于揭露程序中的错误是等效的;测试某等价类的代表值就等价于对这一类其它值的测试。

2024/5/1042

2.2.1等价分类法(3)

等价类的划分①有效等价类对于程序的规格说明来说,是合理的,有意义的输入数据构成的集合。②无效等价类对于程序的规格说明来说,是不合理的,无意义的输入数据构成的集合。在设计测试用例时,要同时考虑有效等价类和无效等价类的设计。2024/5/1043步骤1.划分等价类划分等价类的原则(1)按区间划分输入条件规定取值范围;则可以确立一个有效等价类和两个无效等价类。(2)按数值划分如果规定了输入数据的特定值;则可以确立一个有效等价类和两个无效等价类。2024/5/1044程序的规格说明中,输入条件:

“……

项数可以从1到999

……”

则有效等价类是“1≤项数≤999”;

两个无效等价类是“项数<1”或“项数>999”。在数轴上表示:

划分等价类的原则-例2024/5/1045

(3)按集合划分输入条件规定了输入值的集合,或规定了“必须如何”的条件;可确立一个有效等价类和一个无效等价类(其补集).例Pascal语言中,对变量标识符规定为“以字母打头的……串”;所有以字母打头的构成有效等价类,不在此集合内(不以字母打头)的归于无效等价类。

划分等价类的原则(续)2024/5/1046

(4)如果输入条件是一个布尔量,则可以确定一个有效等价类和一个无效等价类。

划分等价类的原则(续)2024/5/1047(1)在确立了等价类之后,建立等价类表,列出所有划分出的等价类。

步骤2.确立测试用例2024/5/1048步骤2.确立测试用例(续)(2)从划分出的等价类中按以下原则选择测试用例设计尽可能少的测试用例,覆盖所有的有效等价类;针对每一个无效等价类,设计一个测试用例来覆盖它。2024/5/10492.2.2边界值分析法边界值分析大量的错误发生在输入或输出范围的边界上,而不是在输入范围的内部。因此,针对各种边界情况设计测试用例。边界相对于输入等价类和输出等价类而言,稍高于其边界值及稍低于其边界值的一些特定情况。2024/5/1050设计测试用例首先应确定边界情况;应当选取正好等于,刚刚大于,或刚刚小于边界的值做为测试数据,而不是选取等价类中的典型值或任意值做为测试数据。2.2.2边界值分析法(2)2024/5/10512.2.2边界值分析法(3)设计测试用例方法(1)输入条件是一范围(a,b);那么以a,b及紧挨a,b左右的值应作为测试用例。(2)输入条件为一组数,那么选择这组数的最大者和最小者,次大和次小者作为测试用例。2024/5/10522.2.2边界值分析法(4)(3)应用规则(1)(2)于输出条件。设计测试用例使得程序的输出结果刚好是在某些边界上。(4)如果程序的内部数据结构是有界的,那么应设计测试用例使它能够检查该数据结构的边界。2024/5/10533软件测试的过程与策略测试过程按4个步骤进行(1)单元测试集中对用源代码实现的每一个程序单元进行测试,检查各个程序模块是否正确地实现了规定的功能。(2)组装测试把已测试过的模块组装起来,主要对与设计相关的软件体系结构的构造进行测试。2024/5/1054(3)确认测试检查已实现的软件是否满足了需求规格说明中确定了的各种需求,以及软件配置是否完全、正确。(4)系统测试把已经经过确认的软件纳入实际运行环境中,与其它系统成份组合在一起进行测试。软件测试的过程与策略(续)2024/5/10552024/5/10563.1单元测试单元测试在编码阶段进行;针对软件的最小单元-模块进行正确性检验。多采用白盒测试;多个模块可平行地独立进行单元测试。测试的内容模块接口;局部数据结构;路径测试;错误处理测试;边界测试;关键路径测试。2024/5/1057单元测试2024/5/10583.2集成测试集成测试在单元测试的基础上,需要将所有模块按照设计要求组装成为系统。模块相互调用时引入接口问题->集成测试(组装测试、联合测试)。2024/5/10593.2集成测试(续)需要考虑的问题把各个模块连接起来时,穿越模块接口的数据是否会丢失;一个模块的功能是否会对另一个模块的功能产生不利的影响;各个子功能组合起来,能否达到预期要求的功能;全局数据结构是否有问题;单个模块的误差累积起来,是否会放大,以至达到不能接受的程度。2024/5/10603.2集成测试(续)组装模块的方式一次性集成(整体拼装;难于查错)增量式集成自顶向下集成自顶向上集成2024/5/1061自顶向下集成从主控模块开始,按照软件的控制层次结构,以深度优先或广度优先的策略集成各个模块2024/5/1062自顶向下集成-深度优先/广度优先2024/5/1063自顶向下集成(续)优点尽早的对程序的主要控制和决策机制进行检验,尽早发现错误。缺点测试较高层模块时,低层用桩模块替代,不能反映真实情况。2024/5/1064自底向上集成从软件结构最底层模块开始自底向上进行组装和测试2024/5/10653.3确认测试任务(1)验证软件的有效性:判断目标软件系统是否满足用户的功能和性能需求;(2)文档资料是否完整、准确。依据和标准:用户需求规格说明书2024/5/10663.3确认测试(续)步骤1:有效性测试(1)制定测试计划;(2)制定测试过程:定义具体的测试用例;(3)对软件其它需求(如可移植性、兼容性、错误恢复能力、可维护性等)进行测试。步骤2:软件配置复审保证软件配置齐全、分类有序,具有维护阶段所需的细节。2024/5/10672024/5/10683.3确认测试(续)步骤3:验收测试以用户为主的测试。α测试,β测试2024/5/1069α测试α测试公司内部的用户在模拟实际操作环境下进行的测试。目的评价软件产品的FURPS(功能、可使用性、可靠性、性能和支持);尤其注重产品的界面和特色。2024/5/1070β测试由软件的多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者。目的衡量产品的FLURPS。着重于产品的支持性,包括文档、客户培训和支持产品生产能力。处在整个测试的最后阶段。β测试2024/5/10713.4系统测试系统测试将通过确认测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起;在实际运行环境下,对计算机系统进行一系列的组装测试和确认测试。目的通过与系统的需求定义作比较,发现软件与定义不符合的地方。2024/5/1072测试种类软件测试由一系列不同的测试组成。目的对以计算机为基础的系统进行充分的测试。2024/5/1073测试种类(1)功能测试在规定的一段时间内运行软件系统的所有功能,以验证这个软件系统有无严重错误。2024/5/1074测试种类(2)可靠性测试如果系统需求说明书中有对可靠性的要求,则需进行可靠性测试。

①平均失效间隔时间MTBF(MeanTimeBetweenFailures)是否超过规定时限?

②因故障而停机的时间MTTR(MeanTimeToRepairs)在一年中应不超过多少时间。

2024/5/1075测试种类(3)强度测试检查在系统运行环境不正常乃至发生故障的情况下,系统可以运行到何种程度的测试。例如:把输入数据速率提高一个数量级,确定输入功能将如何响应。设计需要占用最大存储量或其它资源的测试用例进行测试。2024/5/1076测试种类(4)

性能测试检查系统是否满足在需求说明书中规定的性能。特别是对于实时系统或嵌入式系统。常需要与强度测试结合起来进行,并要求同时进行硬件和软件检测。通常,对软件性能的检测表现在以下几个方面响应时间、吞吐量、辅助

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论