文章目录
一、版本发布流程
1、增加/变更功能流程
(1)需求确认
涉及人员范围: 产品经理、原型设计师(需要的话)、研发工程师(服务端、终端、硬件、结构)、测试工程师。
动作:
- 产品经理召集所有涉及人员进行需求宣讲,完成最终功能需求确认,同时确认
release版本号
。 - 原型设计师根据最终需求设计原型图(需要的话)。
- 产品经理确认原型图(需要的话)。
- 产品经理组织研发、测试进行沟通协调周期预估、评估影响范围以及提取风险点。
输出: 最终功能需求文档(尽量具体,最好有业务流程图之类的)、原型图(需要的话)、研发和测试周期预估表、风险点报告、release版本号
。
(2)产品开发
涉及人员范围: 研发工程师。
动作:
- 根据
release版本号
创建对应的分支,分支名
=develop/
+release版本号
,例如:develop/3.0.0
。 - 在新建的分支上进行开发并自测,有条件的话根据测试编写的用例进行自测。
- 自测没问题,在最新的分支提交上打alpha版本的tag,并打包上传到ftp服务器,告知测试工程师去获取测试。注:
tag名
=alpha版本号
,例如:3.0.0.118-alpha
。包名
=项目名_
(选填) +tag名
,例如:JH_3.0.0.118-alpha
,如果打出的包是debug调试版,则包名需要加上标识debug
,例如:JH_3.0.0.118-alpha-debug
。
输出: alpha版本的包、CHANGELOG.md。
(3)alpha测试
涉及人员范围: 测试工程师、产品经理、研发工程师。
动作:
- 根据需求文档编写测试用例(前置条件、操作步骤、期望结果)。此步可以和第(2)点同步进行。
- 编写相关自动化测试脚本进行挂机测试。此步可以和第(2)点同步进行。
- 从ftp服务器获取研发工程师所指定的包进行测试,过程中发现问题,有条件时保留现场,让研发人员进行分析,有本地日志记录时,及时抓取日志,并确定问题出现时间范围。所发现的问题需要同样告知产品经理。
- 最后整理测试报告,并和产品经理沟通确认每个问题的严重等级:P0、P1、P2、P3,并把缺陷问题指给具体的某个研发工程师(不确定时指给研发经理)。
- 研发工程师根据严重等级依次解决处理缺陷。
- 所有缺陷自测没问题,在最新的分支提交上打alpha版本的tag,输出对应的包上传到ftp服务器,告知测试工程师获取测试。
- 在beta测试前,至少需要进行3轮的alpha
输出: 测试用例、测试报告、缺陷问题链接、alpha版本的包。
(4)问题修复
涉及人员范围: 研发工程师、测试工程师。
动作:
- 对测试所指派的缺陷问题,根据严重等级依次处理。
- 所有缺陷自测没问题,在最新的分支提交上打alpha版本的tag,输出对应的包上传到ftp服务器,告知测试工程师获取测试,重复第(3)点。
- 在beta测试前,至少需要进行3轮的alpha测试。
- 当最后一轮alpha测试没问题时,在最新的分支提交上打beta版本的tag,并打包上传到ftp服务器,提供给外部测试。注:
tag名
=beta版本号
,例如:3.0.0.214-beta
。包名
=项目名_
(选填) +tag名
,例如:JH_3.0.0.214-beta
。
输出: beta版本的包。
(5)beta测试
涉及人员范围: