发布流程

DEV Urgent

1. 只部署、维护线上环境。2.根据开发提供的版本部署需求，完成部署文档。

TEST

PRODUCT环境

UAT环境

每次t提交DEV-TEST 前拉一下线上版本代码

DEV环境

1 合并代码需要说明，并妥善处理冲突。分支合到主线需要由开发组长把关。2.构建数据结构和接口时，需要同时维护好接口文档，不需要很详细，但需要准确和定期维护。3 主线发布到测试需要提供发布说明，并对更新内容质量负责。

按计划

拉紧急分支

1.发布自由，所有开发都有可能私自发布到MASTER甚至到TEST2.分支混乱，代码覆盖，代码冲突，严重影响整体环境代码质量3.缺失发布说明：包括更新点说明，修复bug说明，和本次发布是否需要修改配置文件，执行脚本等。

1 黑盒，摸索型测试占比100%，整体测试人员水平较低，测试方法单一。2 重复测试比重太多，在不清楚发布内容的情况下，摸瞎测试。3 测试结束没有固定的测试报告，没有测试结果的标准。4 遗漏发现的BUG数量多，多为显而易见的问题。5 目前环境发布由 开发控制，发布频率和发布内容不受测试控制，无版本控制。6 没有固定可参考的测试标准，如产品的需求文档或者高保真原型文档。

测未通过

PRO

DEV 1

DEV 2

建议

目前现状

1.扩充测试方法和测试手段。由GUI自动化代替冒烟测试，减少重复测试量。由接口测试提高功能覆盖面，再通过强化业务知识提升探索测试的覆盖率。2.测试输出： 测试报告， 配置手册，操作手册。3.测试环境控制4.参与产品设计、评审、验收、用户培训、现场实施等过程。5. 增强业务知识水平，为敏捷开发中的探索测试做好基础

测试通过

TEST环境

DEV MASTER

测试

运维

UAT

1. 发布频繁2. 没有部署文档3. 环境责任区分4. 无版本控制，部署后无法确认是否部署了所需版本。

运维发布

不限计划

发布流程

开发