前言
经过我们团队持续不断的推进，团队的自动化UI测试终于走出了研发和尝试阶段，进入到实际项目应用阶段，开始产生生产力。但经过了近两个月的尝试发现，引入了自动化UI测试后发现与原有的开发模式有所冲突，经过这段时间的摸索和磨合，团队形成了一种新的开发和测试的协同模式，也就是SCM。
当前现状
- 功能开发版本控制采用SVN
- 自动化测试脚本版本控制采用Git
- CI系统采用jenkin
- 自动化UI测试工具采用katalon
- Katalon部署到特定节点加入到jenkins
- Jenkins建立特定katalon项目并调度katalon节点进行自动化测试
- 被测系统也部署到katalon节点手动触发更新
主要问题以及解决思路
Release版本管理问题
现象
无法在短时间内拿出可以保证运行的系统对应的代码版本
这一点是我们一直没有做好的地方，由于我们团队规模一直比较小所以版本管理工具一般保持着单主线的模式，但这也就意味着我们对于发布的版本的管理只停留在jar包和tag上。
目标
可在1分钟之内找到可以运行的系统版本，并支持一键式回滚和升级
解决思路
- 在版本控制工具中增加release/sprint_release支线
- 该支线仅在团队通过评审会议后发布
自动化UI测试的版本与开发版本的不同步问题
现象
- 自动化UI测试持续失败
- 被测系统的版本远远落后于开发版
- 开发人员提交到主线后，若测试人员没有完成自动化测试脚本开发，且在katalon节点更新了代码会导致自动化测试脚本由于测试与开发版本不一致失败
目标
- 能让开发和测试同学并行的开发
- 减少版本不一致的可能性
解决思路
- 在项目管理分支中增加pre_ui_test分支以及ui_test分支
- 在测试人员对开发人员完成的功能确认后，开发人员将代码合并到pre_ui_test分支
- 在测试人员针对在pre_ui_test分支上新增的功能完成自动化测试脚本开发后，发布自动化测试脚本到自动化测试版本管理工具上
- 测试人员再将pre_ui_test分支上对应的功能合并到ui_test上
每次自动化测试需要测试人员手动触发
现象
- 每次开发版本更新需要测试人员手动用IDE更新
目标
- 在JENKINS中完全自动化系统UI自动化测试
解决思路
- 按照指定的项目顺序执行下列操作
通过svn更新代码
构建项目
启动项目
- (在测试节点上自动拉取指定的docker镜像，并运行)
- 更新katalon测试脚本
- 通过脚本启动katalon测试
- 更新测试结果
总体SCM
下一步计划
可以从上面的SCM中看出来还有不少可以改进的地方
- 从dev支线合并到pre_ui_test在开发人员提交到dev线时自动完成
- 从pre_ui_test到ui_test的合并可以由测试人员push自动化测试脚本时自动完成
但上面的前提是需要保证开发和测试脚本对应的功能项能够一一对应起来，需要一套复杂的开发管理系统来完成。
