冒烟测试和回归测试
1.何为冒烟测试
冒烟测试是自由测试的一种。冒烟测试在测试中发现问题，找到了一个bug，然后开发人员会来修复这个bug。这时想知道这次修复是否真的解决了程序的bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为冒烟测试。在很多情况下，做冒烟测试是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的bug。
2.何为回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。
回归测试一般是在进行软件的第二轮测试开始的，验证第一轮中发现的问题是否得到修复。当然回归也是一个循环的过程，穿插在软件测试整个生命周期里面。如果回归的问题不通过，则需要开发人员修改后再次回归，直到通过为止。
3.两者有何区别
冒烟测试就是完成一个新版本的开发后，对该版本最基本的功能进行测试，保证基本的功能和流程能走通。如果不通过，则打回开发那边重新开发;如果通过测试，才会进行下一步的测试(功能测试，集成测试，系统测试等等)。冒烟测试优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。
回归测试我有两层理解，一是就是当你修复一个bug后，把之前的测试用例再次应用到修复后的版本上进行测试。二是当一个新版本开发好后，而且冒烟测试通过，此时可以先用上一个版本的测试用例对新版本进行测试，看是否有bug!其实回归测试用的很多，比如新增加一个功能模块等等，所以自动化测试可以高效率的进行回归测试。
4.如何做好冒烟测试
冒烟测试必须在每次提交新的测试版本前执行,且执行规范需根据需求设计文档来要求,开发在每次接受新的开发需求时,必须按照需求文档严格整理出冒烟测试点,也就是基本功能点,毕竟这些功能点都是开发人员要完成的,可能会认为这个工作不重要,如果整理出了这些基本功能点,就不会导致后期版本发布时出现功能遗漏,或者功能实现有缺陷等等问题,只有将所有的问题保留在前期的需求评审阶段,才能更有效率完成用户的需求,后期出问题的几率也就大大降低。
冒烟测试的规范,其实冒烟测试规范取决于人,而不在于流程,如果需求分析做的很细致,就不可能不规范,就不会冒烟标准,更不会存在争议的问题所在,所以这就需要开发在设计阶段对需求的把握,要实现什么样的功能,达到什么样的效果,其实开发在做之前是有预想的,但是到底是否符合用户的需求,就要看跟用户的需求沟通和评审,所以这里所说的准备还是由设计阶段产生的冒烟测试点,然后定义实现的情况,并给出最后评审.当然不同的项目是不一样的,但是准则是冒烟测试不通过,产品是不能提交给测试人员测试的,因为它不具备测试条件。
冒烟测试的执行到底该由谁来做,严格来说,测试人员肯定是要做冒烟测试的,因为这是测试流程中的首要阶段,也是必要条件之前,测试人员执行冒烟测试不通过,就说明版本不具备测试条件,重新发回给开发人员.但是如果每次都出现这种问题,因为冒烟测试不通过而打回原形必然回耽误大家的时间,而为了节省这个时间,提高版本发布的效率,那就需要开发人员自己做冒烟测试,只有开发在提版本之前做一个版本自身体检,才能让这个版本健康的发布出去,这样才会有效的提高大家的工作效率,开发人员做冒烟测试是应该,因为这也是对自身工作负责任的一种态度,通过冒烟测试他们能够检查一次那些需求没有实现,是否有遗漏的,就不会将原本就无效的版本发给测试,导致最后还要被发回重审,既浪费时间,又大大降低效率。
5.如何做好回归测试
关于如何做好回归测试，大体上的人都是认为是先验证bug，然后回归和本次修改相关的地方，但如何评估和此次修改相关的风险，这是一个相对重要且考验对系统认知度的问题。在我们平时的回归测试中，是如何做这一点呢?
(1)和项目中的开发以及项目负责人沟通确认。
这是一个很关键的环节，好的开发人员在提交测试时就会注明可能影响的地方。
(2)关键点的测试。
就是很重要的部分，即使看着和本次修改无太直接关联，也最好能走一下基本流程。因为这是客户最关心的地方点，也是盈利的所在。比如测试的重点：bug修改，关联功能，新增加功能，修改功能呢个，上一轮测试bug多的功能。(测试人员要了解开发在这一轮修改了哪些bug，要注意关注我们的bug管理工具上的变化。)
(3)对开发人员能力的评估。
好的开发人员，修改缺陷时，会修改过程中注意对其它地方的修改。但能力不足的开发人员可能考虑较少。导致修改后，引起的2次bug较多，这个时候就需要加大测试力度，可能的话要整个模块基本功能进行回归。
(4)项目初期对测试用例的维护。
一个项目在开始时，编写测试用例时往往是对这个系统全面了解的过程，这个时候时间也较为充裕，所以写测试用例时，尽可能标注关联测试用例。这在大型项目里是尤其重要的。
(5)变换测试人员，回归比较繁琐，可以通过测试人员的轮流进行减轻一个人做回归的厌倦。
