对软件测试的认识

发布时间:

---------------------------------------------------------------最新资料推荐------------------------------------------------------
对软件测试的认识

对软件测试的认识 赵兴丽 (重庆市北碚区西南大学计算机与信息科学学院,重庆 北碚 400715 摘要:
本文首先就其软件测试的内容、测试原则、测试方法的分类等做了简要的概述。
然后针对软件中的白盒测试、黑盒测试做了详细论述,分析了灰盒测试的必要性,并对处于黑盒与白盒测试之间的灰盒测试做了较细的分析。
最后对这三种软件测试方法做了对比并总结了自己的一点小小的心得体会。 关键字:
黑盒测试 白盒测试 灰盒测试 测试原则 测试方法分类 Abstract
Firstly, the contents of its software testing, test principles, testing methods for classification, a brief overview. Then the white-box testing for software, black box testing are elaborated to analyze the necessity of gray box testing, and in the black box and white box testing gray box testing between the smaller of the analysis done. Finally, do these three software testing methods are compared and summarized their little feelings and experiences. Keywords:

1 / 14

black box testing white box testing gray box testing method for testing the principles of classification 1.软件测试的概 随着人类社会的进步, 经济的发展, 各种领域计算机的普及, 算机软件也遍布了各种场合, 为人们的 生活, 工作,学习, 休闲等提供了前所未有的方便。
因此, 当一个软件从雏形到真正的在一台计算机上运行的时候, 谁也不能保证计算机软件能一步到位的满足人们的需求。
所以产生了软件测试, 软件测试在计算机领域占据着不可替代的角色[1] , 是软件开发过程的重要组成部分,它是用来确认一个程序是否能够满足开发之前用户提出的一些要求。
软件测试就是在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复审,是软件质量保证的关键步骤。 软件测试是为了发现软件中的错误而执行程序的过程。 在软件生存期中软件测试横跨两个阶段:
一般编写完一个模块后就要对它进行测试,这一阶段称单元测试。 编码和单元测试属于软件生存期中的同一个阶段。
在结束这个阶段后对软件系统还要进行各种综合测试,这是软件生存期的另一个独立阶段,又称测试阶段。
软件测试贯穿于整个软件生命周期中,软件测试并不仅局限于程序测试。
需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档,包括需求规格说明、概要设计规格说明、详细设计规格说明及
---------------------------------------------------------------最新资料推荐------------------------------------------------------
源程序,都是软件测试的对象。
Grenford J.Myers 就软件测试目的提出了以下观点:
测试是一个程序的执行过程,其目的在于寻找错误;一个好的测试用例在于能发现到目前为止还没有发现的错误;一个成功的测试是发现了至今未发现的错误的测试。
测试目的不仅为了发现软件漏洞与错误,而且还对软件质量进行度量和评估,以提高软件的质量。
测试以评价系统性能或者程序属性为目标的活动,能够为软件质量的度量与评估的提供依据。
经过分析错误,找到了错误产生的原因,发现当前开发工作所采用的软件的缺陷,以便对软件过程改进。
通过对测试结果的分析整理,还可以修正软件开发规则,并为软件可靠性分析提供参考依据。
2软件测试的内容及原则 2.1 软件测试的内容 软件测试的内容就是说如果拿到一个完整的软件后,接下来要对软件作怎样的处理,包括对软件的验证和确认。
验证和确认都是软件产品在发布前必须要进行的测试活动,二者的区别是测试环境和测试目的不同。
2.1.1 验证(verification 验证(verification就是保证该软件正确地实现了一些特定功能, 即保证软件做了人们所期望软件能够实现的功能。
3 / 14



主要包括以下几个方面:
1.确定软件生存周期中的一个给定阶段的产品是否达到前一阶段确立的需求过程; 2.程序正确性的形式证明, 即采用形式理论证明程序符号设计规定的过程; 3.审查、测试、检查、审计等各类活, 或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。
[5][8] 验证是指已经实现的软件产品是按照它的需求做的,是符合需求说明书的。
验证测试是指测试人员在模拟用户环境的测试环境下,对软件进行测试,验证已经实现的软件产品或产品组件是否实现了需求中所描述的所有需求项。
2.1.2 确认(validation 确认(validation是要做一系列的活动和过程, 目的是为了证实软件在一个给定的外部环境中的逻辑正确性。
从而能够保证软件以正确的方式来做了某一个事件。 包括以下一两个方面:
[5][8] 1.静态确认, 程序不在计算机上实际执行, 通过人工分析来证实软件是正确的; 2.动态确认, 通过执行程序做分析, 测试程序的动态行为, 从而证实软件是否存在问题。
确认是指已经实现的软件产品或产品组件在用户环境下,实现了用户的需要,是符合用户需要的。
确认测试是指测试人员在真实的用户环境下,软件产品或产品组
---------------------------------------------------------------最新资料推荐------------------------------------------------------
件不仅实现了需求中所描述的所有需求项,而且它也是满足用户的最终需要的。
2.2 软件测试的原则 软件测试的原则还没有标准的说法,多数是经验之谈。
从开发者的角度出发,开发者希望测试能表明软件产品不存在错误,且已经实现了用户的需求。
从用户的角度出发,就是希望通过软件测试能充分暴露软件中存在的问题和缺陷;以下几点可以作为测试的基本原则,当然仅供参考: 1)所有的测试应以用户的需求为根本软件测试的目标在于揭示软件中的错误,软件的最终目标是拿来给用户使用。
从用户角度来看,最严重的错误就是那些导致程序无法满足用户需求的错误。
(2 应当把尽早地和不断地进行软件测试作为软件测试者的座右铭。
这一原则就是要求测试工作尽可能早的进行,一免造成以小失大的的不良后果。
应该在测试工作真正开始前的较长时间内就进行测试计划。 测试计划可以在需求模型一完成就开始,详细的测试用例定义可以在设计模型被确定后立即开始。
因此,所有测试应该在任何代码被产生前就进行计划和设计。 (3 Pareto 1879
5 / 14



Villefredo Pareto 提出:
社会财富的 80%是掌握在 20%的人手中,而余下的 80%的人只占 20%的财富。
渐渐地,这种关键的少数(vital few)和次要的多数(trivial many的理论,被广为应用在社会学和经济学中,并被成之为 Pareto 原则(Pareto Principle
[12] 简单地讲,Pareto 原则暗示着测试发现的错误中 80%可能起源于 20%的模块中。
当某个功能出问题,其对用户的影响有多大?然后根据风险大小确定测试的优先级。
优先级高的测试,优先得到执行,一般来讲,针对用户最常用的 20%功能(优先级高的测试会得到完全执行,而低优先级的测试(另外用户不经常用的 80%功能就不是必要的,如果时间或经费不够,就暂时不做或少做。
(4 应由独立的第三方来构造测试 专业性、独立性、客观性和公正性是第三方测试最大的优点。
对软件开发商来说,经过第三方测试机构的测试,不仅可以通过专业化的测试手段发现软件错误,而且还帮助开发商提高软件产品的质量,能够对软件有一个比较科学客观的评价,有助于开发商对自己的产品有一个较好的认识与定位。
(5 充分注意测试中的群集现象 测试后程序残存的错误数目与该程序中已发现的错误数目或检错率成正比。

---------------------------------------------------------------最新资料推荐------------------------------------------------------
不要以为在某个程序段中找到了几个错误就认为该程序中不会有错误了进而就不在进行测试了,其实不然,对于这种错误群集的程序段应该进行重点测试。
(6 对测试错误结果一定要有一个确认的过程, 一般有 A 测试出来的错误, 一定要有一个 B来确认, 严重的错误可以召开评审会进行讨论和分析。
应该从工程的角度理解软件测试,它是有组织、有计划、有步骤的活动。
3 软件测试的分类 根据不同的测试标准,软件测试的种类也不同。
下面就其不同的标准进行了分类,并且着重介绍了黑盒测试、白盒测试以及灰盒测试。
3.1 常用分类 按照开发阶段划分软件测试可分为: 单元测试、集成测试、系统测试、确认测试和验收测试。 按照测试实施组织划分:
开发方测试、用户测试(又称测试)、第三方测试。
按照测试技术分为白盒测试、黑盒测试、灰盒测试;也可分为静态测试、动态测试。
3.2 黑盒测试和白盒测试 3.2.1 黑盒测试 黑盒测试是通过软件的外部表现来发现其缺陷和错误。
黑盒测试也称功能测试或数据驱动测试,该测试的条件是已经知 7 / 14



道了产品所应具有的功能,通过测试来检测每个功能是否都能正常使用。
在进行黑盒测试时,可以把测试程序看作一个不能打开的黑盆子,可以在不考虑程序内部结构和内部特性的情况下,测试者在程序界面处进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息,并保持外部信息(如数据库或文件)的完整性。
[6][7] 黑盒测试方法主要有等价类划分、边值分析、因果图、错误推测等,主要用于软件确认测试。
黑盒测试着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。
[7] 黑盒测试法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。
实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。 这一点也正是人们认为黑盒测试的不足之处。
3.2.2 白盒测试 白盒测试通过对程序内部结构的分析、检测来寻找问题。
白盒测试可以把程序看成装在一个透明的白盒子里,能够清楚地了解程序的内部结构和处理过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的
---------------------------------------------------------------最新资料推荐------------------------------------------------------
功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。
[7] 使用白盒测试法要全面了解程序内部逻辑结构、对所有逻辑路径进行测试。
白盒测试法也是穷举路径测试。
在使用白盒测试方案时,测试者必须检查程序的内部结构,从检查程序的逻辑结构开始,得出测试数据。
即使程序的每条路径都被测试了仍然可能有错误出现。 这是因为:
第一,穷举路径测试决不能查出程序是否违反了设计规范,也就是说程序本身是个错误的程序。
第二,穷举路径测试不可能查出程序中因遗漏路径而出错。 第三,穷举路径测试可能不能发现一些与数据相关的错误。 这也正是该白盒测试方法的缺陷所在。
33 灰盒测试 通过上述对黑盒测试与白盒测试的认识,如果做了这两种测试是否覆盖了软件测试的全部内容,是否就能保证产品的质量呢。
其实是不一定的,或者说如果靠这两种方法来覆盖,投入的代价是比较大的。
因为通过黑盒手工测试是很难完成的,而白盒测试是在单元测试进行的,显然对产品的测试带来很大的局限性,它也无法测试到产品 9 / 14



在集成过程中带来的问题。
那么这时灰盒测试的出现就尤为必要。
3.3.1 灰盒测试的含义 灰盒是是介于白盒测试与黑盒测试之间的测试。
灰盒测试既具有白盒测试的特点,也具有黑盒测试的特点,它关注输出对于输入的正确性;同时也关注内部表现,但不像白盒测试那样详细、完整,只是根据一些表征性的现象、事件、标志来判断内部的运行状态。
测试者可能知道系统组件之间是如何互相作用的,但并不可能对程序内部的功能及运作了解很彻底。
灰盒测试通常与 web 服务应用一起使用,因为尽管应用程序复杂多变,并不断发展进步,因特网仍可以提供相对稳定的接口。 由于不需要测试者接触源代码,所以灰盒测试不存在侵略性和偏见。
开发者和测试者间有明显的区别,人事冲突的风险减到最小。 但是,灰盒测试与白盒测试相比,灰盒测试更难于发现潜在的问题,若在一个单一的应用中,白盒测试可以掌握全部的测试细节。 灰盒测试结合了白盒测试与黑盒测试二者的要素。 它考虑了用户端、特定的系统知识和操作环境。 它在系统组件的协同性环境中评价应用软件的设计。
灰盒测试由方法和工具组成,这些方法和工具取材于应用程序的内部知识和与之交互的环境,能够用于黑盒测试以增强错误发现和错
---------------------------------------------------------------最新资料推荐------------------------------------------------------
误分析的效率、增强测试效率。
灰盒测试关系到测试的输入和输出,但使用关于代码和程序操作等是在测试人员视野之外的信息设计测试 3.3.2 灰盒测试的需求条 灰盒测试法的目的是验证软件满足外部指标要求以及软件的所有通道都进行了检验。
通过该程序的所有路径都进行了检验和验证后, 就得到了全面的验证。
灰盒测试的需要条件有以下几个方面 [4] : (1需要在测试中,不仅部署产品, 还有程序源代码, 不管外部是多少漂亮界面或好使用功能, 最终都是由源代码来实现的。 所以在部署时, 要安装源代码。 从源代码编译生成的目录中运行软件。
[2] (2需要代码覆盖率工具的配置; 部署可以针对本软件开发语言的代码覆盖率工具。
(3测试人员要具备阅读代码的能力, 其对开发语言的熟悉程度和程序设计经验多少决定了采用灰盒测试能够取得多大的好处, 以配置这方面的测试人员或进行必要的培训是必要的。 这也是灰盒测试的缺点之一。
灰盒测试对测试人员的要求也比较高,比如灰盒测试要求测试人员具有丰富的开发知识;需要测试人员更多地从业务层面去考虑问题,考虑更多的组合测试业务场景的能力;另外,很多时候问题的解
11 / 14



决还需要很多外围知识,包括数据库层面上的分析能力、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 的测试例, 必须把周围可能的测试例单独确认一遍。 而就有状态的测试来说, 就更麻烦了,尤其不是一个单独的 test case 造成的问题。
这些在堆的问题中表现的更为突出[9][10][11] 灰盒测试 1够进行基于需求的覆盖测试和基于程序路径覆盖的测试 2测试结果可以对应到程序内部路径,便于 bug 的定位、分析和解决 3能够保
---------------------------------------------------------------最新资料推荐------------------------------------------------------
证设计的黑盒测试用例的完整性, 防止遗漏软件的一些不常用的功能或功能组合 4能够需求或设计不详细或不完整对测试造成的影响 1、投入的时间比黑盒测试大概多 20% - 40%的时间[2] 2、对测试人员的技术要求更高 4.总结 软件测试贯穿了整个软件生命周期。 走查、单元测试、集成测试、系统测试用于整个开发过程中的不同阶段。
开发文档和源程序可以应用单元测试应用走查的方法;单元测试可应用白盒测试方法;集成测试应用近似灰盒测试方法;系统测试和确认测试应用黑盒测试方法。
本文就对软件测试进行了粗略的概述,软件测试的方法很多,针对不同的环境,软件的类型选择不同的测试方法,才能保证软件的可靠运行,从而使软件质量有所保证。
本文只是介绍了软件测试的一些比较浅显的东西。
之所以选择写软件测试这个题目,因为通过学习软件工程这门课程,其中有部分内容对软件测试进行了讲述,加之有位师姐曾经给我说她在做软件测试这方面的工作,当时听后感觉还不清楚软件测试到底是做些什么,便迫不及待的想了解一下这方面的内容,借此机会,故选了该题。
虽然对软件测试的深层含义还没有很透彻的理解,但也或多或少的对软件测试有所理解、认识。 参考文献

13 / 14



[1] /view/105632.htm?func=retitle#6 [2] 陈晓芳,上海交通大学.《几种常见软件可靠性测试方法综述及应用对比》. 中国科技
,
[3]
/view/1d77791b6bd97f192279e97a.html
[4] /view/67c4d5d9d15abe23482f4d40.html [5] 程成、陈霞 《软件工程》机械工业出版社 第八版 p 316 -p 325 [6] 程成、陈霞 《软 p 332 -p 345 [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

对软件测试的认识

相关推荐