程序测试经验的总结

发布: 2010-11-25 13:47 作者: webmaster 来源: 本站原创 [浏览次数:33 ]

 程序测试依据测试范畴可分为功能测试性能测试;又可根据测试等级分为单体测试,结合测试等等,其基本的测试流程都如下所示。

  作为一名程序测试员,在发现一个疑似BUG时,需要做到哪些步骤呢?

  发现疑似BUG
  ↓
  确认是否为BUG
  ↓
  分析类型
  ↓
  分析原因
  ↓
  交予开发者修改
  ↓
  确证修改点

  看起来解决一个BUG似乎很简单,可也更加概念化。虽然在工作中会遇到各式各样的问题,但是限于自身的水平以及时间的制约,很多时候我只是在简单得确认完BUG之后,就随手交给开发人员解决。这样看起来似乎测试很简单,只需要遵循最基本的黑盒测试手法,通过不断地确认程序的功能,只需转给其他人解决便可。但是这种测试方法毕竟过于简单,在职业上不利于我们的成长,在工作上则显得相当不负责任。软件程序地开发,本来就是开发与测试相互并重的一个过程。

  开发者的水平保证了软件产品的生产,而测试者的水平则决定了这个产品的质量。虽然在工作流程上看,测试者找BUG,但是就工作量而言,开发者首先承担了很大了编码任务,在完成一个机能之后,往往不是停留下来等待测试者的确认,而是紧接着进行下一个机能的开发任务。

  对应BUG对于开发者来说,只是穿梭在编码过程中的一个插曲,如果这个插曲反客为主,一方面有可能干扰正在进行中的技能的编码质量,从而导致恶性循环。

  虽然编码的质量首先取决于开发者的认真程度,但是测试者的作用是毋庸置疑的。低级测试员当然只能从功能上寻找程序的不良之处,很大程度上就依靠测试者的能力。

  作为一个低级测试员,在面对固有的测试流程时,想必都乐于将问题抛给开发者解决。长期以往,如此做法只会加重开发者的负担,从而拖累了整个项目。而另一方面,测试者一味地逃避困难,不断地将工作重点抛给开发者,只会不断地削弱测试者在整个团队中的作用和影响。

  因此真正要完成作为测试者的职责,其工作手法就不能仅限于以上的几点步骤,而需要对其中进行补充和加强。

  个人认为,找出BUG固然很重要,丹最重要的是要学会分析BUG的原因,而不是简单的确认BUG的类型。

  我先举个简单的实例来具体解释在发现一个BUG时,测试者应当完成的工作。

  1画面上的一个值没有正确SET到DB中
  ↓
  2.确认确实存在错误
  ↓
  3.分析原因:DB值未SET
  ↓
  4.利用以往经验寻找原因:INSERTSQL不正?
  ↓
  5.分析SQL
  ↓
  6.INSERT SQL正确,分析其他原因:相应变量不正?
  ↓
  7.查看相应变量出处以设置方法
  ↓
  8.确认原因
  ↓
  9.向开发者提出BUG并解释原因
  ↓
  10.开发者完成BUG对应后确实画面相应值已正确SET

   




文章“程序测试经验的总结”由 软件测试 整理发布
转载请注明 http://www.testtimes.net/html/73/n-5373.html

Tag: 程序 经验

 

评分:0

我来说两句:


培训  课程
师资  联系我们

1694083235@QQ.Com

北京市通州区弘祥文化园A座