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

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

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

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

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

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

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