视觉验收流程

19.正常测试流程

13.视觉一轮验收（前端+视觉）发起人：QA

否

10.不合并（有风险任务）

11.合并分支

完成

2.同一上线版本

17.继续视觉验收

7.开发提测

6.版本排期（包含视觉）

3.不同版本流程

1.视觉问题，验收忽略 a.合master前，提bug修改。 b.合master后，提bug，打标“视觉bug”，下次上线。2.视觉需求 a.合master前，开发评估。需修改，提bug给视觉，打标“视觉变更”；本次不修，提需求jira b.合master后，提需求既然，下次上线

15.视觉二轮验收

4.指定负责人（前后端、QA）

是

6.1.视觉终稿（邮件形式）

14.开发修改

16.完成视觉验收（邮件通知）

9.分支是否可合并（开发负责人判断）

18.存在视觉问题

8.冒烟（视觉工作大，在此介入）发起人：前端开发

5.是否包含视觉

1.收到评审

说明：1、验收主体人员：视觉+产品 协助人员：前端+QA2、新增“流程4”版本负责人： a.前、后端开发负责人：评估是否可将多个任务合并到一个分支（流程9）；上线跟踪 b.QA负责人：提醒前端负责人分支合并；上线跟踪3、“流程6”版本排期，增加视觉排期4、新增“流程6.1”视觉终稿，以邮件形式发出。前端拿到终稿邮件后再开始开发5、“流程8”当判断视觉工作量较大时，可将视觉验收提前到开发冒烟时开始6、新增“流程9”前端判断分支是否可合并环节（解决视觉验收问题；节约测试环境）7、“流程16”规范视觉验收完成标准，使用邮件通知8、新增“流程18”完成视觉验收后续视觉问题流程处理办法

12.分支一轮测试