关于软件测试技术的

摘 要：随着计算机技术的飞速发展,软件测试技术已作为一项单独的科目从软件工程领域分离了出来.测试是为做出的软件更好地满足用户需求而进行的一致性测评,即测量最终结果是否与需求分析中的用户需求相吻合或吻合程度.测试方法种类繁多,最基本的有黑盒测试和白盒测试.测试的模块化分析的作用也日益突出,对一个大的软件可以分模块,分单元测试.测试用例的设计技巧性也很强,比如选取最具代表性的用例,使测试文档更加精简.另外,随着测试技术的不断发展,也出现了许多优秀的测试工具,比如：QAC,McCabe,Eunit等,它们使我们对测试事半功倍.

关 键 词：软件单元测试测试用例模块化

中图分类号：TP311.52文献标识码：A文章编号：1007-9416(2012)02-0133-03

当前,对软件工程领域的讨论出现了很多优秀文章.软件工程也作为一门重要的学科得到了快速的发展.在这些文章中对软件的设计和开发都做了比较深刻的探讨.但是,软件测试技术作为软件工程中的一个非常重要的环节却经常得不到人们的深刻认识.往往人们在有些方面还对软件测试的环节和作用有着不同程度的错误认识.

1.软件测试的地位

测试在软件开发的过程中到底应该占据一个什么样的位置?许多人对此问题理解的并不十分深刻.人们有时对此问题的理解在某种程度上甚至还存在着错误.有些人认为软件测试只是对做出的东西做一个功能的检验,此过程只要在开发过程中做好调试工作,这一模块完全可以避免.软件测试是为了测量软件与需求和总体框架是否吻合以及吻合程度.一个软件做的到底合不合格,此产品是否可以发布,是否能够满足用户的需要,是否能给用户留下良好的形象,其中测试起着举足轻重的作用.由此我们可以看出,软件的测试绝不是在开发过程中可有可无的模块,它占据着一个十分重要的地位.

我们做测试是在软件开发过程中与其它各模块有机融合的测试,不是把其单独拿出来看看它是什么,做了什么?而是看我们做这些功用在哪,做了这些为整个软件开发带来什么样的益处.

2.测试技术

2.1对测试认识的常见误区

测试的目的是判断软件是否与预期目标相符及相符的程度.当然如果狭义的讲我们也可以说测试就是尽可能早的、尽可能多的发现现有文件中的错误,并将错误提交给相关人员,使问题尽早得到解决.但是过去有许多人对软件测试并不是认识的特别清楚,即使是现在也有一部分人对测试的理解和测试本质意义仍有很大偏差.以下我们将介绍两种对测试理解的常见错误.

2.1.1测试与调试的等同

有些人将测试和调试在一定程度上混为一谈,他们认为如果在调试上多花些功夫,则测试是完全没有必要的.这是一种极其错误的想法.此种错误的根源在于没有对测试和调试的基本概念搞清楚.调试是指程序员在开发过程中对自己书写的程序进行正误的判断,看自己的代码是否能够按照架构文档描述正常工作.而测试的工作则是看得到的代码或软件是否按照需求文档工作,这具体包括：各个功能是否得到了有效的实现,最终得到的软件的整体性效果如何.软件在一定的压力条件下（比如：内存相对不足）是否能正常工作,输入错误信息得到什么样的回馈,系统在长时间工作的条件下是否还能正常运行等等.

对这些概念理解清楚了,自然就能够正确区分测试和调试的差别.当然测试和调试有一些内容存在交汇点.

2.1.2测试的起始介入时间

有些人认为测试是在软件开发完成后进行一次总体的检查,其起始时间是在其它工作都基本结束的时候,再致力于软件的测试工作.其实则不然,软件的测试工作是应该与需求分析同步起来,也就是说在做需求分析的过程中应当有测试人员介入,这样使得测试人员对此系统具体要完成哪些工作做到心中有数.有一点大家一定注意,测试不只是看程序员写的程序是否能够正常工作,更重要的是看其是否满足用户需求,以及在各种条件下的满足程度.

伴随着需求分析文档的诞生,测试人员的测试框架和测试文档也应当相应的得到实现.当程序员完成部分工作,则测试人员就应该根据测试文档书写测试程序对得到的现有完成部分进行测试.这样一旦发现bug,就及时提交给相关人员,通过这一过程,能使问题在最早的时间段内得到解决,同时也使损失尽可能的降到最低.软件的开发就是这样相互叠加式的前进过程.

在我们了解了测试的常见错误后,下面让我们对测试的分类进行一下梳理.

2.2测试分类

软件的测试按照不同的分类方法可分成不同的类.按照测试人员的不同可分为：专业测试和用户测试；按照软件总体性可分为：黑盒测试和白盒测试；按照开发的不同阶段可分为：软件开发过程中测试和产品测试及后段测试；按照软件性能可分为：功能测试,极限测试,容错测试,压力测试和时间测试等等.在下面向大家介绍几种重要的测试类别.

2.2.1黑盒测试和白盒测试

软件测试从整体角度可分为黑盒测试和白盒测试.黑盒测试顾名思义就是我们对程序代码内部机制不用管,我们关心的只是其功能.比如我们将其看成一个黑箱子,其内部放些什么东西我们并不了解.我们向其做一定的输入,看其输出结果会是什么样子.通过这种方法我们来确定此模块的功用是否与要求相符,这叫做黑盒测试.相反,我们不仅要知道盒子的输入输出反应,还要知道其内部实现机理,一旦在哪一块出现错误,我们可以及时的修正.通过这样的方法进行测试称为白盒测试.

比如我们对于以下代码模块进行测试:

voidswap(int*a,int*b){

a+等于b,

b等于a-b,

a等于a-b,

}示例代码2.1

当我们用黑盒测试的时候我们只看到盒子两个入口,可以放两个变量指针,所以我们就把变量&aValue,&bValue传进去,而结果是交换了两个内存单元的数据.而白盒测试则不然,它要求我们明白盒子（即程序具体代码）的内在实现过程.比如我们发现使的是ja语言,而不支持指针操作,所以我们作为测试员就可以把代码修正,如下：

publicstaticvoidswap(int&a,int&b){

a+等于b,

b等于a-b,

a等于a-b,

}示例代码2.2

这样我们同样实现了相同的功能.

2.2.2功能测试

在软件性能测试中最重要的就是功能测试,功能测试是看我们要测的模块是否能够完成要求的任务,是否在正常情况下给其一个合适的输入能得到期望的回应.功能测试最重要,但在实现起来也最简单.比如测试一个线程能否被正确建立我们可以用以下代码:

voidtest(){

Threadt等于Thread.instance(),

if(t等于等于null){

printfile(0),

return,}

Hresulthr等于t.start(),

if(hr！等于OK)printfile(0),

}示例代码2.3

这样我们就可方便地进行功能测试了,看其是否正常工作,如果不能正常工作,我们将会在输出文件里得到0信息.

2.2.3极限测试

极限测试是我们判断软件在给定边界值的工作情况的,比如我们给定文档说线程可以同时起动10个,则我们可以使用如下程序来实现此功能:

voidtest(){

Threadt等于Thread.instace(),

intcount等于0,

if(t等于等于null){

printfile(0),

return,}

boolb等于true,

while(b){

{保证线程不退出机制}

Hresulth等于t.start(),

if(h！等于OK){

printfile(count),

printfileappend(count>等于10),

b等于false,}

count++,}

｛线程退出,释放资源｝

}示例代码2.4

通过这样的方法我们可以得到最多起动线程数和是否满足了需求,如果满足了用户需求,则我们就会在输出文件里得到两个数,第一个为线程启动数,第二个为true.比如(20true).

2.2.4容错测试

容错测试则是我们不像设计者预期的那样给定的系统值,比如在示例代码2.1的时候我们给其为两变量(a,b)或（pointa,b）(a,pointb)(pointa代表a为一指针)看结果会怎么样,通过这样看当给定错误代码时系统界面是否友好,当然我们更不希望当接收错误信息时系统会崩溃掉.

2.2.5压力测试

压力测试指我们的系统在不像我们设想的理想环境下运行时,会有什么效果.比如内存不足,系统运行一定时间,硬件兼容性低,硬件配置相对较低等等.例如我们做示例代码2.4的压力测试：

voidtest(){

{耗掉大部分内存}

示例代码2.4

}示例代码2.5

这时我们观察看输出文件是否还会得到第一个数大于10而第二个数为true.

2.2.6时间测试

时间测试也叫耐力测试,是看我们设计的系统是否能够长时间运作接收各种怎么写作而仍能正常工作的测试.

2.3测试过程

在软件开发过程中,当进入需求分析阶段,测试工作也将启动.测试根据开发的各个阶段不断前进也将自己逐步推进到新的层次.

2.3.1测试文档的生成

测试文档的生成包括两个阶段.第一阶段是在需求分析及总体框架设计时测试员生成自己的测试框架,此框架根据需求分析文档得到相应的需求测试文档.当然在此阶段不可能细化测试框架,因为我们还不知道我们的系统细节应该是个什么样子.所以到了详细框架设计时,我们就应该根据此框架设计我们的测试用例.

2.3.2测试框架设计

在此阶段我们得到一个整体的测试框架,我们不要求细化内容,当然也不可能在需求分析阶段做到.我们按照需求分析文档和整体框架设文档设计测试框架.比如对于一个简单的操作系统我们可以：

1文件测试

需求：网络应用,等

2进程测试

需求：客户请求启动相应怎么写作,等

3线程测试

需求：当某一任务启动后又有用户请求,启动一线程为其怎么写作,等

如此得到大致的测试方向,当软件开发进发详细框架设计时,我们就有可能根据相应的文档产生出我们的测试文档了.

2.3.3测试用例设计

我们进入测试文档书写的时候,最重要的就是用例设计.我们对用例的选择,一方面要进行全面性考虑,另一方面我们也要选择那些有代码性的用例来设计.即我们不仅要有数量,面面俱到,还要有质量,每个用例都有一个特定的代表,而并非简单的用例重复.例如:线程测试的一个用例（用例1）

测试名称

线程测试

测试类型

功能测试

预期结果

输出（n,true）n>10

测试目的

在正常情况下线程的最大启动数目应该在10以上

测试简述

1．产生一个线程实例,看是否正确

2．注册一个机制使启动线程不退出

3．循环判断最大启动线程数

4．线程退出,释放资源(如表1）

通过以上的设计,我们就可以方便地进行测试程序的编码了.

2.3.4测试程序的书写

在此阶段我们根据测试文档书写测试代码.在书写代码时我们有几点需要注意：

第一,结果简单.我们需要的最终结果是个易于看易于理解的结果,而并非十分晦涩复杂难懂的文件.初学者最容易犯这个毛病,因为输出多对调试增加了方便.但是我们需要的结果要尽可能简单,因为在dailybuider里面要有生成结果和标准结果的比较,如果复杂了,则不易实现文件的比较.

第二,确保测试程序的正确性.在书写测试程序时我们要确保我们所写的程序是正确的.如果这个都保证不了,那我们就无从谈起发现bug.因为真的发现了问题,我们不知道是自己的程序错误还是其他人犯的错.这就要求我们对我们所测的内容有比较详细的了解.

第三,正确取边界值.在我们做极限测试时,要选取有代表性的边界值用来测量.在此过程要防止单一化,要多选几个靠近边界的值,以达到有效的确定边界.

2.3.5测试报告的填写

我们做好了以上几步后,最终我们还要将测试的过程以文档的形式保存起来,测试报告包括测试时的一些重要信息.比如：

测试报告：

测试题目：线程测试

测试过程：等

预期结果：等

实际结果：等

在测试阶段是否异常：（是／否）

异常描述：等

文档示例3.1

在填写测试报告时要实事求是,把各项详细填写.这样为bug责任人提供修复依据.

2.4测试工具

随着软件工程和软件测试技术的发展,软件测试工具也层出不穷,种类繁多.如Eunit就是比较优秀了工具之一.软件测试工具可分为动态测试分析工具,静态测试分析工具和软件测试管理工具.其中前两项属于软件测试技术的范畴,是按静态测试和动态测试两种主要的测试方法进行分类的.

2.4.1动态测试分析工具

由于动态测试是一项过程性工作,需要经过测试准备（包括测试计划,测试设计和测试开发）测试执行和测试评价等各阶段的工作才能完成,因此软件动太测试工具的主要功能一般包括测试准备,测试执行和测试评价3类.

2.4.2静态测试分析工具

软件的静态测试工具是指在不执行被测程序的条件下,被测软件进行分析的工具.软件静态测试工具主要具有４类功能：分析理解,质量度量,规则检查和特殊检查.

比较典型的测试工具有:QAC,McCabe,PolySpace,Eunit等.

总之,软件测试就是为做出的软件更好地满足用户需求而进行的一致性测评,即测量最终结果是否与需求分析中的用户需求相吻合或吻合程度.软件的测试绝不是在开发过程中可有可无的模块,它占据着一个十分重要的地位,在软件开发过程中我们应给予其足够的重视和正确的认识.