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

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



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



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



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



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


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


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


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



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



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


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

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



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


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


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


(1)测试用例剔除:


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


(2)回归测试点要考虑到兼容性:


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


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


(1)再测试全部用例:


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


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


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


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


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


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

发布于 2019-02-24