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.分支一轮测试
