測試左移和測試右移，我們為何要「上下求索」？

轉載請註明出處❤️

作者：測試蔡坨坨

原文連結：caituotuo.top/7b9ad46d.html

你好，我是測試蔡坨坨。

今天，我們來聊一聊測試左移和測試右移。

傳統測試流程與敏捷測試

在探討測試左移和測試右移之前，我們先來聊一下傳統的軟體測試流程（瀑布模型）和目前很多公司在用的測試流程（敏捷模型）的區別。

軟體測試作為軟體研發的一部分，有什麼樣的開發模式，就有與之對應測試模式。因此就有了適合傳統瀑布開發模式的傳統測試和適合敏捷開發模式的敏捷測試。

• 傳統測試是在程式開發完成之後，更強調測試的獨立性，將開發和測試兩個角色分的比較清楚，而敏捷測試更強調整個團隊對測試負責。
• 傳統測試具有明顯的階段性，而敏捷測試更強調持續測試和持續質量反饋。
• 傳統測試強調測試的計劃性，而敏捷測試強調測試的速度和適應性，需要不斷調整測試計劃以適應需求的變更。
• 傳統測試更關注測試檔案，如測試計劃、測試用例、測試缺陷和測試報告等，而敏捷測試更關注產品本身以及交付的客戶價值，強調面對面的溝通共同作業，持續質量反饋和缺陷預防。
• 傳統測試鼓勵自動化，但成功與否沒有致命的影響，而敏捷測試需要由良好的自動化測試框架支撐，因為在敏捷模式下，產品迭代速度快，市場不斷調整，客戶需求不斷變化，單純的手工測試越來越無法適應整個變化過程，測試人員如何快速響應並保證產品在上線後的質量能夠滿足客戶要求，如何保證在上線一個新功能的同時快速對舊功能進行迴歸，保證舊功能不被新功能影響而出現嚴重的Bug，自動化測試無疑是一個不錯的選擇。

從兩者的區別，我們可以看出傳統測試最明顯的弊端就是介入晚以及沒有持續測試。

所以，為了從根本上解決這類問題，於是開始推廣並實踐測試左移和測試右移。

測試左移

測試左移，顧名思義就是測試要在提測之前介入軟體研發流程，及時發現錯誤，避免將許多本可以規避的問題帶到測試階段才發現，導致修復成本過高，甚至導致專案延期無法按時交付。提倡預防缺陷勝於發現缺陷，需要把質量構建推向源頭，也就是產品需求，因為最嚴重的錯誤不外乎是系統不能滿足使用者需求。

測試左移通過持續對產品需求和設計進行評審，在需求評審時不只是簡單瞭解需求，而是要去評估需求的質量，分析需求的完整性以及合理性，及時發現需求和設計中的問題，從而可以更好地避免由於產品檔案不完善導致需求不明確的問題。

測試左移還包括程式碼評審，以及讓開發做更多的測試，加強單元測試，開發自測，持續整合等。在開發階段參與設計方案的設計，瞭解開發的實現方式和程式碼框架，從而可以更好地評估改動範圍、需要回歸的內容以及是否有遺漏的模組和系統。測試還可以通過提供測試用例或自動化測試指令碼的方式給開發，讓開發在設計時考慮更全面，同時方便開發自測，有助於提高產品質量，避免在收到提測包時冒煙測試主流程都沒通過，導致測試效率低下。

測試還需要不斷培養產品、開發同學的質量意識，提倡團隊對質量負責，同時提供必要的技術支援，協助產品、開發更好地進行測試，比如：公共測試用例、測試工具、測試指令碼等。

這樣一來，你會發現提測的質量會大大提高，原本要花一天時間冒煙的功能很快就能通過。

測試右移

測試右移指的是在軟體釋出之後關注線上環境，持續監控軟體的線上質量，以驗證產品在使用者的實際環境、資料、場景下，功能和效能是否符合使用者預期，而不是專案發布完成就萬事大吉了。

比如以下測試右移的活動：

• 通過監控預警系統，及時發現問題並跟進解決，將影響範圍降到最小。監控預警系統對IT基礎設施，以及業務系統中的大量資料進行採集處理，監測系統執行狀況，通過視覺化看板展示系統及服務的執行狀態、資源使用情況，當發生異常時，能及時告警，並幫助運維人員快速定位問題。

  • 對各種IT系統設施進行監控，比如：作業系統、伺服器、虛擬機器器、容器和網路通訊資訊，CPU、記憶體、磁碟等資源的使用情況；對中介軟體監控，比如：資料庫中介軟體、MQ訊息佇列、Web伺服器等系統，監控一段時間的請求量、響應時間以及存取紀錄檔資訊；對應用監控，比如：服務依賴關係和介面效能監控；對業務監控，例如：關注線上業務及使用者使用情況，使用場景，多關注使用者價值高、使用率高的功能，在用例中補充遺漏的場景，儘量多地進行覆蓋；對使用者體驗監控，比如：載入時長、卡頓率等。
  • 資料採集處理包括資料收集、資料處理、資料應用，處理後的資料可以在監控面板上以曲線圖、餅狀圖和儀表盤等直觀的方式展示，同時根據設定的閾值和告警規則監控各項指標和資料狀態，當符合告警規則時，系統通過郵件、簡訊等方式通知相關人員，以達到及時響應的效果。

• 線上效能測試

  • 全鏈路壓測
  • 線上效能監控
  • 流量回放技術

• 安全性監控

  在研發階段進行程式碼的靜態分析、安全性功能驗證和滲透測試等，以發現程式碼和系統級別的安全漏洞。在產品上線後，通過監控和檢查，發現系統的安全漏洞並及時修正。比如：身份認證、授權、存取控制和不可抵賴等是否已經整合到系統內；對使用者名稱、存取時間、操作和資源地址進行審計，判斷是否符合規範和要求；入侵檢測，檢測一些使用者是否越過存取控制機制進入系統內部，對存取頻率過高的情況進行警報並暫時凍結等。

• A/B測試

  把新舊兩個版本同時推播給不同的客戶，通過對比實驗進行科學驗證，從而判斷這些變化是否產生了更積極並符合預期的影響力，為下一步的決策或改進提供依據。

• 混沌工程

  對於大規模、高複雜的服務系統來說，僅在測試環境進行測試已經無法滿足質量需求，在生產環境下進行測試必將會在現在及未來雲時代中佔據重要地位，而混沌工程及其基於故障注入的測試提供了在生產環境中進行科學實驗的方法和技術。

總結

不得不承認測試左移和測試右移的提出，對於測試角色來說，無疑是一個很大的進步。

但是，這也反映出了一些問題。測試左移在一定程度上代表著測試人員對即將拿到一個什麼樣的半成品充滿了擔憂，所以我們迫不及待想做些什麼，於是我們拼命地往左邊擠，力求儘快發現一些錯誤，將這些問題扼殺在搖籃裡，避免自己接到一手爛攤子而焦頭爛額。測試右移在一定程度上是測試人員對自己測試的不自信，因為有時候我們絞盡腦汁設計測試用例，通過多輪反覆驗證，滿懷期待的上線，但是使用者總會以某個不可思議的角度狠狠地敲你一棒子，於是我們通過測試右移，持續測試，關注線上環境，趕在客戶發飆之前悄悄地把缺陷解決。

同時也反映了測試人員對質量的影響是很小的，單純在測試階段執行測試是不夠的，所以我們不得不「上下求索」，以求一份安心，不應該把提測認為測試活動的開始，把上線認為是測試活動的結束，更不要認為質量只是測試人員需要關注的，因為質量不是被測試出來的而是被設計出來的，應該伴隨整個軟體的生命週期。