冒烟测试,是对软件的基本功能进行测试,测试对象是每一个新编译的需要正式测试的软件版本,目的是确认软件的基本功能正常,保证软件系统能正常跑起来,可以进行后续的正常测试工作的进行,如果最基本的测试都有问题了,就直接打回开发部了,所以正式交付的测试版本,必须先通过冒烟测试的考验
冒烟测试只是一个测试活动,并不是一个测试阶段。也就是说冒烟测试贯穿于测试的人一个阶段。单元测试、集成测试、 系统测试里都会有冒烟测试。
测试是测试人员确认软件存在bug的过程,此过程中不可避免是需要开发人员要不停的修改bug,那么常常会发现一个功能的改动,导致下一轮系统测试出现问题。即发现也许以前修改的bug的确是解决了,可是由于修改一个或多个bug导致其他功能模块出现新的问题,测试跑不通了,只能测试终止。那么我们如何确保开发人员修复了bug后,这个bug的修复没有影响到其他功能模块呢?这时就需要进行冒烟测试啦。
由于冒烟测试特别关注更改过的代码,因此必须与编写代码的开发人员协同工作。必须了解以下内容:
代码中进行了什么更改。若要理解该更改,必须理解使用的技术;开发人员可以提供相关说明。
更改对功能有何影响。
更改对各组件的依存关系有何影响。
在进行冒烟测试前检查代码
在运行冒烟测试前,进行侧重于代码中的所有更改的代码检查。代码检查是验证代码质量并确保代码无缺陷和错误的最有效、 最经济的方法。冒烟测试确保通过代码检查或风险评估标识的主要的关键区域或薄弱区域已通过验证, 因为如果失败,测试就无法继续。
在干净的调试版本中安装私有二进制文件
由于冒烟测试必须侧重于仅对更新后的二进制文件中的功能更改进行验证,所以必须通过使用被测试文件的调试二进制文件来使测试 在干净的测试环境中运行。 注意:在冒烟测试中,使用不匹配的二进制文件进行测试是一个常见错误。为了避免此错误,当两个或多个更新后的二进制文件之间存 在依赖项时,请在测试版本中包括所有更新后的二进制文件。否则,测试的结果可能无效。
创建每日构建(Daily Build)
每日构建要求团队成员协同工作,并鼓励开发人员彼此保持同步。如果新版本的迭代被延迟,则该延迟很容易导致具有多个依赖项的 产品不同步。遵循每日构建和冒烟测试的过程,任何更改过的或新的二进制文件都可确保实现高质量。
注意:将高质量的每日构建作为团队最重要的任务。如果由于嵌入代码未进行冒烟测试而导致版本中断,则需要开发人员和测试人员停止所有其他工作,直到问题被解决为止。对导致中断版本的人员的处罚不应该很重,但这个处罚一定要能强调这样一个道理:正确构建是团队最重要的任务。
不需要执行穷举测试。冒烟测试的目的不是确保二进制文件100%没有错误。这样需要花费太多的时间。执行冒烟测试是为了在高级别验证版本。要确保二进制文件中的更改不会破坏常规版本的稳定性,也不会导致功能中出现严重错误。
Web测试和负载测试
生成Web测试和负载测试时,在运行任何时间长、工作量大的测试之前运行冒烟测试是一种很好的做法。在Web测试和负载测试中, 冒烟测试时间短,工作量也小。使用冒烟测试是为了在运行性能测试或压力测试之前,确保一切都已正确配置并可按预期运行。
测试经理和项目经理等相关人员从测试用例库中选定重要的测试用例,标记为冒烟测试用例。或者单独编写。
1、主流程和主功能的确认
要求测试人员在测试开始前跟开发人员确认需求和重要的流程、功能,最好将功能点和流程以及预期结果和开发人员说明清楚。 冒烟测试不要求测试结果像正式测试阶段那么准确,但是也需要列一个指标来衡量测试是否通过。)
2、预计时间
根据列出的功能点和开发人员代码质量的可信度,评估冒烟测试在不同环境下可能花费的最长和最短时间,列到测试计划中。
3、数据的准备
在测试前,透彻的了解主要功能对应表的存储结构,准备好需要的数据。冒烟测试开始后,不会因为这些工作浪费时间。
测试人员严格按照前期的约定去校验主流程,全部校验完和开发人员报告情况,不能放过一个主要的测试功能点。
作者:Shining-LY
原文链接:https://blog.csdn.net/qq_37964547/article/details/82185640