软件测试的原则

1.尽早和不断地测试

        要尽早地测试,让测试人员在软件的需求和设计阶段就介入,而不是等这些工作全部完成了才进行测试。就像在建筑大楼预浇水泥框架前首先对设计蓝图进行仔细的核查,如果浇好了框架却发现出了问题就不是拆不拆这么简单的了(我认为软件开发过程跟建筑过程一样)。问题发现得越早,解决问题的代价就越小,这算是一条真理。发现软件错误的时间在整个软件过程阶段中越靠后,修复它所消耗的资源就越大。

       不断的测试应该表现为反复的、递增的,这和现在的很多项目都采用螺旋迭代——测试同样应该是增量的,每一次增量完成以后部分测试进入回归测试形式,下一次测试的开始覆盖前几次测试的范围。

2.彻底的测试不可能
       初涉软件测试人员希望拿到软件后就进行完全的测试,找出所有的软件错误,并使软件趋于完美。想法是非常好的,但是实现它是不可能的,哪怕是最简单的程序,主要原因有四个原因:
  • 测试数据输入量太大
  • 输出结果太多
  • 软件的操作步骤太多
  • 软件说明书并非“盲人手册”
      就是因为存在着输入量太大,输出结果太多,软件实现途径太多和软件实现没有客观标准,从不同的角度看软件缺陷的标准不同这些客观因素的存在,所以我们只能做到有限数量路径测试。
      如果时间不够,无法进行充分的测试怎么办?—— 使用风险分析,确定测试的重点!
      由于很少有机会对一个应用软件进行所有可能的测试 (包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西),对大多数软件开发项目来说,利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由,也可采用正式的方法。
  • 对于该项目的用途而言,哪种功能最重要?
  • 哪种功能对用户最明显?
  • 哪种功能对安全影响最大?
  • 哪种功能对用户最有用?
  • 对客户来说,该应用软件的哪个部分最重要?
  • 在开发过程中,该应用软件的哪个部分可以最先测试?
  • 哪一部分代码最复杂,容易导致出现错误?
  • 哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?
  • 哪一部分程序与过去项目中引起问题的部分相类似/有关?
  • 哪一部分程序与过去项目中需要大量维护的部分相类似/有关?
  • 需求和设计的那些部分不清楚或不容易读?
  • 开发人员认为在应用软件中哪些部分是高风险的?
  • 哪些问题能造成最差的发行?
  • 哪些问题最能引起用户抱怨?
  • 哪些测试可以容易地覆盖多种功能?
  • 哪些测试在覆盖高风险部分的测试时使用时间最少?

3.软件测试是有风险的行为
     
        如果决定不去测试所有的情况,那么我们就面临了很大的风险,比如在计算器例子中假设1024+1024会出现致命的错误,那么你会怎么办?所以说这也变相说明了为什么有些错误我们怎样测试都发现不了,一但到了客户那里马上为客户所发现。

     软件测试人员需要学会的一个主要本领就是如何把无边无际的可能性控制到一个可以接受的范围内,这就需要根据风险制定出相应的计划了。

     我们可以通过对资源的调节,对测试程度和范围进行有效控制。一边是完全测试,另一边是从不测试,这都是测试的两个极端表现。至于往哪边移动就看你的现有资源投入了,原则是尽量使用有限资源得到最大的回报。我们可以通过对测试用例复用、测试数据选取来确定对测试的充分性,但是不管怎样测试总有错误会遗留给用户,经过长时间反复的使用才让它真正暴露出来。这就是测试只能保证尽可能多地发现错误,不能保证发现所有的错误。

4.并非所有的错误都能修复

       在软件测试中最令人沮丧的是,即使你全力以赴也不能保证所有你发现的软件错误都能被正确的关闭,这并不意味着软件测试人员未达到目的,要知道现在我们所使用的任何软件系统中都存在着大大小小的软件缺陷。
  • 没有足够的时间。在任何一个项目中,通常是所包含的软件功能复杂,而代码的编写人员和测试人员较少。并且,在项目进度中没有为修改和再次测试留出足够的项目时间。
  • 不算真正的软件错误。总会有人说:这不算真正的软件缺陷,而是一项真正的软件功能。在某些场合和环境下,错误的理解、测试本身的错误和不完整的软件说明书会把软件缺陷当作附加功能来对待。
  • 修复的风险太大。非常遗憾的是这样的情况经常出现,软件本身是脆弱的、难以理清的。也可以这样说软件就是一团乱麻,所以修复它需要冒很大的风险,也许修复了一个软件错误导致出现了其它更多的软件错误。如果项目进度紧张,修改软件错误要冒更大的风险,所以跳过这些以避免出现更多的麻烦也是一种安全之道。
  • 不值得修复。不常出现的软件错误和在一些不太常用的功能中包含的软件错误可以放过,虽然这看上去有点“违反原则”。不值得修复并不意味着不修复,只不过这些错误将在螺旋模型的下一次过程中被一一修复。
5.反向思维逻辑.
      测试最重要的一件事就是要考虑到所有的出错可能性。同时,还要做一些不是按常规做的、非常奇怪的事。说起来可能不太好听,测试的过程就像黑客(Hacker)的攻击过程那样。可以这么说,像黑客这样的人是最好的软件安全测试员。他们专门找软件的漏洞,从而破坏这个软件,这样就可以修复这些漏洞来保证软件的性能。如果找不到这种漏洞,那就说明该软件质量己经很好了
      除了漏洞之外,测试还应该考虑性能(Performance)问题,也就是一定要保证软件运行得很好,非常快,没有内存泄漏,不会出现那种越来越慢的情况。我们可以在不关机的情况下,与其他软件一起持续运行一个多月,看看是否会出现越来越慢的情况(当然必须保证其他软件是没有问题的)。我们在做IE 的时候,就是让它72小时连续不停地打开不同的网页,处理几万个不同的网页,而且速度不能减慢。有许多软件,当只有一两个人用的时候,可能感觉不到什么问题,而当几百个用户一起用的时候,有的网站就出现各种各样的异常,这就是测试工作还比较欠缺的缘故。
      另外,测试还要考虑软件的兼容性(Compatibility)。一般来说,一个软件是由许多小软件构成的,如果其中一个小软件与它的前一版本不兼容,那么这个软件就会出现错误。这种错误需要通过测试来发现和解决。许多人认为写代码的人一定能找出错误来。其实开发人员在写代码的时候,如果有错误,他可以意识到了,可是写出来的错误,他不一定能想得到。我自己也编过程序,在编程序的时候很自信,觉得不会有错,可事实上,即使是我编的小程序也有错误,但要自己找出来,却要费很大劲。

6.由小到大的测试范围

     小规模代表着测试的粒度,或者表现为某种程度的单元测试。多块的单元测试构成了测试的基底(如果是面向对象的测试则单元测试被替换为“类测试”,集成测试被替换为“交互测试”),测试进度曲线依据这个基底向更高一级的测试过程过渡。

7.避免检查自己的代码
  • 程序员从来都不会承认自己写的程序有错误
  • 程序员测试自己的编码是一件很糟糕的事
  • 但是让他们测试别人的编码却成了最好的测试人员。
  • 程序员的测试思路有明显的局限性
  • 多数程序员没有经过严格正规的职业训练
  • 程序员无良好的BUG跟踪和回归测试习惯

8.追溯至用户需求

“产品缺陷的80%以上是在产品开发过程中的需求定义阶段引入的,如果需求得到了准确的验证,则可以消除80%的返工问题,节省总项目投入费用的45%”。
总项目费用的45%这是多么客观的一个数字,还有什么理由来阻止我们不在需求阶段就介入严格的测试工作呢?
需求评审报告
设计评审报告


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值