对软件测试的认识Word格式文档下载.docx
- 文档编号:17669117
- 上传时间:2022-12-08
- 格式:DOCX
- 页数:8
- 大小:22.18KB
对软件测试的认识Word格式文档下载.docx
《对软件测试的认识Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《对软件测试的认识Word格式文档下载.docx(8页珍藏版)》请在冰豆网上搜索。
在软件生存期中软件测试横跨两个阶段:
一般编写完一个模块后就要对它进行测试,这一阶段称单元测试。
编码和单元测试属于软件生存期中的同一个阶段。
在结束这个阶段后对软件系统还要进行各种综合测试,这是软件生存期的另一个独立阶段,又称测试阶段。
软件测试贯穿于整个软件生命周期中,软件测试并不仅局限于程序测试。
需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档,包括需求规格说明、概要设计规格说明、详细设计规格说明及源程序,都是软件测试的对象。
GrenfordJ.Myers就软件测试目的提出了以下观点:
测试是一个程序的执行过程,其目的在于寻找错误;
一个好的测试用例在于能发现到目前为止还没有发现的错误;
一个成功的测试是发现了至今未发现的错误的测试。
测试目的不仅为了发现软件漏洞与错误,而且还对软件质量进行度量和评估,以提高软件的质量。
测试以评价系统性能或者程序属性为目标的活动,能够为软件质量的度量与评估的提供依据。
经过分析错误,找到了错误产生的原因,发现当前开发工作所采用的软件的缺陷,以便对软件过程改进。
通过对测试结果的分析整理,还可以修正软件开发规则,并为软件可靠性分析提供参考依据。
2.软件测试的内容及原则2.1软件测试的内容软件测试的内容就是说如果拿到一个完整的软件后,接下来要对软件作怎样的处理,包括对软件的验证和确认。
验证和确认都是软件产品在发布前必须要进行的测试活动,二者的区别是测试环境和测试目的不同。
2.1.1验证(verification)验证(verification)就是保证该软件正确地实现了一些特定功能,即保证软件做了人们所期望软件能够实现的功能。
主要包括以下几个方面:
1.确定软件生存周期中的一个给定阶段的产品是否达到前一阶段确立的需求过程;
2.程序正确性的形式证明,即采用形式理论证明程序符号设计规定的过程;
3.审查、测试、检查、审计等各类活动,或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。
[5][8]验证是指已经实现的软件产品是按照它的需求做的,是符合需求说明书的。
验证测试是指测试人员在模拟用户环境的测试环境下,对软件进行测试,验证已经实现的软件产品或产品组件是否实现了需求中所描述的所有需求项。
2.1.2确认(validation)确认(validation)是要做一系列的活动和过程,目的是为了证实软件在一个给定的外部环境中的逻辑正确性。
从而能够保证软件以正确的方式来做了某一个事件。
包括以下一两个方面:
:
[5][8]1.静态确认,程序不在计算机上实际执行,通过人工分析来证实软件是正确的;
2.动态确认,通过执行程序做分析,测试程序的动态行为,从而证实软件是否存在问题。
确认是指已经实现的软件产品或产品组件在用户环境下,实现了用户的需要,是符合用户需要的。
确认测试是指测试人员在真实的用户环境下,软件产品或产品组件不仅实现了需求中所描述的所有需求项,而且它也是满足用户的最终需要的。
2.2软件测试的原则软件测试的原则还没有标准的说法,多数是经验之谈。
从开发者的角度出发,开发者希望测试能表明软件产品不存在错误,且已经实现了用户的需求。
从用户的角度出发,就是希望通过软件测试能充分暴露软件中存在的问题和缺陷;
以下几点可以作为测试的基本原则,当然仅供参考:
(1)所有的测试应以用户的需求为根本软件测试的目标在于揭示软件中的错误,软件的最终目标是拿来给用户使用。
从用户角度来看,最严重的错误就是那些导致程序无法满足用户需求的错误。
(2)应当把尽早地和不断地进行软件测试作为软件测试者的座右铭。
这一原则就是要求测试工作尽可能早的进行,一免造成以小失大的的不良后果。
应该在测试工作真正开始前的较长时间内就进行测试计划。
测试计划可以在需求模型一完成就开始,详细的测试用例定义可以在设计模型被确定后立即开始。
因此,所有测试应该在任何代码被产生前就进行计划和设计。
(3)Pareto原则应用于软件测试1879年,意大利人VillefredoPareto提出:
社会财富的80%是掌握在20%的人手中,而余下的80%的人只占有20%的财富。
渐渐地,这种关键的少数(vitalfew)和次要的多数(trivialmany)的理论,被广为应用在社会学和经济学中,并被成之为Pareto原则(ParetoPrinciple)。
[12]简单地讲,Pareto原则暗示着测试发现的错误中80%很可能起源于20%的模块中。
当某个功能出问题,其对用户的影响有多大?
然后根据风险大小确定测试的优先级。
优先级高的测试,优先得到执行,一般来讲,针对用户最常用的20%功能(优先级高)的测试会得到完全执行,而低优先级的测试(另外用户不经常用的80%功能)就不是必要的,如果时间或经费不够,就暂时不做或少做。
(4)应由独立的第三方来构造测试专业性、独立性、客观性和公正性是第三方测试最大的优点。
对软件开发商来说,经过第三方测试机构的测试,不仅可以通过专业化的测试手段发现软件错误,而且还帮助开发商提高软件产品的质量,能够对软件有一个比较科学客观的评价,有助于开发商对自己的产品有一个较好的认识与定位。
(5)充分注意测试中的群集现象测试后程序残存的错误数目与该程序中已发现的错误数目或检错率成正比。
不要以为在某个程序段中找到了几个错误就认为该程序中不会有错误了进而就不在进行测试了,其实不然,对于这种错误群集的程序段应该进行重点测试。
(6)对测试错误结果一定要有一个确认的过程,一般有A测试出来的错误,一定要有一个B来确认,严重的错误可以召开评审会进行讨论和分析。
应该从工程的角度理解软件测试,它是有组织、有计划、有步骤的活动。
3软件测试的分类根据不同的测试标准,软件测试的种类也不同。
下面就其不同的标准进行了分类,并且着重介绍了黑盒测试、白盒测试以及灰盒测试。
3.1常用分类按照开发阶段划分软件测试可分为:
单元测试、集成测试、系统测试、确认测试和验收测试。
按照测试实施组织划分:
开发方测试、用户测试(又称测试)、第三方测试。
按照测试技术分为白盒测试、黑盒测试、灰盒测试;
也可分为静态测试、动态测试。
3.2黑盒测试和白盒测试3.2.1黑盒测试黑盒测试是通过软件的外部表现来发现其缺陷和错误。
黑盒测试也称功能测试或数据驱动测试,该测试的条件是已经知道了产品所应具有的功能,通过测试来检测每个功能是否都能正常使用。
在进行黑盒测试时,可以把测试程序看作一个不能打开的黑盆子,可以在不考虑程序内部结构和内部特性的情况下,测试者在程序界面处进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息,并保持外部信息(如数据库或文件)的完整性。
[6][7]黑盒测试方法主要有等价类划分、边值分析、因果图、错误推测等,主要用于软件确认测试。
黑盒测试着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。
[7]黑盒测试法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。
实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。
这一点也正是人们认为黑盒测试的不足之处。
3.2.2白盒测试白盒测试通过对程序内部结构的分析、检测来寻找问题。
白盒测试可以把程序看成装在一个透明的白盒子里,能够清楚地了解程序的内部结构和处理过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。
[7]使用白盒测试法要全面了解程序内部逻辑结构、对所有逻辑路径进行测试。
白盒测试法也是穷举路径测试。
在使用白盒测试方案时,测试者必须检查程序的内部结构,从检查程序的逻辑结构开始,得出测试数据。
即使程序的每条路径都被测试了仍然可能有错误出现。
这是因为:
第一,穷举路径测试决不能查出程序是否违反了设计规范,也就是说程序本身是个错误的程序。
第二,穷举路径测试不可能查出程序中因遗漏路径而出错。
第三,穷举路径测试可能不能发现一些与数据相关的错误。
这也正是该白盒测试方法的缺陷所在。
3.3灰盒测试通过上述对黑盒测试与白盒测试的认识,如果做了这两种测试是否覆盖了软件测试的全部内容,是否就能保证产品的质量呢。
其实是不一定的,或者说如果靠这两种方法来覆盖,投入的代价是比较大的。
因为通过黑盒手工测试是很难完成的,而白盒测试是在单元测试进行的,显然对产品的测试带来很大的局限性,它也无法测试到产品在集成过程中带来的问题。
那么这时灰盒测试的出现就尤为必要。
3.3.1灰盒测试的含义灰盒是是介于白盒测试与黑盒测试之间的测试。
灰盒测试既具有白盒测试的特点,也具有黑盒测试的特点,它关注输出对于输入的正确性;
同时也关注内部表现,但不像白盒测试那样详细、完整,只是根据一些表征性的现象、事件、标志来判断内部的运行状态。
测试者可能知道系统组件之间是如何互相作用的,但并不可能对程序内部的功能及运作了解很彻底。
灰盒测试通常与web服务应用一起使用,因为尽管应用程序复杂多变,并不断发展进步,因特网仍可以提供相对稳定的接口。
由于不需要测试者接触源代码,所以灰盒测试不存在侵略性和偏见。
开发者和测试者间有明显的区别,人事冲突的风险减到最小。
但是,灰盒测试与白盒测试相比,灰盒测试更难于发现潜在的问题,若在一个单一的应用中,白盒测试可以掌握全部的测试细节。
灰盒测试结合了白盒测试与黑盒测试二者的要素。
它考虑了用户端、特定的系统知识和操作环境。
它在系统组件的协同性环境中评价应用软件的设计。
灰盒测试由方法和工具组成,这些方法和工具取材于应用程序的内部知识和与之交互的环境,能够用于黑盒测试以增强错误发现和错误分析的效率、增强测试效率。
灰盒测试关系到测试的输入和输出,但使用关于代码和程序操作等是在测试人员视野之外的信息设计测试3.3.2灰盒测试的需求条件灰盒测试法的目的是验证软件满足外部指标要求以及软件的所有通道都进行了检验。
通过该程序的所有路径都进行了检验和验证后,就得到了全面的验证。
灰盒测试的需要条件有以下几个方面[4]:
(1)需要在测试中,不仅部署产品,还有程序源代码,不管外部是多少漂亮界面或好使用功能,最终都是由源代码来实现的。
所以在部署时,要安装源代码。
从源代码编译生成的目录中运行软件。
[2]
(2)需要代码覆盖率工具的配置;
部署可以针对本软件开发语言的代码覆盖率工具。
(3)测试人员要具备阅读代码的能力,其对开发语言的熟悉程度和程序设计经验多少决定了采用灰盒测试能够取得多大的好处,所以配置这方面的测试人员或进行必要的培训是必要的。
这也是灰盒测试的缺点之一。
灰盒测试对测试人员的要求也比较高,比如灰盒测试要求测试人员具有丰富的开发知识;
需要测试人员更多地从业务层面去考虑问题,考虑更多的组合测试业务场景的能力;
另外,很多时候问题的解决还需要很多外围知识,包括数据库层面上的分析能力、J2EE服务器内部的调用链分析等。
灰盒测试是一个非常好的测试理念,但要真正发挥其作用,显然还需要借助于相应的自动化工具。
AppSight[3]就是其中一种自动化工具。
3.3.3白盒、黑盒、灰盒测试方法的优缺点比较[2]测试方法优点缺点白盒测试1、使测试人员仔细思考软件的实现2、可以检测代码中的每条分支和路径3、揭示隐藏在代码中的错误4、对代码的测试比较彻底5、相对比较优化1、代价高2、无法检测代码中遗漏的路径和数据敏感性错误3、不能验证规格的正确性黑盒测试1、基本上不用人管着,如果程序停止运行了一般就是被测试程序crash了2、设计完测试例之后,下来的工作就是比较好做了,当然更苦闷的是确定crash原因.[2][9]1、结果取决于测试用例的设计,测试例的设计部分来源于经验2、没有状态转换的概念,目前一些成功的例子基本上都是针对PDU来做的还做不到针对被测试程序的状态转换来做3、就没有状态概念的测试来说,很难寻找和确定造成程序crash的测试例,必须把周围可能的测试例单独确认一遍。
而就有状态的测试来说,就更麻烦了,尤其不是一个单独的testcase造成的问题。
这些在堆的问题中表现的更为突出[9][10][11]灰盒测试1、能够进行基于需求的覆盖测试和基于程序路径覆盖的测试2、测试结果可以对应到程序内部路径,便于bug的定位、分析和解决3、能够保证设计的黑盒测试用例的完整性,防止遗漏软件的一些不常用的功能或功能组合4、能够需求或设计不详细或不完整对测试造成的影响1、投入的时间比黑盒测试大概多20%-40%的时间[2]2、对测试人员的技术要求更高4.总结软件测试贯穿了整个软件生命周期。
走查、单元测试、集成测试、系统测试用于整个开发过程中的不同阶段。
开发文档和源程序可以应用单元测试应用走查的方法;
单元测试可应用白盒测试方法;
集成测试应用近似灰盒测试方法;
系统测试和确认测试应用黑盒测试方法。
本文就对软件测试进行了粗略的概述,软件测试的方法很多,针对不同的环境,软件的类型选择不同的测试方法,才能保证软件的可靠运行,从而使软件质量有所保证。
本文只是介绍了软件测试的一些比较浅显的东西。
之所以选择写软件测试这个题目,因为通过学习软件工程这门课程,其中有部分内容对软件测试进行了讲述,加之有位师姐曾经给我说她在做软件测试这方面的工作,当时听后感觉还不清楚软件测试到底是做些什么,便迫不及待的想了解一下这方面的内容,借此机会,故选了该题。
虽然对软件测试的深层含义还没有很透彻的理解,但也或多或少的对软件测试有所理解、认识。
参考文献:
[1]/view/105632.htm?
func=retitle#6[2]陈晓芳,上海交通大学.《几种常见软件可靠性测试方法综述及应用对比》.中国科技信息,[3]/view/1d77791b6bd97f192279e97a.html[4]/view/67c4d5d9d15abe23482f4d40.html[5]程成、陈霞译《软件工程》机械工业出版社第八版p316-p325[6]程成、陈霞译《软件工程》机械工业出版社第八版p332-p345[7]/view/0543457101f69e3143329440.html[8]Rakitin,S.K.《软件验证与确认的最佳管理办法》电子工业出版社2019[9]马瑞芳,王会燃.《计算机软件测试方法的研究》小型微型计算机系统,2003年12月期[10]徐明,杨文.《软件测试与软件可靠性的研究》.中国科技信息,2006年第11期[11]陆民燕,陈雪松.《软件可靠性测试及其实践》.测控技术,2019年19卷第5期[12]/thread-4000-1-1.html
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 认识