冒烟测试 and 回归测试的概念？

冒烟测试,就是完成一个新版本开发之后,对该版本的最基本功能进行测试，保证基本的功能和流程能走通。严格按照冒烟测试的流程和标准来执行,一旦基本功能点不通过,我们将不予受理测试任务,版本测试必须要有这样一个冒烟测试的过程来约束开发人员,让他们洁身自好,真正负责任的去做产品,帮助开发人员提高自身的质量意识,从而可以更有效的提高产品的质量,和版本发布速度.也许说,效率是要靠团队来推动的。

其中最重要的是：基本功能和流程能走通，就算冒烟测试通过。

下面我具体说说冒烟测试如何执行,如何规范标准?

冒烟测试必须在每次提交新的测试版本后执行，且执行规范需根据需求设计文档来要求,由测试同学写完用例之后，将用例标记为P0。开发同学需要完成P0用例的开发并且自测之后，测试同学就可以执行P0的用例。

一般我们会把用例标记为三个标准：P0、P1、P2.

P0：主要功能流程的用例，需要满足主要的需求、功能流程，这部分用例也是”冒烟测试”过程中需要执行的用例。

P1：非主要功能用例，一般是对某个测试点进行的补充或详细说明，UI测试等。并不是开发必须要执行的，但是在开发提测之后必须要详细测试执行。

P2：一些边缘的测试用例，不影响产品使用和主要的功能，比如兼容测试等。

除了冒烟测试之外，还有回归测试，在面试基础理论时也是会经常的问到。

回归测试的定义就是修改代码之后，是否会对原来的代码或者功能造成影响。

回归测试是只重复以前的全部或部分相同的功能测试，最常见的就是版本迭代过程中，查看之前版本的功能是否正常，是否引入了其他的问题。

新加入的测试模块会影响哪些之前的功能，需要进行版本之间的兼容性测试。

做回归测试时的用例准则同样也有：

1.对于一个软件开发项目来说，项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中，并对其进行维护和管理。当得到一个软件的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候，就可以根据所选择的回归测试策略，从基线测试用例库中提取合适的测试用例组成回归测试包，通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程。

2.测试用例的维护需要有测试同学进行相关规划，维护的主要内容包括以下几个方面：

（1）测试用例剔除：

业务发展需要，某些模块的回归用例可能还是以前的，那么就需要删除掉以前的部分用例，重新去回归测试时需要重点看一下之前的功能是否还存在。

（2）回归测试点要考虑到兼容性：

比如某个用户在新版本上有某某功能，或者某模块的业务，但是在旧的版本上并没有此功能，需要看一下之前版本上该模块的状态，兼容性怎样，产品是否有明确的说明。

3.选择回归测试应该兼顾效率和有效性两个方面，常用的选择回归测试的方式包括：

(1)再测试全部用例：

选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度。

(2)基于风险或改动点进行测试：

基于改动点或者改动范围来进行相应的测试，这种测试最节省时间和有效，因为一般回归测试都是针对功能点的测试，但是有时候评估风险点时可能并不能完全覆盖，有时候可能更加考验测试同学对需求、对系统、对业务流程非常熟悉，才可能会把影响点测试全面。

冒烟测试和回归测试用自动化的方式测试

自动化测试可以提高上边两种测试的执行效率和测试质量。所以自动化的测试测试策略和测试方法有时是非常考验你的。

从需求出发，从冒烟测试、回归测试的侧重点出发，发挥自动化测试的最大价值，这也是我们每个测试同学需要深入思考的点