对软件测试的几点看法

简介:

软件测试作为软件质量保证的重要手段已引起软件用户和开发人员越来越多的关注。然而在对测试认识逐渐深化的过程中,首先应该弄清几个问题。

  非进行测试不可吗?

  世界软件市场将有一个突飞猛进的发展,应用程序的类型越来越复杂,从传统客户/服务器应用,到基于浏览的Internet/Intranet应用,再到混合型应用等等。在这些大量的、日渐复杂的应用程序中,由于GUI的对象丰富,使得状态组合数量巨增;软、硬件来自不同厂商,程序运行环境复杂;版本不断升级以及同时使用某个厂家的不同版本,致使程序运行环境经常改变;并发用户的数量逐渐增多,对性能要求不断提高等等。可见,随着软件业的发展,测试成为必然。

  据统计,在软件开发总成本中,用在测试上的开销要占30%到50%。如果把维护阶段考虑在内,讨论整个软件生存期时,测试的成本比例也许会有所降低,但实际上维护工作相当于二次开发,乃至多次开发,其中必定还包含有许多测试工作。因此,有人估计软件工作有50%的时间和50%以上的成本花在测试工作上。因此,测试是必需的,问题是我们应该思考“采用什么方法、如何安排测试?”

  测试和调试可以相互替代吗?

  为了判断应用系统是否合格,而用预先确定的一系列数据在系统中运行,并与预期的结果进行比较,这一过程称为测试。它是软件质量保证的重要手段。然而,有些人往往把测试和调试混为一谈,这是不正确的。

  简单地说,测试是一种检验,经过测试人们会看到一些现象。这些现象也许是可疑的征兆,但往往不能直接从测试的结果中找到错误的根源。这就需要充分利用测试结果和测试提供的信息进行全面分析,以便找到错误的根源和出现错误的原因。紧接着便是纠正已发现的错误。测试以后进行的这些工作称为调试或排错。

  我们不能把两者混为一谈。但它们毕竟有着密切的关系,常常是在测试以后紧接着要着手排错。实际上,这两种工作经常交叉进行,是不可相互替代的。

  科学的测试应从何时开始?

  有一种传统的观念认为:“应用系统开发完毕,再对它进行测试。”用这种思想来指导测试工作是相当危险的。

  对于软件质量的判断决不只限于程序本身,它和编码以前所完成的需求分析及软件设计工作密切相关。很显然,表现在程序中的错误,并不一定是编码所引起的,很可能是详细设计、概要设计阶段,甚至是需求分析阶段的问题引起的。错误在初期也许只是范围很小的隐藏问题,但由于各开发阶段的连续性,使其逐步扩展。如果早期开发中出现的错误不能及时发现和解决,将带到设计、编码、测试等各阶段,影响会逐步扩大。这就要付出不必要的人力、物力来修正错误。可见,解决问题、纠正错误应追溯到前期的工作,越早着手越好。科学的测试是贯穿整个产品生命周期中的测试。

  考虑到以上这些情况,我们将测试分成如下阶段:模块测试、集成测试、确认测试和系统测试。对程序的最小单位——模块进行测试,是为了检验每个模块能否单独工作,从而发现模块的编码问题和算法问题;集成测试是将多个模块连接起来,以检验概要设计中对模块之间接口设计的问题;确认测试则应以需求规格说明书中的规定作为检验尺度,发现需求分析的问题;最后的系统测试是将开发的软件与硬件和其他相关因素(如人员的操作、数据的获取等)综合起来进行全面检验,这样的做法涉及到软件需求以及软件与系统中其他方面的关系。

  我们应着眼于整个软件生存期,特别是着眼于编码以前各开发阶段的测试工作,以保证软件的质量,这就要突破原来对测试的理解。据有关机构研究表明:在开发周期中,每推后一步实施错误检查,成本就会增加10%。因此,查找、修改错误的最佳开始时间是在项目设计阶段,之后还要伴随着开发过程的每一个环节,保证测试与开发的同步进行。

  对软件能够做到彻底测试吗?

  既然测试的目的就是查找软件中的错误,那么为了得到高质量的软件,能不能借助测试工具将所有隐藏的错误全部找出来呢?

  我们知道,只有对应用的每一个运行环境、语句、条件分支、路径等进行穷举测试,才能确保测试的彻底性。但往往这种做法工作量过大,所用时间过长,实际是不现实的,因而也就失去了实用价值。软件工程的总目标是充分利用有限的人力和物力资源,高效率、高质量地完成测试开发项目。在测试阶段既然穷举测试是不现实的,为了节省时间和资源,提高测试效率,就必须精心设计测试用例,这样采用这些测试数据能够取得最佳的测试效果。掌握测试量的度是至关重要的。一位有经验的软件开发管理人员在谈到软件测试时曾这样说过:“不充分的测试是愚蠢的,而过度的测试是一种罪孽。”测试不足意味着让用户承担隐藏错误带来的危险;过度测试则会浪费许多宝贵的资源。到测试后期,即使找到了错误,然而已经付出了过高的代价。总之,进行测试是为了使软件中蕴涵的缺陷低于某一特定阈值,使产出/投入比达到最大。








====================================分割线================================



最新内容请见作者的GitHub页:http://qaseven.github.io/

目录
打赏
0
0
0
0
26197
分享
相关文章
程序员为何需要反复修改Bug?探寻代码编写中的挑战与现实
作为开发者,我们在日常开发过程中,往往会遇到反复修改bug的情况,而且不能一次性把代码写的完美无瑕,其实开发项目是一项复杂而富有挑战性的任务,即使经验丰富的程序员也难以在一次性编写完美无瑕地完成代码,我个人觉得一次性写好代码是不可能完成的事情。虽然在设计之初已经尽力思考全面,并在实际操作中力求精确,但程序员仍然需要花费大量时间和精力来调试和修复Bug。那么本文就来分享程序员需要反复修改Bug的原因,以及在开发中所面临的复杂性与挑战。
242 1
程序员为何需要反复修改Bug?探寻代码编写中的挑战与现实
谈谈讲清楚这件事的重要性
如何讲清楚一件事我相信很多人都很困惑也很无助,尤其是在晋升场合,在向上汇报或者是做大范围分享的时候,恨不得找个地缝钻进去。很多时候我们常常是这样安慰自己,我是实干派技术人,不需要那些花里胡哨的东西,我技术过硬比什么都重要。曾经一度我也是这样认为,最后改变我这个想法的是一句话:如果你讲不清楚多半是想不清楚,如果你都想不清楚如何能够带领更多人拿到结果?
1615 12
软件测试面试技巧有哪些?这几点你得知道,不然后悔都来不及
新手测试技术不过硬,最害怕hr在面试时,问到技术方面的问题,那么在进行软件测试面试时,有哪些软件测试面试技巧可以帮助测试人,提高面试通过率呢?
201 0
程序员写好技术文章的几点小技巧
去年成为了内网技术分享平台的年度作者,受邀写一篇关于“如何写好文章”的文章。我本身并不喜欢写字,去年写的几篇文章,涉及的话题自带流量,所以阅读量多了一些,谈不上有多擅长。不过还是决定分享一下自己在写文章时用到的一些小技巧,希望对大家有帮助。
程序员写好技术文章的几点小技巧
关于软件工程的几点思考
来阿里已经很长一段时间了,从刚开始来我就想写点关于软件工程,服务化和开发效率的个人理解,却一直没有想好怎么写,一直在心里筹划思考该如何准确地表达我所想的内容,也能够给别人带来一些有价值的信息,但是拖了很久了,想想还是写出来罢,没有必要追求那么完美,欢迎拍砖。(顺便说下,有观点认为拖延症患者都有或多或少的完美主义倾向,处女座的同学验证下哈。) ## 1 什么是软件工程? 服务化其实是一个软
2402 0
谈谈软件测试领域
功能测试-自动化测试-性能测试-测试管理   测试发展前景,测试的薪资水平, 大公司与小公司的区别 测试的职位级别工作如何划分 工作任务如何分配 用户体验测试 易用性测试 专项测试 网站b/s,web、移动app、客户端c/s 业务UAT测试 。。。
788 0