前言

經過我們團隊持續不斷的推進，團隊的自動化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自動化測試指令碼時自動完成
  但上面的前提是需要保證開發和測試指令碼對應的功能項能夠一一對應起來，需要一套複雜的開發管理系統來完成。