一文搞懂測試左移和測試右移的 Why-How-What
軟體測試技術應當貫穿整個軟體開發生命週期、對軟體產品（包括階段性產品）進行驗證和確認的活動過程，其核心目標是儘快儘早地發現軟體產品中所存在的各種問題 bug—— 與使用者需求、預先定義的不一致性。
然而，傳統的軟體測試流程是：
接到專案後參與需求評審，然後根據需求文件寫寫用例和準備指令碼，等開發提測之後正式開始測試、提 Bug、迴歸測試，測試通過後就結束了。然後，專案交給運維上線，之後測試人員再投入下一個專案，繼續重複這樣的流程。
這樣的流程看似沒什麼問題，但缺點是：測試過程是在一定時間間隔之內發生的，測試人員必須等待產品完全構建才能找到錯誤和故障。不可否認，花費的時間超過了可以商定的時間，測試人員就非常被動，因為等待程式碼成為測試人員的瓶頸。
而在移動網際網路和 DT 時代，網際網路產品迭代週期短、速度快、頻次高，促進了敏捷開發和持續交付等研發模式的全面流行，這也給傳統軟體測試方式帶來了更大的時間壓力。
而測試左移以及測試右移的意義就在於能夠讓測試擁有更多的主動權，有更充足的時間進行測試，同時不會像之前因為質量差風險高每次都延期上線，並且產品的線上質量也能有保證。
不管是測試左移還是測試右移，都是為產品質量服務。測試人應該秉持這樣的理念：不要把提測認為是測試活動的開始，上線是測試活動的結束，更不要認為質量只是測試同學需要關注的。
測試左移是向測試之前的開發階段移動。
測試左移的原則支援測試團隊在軟體開發週期早期和所有干係人合作。因此他們能清晰地理解需求以及設計測試用例去幫助軟體“快速失敗”，促使團隊更早的修改所有的 Bug。更深入的參與和理解會促進測試人員獲取產品完整的知識，徹底想清楚各種場景，並根據軟體行為設計實時的場景，這些都會幫助團隊在編碼完成之前識別出一些缺陷。
測試左移聚焦在使測試人員在全部和最重要的專案階段參與進來。這就是測試人員把焦點從發現 Bug 轉移到 Bug 的預防上，同時也驅動專案的商業目標。
隨著測試團隊的責任的提高，團隊不在僅僅聚焦在“測試軟體去發現 Bug”，而是積極團隊合作，參與專案初始階段的計劃和建立強壯有效的測試策略，而測試策略又為團隊提供好的測試領導力和指導，使團隊聚焦在產品的長遠的視角，而不僅僅是測試工作。
測試左移首先為測試人員提供了設計測試的機會，無論這些測試是被聚焦在客戶的體驗還是期望，也促使開發人員根據這些測試去開發軟體以滿足客戶需求。
測試右移是測試活動向產品釋出之後的步驟移動。
測試右移是產品上線了之後也可以進行一些測試活動。主要關注的是產品效能及可用性監控，以及新功能的測試。通過測試右移可以在生產環境做監控，監控線上效能和可用率，一旦線上發生任何問題，儘快反應，提前反應，給使用者良好的體驗。
在霍格沃茲測試學院的測試開發課程教學體系，已經整理了當下最流行最實用的測試左右移技術棧，這裡供參考：
- 程式碼審計系統 SonarQube 實戰
- 測試用例與 JaCoCo 程式碼覆蓋率資料分析實戰
- ASM 插樁技術與 JVM-SandBox 專案實戰
- 精準化測試平臺構建實戰（可參考之前文章）
- ELK 深度解讀與最佳應用實踐
- 測試資料採集、同步、儲存與分析實戰
- 線上質量監控與資料分析實戰
- 測試平臺開發實戰（SpringBoot+Vuejs+Bootstrap）
以上，測試左移和測試右移是現代網際網路研發和測試技術體系的必然趨勢，也是大廠對中高階測試開發工程師的必備技能要求。
測試開發工程師會通過測試左移，更深入介入開發工作，提前與開發人員一起制定測試計劃，推動程式碼評審、程式碼審計、單元測試、自動化冒煙測試、測試精準化分析以及研發自測等來保證研發階段的質量。
另外，也會通過測試右移，參與配置部署，將自動化測試用例配置到持續交付鏈中，並全流程監控釋出後的應用質量。
附-測試左移和測試右移部分-實戰大綱，詳細完整版大綱請入群諮詢。
3 期熱招中，掃碼入群諮詢
提升自己的核心競爭力吧