冒烟测试

   项目匆忙进入测试阶段一些功能开发并不完善，集成后进行测试发现好多的js错误，导致测试人员无法正常的进行测试。一个同事提出了“冒泡测试（冒烟测试）”。

   冒烟测试的大致意思是发布一个最新版本，然后开发人员自己去测试自己开发的模块，确保系统能正常运行，尽可能最快的时间发现和修正问题。经冒泡测试第二次发布的版本各个模块js问题大大的减少，效果还是很明显的。

   以下是关于冒泡测试的一些内容。

冒烟测试（smoke testing）,据说是微软起的名字。在《微软项目求生法则》一书第14章“构建过程”关于冒烟测试，就是开发人员在个人版本的软件上执行目前的冒烟测试项目，确定新的程序代码不出故障。

冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板功基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。

冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。

在一般软件公司，软件在编写过程中，内部需要编译多个版本(Builds)，但是只有有限的几个版本需要执行正式测试（根据项目开发计划），这些需要执行的中间测试版本，在刚刚编译出来后，软件编译人员需要进行基本性能确认测试，例如是否可以正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等Bug。如果通过了该测试，则可以根据正式测试文档进行正式测试。否则，就需要重新编译版本，再次执行版本可接收确认测试，直到成功。

新版本的基本功能确认检查的测试，有的公司成为版本健康检查(Build Sanity Check)。对于编译的本地化软件新版本，除了进行上面提到的各种测试检查，还要检查是否在新的本地化版本中正确包含了全部应该本地化的文件。可以通过采用文件和目录结构比较工具，首先比较源语言版本和本地化版本的文件和目录中的文件数目、文件名称和文件日期等，这个过程称为版本镜像检查(Build Image Check)。其次，分别安装源语言版本和本地化版本，比较安装后的文件和目录结构中的文件数目、文件名称和文件日期等，这个过程称为版本安装检查(Build Installing Check)。

    如果不进行冒烟测试那么在系统集成以后，测试人员使用不同的数据在不同的场景下会出现各种各样的问题，就像我们这个项目组遇到的问题一样，不断出现的问题让测试人员没有办法进行下去，而且这些问题不一定是什么大问题。测试人员在提出bug开发人员在去找到对应的bug修改这样中间也是耗费一定时间的对项目进度是不利的！