一文搞懂測試左移和測試右移的 Why-How-What

軟件測試技術應當貫穿整個軟件開發生命周期、對軟件產品（包括階段性產品）進行驗證和確認的活動過程，其核心目標是盡快盡早地發現軟件產品中所存在的各種問題 bug—— 與用戶需求、預先定義的不一致性。

然而，傳統的軟件測試流程是：

接到項目后參與需求評審，然后根據需求文檔寫寫用例和準備腳本，等開發提測之后正式開始測試、提 Bug、回歸測試，測試通過后就結束了。然后，項目交給運維上線，之后測試人員再投入下一個項目，繼續重復這樣的流程。

這樣的流程看似沒什么問題，但缺點是：測試過程是在一定時間間隔之內發生的，測試人員必須等待產品完全構建才能找到錯誤和故障。不可否認，花費的時間超過了可以商定的時間，測試人員就非常被動，因為等待代碼成為測試人員的瓶頸。

而在移動互聯網和 DT 時代，互聯網產品迭代周期短、速度快、頻次高，促進了敏捷開發和持續交付等研發模式的全面流行，這也給傳統軟件測試方式帶來了更大的時間壓力。

而測試左移以及測試右移的意義就在于能夠讓測試擁有更多的主動權，有更充足的時間進行測試，同時不會像之前因為質量差風險高每次都延期上線，并且產品的線上質量也能有保證。

不管是測試左移還是測試右移，都是為產品質量服務。測試人應該秉持這樣的理念：不要把提測認為是測試活動的開始，上線是測試活動的結束，更不要認為質量只是測試同學需要關注的。

測試左移是向測試之前的開發階段移動。

測試左移的原則支持測試團隊在軟件開發周期早期和所有干系人合作。因此他們能清晰地理解需求以及設計測試用例去幫助軟件“快速失敗”，促使團隊更早的修改所有的 Bug。更深入的參與和理解會促進測試人員獲取產品完整的知識，徹底想清楚各種場景，并根據軟件行為設計實時的場景，這些都會幫助團隊在編碼完成之前識別出一些缺陷。

測試左移聚焦在使測試人員在全部和最重要的項目階段參與進來。這就是測試人員把焦點從發現 Bug 轉移到 Bug 的預防上，同時也驅動項目的商業目標。

隨著測試團隊的責任的提高，團隊不在僅僅聚焦在“測試軟件去發現 Bug”，而是積極團隊合作，參與項目初始階段的計劃和建立強壯有效的測試策略，而測試策略又為團隊提供好的測試領導力和指導，使團隊聚焦在產品的長遠的視角，而不僅僅是測試工作。

測試左移首先為測試人員提供了設計測試的機會，無論這些測試是被聚焦在客戶的體驗還是期望，也促使開發人員根據這些測試去開發軟件以滿足客戶需求。

測試右移是測試活動向產品發布之后的步驟移動。

測試右移是產品上線了之后也可以進行一些測試活動。主要關注的是產品性能及可用性監控，以及新功能的測試。通過測試右移可以在生產環境做監控，監控線上性能和可用率，一旦線上發生任何問題，盡快反應，提前反應，給用戶良好的體驗。

在霍格沃茲測試學院的測試開發課程教學體系，已經整理了當下最流行最實用的測試左右移技術棧，這里供參考：

代碼審計系統 SonarQube 實戰

測試用例與 JaCoCo 代碼覆蓋率數據分析實戰

ASM 插樁技術與 JVM-SandBox 項目實戰

精準化測試平臺構建實戰（可參考之前文章）

ELK 深度解讀與最佳應用實踐

測試數據采集、同步、存儲與分析實戰

線上質量監控與數據分析實戰

測試平臺開發實戰（SpringBoot+Vuejs+Bootstrap）

以上，測試左移和測試右移是現代互聯網研發和測試技術體系的必然趨勢，也是大廠對中高級測試開發工程師的必備技能要求。

測試開發工程師會通過測試左移，更深入介入開發工作，提前與開發人員一起制定測試計劃，推動代碼評審、代碼審計、單元測試、自動化冒煙測試、測試精準化分析以及研發自測等來保證研發階段的質量。

另外，也會通過測試右移，參與配置部署，將自動化測試用例配置到持續交付鏈中，并全流程監控發布后的應用質量。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。