首页 > 软件测试 > 浅谈软件测试用例

浅谈软件测试用例

 一、我们在什么时候可以设计测试用例?

  当根据客户的需求整理出项目需求分析文档时,我们就可以根据需求文档来编写测试用例了。但是,一般我们(国内大多小公司)项目需求文档都非常“简陋”,所以,很难根据需求文档设计测试用例。

  我们只有等到项目开发人员把项目开发出来,给我们系统文档、部署环境、数据库结构(如果系统牵涉到数据库的话),我们根绝这些文档来设计测试用例。


  二、测试用例的评审与更新

  我们设计的测试用例设计完成之后,是否完整?是否符合系统?符合客户要求?对用例做一个评审是必不可少。关于评审的方式,不同的公司有不同的流程。

  我们编写的测试用例也不是经过评审之后就不变了,随着需求的变更、功能的改进,测试用例当然也需要更新和变动。

  三、什么情况下不适合写测试用例

  文件时间

  如果一个功能我很快就测试完了,而且只需要测试一遍,但我们设计测试用例时却比较麻烦,花时间也长。这个时候就没必要编写测试用例了。

  需求变动大且频繁

  需求的功能变动非常频繁,而且变动很大,之前编写的测试用例根本没法使用,必须要重新编写,这个时候也没必要去设计测试用例了。

  项目时间不允许

  这一项是不太厚道的做法,如果不是急需交付客户的话,尽量不要这样做;当然了,如果只是给客户展示或试用,可以在之后进行补充和完善测试用例。

  不要编写不完整或别人看不懂的测试用例,那样就没有意义了。

  四、停止软件测试的标准。

  语句覆盖最低不能小于80%,测试需求覆盖率达到100%,测试用例覆盖率达到100%,一、二级缺陷修复率达到100%,三、四级修复率达到80%。

  (上面一句是再在网上找的,不是标准,只是个参考)

  bug等级:

  一级:非常严重的bug
  二级:严重的bug
  三级:一般性的bug
  四级:建议性问题

  五、关于探索性测试

  完全的执行测试用例时一件非常枯燥的事情,个人在执行测试用例时会做一些,其它的非常规性的操作,看系统是否会有相应的处理和提示。我的一部分bug就是再这种非常规操作下发现的。

  当然了真正的探索性测试需要对产品的深入了解,以及软件开发技术有一定的深度和宽度。姑且把我们的探索性测试看成是瞎捣鼓吧!呵呵。

  六、交叉测试

  有木有发现,当我们第一遍测试系统时,会非常认真,但要我们测试第二遍时,我们不愿意像第一次那样认真的去测了,这不能说明我们不负责,而是每个人都有的心理现象。这个时候,我们可以和其它测试人员交换功能来测试,提高效率,而且更容易发现问题。

  七、测试的目的

  1、我们让它做的它必须会做。

  2、我们不让它做的它必须不会做。

  可能你会发现有附加功能的时候,就是客户没有要求,我们加了这样的功能,可能加了这点功能系统看上去会更好。这时怎么办?算问题么?

  作为开发人员,中规中矩的做东西最好,如果真的有非常好的功能要加的话,需要和客户沟通,然后写到需求里。毕竟多一点功能多一点风险。呵呵

  作为测试人员,凡是不符合需求文档的都需要当问题点提出。责任分明,以免后续麻烦。

除非注明,文章为IT热血青年原创,欢迎转载!转载请注明本文地址,谢谢。
本文地址:http://blog.itblood.com/on-the-software-test-case.html

  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.