zoukankan      html  css  js  c++  java
  • 再谈冒烟测试

          记得有一次面试中面试官问了我一个问题,谈谈什么是冒烟测试,我当时就傻了,估计人家从这个问题中就得出结论,我还是个新手,也许测试还没入门呢!不过只有跌倒过一次,才不会再次在原来的地方跌倒,不然那样就太糟糕了.就因为这样我回去好好翻了翻资料,把冒烟测试理清楚了,原来如此!

          冒烟测试,严格来说就是一个基本功能点的验证测试,可能是我在上家公司的产品质量不怎么样的缘故吧,我们做得比较多的是冒烟测试,每次只要开发人员一提交测试版本到测试部门,我们会严格按照冒烟测试的流程和标准来执行,一旦基本功能点不通过,我们将不予受理测试任务,并可以保留对开发人员的上诉意见,虽然我们每次执行的不是很严格,但每次总会做这么一个过程.不是为了针对谁,而且版本测试必须要有这样一个冒烟测试的过程来约束开发人员,让他们洁身自好,真正负责任的去做产品,帮助开发人员提高自身的质量意识,从而可以更有效的提高产品的质量,和版本发布速度.也许说,效率是要靠团队来推动的.

         下面我想具体说说冒烟测试如何执行,并且如何规范标准,还有就是该由谁来做?

         冒烟测试必须在每次提交新的测试版本前执行,且执行规范需根据需求设计文档来要求,开发在每次接受新的开发需求时,必须按照需求文档严格整理出冒烟测试点,也就是基本功能点,毕竟这些功能点都是开发人员要完成的,可能会认为这个工作不重要,如果整理出了这些基本功能点,就不会导致后期版本发布时出现功能遗漏,或者功能实现有缺陷等等问题,只有将所有的问题保留在前期的需求评审阶段,才能更有效率完成用户的需求,后期出问题的几率也就大大降低.

         冒烟测试的规范,其实冒烟测试规范取决于人,而不在于流程,如果需求分析做的很细致,就不可能不规范,就不会冒烟标准,更不会存在争议的问题所在,所以这就需要开发在设计阶段对需求的把握,要实现什么样的功能,达到什么样的效果,其实开发在做之前是有预想的,但是到底是否符合用户的需求,就要看跟用户的需求沟通和评审,所以这里所说的准备还是由设计阶段产生的冒烟测试点,然后定义实现的情况,并给出最后评审.当然不同的项目是不一样的,但是准则是冒烟测试不通过,产品是不能提交给测试人员测试的,因为它不具备测试条件.

         冒烟测试的执行到底该由谁来做,我们以前公司也经常碰到这样的矛盾,其实开发人员不愿意做测试是事实,但是提高产品的质量最后还是由开发人员自己来完成,这一点测试人员也无能为力,但如何才能让他们体会到这一点呢.那就需要通过严格的考核标准来推动,有压力才有动力,这个准则任何时候都是有效果的.其实严格来说,测试人员肯定是要做冒烟测试的,因为这是测试流程中的首要阶段,也是必要条件之前,测试人员执行冒烟测试不通过,就说明版本不具备测试条件,重新发回给开发人员.但是如果每次都出现这种问题,因为冒烟测试不通过而打回原形必然回耽误大家的时间,而为了节省这个时间,提高版本发布的效率,那就需要开发人员自己做冒烟测试,只有开发在提版本之前做一个版本自身体检,才能让这个版本健康的发布出去,这样才会有效的提高大家的工作效率,开发人员做冒烟测试是应该,因为这也是对自身工作负责任的一种态度,通过冒烟测试他们能够检查一次那些需求没有实现,是有遗漏的,就不会将原本就无效的版本发给测试,导致最后还要被发回重申,既浪费时间,又大大降低效率,何必呢?

          所以说任何一个理论的诞生都是有它的依据和道理的,虽然麻烦一点,但是效率提高了很多,何乐而不为呢!

  • 相关阅读:
    OpenCascade Ray Tracing Rendering
    Create New Commands in Tcl
    OpenCascade Modeling Algorithms Fillets and Chamfers
    OpenCascade Modeling Algorithms Boolean Operations
    Construction of Primitives in Open Cascade
    Open Cascade Data Exchange STL
    Tcl Tk Introduction
    Open Cascade DataExchange IGES
    Netgen mesh library : nglib
    Hello Netgen
  • 原文地址:https://www.cnblogs.com/candle806/p/1858378.html
Copyright © 2011-2022 走看看