需求评审
0、新版本需求出来前需要PM邮件发送给整个项目组。1、需求评审需要参加人员：PM、RD、QA、UI，业务人员（需要调整的点需要在用例评审之前确认完，之后不能做大的调整修改，小调整需要回复版本需求 邮件告知RD、QA）2、用例评审需要参加人员：QA、RD、PM（用例评审之后QA需要整理P0级别case 发出准入测试邮件，在API或者前端提测前需要自测保证准入测试邮件中的case可用性。之后需回复准入邮件确认。保证提测版本的可测性。）3、showCase需要参加人员：PM、QA、UI、业务人员 showcase之后，UI确认需要调整的点、RM确认需要调整的部分、需要整理出表，在最后发布前进行确认。或者QA推动确认。（showCase结束之后，开始综合测试，如有新版本需求需切新分支，bug修改每天提测代码不超过4次）4、测试通过之后需要QA邮件回复版本邮件 测试报告，包含：测试结论、测试内容、测试结果、bug数、遗留bug数。风险点，以及Re\\Fe修改版本数
测试一轮
用例评审
综合测试
APIbug
后端与前端API联调完成
默认一个版本需求评审需要业务部门参加确认确认后在整个发版前开发阶段，不允许该阶段业务功能变动增加，如需增加只能到下一个版本
测试用例编写
bug
测试回归
API测试
API提测
showCase
发版合并master
后端开发过程
这个阶段端代码切版本分支版本号样式：Re1.0.0.n / Fe1.0.0.nN为bug修改提交次数
前端提测
前端研发
bug修改
bug修复
