一、測試左移的背景

在QA方面，測試自動(dòng)化是一種行之有效的方法，可以讓業(yè)務(wù)測試更加便捷，減少任何形式重復(fù)勞作和返工測試，提高輪次測試執(zhí)行效率。目前自動(dòng)化已在迭代應(yīng)用中進(jìn)入收益階段，不僅在回歸階段代替手工回歸測試，將自動(dòng)化作用價(jià)值體現(xiàn)最大，也讓自動(dòng)化提前介入需求測試分析中，做到“測試左移”。

今年第一季度團(tuán)隊(duì)已提前試點(diǎn)“測試左移”，將自動(dòng)化提前納入需求測試分析階段，在研發(fā)提測節(jié)點(diǎn)按需完成自動(dòng)化左移。但是光從口頭上說“測試左移”，也不能印證自動(dòng)化左移的數(shù)據(jù)，以及左移帶來的實(shí)際收益和價(jià)值，現(xiàn)階段平臺(tái)側(cè)將 RDC(Research and Development Collaboration / 研發(fā)協(xié)同平臺(tái)，得物技術(shù)部自研的一套項(xiàng)目管理工具）、協(xié)同面板、流水線、用例平臺(tái)、自動(dòng)化平臺(tái)五方聯(lián)合，共同搭建出測試左移的全鏈路操作。

測試左移的本質(zhì)：越早的發(fā)現(xiàn)不合理的地方，出問題的幾率就越低。

二、測試左移的收益和價(jià)值

測試左移是軟件研發(fā)生命周期過程中的測試策略，將問題進(jìn)行早發(fā)現(xiàn)早修復(fù)，并且節(jié)約修復(fù)成本。同時(shí)測試左移的落地實(shí)踐，也是推行需求研發(fā)自測的實(shí)行過程中的關(guān)鍵步驟。測試左移的節(jié)點(diǎn)在“需求提測之前”。

測試左移的收益

• 早期發(fā)現(xiàn)和修復(fù)缺陷：測試左移可以幫助研發(fā)在需求開發(fā)過程中早期發(fā)現(xiàn)缺陷，并及時(shí)修復(fù)，避免測試后期對(duì)缺陷的修復(fù)成本和影響。
• 提高測試覆蓋率：測試左移可以幫助早期識(shí)別測試用例，在測試分析和測試用例編寫階段提高需求測試場景用例的覆蓋率。
• 優(yōu)化軟件設(shè)計(jì)：測試左移可以提前介入研發(fā)代碼設(shè)計(jì)，加強(qiáng)與研發(fā)團(tuán)隊(duì)的溝通協(xié)作，了解代碼接口邏輯實(shí)現(xiàn)細(xì)節(jié)，使測試的執(zhí)行更具有質(zhì)量和效率。
• 提高測試效率：測試左移可以前置介入左移方案設(shè)計(jì)和編寫，提升測試階段左移用例執(zhí)行效率，降低手工投入測試成本。

測試左移的價(jià)值

• 減少測試的回歸周期、減少人工測試投入成本；
• 提高產(chǎn)研測三方的高效溝通和協(xié)作，讓測試更加融入到開發(fā)過程中；
• 提高軟件整體質(zhì)量，避免需求上線發(fā)生故障。

圖片

三、持續(xù)集成之流水線

什么是流水線？

圖片

流水線的類型

全流程流水線

• 感知應(yīng)用服務(wù)的代碼變更，融入需求測試輪次節(jié)點(diǎn)特征，自動(dòng)構(gòu)建部署應(yīng)用服務(wù)發(fā)布，減少人工 check 投入成本
• 流程：

研發(fā)本地代碼提交至 Feature 分支：Feature 分支觸發(fā) Push 流水線；

Feature 分支提 MR 進(jìn) Release-{Version} 分支：Release-{Version} 分支觸發(fā) MR 流水線；

MR 通過：Release-{Version} 分支觸發(fā) Push 流水線，自動(dòng)檢測代碼檢查、構(gòu)建、部署。

圖片

現(xiàn)階段流水線不再需要針對(duì)每個(gè)服務(wù)每個(gè)流水線類型做配置了，可以通過流水線模板降低流水線配置的操作費(fèi)力度。

• 內(nèi)置流水線模板：內(nèi)設(shè)五種流水線模板，無需額外配置操作，開箱即用；支持特殊倉庫自定義；
• 自動(dòng)適配迭代：開發(fā)分支自動(dòng)適配開發(fā)迭代染色環(huán)境，迭代分支自動(dòng)同步一輪、二輪染色環(huán)境(無二輪環(huán)境的統(tǒng)一使用一輪環(huán)境)。

Push 流水線

開發(fā)分支代碼變更后自動(dòng)構(gòu)建部署到需求對(duì)應(yīng)的染色迭代開發(fā)環(huán)境，Push 流水線主要的作用：

• 代碼提交后即時(shí)進(jìn)行構(gòu)建檢查、代碼掃描，提前發(fā)現(xiàn)代碼問題；
• Push 后自動(dòng)構(gòu)建部署到開發(fā)分支對(duì)應(yīng)的染色環(huán)境(若無則不觸發(fā))，為開發(fā)過程提效。

圖片

MR 流水線

• MR 流水線主要的作用為：

合并前：作為代碼門禁卡口，構(gòu)建檢查、增量代碼掃描問題；

合并后：觸發(fā) Release-${Version}/Release 分支流水線進(jìn)行自動(dòng)構(gòu)建部署到迭代染色環(huán)境。

• 運(yùn)行方式：

圖片

提測流水線

• 協(xié)同面板提測流程增加提測流水線，需求關(guān)聯(lián)的后端應(yīng)用自動(dòng)觸發(fā)；
• 執(zhí)行方式：

在協(xié)同面板進(jìn)行需求提測時(shí)，針對(duì)需求關(guān)聯(lián)的應(yīng)用創(chuàng)建染色環(huán)境執(zhí)行提測流水線；

基于 Release-${Version} 迭代分支運(yùn)行，運(yùn)行結(jié)果反饋在協(xié)同面板；

提測流水線運(yùn)行任務(wù)節(jié)點(diǎn)：構(gòu)建、部署、自動(dòng)化測試、代碼掃描、Jar 包掃描、安全掃描。

圖片

Daily 流水線

• 基準(zhǔn) Daily

運(yùn)行環(huán)境：基準(zhǔn)環(huán)境(T1)；

運(yùn)行分支：Release 分支(生產(chǎn)環(huán)境 Commit tag)；

運(yùn)行方式：只運(yùn)行基準(zhǔn)環(huán)境的集成自動(dòng)化測試，用于 Case 穩(wěn)定性驗(yàn)證(目標(biāo)成功率100%)。

• 迭代 Daily

• 運(yùn)行環(huán)境：開發(fā)周一輪染色環(huán)境、測試周一輪染色環(huán)境；

• 運(yùn)行分支：Release-${Version}/Release 分支；

• 運(yùn)行方式：用于迭代分支的自動(dòng)化檢查，及時(shí)發(fā)現(xiàn)迭代分支代碼質(zhì)量問題。

流水線的使用

圖片

四、測試左移之自動(dòng)化左移

關(guān)于“測試左移”，想必會(huì)有幾個(gè)問題大家想要了解。什么是左移、什么是自動(dòng)化左移、什么節(jié)點(diǎn)算左移、左移的標(biāo)準(zhǔn)是什么、左移的數(shù)據(jù)結(jié)果如何衡量，下面我們來看看思路和方案。

什么是自動(dòng)化左移？

什么節(jié)點(diǎn)算左移？

圖片

左移節(jié)點(diǎn)

• 提測左移：服務(wù)端研發(fā)操作提測時(shí)；
• 迭代左移：迭代時(shí)間范圍內(nèi)。

左移的標(biāo)準(zhǔn)是什么？

提測左移

• 需求在服務(wù)端研發(fā)點(diǎn)“提測”之前；
• 需求測試用例下有關(guān)聯(lián)自動(dòng)化用例；
• 關(guān)聯(lián)的自動(dòng)化用例狀態(tài)必須是：“上線”。

迭代左移

• 迭代時(shí)間范圍內(nèi)；
• 需求測試用例下有關(guān)聯(lián)自動(dòng)化用例；
• 關(guān)聯(lián)的自動(dòng)化用例狀態(tài)必須是：“上線”；
• 關(guān)聯(lián)的自動(dòng)化用例必須是：“執(zhí)行過”（在自動(dòng)化測試計(jì)劃中執(zhí)行過）。

Q：若需求是跨版本，怎么辦？

A：用例平臺(tái)的用例模塊支持可移動(dòng)，在模塊移動(dòng)的時(shí)候平臺(tái)自動(dòng)更改版本號(hào)，同時(shí)用例平臺(tái)告訴自動(dòng)化平臺(tái)版本號(hào)的變更。

左移數(shù)據(jù)結(jié)果如何衡量？

圖片

提測左移的數(shù)據(jù)指標(biāo)衡量會(huì)在星盤平臺(tái)輸出對(duì)應(yīng)的結(jié)果數(shù)據(jù)。

• 星盤：迭代維度，查看域/子域的測試左移；

迭代左移的數(shù)據(jù)指標(biāo)會(huì)在自動(dòng)化平臺(tái)輸出對(duì)應(yīng)的結(jié)果數(shù)據(jù)；

• 自動(dòng)化：迭代/時(shí)間范圍維度，查看域/子域/人的測試左移。

五、自動(dòng)化左移規(guī)范

自動(dòng)化編寫

編寫規(guī)范參考：【接口自動(dòng)化】平臺(tái)應(yīng)用規(guī)范。

圖片

關(guān)于提測左移的自動(dòng)化，編寫實(shí)施步驟：

圖片

提測分支合并

• 是（已合入）：允許提測；
• 否（沒合入）：不允許提測。

流程：協(xié)同面板--->子域/版本號(hào)--->需求“開發(fā)”節(jié)點(diǎn)--->提測

圖片

圖片

提測自動(dòng)化

提測自動(dòng)化配置：

• BVT 主流程：子域業(yè)務(wù)模塊核心 BVT 主流程自動(dòng)化測試計(jì)劃；
• 需求左移：提測時(shí)，自動(dòng)檢索需求用例目錄下是否有自動(dòng)化上線 Case（無需配置）。

BVT 主流程：

• 執(zhí)行 Case：研發(fā)提測時(shí)間，觸發(fā)業(yè)務(wù)域 BVT 主流程自動(dòng)化；
• 執(zhí)行環(huán)境：迭代 Round-1 染色環(huán)境；
• 執(zhí)行目的：保證研發(fā) Feature-xxx 分支合入 Release-{Version} 分支后對(duì)業(yè)務(wù)域的主流程是否有影響。

需求左移：

• 執(zhí)行 Case：研發(fā)提測時(shí)間，觸發(fā)業(yè)務(wù)域需求自動(dòng)化；
• 執(zhí)行環(huán)境：需求染色環(huán)境（自動(dòng)創(chuàng)建）；
• 執(zhí)行目的：需求維度自動(dòng)化 Case 是否受需求提測影響而失敗，判斷是否是腳本問題還是代碼問題。

提測分析

提測自動(dòng)化執(zhí)行失敗，是否會(huì)影響研發(fā)提測進(jìn)度？

• 不會(huì)。現(xiàn)階段不會(huì)卡研發(fā)提測進(jìn)度流程。

提測自動(dòng)化執(zhí)行失敗，可以提缺陷嗎？

• 可以。失敗分析后定位出是研發(fā)代碼缺陷，直接提 RDC- 需求缺陷，缺陷階段=測試冒煙。

六、總結(jié)與下一步規(guī)劃

自動(dòng)化測試左移是從之前傳統(tǒng)的后期繼承測試階段提前至開發(fā)階段的策略，通過在開發(fā)過程中引入自動(dòng)化測試，在逐步提高測試效率，減少測試過程中的缺陷發(fā)生。我們將自動(dòng)化測試與持續(xù)集成和持續(xù)交付相結(jié)合，實(shí)現(xiàn)了快速、頻繁的測試和交付，減少了開發(fā)和測試之間的時(shí)間間隔，提高了產(chǎn)品質(zhì)量和交付速度。

在自動(dòng)化測試左移的基礎(chǔ)上，我們將進(jìn)一步完善和優(yōu)化自動(dòng)化測試流程，以提高測試的覆蓋率和質(zhì)量，擴(kuò)大自動(dòng)化測試范圍和持續(xù)監(jiān)控和優(yōu)化，提升自動(dòng)化測試范圍，并且再進(jìn)一步提高測試效率和質(zhì)量。