測試左移與提測流水線的應用實踐
一、測試左移的背景
在QA方面，測試自動化是一種行之有效的方法，可以讓業(yè)務測試更加便捷，減少任何形式重復勞作和返工測試，提高輪次測試執(zhí)行效率。目前自動化已在迭代應用中進入收益階段，不僅在回歸階段代替手工回歸測試，將自動化作用價值體現(xiàn)最大，也讓自動化提前介入需求測試分析中，做到“測試左移”。
今年第一季度團隊已提前試點“測試左移”，將自動化提前納入需求測試分析階段，在研發(fā)提測節(jié)點按需完成自動化左移。但是光從口頭上說“測試左移”，也不能印證自動化左移的數(shù)據(jù)，以及左移帶來的實際收益和價值，現(xiàn)階段平臺側將 RDC(Research and Development Collaboration / 研發(fā)協(xié)同平臺，得物技術部自研的一套項目管理工具）、協(xié)同面板、流水線、用例平臺、自動化平臺五方聯(lián)合，共同搭建出測試左移的全鏈路操作。
測試左移的本質：越早的發(fā)現(xiàn)不合理的地方，出問題的幾率就越低。
二、測試左移的收益和價值
測試左移是軟件研發(fā)生命周期過程中的測試策略，將問題進行早發(fā)現(xiàn)早修復，并且節(jié)約修復成本。同時測試左移的落地實踐，也是推行需求研發(fā)自測的實行過程中的關鍵步驟。測試左移的節(jié)點在“需求提測之前”。
測試左移的收益
- 早期發(fā)現(xiàn)和修復缺陷：測試左移可以幫助研發(fā)在需求開發(fā)過程中早期發(fā)現(xiàn)缺陷，并及時修復，避免測試后期對缺陷的修復成本和影響。
- 提高測試覆蓋率：測試左移可以幫助早期識別測試用例，在測試分析和測試用例編寫階段提高需求測試場景用例的覆蓋率。
- 優(yōu)化軟件設計：測試左移可以提前介入研發(fā)代碼設計，加強與研發(fā)團隊的溝通協(xié)作，了解代碼接口邏輯實現(xiàn)細節(jié)，使測試的執(zhí)行更具有質量和效率。
- 提高測試效率：測試左移可以前置介入左移方案設計和編寫，提升測試階段左移用例執(zhí)行效率，降低手工投入測試成本。
測試左移的價值
- 減少測試的回歸周期、減少人工測試投入成本；
- 提高產(chǎn)研測三方的高效溝通和協(xié)作，讓測試更加融入到開發(fā)過程中；
- 提高軟件整體質量，避免需求上線發(fā)生故障。
圖片
三、持續(xù)集成之流水線
什么是流水線？
圖片
流水線的類型
全流程流水線
- 感知應用服務的代碼變更，融入需求測試輪次節(jié)點特征，自動構建部署應用服務發(fā)布，減少人工 check 投入成本
- 流程：
研發(fā)本地代碼提交至 Feature 分支：Feature 分支觸發(fā) Push 流水線；
Feature 分支提 MR 進 Release-{Version} 分支：Release-{Version} 分支觸發(fā) MR 流水線；
MR 通過：Release-{Version} 分支觸發(fā) Push 流水線，自動檢測代碼檢查、構建、部署。
圖片
現(xiàn)階段流水線不再需要針對每個服務每個流水線類型做配置了，可以通過流水線模板降低流水線配置的操作費力度。
- 內置流水線模板：內設五種流水線模板，無需額外配置操作，開箱即用；支持特殊倉庫自定義；
- 自動適配迭代：開發(fā)分支自動適配開發(fā)迭代染色環(huán)境，迭代分支自動同步一輪、二輪染色環(huán)境(無二輪環(huán)境的統(tǒng)一使用一輪環(huán)境)。
Push 流水線
開發(fā)分支代碼變更后自動構建部署到需求對應的染色迭代開發(fā)環(huán)境，Push 流水線主要的作用：
- 代碼提交后即時進行構建檢查、代碼掃描，提前發(fā)現(xiàn)代碼問題；
- Push 后自動構建部署到開發(fā)分支對應的染色環(huán)境(若無則不觸發(fā))，為開發(fā)過程提效。
圖片
MR 流水線
- MR 流水線主要的作用為：
合并前：作為代碼門禁卡口，構建檢查、增量代碼掃描問題；
合并后：觸發(fā) Release-${Version}/Release 分支流水線進行自動構建部署到迭代染色環(huán)境。
- 運行方式：
圖片
提測流水線
- 協(xié)同面板提測流程增加提測流水線，需求關聯(lián)的后端應用自動觸發(fā)；
- 執(zhí)行方式：
在協(xié)同面板進行需求提測時，針對需求關聯(lián)的應用創(chuàng)建染色環(huán)境執(zhí)行提測流水線；
基于 Release-${Version} 迭代分支運行，運行結果反饋在協(xié)同面板；
提測流水線運行任務節(jié)點：構建、部署、自動化測試、代碼掃描、Jar 包掃描、安全掃描。
圖片
Daily 流水線
- 基準 Daily
運行環(huán)境：基準環(huán)境(T1)；
運行分支：Release 分支(生產(chǎn)環(huán)境 Commit tag)；
運行方式：只運行基準環(huán)境的集成自動化測試，用于 Case 穩(wěn)定性驗證(目標成功率100%)。
- 迭代 Daily
運行環(huán)境：開發(fā)周一輪染色環(huán)境、測試周一輪染色環(huán)境；
運行分支：Release-${Version}/Release 分支；
運行方式：用于迭代分支的自動化檢查，及時發(fā)現(xiàn)迭代分支代碼質量問題。
流水線的使用
圖片
四、測試左移之自動化左移
關于“測試左移”，想必會有幾個問題大家想要了解。什么是左移、什么是自動化左移、什么節(jié)點算左移、左移的標準是什么、左移的數(shù)據(jù)結果如何衡量，下面我們來看看思路和方案。
什么是自動化左移？
什么節(jié)點算左移？
圖片
左移節(jié)點
- 提測左移：服務端研發(fā)操作提測時；
- 迭代左移：迭代時間范圍內。
左移的標準是什么？
提測左移
- 需求在服務端研發(fā)點“提測”之前；
- 需求測試用例下有關聯(lián)自動化用例；
- 關聯(lián)的自動化用例狀態(tài)必須是：“上線”。
迭代左移
- 迭代時間范圍內；
- 需求測試用例下有關聯(lián)自動化用例；
- 關聯(lián)的自動化用例狀態(tài)必須是：“上線”；
- 關聯(lián)的自動化用例必須是：“執(zhí)行過”（在自動化測試計劃中執(zhí)行過）。
Q：若需求是跨版本，怎么辦？
A：用例平臺的用例模塊支持可移動，在模塊移動的時候平臺自動更改版本號，同時用例平臺告訴自動化平臺版本號的變更。
左移數(shù)據(jù)結果如何衡量？
圖片
提測左移的數(shù)據(jù)指標衡量會在星盤平臺輸出對應的結果數(shù)據(jù)。
- 星盤：迭代維度，查看域/子域的測試左移；
迭代左移的數(shù)據(jù)指標會在自動化平臺輸出對應的結果數(shù)據(jù)；
- 自動化：迭代/時間范圍維度，查看域/子域/人的測試左移。
五、自動化左移規(guī)范
自動化編寫
編寫規(guī)范參考：【接口自動化】平臺應用規(guī)范。
圖片
關于提測左移的自動化，編寫實施步驟：
圖片
提測分支合并
- 是（已合入）：允許提測；
- 否（沒合入）：不允許提測。
流程：協(xié)同面板--->子域/版本號--->需求“開發(fā)”節(jié)點--->提測
圖片
圖片
提測自動化
提測自動化配置：
- BVT 主流程：子域業(yè)務模塊核心 BVT 主流程自動化測試計劃；
- 需求左移：提測時，自動檢索需求用例目錄下是否有自動化上線 Case（無需配置）。
BVT 主流程：
- 執(zhí)行 Case：研發(fā)提測時間，觸發(fā)業(yè)務域 BVT 主流程自動化；
- 執(zhí)行環(huán)境：迭代 Round-1 染色環(huán)境；
- 執(zhí)行目的：保證研發(fā) Feature-xxx 分支合入 Release-{Version} 分支后對業(yè)務域的主流程是否有影響。
需求左移：
- 執(zhí)行 Case：研發(fā)提測時間，觸發(fā)業(yè)務域需求自動化；
- 執(zhí)行環(huán)境：需求染色環(huán)境（自動創(chuàng)建）；
- 執(zhí)行目的：需求維度自動化 Case 是否受需求提測影響而失敗，判斷是否是腳本問題還是代碼問題。
提測分析
提測自動化執(zhí)行失敗，是否會影響研發(fā)提測進度？
- 不會。現(xiàn)階段不會卡研發(fā)提測進度流程。
提測自動化執(zhí)行失敗，可以提缺陷嗎？
- 可以。失敗分析后定位出是研發(fā)代碼缺陷，直接提 RDC- 需求缺陷，缺陷階段=測試冒煙。
六、總結與下一步規(guī)劃
自動化測試左移是從之前傳統(tǒng)的后期繼承測試階段提前至開發(fā)階段的策略，通過在開發(fā)過程中引入自動化測試，在逐步提高測試效率，減少測試過程中的缺陷發(fā)生。我們將自動化測試與持續(xù)集成和持續(xù)交付相結合，實現(xiàn)了快速、頻繁的測試和交付，減少了開發(fā)和測試之間的時間間隔，提高了產(chǎn)品質量和交付速度。
在自動化測試左移的基礎上，我們將進一步完善和優(yōu)化自動化測試流程，以提高測試的覆蓋率和質量，擴大自動化測試范圍和持續(xù)監(jiān)控和優(yōu)化，提升自動化測試范圍，并且再進一步提高測試效率和質量。
