冒烟测试流程规范

一、流程阶段

需求开发完成，开发自测后，产品先和开发进行验收

产品验收通过后，可发给设计进行UI走查，开发发送提测邮件

产品、开发、测试一起进行冒烟

对于目前没测试资源的项目，可以先进行冒烟，等到开始测试前再次进行冒烟（此次的冒烟阶段为测试主导，如发现严重问题，可与产品及开发人员进行商定，是否需要变更需求或方案）

未通过的项目再次进行冒烟时，需要冒烟所有的用例，而不只是单独针对上次未通过的部分进行冒烟

二、冒烟用例

由测试来编写，项目用例评审时一起进行评审，或直接发给产品及开发确认

三、冒烟流程执行

前端、后端、产品（设计）及测试共同参加，产品操作来进行演示

可由测试辅助提供账号或数据等操作

四、通过标准（优先级从上到下）

无阻碍测试部分

主流程全部通过

冒烟case通过率百分之九十以上

冒烟结果邮件模板（测试发送）【测试工时大于等于1pd的所有项目都需要发送冒烟结果邮件】【小于1pd的项目，如果有严重阻塞的部分可选择发送冒烟结果不通过的邮件】

邮件主题：【项目冒烟通告】（项目标题）冒烟结果     如：【项目冒烟通告】Android点播、回放重构冒烟结果

收件人：全部涉及开发+产品+测试 抄送 技术部 产品等

邮件正文：

【项目链接】

https://www.tapd.cn/59117xxxxxx

产品：xxx

研发：xxx

QA：xxx

技术负责人：xxx

研发工时：xxpd（前端xxpd+后端xxpd）

QA工时：xxpd

计划提测时间：xxxx-xx-xx

计划发布时间：xxxx-xx-xx

是否提测delay：是/否

delay原因：xxxx

冒烟方式：功能/接口/codediff

冒烟次数：1

冒烟结果：通过/不通过（原因是xxxx流程异常）

冒烟问题列表：

xx页面点击后无法跳转=====开发谁谁谁的问题，需要改动提交参数

xx页面点击崩溃====后端返回数据无法解析

xx数据返回异常===数据对接问题