测试流程规范

一、测试流程规范

1.1、遗留Bug录入需求池

迭代开始前，将过往版本遗留Bug在禅道上录⼊需求池，事件类型为缺陷，并指给对应的开发；

1.2、需求评审

产品从需求池抽取需求，进行需求排期的时候，测试参与其中对需求进行评审，同时确定测试边界；

1.3、测试排期

确定需求范围后，开发同学进行开发时间的排期、测试同学进行测试周期的排期，对⼯作量进⾏预估；

1.4、测试用例编写

对于确定的需求范围进行测试用例的编写，并在编写之后与具体实施的开发同步进行评审；

1.5、冒烟测试

开发同学提测前，需要执行冒烟用例保证冒烟测试通过；

1.6、测试执行

开发在具体需求开发完成后，冒烟测试通过后，发送提测邮件通知测试同学，并把对应代码部署到测试环境供测试同学进行功能测试；

测试同学先测试冒烟用例，通过后基于测试用例进行全量测试和回归测试。每日同步测试日报反馈测试进度；

1.7、发版上线

测试结束后，研发负责⼈安排上线准备，进行上线准备；

二、阶段输出物

阶段	参与⻆⾊	输出物
需求阶段	产品、UI、开发、测试	PRD⽂档、交互设计稿(UI)
开发阶段	开发	详细设计⽂档
测试阶段	测试、开发、产品	1、冒烟测试用例--提测前提供，作为冒烟是否通过标准； 2、测试用例--提测前提供，评审阶段由产品、UI、开发、测试人员参加； 3、测试日报--提测后，冒烟测试通过进入一轮测试后，每天由对应测试同学发送； 4、质量报告--功能测试、专项测试完成后由测试负责⼈发送；

三、测试环境要求

3.1、测试环境

提测阶段在测试环境进行测试

3.2、应用部署窗口

研发负责⼈、测试负责⼈，部署前和部署完成后需要通知测试，注明部署内容

四、测试数据要求

测试数据规范——要有含义，不能随便便输⼊⼀堆乱码

测试账号独⽴

测试数据库权限(测试环境)对于涉及到需要修改数据库字段值的，需要有对应的case(例如测试需要job触发的功能)，明确修改的表及字段

对于数据构造，如非必要，只能通过页面或接口，不能通过数据库直接插⼊对于时间、日期数据库字段类型，注意数据格式的规范性

五、BUG提交规范

所有的Bug统⼀提交到禅道上，同时BUG需要注明环境、访问链接、账号/测试数据、重现步骤、预期结果、实际结果、截图(要能根据描述快速定位问题)；

BUG优先级(紧急、重要、⼀般)，阻塞流程的置为紧急，紧急BUG日清；

指派给对应研发负责⼈，由研发负责⼈确认问题并指派给对应开发(区分优化需求/BUG)；

5.1、BUG严重程度定义

致命：导致业务主要服务不可⽤，造成业务资损，系统崩溃，数据错误和被破坏，死机；

严重：主要功能部分没有实现、产品和需求不符合，阻塞完整业务流程，程序接口错误，性能问题导致服务器RT过⻓和内存溢出等；

⼀般：次要功能未实现、与产品需求规格书不符、界⾯出现错误、格式错误、没有进行⼀些特殊的限制和要求、删除内容没有做提示等方面；

轻微:发⽣在⼀些小的界⾯方面的问题。例如错别字、提示信息、语法、日期显示格式不正确、界⾯不美观、操作不⽅便和不习惯等诸多方面；

5.2、BUG严重优先级定义

紧急：阻塞主流程测试的，问题必须⻢上解决，否则系统根本无法达到预定的需求；

重要：有时间就要⻢上解决，关系到系统的主要功能模块能否正常；

⼀般：问题不影响主要功能的实现，但是影响其他使用；