对于冒烟测试的一点疑惑

jeffwang

就我的理解而言, 冒烟测试的重点在于对build出来的软件的主要功能进行随机测试 根据测试结果衡量软件是否值得QA测试. 但是如何衡量哪些功能是主要的呢, 对于一个SQA框架的软件来说, 主要的功能和框架在前期就已经基本成型, 就我的理解,后期不断集成的功能只是对主要功能进行一个丰富,或者说后期集成的功能即使有严重的bug 也不会对主要功能造成影响.

那么如何看待后期集成的这些功能呢, 是否有必要将他们加入到冒烟测试里面呢? 如何需要 那么要以什么标准进行选择呢?

jeffwang

汗  抛了砖 连块砖头都没引出来

jessica42237728

据说，冒烟测试是微软提出的。微软的测试使用的是每日build。每日build是编写自动化测试代码，回归测试系统。冒烟测试应该是每日build之前，就是系统提交给测试部门测试之前，先运行一下，看是否能够在主要功能上运行得起。然后，发到测试部门，看值不值得测试部门运行自动化脚本进行全面测试。
   对于你所说的情况，在前期主要功能已经开发完毕的情况下，再以后添加的小功能应该就属于回归测试的阶段了。如果主要的功能都已经通过测试了，说明冒烟测试是早已经通过的。这个时侯，小功能的更改引发的版本的提交，是要进行回归测试的，而不必要纠结是否需要将添加的小功能填写到冒烟测试用例中的。
   当然，如果你所说的添加的功能是一个独立的模块，是后期作为独立功能模块开发和测试的。那么在提交测试之前，可以对这个新增功能模块的主要功能进行冒烟测试用例的组织。（这就相当于另一轮新的测试了，我觉得你说的好像不属于此类情况。）
   这是我的理解，不对的地方，就当是你引出来的另一块砖头吧。。呵呵。

[ 本帖最后由 jessica42237728 于 2008-12-22 11:17 编辑 ]

dpgibson

冒烟测试来源于硬件测试。线路板首次加电后，看看是不是冒烟了。
Build后的版本确认测试，有两个目的。一是确认主要功能是否可用，二是确认新增功能是否可测。达到测试接受标准。 具体情况还要看流程而定。

咚咚宝031102

2   3楼说的没有错


简单的说     冒烟测试就是实现最基本的功能

shunfyu

  我老和程序员开开玩笑，说你们每天都在做 "Smoke Testing" ，我们就省了吧   
注：Smoke Testing 表示吸烟。。。

maguschen

有谁能够百分百肯定知道后期被继承进来的components没有对已有的功能造成影响呢？

例如一个FTP软件，主要功能当然是上传和下载了，这个功能应该在很早的时候已经完成并且通过测试；有一天，某人突发奇想，要换一个更加漂亮的上传LOGO，然后这个行为就break了上传功能了。在这样的情况下冒烟测试就有体现出其价值了。

majun915

学习了 哈哈