毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx

上传人:聆听****声音 文档编号:3740066 上传时间:2023-05-02 格式:DOCX 页数:53 大小:140.89KB
下载 相关 举报
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第1页
第1页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第2页
第2页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第3页
第3页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第4页
第4页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第5页
第5页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第6页
第6页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第7页
第7页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第8页
第8页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第9页
第9页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第10页
第10页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第11页
第11页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第12页
第12页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第13页
第13页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第14页
第14页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第15页
第15页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第16页
第16页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第17页
第17页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第18页
第18页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第19页
第19页 / 共53页
毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx_第20页
第20页 / 共53页
亲,该文档总共53页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx

《毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx(53页珍藏版)》请在冰点文库上搜索。

毕业设计(论文)-软件测试方法与测试过程的分析与研究2Word格式文档下载.docx

在遵守以上原则的基础上进行软件测试,可以以最少的时间和人力找出软件中的各种缺陷,从而达到保证软件质量的目的。

1.2.2软件测试的分类

软件测试的技术和方法是多种多样的,对于软件测试技术,可以从不同的角度加以分类。

1.从是否关心软件内部结构和具体实现的角度(即按测试方法)划分为白盒测试和黑盒测试。

2.从是否执行程序的角度(即按测试方式)划分为静态测试和动态测试。

3.从软件开发的过程按阶段(即按测试过程)划分为单元测试、集成测试、确认测试、系统测试和验收测试。

这四个过程相互独立且顺序相接,依次进行。

4.从用户的需求(即测试目的)划分为功能测试、健壮性测试、接口测试和性能测试。

此外,按照测试目的划分还包括强度测试、压力测试、用户界面测试、安全测试、可靠性测试、安装\反安装测试、文档测试、恢复测试和兼容性测试

1.3软件测试的复杂性与经济性

1.3.1软件测试的复杂性

设计测试用例是一项细致并需要高度技巧的工作,稍有不慎就会顾此失彼,发生不应有的疏漏。

不论是黑盒测试方法还是白盒测试方法,由于测试情况数量巨大,都不可能进行彻底的测试。

所谓彻底测试,就是让被测程序在一切可能的输入情况下全部执行一遍。

通常也称这种测试为“穷举测试”。

“黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。

实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。

“白盒”法是穷举路径测试,贯穿程序的独立路径数是天文数字,但即使每条路径都测试了仍然可能有错误。

第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。

第二,穷举路径测试不可能查出程序中因遗漏路径而出错。

第三,穷举路径测试可能发现不了一些与数据相关的错误。

e.w.dijkstra的一句名言对

测试的不彻底性作了很好的注解:

“程序测试只能证明错误的存在,但不能证明错误不存在”。

在实际测试中,穷举测试工作量太大,实践上行不通,这就注定了一切实际测试都是不彻底的。

当然就不能够保证被测试程序中不存在遗留的错误。

1.3.2软件测试的经济性

软件工程的总目标是充分利用有限的人力和物力资源,高效率、高质量地完成测试。

为了降低测试成本,选择测试用例时应注意遵守“经济性”的原则。

第一,要根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级;

第二,要认真研究测试策略,以便能使用尽可能少的测试用例,发现尽可能多的程序错误。

掌握好测试量是至关重要的,一位有经验的软件开发管理人员在谈到软件测试时曾这样说过:

“不充分的测试是愚蠢的,而过度的测试是一种罪孽”。

测试不足意味着让用户承担隐藏错误带来的危险,过度测试则会浪费许多宝贵的资源。

第二章 软件测试基本技术

2.1软件测试技术概述

通常人们把软件测试技术归结为两大类:

白盒测试和黑盒测试。

白盒测试又可分为静态测试和动态测试。

静态测试技术不要求在计算机上实际执行所测程序,主要以一些人工的模拟技术对软件进行分析和测试。

它 主要包括代码检查法、静态结构分析法等;

动态测试技术是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序,而达到发现程序错误的过程。

它 主要包括程序插桩、逻辑覆盖、基本路径测试等。

黑盒测试一般可分为功能测试和非功能测试两大类;

功能测试主要包括等价类划分、边值分析、因果图法、错误推测、功能图法等,主要用于软件确认测试;

非功能测试主要包括使用性能测试、性能测试、强度测试、兼容性测试、配置测试、安全测试等。

对任何工程产品都可以使用白盒测试和黑盒测试两种方法之一进行测试。

2.2白盒测试技术

2.2.1白盒测试的概述

白盒测试也称结构测试或逻辑驱动测试,它是按照程序内部的结构测试程序,通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行,检验程序中的每条通路是否都能按预定要求正确工作。

这一方法是把测试对象看作一个打开的盒子,测试人员依据程序内部逻辑结构相关信息,设计或选择测试用例,对程序所有逻辑路径进行测试,通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。

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

白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。

逻辑覆盖测试分支结构,循环覆盖测试循环结构。

其中逻辑覆盖代码的覆盖深度是不同的,

从覆盖源程序语句的详尽程度分析包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。

白盒法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。

白盒法是穷举路径测试。

在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。

贯穿程序的独立路径数是天文数字。

但即使每条路径都测试了仍然可能有错误。

2.2.2白盒测试的工具

白盒测试目前主要用在具有高可靠性要求的软件领域,例如:

军工软件、航天航空软件、工业控制软件等等。

白盒测试工具在选购时应当主要是对开发语言的支持、代码覆盖的深度、嵌入式软件的测试、测试的可视化等。

对开发语言的支持:

白盒测试工具是对源代码进行的测试,测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。

但是对于不同的开发语言,测试工具实现的方式和内容差别是较大的。

目前测试工具主要支持的开发语言包括:

标准C、C++、VisualC++、Java、VisualJ++、Visualun

it等。

不同的测试工具对于代码的覆盖能力也是不同的,通常能够支持修正条件判定覆盖的测试工具价格是极其昂贵的。

嵌入式软件的测试:

对于嵌入式软件的测试,我们还需要一方面进一步考虑测试工具对于嵌入式操作系统的支持能力,例如DOS、Vxworks、Neculeu

s、Linux和WindowsCE等;

另一方面还需要考虑测试工具对于硬件平台的支持能力,包括是否支持所有64/32/16位CPU和MCU,是否可以支持 PCI/V

ME/CPCI总线。

测试的可视化:

白盒测试是工作量巨大并且枯燥的工作,可视化的设计对于测试来说是十分重要的。

在选购白盒测试工具时,应当考虑该款测试工具的可视化是否良好,例如:

测试过程中是否可以显示覆盖率的函数分布图和上升

趋势图,是否使用不同的颜色区分已执行和未执行的代码段显示分配内存情况实时图表等,这些对于测试效率和测试质量的提高是具有很大的作用的。

2.2.3白盒测试的方法介绍

1.白盒测试之基本路径法

其中运用最为广泛的是基本路径测试法。

基本路径测试法是在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例的方法。

设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。

在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例。

包括以下4个步骤和一个工具方法:

(1)程序的控制流图:

描述程序控制流的一种图示方法。

(2)程序圈复杂度:

McCabe复杂性度量。

从程序的环路复杂性可导出程序基本路径集合中的独立路径条数,这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。

(3)导出测试用例:

根据圈复杂度和程序结构设计用例数据输入和预期结

果。

(4)准备测试用例:

确保基本路径集中的每一条路径的执行。

基本路径测试的工具方法:

○1图形矩阵:

是在基本路径测试中起辅助作用的软件工具,利用它可以实

现自动地确定一个基本路径集。

○2程序的控制流图:

圆圈称为控制流图

的一个结点,表示一个或多个无分支的语句或源程序语句流图只有二种图形符号:

图中的每一个圆称为流图的结点,代表一条或多条语句。

流图中的箭头称为边或连接,代表控制流任何过程设计都要被翻译成控制流图。

如何根据程序流程图画出控制流程图呢?

在将程序流程图简化成控制流图时,应注意:

在选择或多分支结构中,分支的汇聚处应有一个汇聚结点。

边和结点圈定的区域叫做区域,当对区域计数时,图形外的区域也应记为一个区域。

基本路径测试法的步骤:

第一步:

画出控制流图

流程图用来描述程序控制结构。

可将流程图映射到一个相应的流图 (假设流程图的菱形决定框中不包含复合条件)。

在流图中,每一个圆,称为流图的结点,代表一个或多个语句。

一个处理方框序列和一个菱形决测框可被映射为一个结点,流图中的箭头,称为边或连接,代表控制流,类似于流程图中的箭头。

一条边必须终止于一个结点,即使该结点并不代表任何语句 (例如:

if-else-then结构)。

由边和结点限定的范围称为区域。

计算区域时应包括图外部的范围。

1

2

3

6

9

10

8

7

5

4

(a)程序流程图

结点

2,3

4,5

7 8

区域

11

(b)程序图

图2.1控制流程图和控制流图

第二步:

计算圈复杂度

圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量,将该度量用于计算程序的基本的独立路径数目,为确保所有语句至少执行一次的测试数量的上界。

独立路径必须包含一条在定义之前不曾用到的边。

有以下三种方法计算圈复杂度:

流图中区域的数量对应于环型的复杂性;

给定流图G的圈复杂度V(G),定义为V(G)=E-N+2,E是流图中边的数量,N是流图中结点的数量;

给定流图G的圈复杂度V(G),定义为V(G)=P+1,P是流图G中判定结点的数量。

第三步:

导出测试用例

根据上面的计算方法,可得出四个独立的路径。

一条独立路径是指,和其他的独立路径相比,至少引入一个新处理语句或一个新判断的程序通路。

V(

G)值正好等于该程序的独立路径的条数。

下面我们通过一个实例来说明基本路径测试。

例:

请看以下代码,它由C++语言书写,把它转化成图形矩阵,最后请使用基本路径测试法为变量temp设计测试用例,使之满足基本路径覆盖要求。

/*1*/.voidReadPara(CStringtemp)

/*2*/.{

/*3*/. if(temp=="

>

="

/*4*/. m_oper.SetCurSel(0);

/*5*/. else

/*6*/. {

/*7*/. if(temp=="

"

/*8*/. m_oper.SetCurSel

(1);

/*9*/. else

/*10*/. {

/*11*/. if(temp=="

=="

/*12*/. m_oper.SetCurSel

(2);

/*13*/. else

/*14*/. {

/*15*/. if(temp=="

<

/*16*/. m_oper.SetCurSel(3);

/*17*/. Else

/*18*/. {

/*19*/. if(temp=="

/*20*/. m_oper.SetCurSel(4);

/*21*/. else

/*22*/. m_oper.SetCurSel(5);

/*23*/. }

/*24*/. }

/*25*/. }

/*26*/. }

/*27*/. return;

/*28*/.}

(1)画出这段代码的控制流图,如图2.2所示:

图2.2控制流图

(2)根据控制流图,计算环路复杂度V(G)=22-18+2=6。

(3)导出测试用例,列出路径:

Path1:

2-3-4-27-28

Path2:

2-3-7-8-26-27-28Path3:

2-3-7-11-12-25-26-27-28

Path4:

2-3-7-11-15-16-24-25-26-27-28Path5:

2-3-7-11-15-19-20-23-24-25-26-27-28Path6:

2-3-7-11-15-19-22-23-24-25-26-27-28

(4)设计测试用例

根据第3步中给出的路径,下面设计测试用例列在表2.1中。

表2.1测试用例列表

传入参数

预期调用

Path

ReadPara(”>

=”)

m_oper.SetCurSel(0)

”)

m_oper.SetCurSel

(1)

ReadPara(”==”)

m_oper.SetCurSel

(2)

ReadPara(”<

m_oper.SetCurSel(3)

m_oper.SetCurSel(4)

ReadPara(”+”)

m_oper.SetCurSel(5)

2.白盒测试之程序插桩

在软件测试中,常常要用到一种“插桩”技术,通过在源代码中加入记录信息语句,以便进行运行信息的追踪和调试,统计有关的运行资源状况。

想做插桩,可以思考以下几点:

(1)如果出现在语句中包含了return语句,怎么在它前面插入指定语句?

同时保证语句的语法合法性?

例如:

for(j=0;

j<

10000;

j++)

{

if(j==k)

return;

//不能直接在之前插入,否则意义全变了

}

(2)当出现需要在for 循环语句、while循环语句中进行插入信息时候,很可能会导致程序运行时间非常长,是否有办法改进“插桩”机制?

(3)是否可以由用户进行指定,比如for 语句、while语句或者指定的语句前不允许进行“插桩”,怎么实现?

(4)如果对于一个庞大的系统软件,我们需要进行对所运行的程序的每个函数记录其运行的有关参数,如:

运行开始时间、退出时间、运行总时间、调用次数等等的统计。

3.白盒测试之逻辑覆盖

逻辑覆盖是设计白盒测试方案的一种技术。

前面我们已经对逻辑覆盖做了一定的介绍,这里就不多作说明了,下面我们给出一个测试实例加以分析。

【例】为下列代码设计测试用例:

if a>

1andb=0 then x=x/aif a=2 or x>

1 then x=x+1

s

a

c

b

e

d

(a)流程图 (b)程序图

图2.3被测试代码段的流程图和被测试代码段的程序图

(1)语句覆盖

为了暴露程序中的错误,至少每个语句应该执行一次。

语句覆盖的含义是,选择足够多的测试数据,使被测程序中每个语句至少执行一次。

例如选择测试数据a=2,b=0,x=3能够覆盖语句c、e。

(2)判定覆盖

判定覆盖又叫分支覆盖,它的含义是,不仅每个语句必须至少执行一次,而且每个判定的每种可能的结果都应该至少执行一次,也就是每个判定的每个分支都至少执行一次。

选择两组测试数据:

a=3,b=0,x=1(通过路径1453)

a=2,b=1,x=2(通过路径1267)

(3)条件覆盖

条件覆盖的含义是,不仅每个语句至少执行一次,而且使判定表达式中的每个条件都取到各种可能的结果。

上述两个判定表达式中有4个条件:

a>

1, b=0, a=2, x>

a=2,b=0,x=3

(使a>

1,b=0,a=2,x>

1为真,通过路径14567)a=1,b=1,x=1

1为假,通过路径123)

选择另外两组测试数据:

a=1,b=0,x=3

(使b=0,x>

1为真,a>

1,a=2为假,通过路径1267)a=2,b=1,x=1

1为假,a>

1,a=2为真,通过路径1267)

这两组测试数据均使a>

1ANDb=0为假,a=2ORx>

1为真,不满足判定覆盖。

所以满足条件覆盖不一定满足判定覆盖。

(4)判定/条件覆盖

既然判定覆盖不一定包含条件覆盖,条件覆盖也不一定包含判定覆盖,自然会提出一种能同时满足这两种覆盖标准的逻辑覆盖,这就是判定/条件覆盖。

它的含义是,选取足够多的测试数据,使得判定表达式中的每个条件都取到各种可能的值,而且每个判定表达式也都取到各种可能的结果。

选择两组测试用例:

a=2,b=0,x=3(使a>

1,b=0,a=2,x>

1和(a>

1)AND(b=0),(a=2)OR(x>

1)为真

a=1,b=1,x=1(使a>

1)AND(b=0),(a=2)OR(x>

1)为假注意:

若将b=0写为b≠0,而a>

1为假,x>

1写为x≤1,而a=2为真,就

测试不出来。

(5)条件组合覆盖

条件组合覆盖是更强的逻辑覆盖标准,它要求选取足够多的测试数据,使得每个判定表达式中条件的各种可能组合都至少出现一次。

两个判定表达式共有四个条件,因此有8种组合:

a>

1,b=0;

a>

1,b≠0;

a≤1,b=0;

a≤1,b≠0

a=2,x>

1;

a=2,x≤1;

a≠2,x>

a≠2,x≤1

以下4组测试用例可以满足条件组合覆盖:

①a=2,b=0,x=2 ②a=2,b=1,x=1

③a=1,b=0,x=2 ④a=1,b=1,x=1

(6)路径覆盖

覆盖所有可能的路径,以下4组测试用例可以路径覆盖:

①a=2,b=0,x=2 ②a=2,b=1,x=1

③a=1,b=1,x=1 ④a=1,b=0,x=2

但不能覆盖a≤1,b=0和a≠2,x>

1。

所以满足路径覆盖不一定满足条件组合覆盖。

在实际的逻辑测试中,一般以条件组合覆盖为主设计测试用例,然后补充测试用例,达到路径覆盖。

4.白盒测试之循环覆盖

循环测试是一种白盒测试技术,它专注于测试循环结构的有效性。

在结构化的程序中通常只有三种循环,分别是简单循环、串接循环和嵌套循环,如图2.4所示。

简单循环 嵌套循环 串接循环

图2.4三种循环结构类型

下面分别讨论不同类型循环的测试方法。

(1)简单循环

应该使用下列测试集来测试简单循环,其中n是允许通过循环的最大次数。

·

跳过循环。

只通过循环一次。

通过循环两次。

通过循环m次,其中m<n-1。

通过循环n-1,n,n+1次。

【例】n=k;

//为测试设置的语句i=1;

while(i≤n){

……i=i+1;

若允许循环的最大次数为6,k取值分别为:

0:

跳过循环

1,2:

只执行1,2次循环

4:

执行4次循环

5,6,7:

执行n-1,n,n+1次循环

(2)嵌套循环

如果把简单循环的测试方法直接应用到嵌套循环,可能的测试数就会随嵌套层数的增加按几何级数增长,这会导致不切实际的测试数目。

B.Beizer提出了一种能减少测试数的方法。

从最内层循环开始测试,把所有其他循环都设置为最小值。

对最内层循环使用简单循环测试方法,而使外层循环的迭代参数(例如,循环计数器)取最小值,并为越界值或非法值增加一些额外的测试。

由内向外,对下一个循环进行测试,但保持所有其他外层循环为最小值,其他嵌套循环为“典型”值。

继续进行下去,直到测试完所有循环。

(3)串接循环

如果串接循环的各个循环都彼此独立,则可以使用前述的测试简单循环的方法来测试串接循环。

如果两个循环串接,而且第一个循环的循环计数器值是第二个循环的初始值,则这两个循环并不是独立的。

当循环不独立时,建议使用测试嵌套循环的方法来测试串接循环。

白盒测试作为软件质量保证中的重要一环,对产品稳定性起到至关重要的影响,不幸的是,由于实施白盒测试有较高技术难度,该软件过程常被厂商忽略,因为难于实施,所以容易失败,失败后产生畏惧心理,就更不愿意进一步去尝试

,如此形成恶性循环。

我们应该克服这种心理恐惧,不畏惧“白盒测试”这只拦路虎,只要方法得当,白盒测试还是能做起来的。

2.3黑盒测试技术

2.3.1黑盒测试技术概述

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > IT计算机 > 电脑基础知识

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2