软件测试---冒烟测试和回归测试

什么是冒烟测试

冒烟测试是自由测试的一种，是对软件的基本功能进行测试，由开发人员与测试人员共同执行，测试对象是每一个新编译的需要正式测试的软件版本。目的是确认软件的基本功能正常，保证软件系统能正常跑起来，可以进行后续的正常测试工作的进行，如果最基本的测试都有问题了，就直接打回开发部了，所以正式交付的测试版本，必须先通过冒烟测试的考验。

冒烟测试只是一个测试活动，并不是一个测试阶段。也就是说冒烟测试贯穿于测试的任何一个阶段。单元测试、集成测试、系统测试里都会有冒烟测试。

不做冒烟测试的问题

测试人员直接测的话，测试执行一半或者刚开头，就出现基本功能有问题，无法继续测试下去的情况，这时只能中断测试，返回给开发部进行修改，这样会浪费测试部门的时间和资源。

冒烟测试的特点

1.这种测试强调对程序的主要功能进行验证，而不会对具体功能进行更深入的测试。
2.冒烟测试是随着版本转测进行的，它是一个开关(判断版本能否转测试)而不是一个研发流程中的测试阶段。
3.冒烟测试用例一般选取的是测试用例中level 0的用例，保证主功能可用。
4.冒烟测试就是在一个新版本出来的时候，将软件的全部功能过一遍，看有没有什么大问题。如果功能可以正常运行，不会影响测试进行，那么这个版本就可以真正开始测试了。如果功能有重大问题或影响测试进行，那么这个版本就是不合格的，不用进行进一步的测试。

谁来执行冒烟测试

1.开发：编码完成后，开发可根据测试提供的冒烟用例进行自测
2.产品：验收阶段，产品可根据冒烟用例对产品进行验收。
3.测试：开发提测后，测试根据冒烟用例进行测试验证。

执行冒烟测试的前提

由于冒烟测试是与开发的合同协作，因此有几个合作前提：
1.初步了解代码中进行了什么更改。若要理解该更改，必须理解使用的技术
2.开发需告知此修改对其他功能是否影响
3.更改对各组件的依存关系有何影响

执行冒烟测试需要注意的

1.列出冒烟测试的主要功能、测试点。
2.冒烟测试不是只对修改过功能进行测试
3.重视平时测试时容易忽略的隐藏功能
4.重视常见又很重要的步骤 如：下载安装

冒烟测试的实现过程

1.测试规划阶段：冒烟测试用例的编写以及测试执行都是需要时间成本的，故在最初制作项目计划的时候，就应该识别该任务，并充分考虑其工作量。根据项目实际，确定在单元测试，集成测试，系统测试的哪个或哪几个阶段开展冒烟测试。
2.冒烟测试用例设计：分析系统主要功能和业务流程，编写覆盖这些功能的正向测试用例。如果没有用例就无法跟踪和掌握整个冒烟测试的重点以及各个版本之间的冒烟对比。冒烟测试用例应该随着系统的不断扩展而不断扩展，它不应该是一成不变的。
3.冒烟测试执行：每个版本发布时，根据版本包含的功能特性，评估需要执行的冒烟测试用例。
4.冒烟测试结果输出：冒烟测试执行情况，通过的测试用例数，不通过的测试用例数，据此判断是否开始正式的测试。

冒烟测试用例应该包含的内容

1.业务流的测试：保证正常业务链路的通畅。
2.工作流的测试：主要是测试流程流转是否正常，至于流程步骤的表单内容是否正确则不关注。
3.关键功能的测试：至少要保证系统运转所需的启动数据以及一些开关控制正常。
4.重要基本功能的测试：比如对核心业务有影响的一些增删改等。

冒烟测试的入口准则

1.软件版本已经发布
2.冒烟测试计划和测试用例通过评审
3.测试环境准备完毕

冒烟测试的出口准则:

1.发现的致命和严重类缺陷为0
2.一般和建议类缺陷总数/冒烟场景总数<= 2
3.所有必选测试场景的通过率=100%
4.随即抽取的可选测试场景通过率>80%

冒烟测试自动化

冒烟测试可以手动执行，可以考虑自动化执行。稳定的系统适合自动化冒烟测试，集成过程中的系统适合手工冒烟测试，因为冒烟测试内容在动态变化，变化中的自动化脚本维护工作量比较大。
自动化冒烟测试脚本应当遵循的原则
1.覆盖主要功能
2.测试脚本要简单、易用
3.测试脚本要独立：每个测试脚本要尽可能的独立，每个测试脚本覆盖的测试点要尽可能的单一
4.要有对测试脚本的设计和说明文档，以便于维护。
5.测试结果收集：留存每一次的测试结果，对比一段时间内的测试结果，可以知道产品那些功能点质量不稳定，如果同一个测试点在一段时间内经常不能够测试通过，那么这一部分的代码十分有必要进行review，有可能存在更大的隐患。

什么是回归测试

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误，回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试，在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。
因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。

回归测试一般是在进行软件的第二轮测试开始的，验证第一轮中发现的问题是否得到修复，当然回归也是一个循环的过程，穿插在软件测试整个生命周期里面，如果回归的问题不通过，则需要开发人员修改后再次回归，直到通过为止。

冒烟测试和回归测试的区别

冒烟测试：

冒烟测试就是完成一个新版本的开发后，对该版本最基本的功能进行测试，保证基本的功能和流程能走通，如果不通过，则打回开发那边重新开发；
如果通过，才会进行下一步的测试（功能测试、集成测试、系统测试等等） 优点：节省测试时间，减少测试轮数，防止build失败，缺点是覆盖率比较低。

回归测试有两种理解：

一是：当你修复一个BUG后，把之前的测试用例再次应用到修复后的版本上进行测试。
二是：一个版本开发好后，且冒烟测试通过，此时可以先用上一个版本的测试用例对新版本进行测试，看是否有BUG。其实回归测试用的很多，比如新增一个功能模块等等，所以自动化测试可以高效率的进行回归测试。