软件冒烟测试报告,冒烟测试方法及报告模板

本文章转载于搜狗测试

不知道大家在日常工作中，有没有遇到以下情形：

情景1：“新版本提测了，测试拿过版本就开始进行测试，测试半天后，突然发现：某个功能实现逻辑与需求不符，开发需要重新修改，已测试的功能白测了~~”

情景2：“新版本提测后，执行半天用例后，发现部分功能不可用，后面的用例直接阻塞了~~”

遇到以上情况，即影响测试进度，又影响测试心情，怎么办？今天小编就给大家介绍一下“冒烟测试”(或叫“预测试”)

冒烟测试的目的：

确认提测模块的基本功能、实现逻辑符合需求，可以进行后续的正式测试工作，将正式测试未知的风险降至最低，防止bug阻塞导致测试进度阻塞

冒烟测试时机：

1. 新增功能提测时

2. Bug修改或需求变更对原有功能模块逻辑修改范围较大

冒烟测试时间安排：

由各模块负责人安排具体的预测试时间。参考规则：

1. 冒烟测试的时间可根据模块的复杂程度来定，复杂度越高的模块，预测试的时间可以安排的长些

2. 冒烟测试时间一般不超过该模块一轮测试时间的10%

冒烟测试标准：

有以下1条执行结果，预测试不通过

1. 提测模块中，不可测试的功能点占总功能点的40%以上

2. 崩溃或bug导致70%以上的功能无法测试(即有70%的测试用例阻塞测试。另：若阻塞部分有独立模块，与其他模块无影响时，该模块可以测试)。

3. 崩溃频繁导致无法进行测试。

4. 半个小时随机测试，发现bug数量超过20个

5. 兼容机型、浏览器等有一半以上不可用，需要与开发负责人确认修改范围是否与兼容有关，再评估是否可测试

6. 个别bug影响60%以上的功能逻辑

冒烟测试结果模板：

邮件主题：【xx版本-冒烟测试结果】——xx模块验证通过/验证不通过

邮件发送：发给开发；抄送给产品、开发经理、测试项目负责人

模板字段说明：

预测试验证次数：验证该模块预测试的次数

模块名称：测试验证的功能模块

提交bug个数：填写该模块一共提交了几个bug

阻塞Bug或严重bug说明：bug相关说明

模块状态说明：

分别说明当前模块可测试内容、不可测试内容、未提测内容，内容填写样式如上表；如果全部可测试，直接填写全部可测试；如果部分可测试，需要填写测试时间

测试负责人和开发负责人：对应相关人员

预计测试时间 ：说明预计开始测试时间点

项目进度影响：填写对当前项目进度的影响；如果无，则填写“无”