# 中台系统开发测试规范

[TOC]

# 中台系统列表

中台系统会不定期收集需求，进行常规的开发迭代

中台系统针对不同的项目做私有化部署之后，如果需要给中台系统提定制化需求或者bug反馈，需要按以下规范执行

业务方产品人员&中台方产品人员：对齐需求，UI/UE，迭代宣讲
开发人员：
- 对于定制化需求：基于master拉分支，分支命名格式feat-{项目代号}-{功能特性}，如feat-geely-events；
- 对于bug：基于生产环境tag拉分支，分支命名格式fix-{生产环境tag}，如fix-geely-v1.0.1。注意：对于在上线生产环境的过程中发现的bug，也适用此条规范
开发人员&测试人员：开发完成之后，提测，提测时需要提供基于上个版本的Release Note，便于测试人员准备用例
开发人员：测试环境测试完成之后，兼容性review
测试人员：对兼容性review后产生的变动，做回归测试
开发人员：UAT或预发布验证之后，走发版流程，遵循发版规范

中台系统测试：负责在常规迭代中输出全量的测试用例，对业务方需求保持知晓，识别业务方对原测试用例的影响并把关中台系统的整体质量
业务方测试：
- 从业务角度切入，测试跟业务相关的中台能力，比如活动提报会发起审批，那这个场景下的所有跟审批相关的流程需要从业务角度输出用例并测试；
- 业务方对中台系统提出的需求或者优化项，由业务方测试主导输出用例和测试工作

发版到生产环境之前，需要做到：开发人员在开发环境或测试环境自测验证，然后发布预发布环境让开发人员和测试人员验证，最后才能执行发布生产环境的流程。不同项目中对环境的命名可能不同，但基本都会有这三套环境
获取预发布环境测试验证通过的版本号commitid1，版本号可以从预发布环境使用的docker镜像的tag中获取。如：
基于commitid1打一个tag，格式为：{项目代号}-{版本号}，如geely-v1.0.1，并填写Release Note，Release Note获取方式参考附录
基于上一步中获取的tag打包发布生产环境
生产环境验证通过之后，及时tag通过提MR的方式合回到项目master上。(可能需要基于tag建立一个同名分支，才能创建MR)
记录上线过程中需要以后解决的遗留项，备注到tapd中，统一在【前端中台系统】发版遗留工作 (opens new window)中创建子需求以便跟进

长期分支
- master：存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的发布版。设置为被保护分支，不能直接 merge，只能通过 merge request 的方式，通过相关人员 review 之后才能被合入
临时分支。开发完成后，合入master 分支
- feat-xx：功能分支。基于 master 分支检出，用于开发新功能
- fix-xx：补丁分支。基于有bug的tag检出，用于 bug 修复

良好的 git 提交信息，可以清晰表达本次提交所改动和影响范围，方便后续 review 代码，自动生成 changelog。提交信息的格式如下：

<type>(<scope>): <subject>

注：开发过程中千万不要攒提交，不利于版本回退。遵循”一个问题一次提交“的原则

生产环境发布完成之后，需要将tag合到master分支上。

获取原来部署的服务使用的代码版本commitid1
获取将要更新的代码版本的版本commitid2
执行git log --pretty=format:"%s" {commitid1}...{commitid2}，可获取版本变动记录。原则上如果提交日志写的够清晰，可以相对完整的输出Release Note
如果git log信息不太足够，可以通过对比两个版本之间的文件变动，获取Release Note。
- 依赖vscode插件Source Control,选择相应git仓库的commitid1、commitid2进行比较
- 根据两个版本的文件变动差异，获取Release Note