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

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

(本文转载自软件工程专家网 www.21cmm.com
 

  人们常常以为,开发一个程序是困难的,测试一个程序则比较容易。这其实是误解。设计测试用例是一项细致并需要高度技巧的工作,稍有不慎就会顾此失彼,发生不应有的疏漏。

  不论是黑盒测试方法还是白盒测试方法,由于测试情况数量巨大,都不可能进行彻底的测试。所谓彻底测试,就是让被测程序在一切可能的输入情况下全部执行一遍。通常也称这种测试为“穷举测试”。 “黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。 “白盒”法是穷举路径测试,贯穿程序的独立路径数是天文数字,但即使每条路径都测试了仍然可能有错误。第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。第二,穷举路径测试不可能查出程序中因遗漏路径而出错。第三,穷举路径测试可能发现不了一些与数据相关的错误。E.W.Dijkstra的一句名言对测试的不彻底性作了很好的注解:“程序测试只能证明错误的存在,但不能证明错误不存在”。

  在实际测试中,穷举测试工作量太大,实践上行不通,这就注定了一切实际测试都是不彻底的。当然就不能够保证被测试程序中不存在遗留的错误。软件工程的总目标是充分利用有限的人力和物力资源,高效率、高质量地完成测试。为了降低测试成本,选择测试用例时应注意遵守“经济性”的原则。第一,要根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级;第二,要认真研究测试策略,以便能使用尽可能少的测试用例,发现尽可能多的程序错误。掌握好测试量是至关重要的,一位有经验的软件开发管理人员在谈到软件测试时曾这样说过:“不充分的测试是愚蠢的,而过度的测试是一种罪孽”。测试不足意味着让用户承担隐藏错误带来的危险,过度测试则会浪费许多宝贵的资源。

  测试是软件生存期中费用消耗最大的环节。测试费用除了测试的直接消耗外,还包括其它的相关费用。能够决定需要做多少次测试的主要影响因素如下:

①、系统的目的

  系统的目的的差别在很大程度上影响所需要进行的测试的数量。那些可能产生严重后果的系统必须要进行更多的测试。一台在Boeing 757上的系统应该比一个用于公共图书馆中检索资料的系统需要更多的测试。一个用来控制密封燃气管道的系统应该比一个与有毒爆炸物品无关的系统有更高的可信度。一个安全关键软件的开发组比一个游戏软件开发组要有苛刻得多的查找错误方面的要求。

②、潜在的用户数量

  一个系统的潜在用户数量也在很大程度上影响了测试必要性的程度。这主要是由于用户团体在经济方面的影响。一个在全世界范围内有几千个用户的系统肯定比一个只在办公室中运行的有两三个用户的系统需要更多的测试。如果不能使用的话,前一个系统的经济影响肯定比后一个系统大。除此而外,在分配处理错误的时候,所花的代价的差别也很大。如果在内部系统中发现了一个严重的错误,在处理错误的时候的费用就相对少一些,如果要处理一个遍布全世界的错误就需要花费相当大的财力和精力。

③、信息的价值

  在考虑测试的必要性时,还需要将系统中所包含的信息的价值考虑在内,一个支持许多家大银行或众多证券交易所的客户机/服务器系统中含有经济价值非常高的内容。很显然这一系统需要比一个支持鞋店的系统要进行更多的测试。这两个系统的用户都希望得到高质量、无错误的系统,但是前一种系统的影响比后一种要大得多。因此我们应该从经济方面考虑,投入与经济价值相对应的时间和金钱去进行测试。

④、开发机构

  一个没有标准和缺少经验的开发机构很可能开发出充满错误的系统。在一个建立了标准和有很多经验的开发机构中开发出来的系统中的错误不会很多,因此,对于不同的开发机构来说,所需要的测试的必要性也就截然的不同。 然而,那些需要进行大幅度改善的机构反而不大可能认识到自身的弱点。那些需要更加严格的测试过程的机构往往是最不可能进行这一活动的,在许多情况下,机构的管理部门并不能真正地理解开发一个高质量的系统的好处。

⑤、测试的时机

  测试量会随时间的推移发生改变。在一个竟争很激烈的市场里,争取时间可能是制胜的关键,开始可能不会在测试上花多少时间,但几年后如果市场分配格局已经建立起来了,那么产品的质量就变得更重要了,测试量就要加大。测试量应该针对合适的目标进行调整。

  • 0
    点赞
  • 0
    评论
  • 3
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

软件测试基础 一、概述 二、软件测试 三、软件测试基本方法 四、软件测试复杂性经济性 五、软件测试心理学问题 六、好测试工程师应具备素质 七、参考文献   一、概述 信息技术飞速发展,使软件产品应用到社会各个领域,软件产品质量自然成为人们共同关注焦点。不论软件生产者还是软件使用者,均生存在竞争环境中,软件开发商为了占有市场,必须把产品质量作为企业重要目标之一,以免在激烈竞争中被淘汰出局。用户为了保证自己业务顺利完成,当然希望选用优质软件。质量不佳软件产品不仅会使开发商维护费用用户使用成本大幅增加,还可能产生其他责任风险,造成公司信誉下降,继而冲击股票市场。在一些关键应用 (如民航订票系统、银行结算系统、证券交易系统、自动飞行控制软件、军事防御核电站安全控制系统等) 中使用质量有问题软件,还可能造成灾难性后果。 软件危机曾经是软件界甚至整个计算机界最热门话题。为了解决这场危机,软件从业人员、专家学者做出了大量努力。现在人们已经逐步认识到所谓软件危机实际上仅是一种状况,那就是软件中有错误,正是这些错误导致了软件开发在成本、进度质量上失控。有错是软件属性,而且是无法改变,因为软件是由人来完成,所有由人做工作都不会是完美无缺。问题在于我们如何去避免错误产生消除已经产生错误,使程序中错误密度达到尽可能低程度。 给软件带来错误原因很多,具体地说,主要有如下几点: ①、交流不够、交流上有误解或者根本不进行交流 在应用应该做什么或不应该做什么细节(应用需求)不清晰情况下进行开发。 ②、软件复杂性 图形用户界面(GUI),客户/服务器结构,分布式应用,数据通信,超大型关系型数据库以及庞大系统规模,使得软件及系统复杂性呈指数增长,没有现代软件开发经验人很难理解它。 ③、程序设计错误 向所有人一样,程序员也会出错。 ④、需求变化 需求变化影响是多方面,客户可能不了解需求变化带来影响,也可能知道但又不得不那么做。需求变化后果可能是造成系统重新设计,设计人员日程重新安排,已经完成工作可能要重做或者完全抛弃,对其他项目产生影响,硬件需求可能要因此改变,等等。如果有许多小改变或者一次大变化,项目各部分之间已知或未知依赖性可能会相互影响而导致更多问题出现,需求改变带来复杂性可能导致错误,还可能影响工程参积极性。 ⑤、时间压力 软件项目日程表很难做到准确,很多时候需要预计猜测。当最终期限迫近关键时刻到来之际,错误也就跟着来了。 ⑥、自负人更喜欢说: '没问题' '这事情很容易' '几个小时我就能拿出来' 太多不切实际‘没问题’,结果只能是引入错误。 ⑦、代码文档贫乏 贫乏或者差劲文档使得代码维护修改变异常艰辛,其结果是带来许多错误。事实上,在许多机构并不鼓励其程序员为代码编写文档,也不鼓励程序员将代码写得清晰容易理解,相反他们认为少写文档可以更快进行编码,无法理解代码更易于工作保密(“写得艰难必定读痛苦”)。 ⑧、软件开发工具 可视化工具,类库,编译器,脚本工具,等等,它们常常会将自身错误带到应用软件中。就象我们所知道,没有良好工程化作为基础,使用面向对象技术只会使项目变得更复杂。 为了更好地解决这些问题,软件界做出了各种各样努力。 人们曾经认为更好程序语言可以使我们摆脱这些困扰,这推动了程序设计语言发展,更多语言开始流行,为了使程序更易于理解开发了结构化程序设计语言,如PL/1,PASCAL等;为了解决实时多任务需求开发了结构化多任务程序设计语言,如Modula,Ada等;为了提高重用性开发了面向对象程序设计语言,如Simlasa等;为了避免产生不正确需求理解,开发形式化描述语言,如HAL/S等,这使得建立基于自然语言描述成为可能,人们以形式化语言来描述需求;为了支持大型数据库应用,开发了可视化工具,如Visual Studio、Power Builder等。程序语言对提高软件生产效率起到了一定积极作用,但它对整个软件质量尤其是可靠性影响,其他因素相比作用较小。 可能是因为程序语言基于严格语法语义规则,人们企图用形式化证明方法来证明程序正确性。将程序当作数学对象来看待,从数学意义上证明程序是正确是可能。数学家对形式化证明方法最有兴趣,在论文上谈起来非常吸引人,但实际价值却非常有限,因为形式化证明方法只有在代码写出来之后才能使用,这显然太迟了,而且对于大程序证明起来非常困难。 受到其他行业项目工程化启发,软件工程学出现了,软件开发被视为一项工程,以工程化方法来进行规划管理软件开发。 针对需求不确定应用,可以使用渐进迭代类开发模型。还可以采用快速应用程序开发(RAD)协同应用程序开发(JAD)技术,由软件开发者用户代表共同参开发软件规范。RADJAD基本思路是开发者用户共同设计系统中屏幕,开发者迅速地把实现这些屏幕最基本功能编写好,然后把它们交给用户看,然后用户开发者回顾这些屏幕以确认它们达到了用户要求,这个周期一直持续到系统基本部分定义完毕。一旦设计被用户接受,开发者将完成完全实现屏幕需要代码。RAD传统软件开发项目之间一个基本区别是:应用程序RAD系统是按阶段发布。传统项目一般一次发布,也叫“big bang”。RAD方法使用高效开发工具,开发者能够非常迅速地设计出系统基本屏幕,允许用户在开发周期中很早就能见识到系统将来看起来怎么样,避免了在传统开发项目中长篇大论并且枯燥难懂说明。 IBMDr.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%。如果把维护阶段也考虑在内,讨论整个软件生存期时,测试成本比例也许会有所降低,但实际上维护工作相当于二次开发,乃至多次开发,其中必定还包含有许多测试工作。因此,测试对于软件生产来说是必需,问题是我们应该思考“采用什么方法、如何安排测试?” 二、软件测试 软件测试决定了如何去组织测试。如果测试是为了尽可能多地找出错误,那么测试就应该直接针对软件比较复杂部分或是以前出错比较多位置。如果测试是为了给最终用户提供具有一定可信度质量评价,那么测试就应该直接针对在实际应用中会经常用到商业假设。 不同机构会有不同测试;相同机构也可能有不同测试,可能是测试不同区域或是对同一区域不同层次测试。 在谈到软件测试时,许多人都引用Grenford J. Myers在《The Art of Software Testing》一书中观点: ①、软件测试是为了发现错误而执行程序过程; ②、测试是为了证明程序有错,而不是证明程序无错误。 ③、一个好测试用例是在于它能发现至今未发现错误; ④、一个成功测试是发现了至今未发现错误测试。 这种观点可以提醒人们测试要以查找错误为中心,而不是为了演示软件正确功能。但是仅凭字面意思理解这一观点可能会产生误导,认为发现错误是软件测试唯一目,查找不出错误测试就是没有价值,事实并非如此。 首先,测试并不仅仅是为了要找出错误。通过分析错误产生原因错误分布特征,可以帮助项目管理者发现当前所采用软件过程缺陷,以便改进。同时,这种分析也能帮助我们设计出有针对性地检测方法,改善测试有效性。 其次,没有发现错误测试也是有价值,完整测试是评定测试质量一种方法。详细而严谨可靠性增长模型可以证明这一点。例如 Bev Littlewood发现一个经过测试而正常运行了n小时系统有继续正常运行n小时概率。 三、软件测试基本方法
相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值