软件测试基础(2)

发表于:2014-12-13来源:uml.org.cn作者:不详点击数: 标签:软件测试基础
可能是因为程序语言基于严格的语法和语义规则,人们企图用形式化证明方法来证明程序的正确性。将程序当作数学对象来看待,从数学意义上证明程序是

  可能是因为程序语言基于严格的语法和语义规则,人们企图用形式化证明方法来证明程序的正确性。将程序当作数学对象来看待,从数学意义上证明程序是正确的是可能的。数学家对形式化证明方法最有兴趣,在论文上谈起来非常吸引人,但实际价值却非常有限,因为形式化证明方法只有在代码写出来之后才能使用,这显然太迟了,而且对于大的程序证明起来非常困难。

  受到其他行业项目工程化的启发,软件工程学出现了,软件开发被视为一项工程,以工程化的方法来进行规划和管理软件的开发。

  针对需求不确定的应用,可以使用渐进和迭代类的开发模型。还可以采用快速应用程序开发 (RAD)和协同应用程序开发(JAD)技术,由软件开发者和用户代表共同参与开发软件规范。RAD和JAD的基本思路是开发者和用户共同设计系统中的屏幕,开发者迅速地把实现这些屏幕的最基本功能编写好,然后把它们交给用户看,然后用户和开发者回顾这些屏幕以确认它们达到了用户的要求,这个周期一直持续到系统的基本部分定义完毕。一旦设计被用户接受,开发者将完成完全实现屏幕需要的代码。RAD和传统软件开发项目之间的一个基本区别是:应用程序RAD系统是按阶段发布的。传统项目一般一次发布,也叫“big bang”。RAD方法使用高效开发工具,开发者能够非常迅速地设计出系统的基本屏幕,允许用户在开发周期中很早就能见识到系统将来看起来怎么样,避免了在传统开发项目中长篇大论并且枯燥难懂的说明。

  IBM的Dr.Harlan Mills提出了净室过程。净室过程组合了形式化程序验证和统计过程控制(SPC)。在这种方法中,首先用正确性数学证明预防缺陷发生,然后用MTBF度量软件质量。净室过程是一种相当新的软件开发方法,它要求软件开发在管理方式和技术方法上作重大改变,特别是要求SPC应用到软件的知识,这影响了其被广泛的接受。

  硬件成本持续降低,可支持 CASE工具运行的新的强大的工作站和网络已经成为软件工程使用的工作平台,CASE工具可完成一些特定的软件开发过程。这些工具提供给软件设计者以图形方式描述软件设计的能力,这样就易于维护、易于交叉检查、易于理解。许多人(尤其是CASE工具供货商)相信CASE工具扮演了解决软件危机和拯救软件工业的角色,但事实上我们看到的情形却是许多公司花了大量的金钱买回的CASE工具但很少使用,原因在于这些工具执行的过程与机构的软件设计过程不相适用。

  在可以借助许多新的技术和工具进行软件开发的今天,软件开发过程的成熟性问题开始引起人们的重视。这种产品一致性问题的主要症结在于管理,因此人们将目标转向了管理的改善,一些以改进软件开发过程为目标的活动已经展示出积极的结果。

  以下是一些比较典型的文本。

  SEI SW-CMM

  ISO SPICE( Software Process Improvement and Capability dEtermination )

  Bootstrap

  ISO-9000-3

  TickIT

  Trillium

  事实上,对于软件来讲,还没有象银弹那样的东西。不论采用什么技术和什么方法,软件中仍然会有错。采用新的语言、先进的开发方式、完善的开发过程,可以减少错误的引入,但是不可能完全杜绝软件中的错误,这些引入的错误需要测试来找出,软件中的错误密度也需要测试来进行估计。

  测试是所有工程学科的基本组成单元,是软件开发的重要部分。自有程序设计的那天起测试就一直伴随着。统计表明,在典型的软件开发项目中,软件测试工作量往往占软件开发总工作量的 40%以上。而在软件开发的总成本中,用在测试上的开销要占30%到50%。如果把维护阶段也考虑在内,讨论整个软件生存期时,测试的成本比例也许会有所降低,但实际上维护工作相当于二次开发,乃至多次开发,其中必定还包含有许多测试工作。因此,测试对于软件生产来说是必需的,问题是我们应该思考“采用什么方法、如何安排测试?”

  二、软件测试的目的

  软件测试的目的决定了如何去组织测试。如果测试的目的是为了尽可能多地找出错误,那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。如果测试目的是为了给最终用户提供具有一定可信度的质量评价,那么测试就应该直接针对在实际应用中会经常用到的商业假设。

  不同的机构会有不同的测试目的;相同的机构也可能有不同测试目的,可能是测试不同区域或是对同一区域的不同层次的测试。

原文转自:http://www.uml.org.cn/bzgf/bzgf060802.htm