在一般的项目里，我们往往需要进行多个版本的测试工作，但是在我们按照计划执行正式的系统集成测试前，我们需要作一些中间测试版。
在刚刚编译出来后，软件编译人员需要进行基本性能确认测试，例如是否可以正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等Bug。
如果通过了该测试，则可以根据正式测试文档进行正式测试。否则，就需要重新编译版本，再次执行版本可接收确认测试，直到成功。
何为冒烟测试？
冒烟测试是自由测试的一种，冒烟测试是测试中发现的问题，找到了一个bug，然后开发人员会来修复这个bug，这时想知道这次修复是否真的解决了程序的bug，或者是否会对其他模块造成影响，就需要针对此问题进行专门测试，这个过程就称为冒烟测试。
在很多情况下，做冒烟测试是开发人员试图解决一个问题的时候，造成了其他功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其他的额问题，这就可能引起了其他新的BUG。
冒烟测试引入到软件测试中，是指测试人员在正规测试一个新版本之前，先投入较少的人力和时间验证一个软件的主要功能，如果主要功能都没有实现，则打回开发组重新。
这样做的好处是可以节省大量的时间成本和人力成本。
何为回归测试？
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误，回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大量的工作量比重，软件开发的各个阶段都会进行多次回归测试，在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。
因此，通过选择正确的回归测试策略来改进回归测试策略来改进回归测试的效率和有效性是非常有意义的。
回归测试一般是在进行软件的第二轮测试开始的，验证第一轮中发现的问题是否得到修复，当然回归也是一个循环的过程，穿插在软件测试整个生命周期里面，如果回归的问题不通过，则需要开发人员修改后再次回归，直到通过为止。
两者有何区别？
冒烟测试就是完成一个新版本的开发后，对该版本最基本的功能进行测试，保证基本的功能和流程能走通，如果不通过，则打回开发那边重新开发；
如果通过测试，才会进行下一步的测试（功能测试、集成测试、系统测试等等。冒烟测试）优点是节省测试时间，防止build失败，缺点是覆盖率比较低。
回归测试有两种理解：
一是：当你修复一个BUG后，把之前的测试用例再次应用到修复后的版本上进行测试。二是：一个版本开发好后，而且冒烟测试通过，此时可以先用上一个版本的测试用例对新版本进行测试，看是否有BUG其实回归测试用的很多，比如新增加一个功能模块扥等，所以自动化测试可以高效率的进行回归测试。