最近公司晉升季，聽參加的小夥伴提到一些概念性的東西，其中就包括測試左移和右移。
這裏就藉着測試左移和右移的概念，覆盤一下測試工作中的內容。
一、左移右移是什麼
首先簡述一下左移右移的概念。
左移
說白了就是儘早的進行測試。比如在正式提測之前，可以對需求、代碼等進行評估或測試。
右移
這裏是針對發佈上線之後，再進行一系列的手段能夠及時發現問題，降低影響範圍。比如線上迴歸、監控等。
相比之下，右移可做的事情可能不少人都沒有注意。
其實真正要做得好的話，右移或許要比左移更有挑戰性。因爲那是在線上，考驗我們是否有能力第一時間發現問題，解決問題降低影響。
二、實際中做了什麼
總體來看，目前從左到右的過程中基本都有做一些工作。下面盤點一下可做的、已做的，以及實際中的一些問題等等。
1. 需求評審
預期狀態下是測試人員能夠主動參與需求的設計討論中，這個環節基本上都是做到的。
但是這裏重要的是，我們參與需求會不能僅僅“聽需求”，更重要的是能認真的分析需求，判斷需求的合理性、上下文是哪些，以及需求覆蓋的場景是否全面等。
2. 開發設計評審
這個環節也是很重要的，形式上或許不用那麼嚴謹。
比如我們通常在大的需求、項目時候會有正式的會議討論，但是日常大多迭代中，可能直接跟開發面對面碰一下就好了。
所以說形式不重要，但是環節必須有。
通常來說，開發人員會告訴你自己的設計，以及自己覺得會影響到的點有哪些，我們可以進行參考並進行補充。
對於開發提到的技術，我們不一定要全部都懂，但是設計思路還是需要理解的，有助於我們提高測試設計的覆蓋度。
有些涉及到一些中間件交互，比如緩存、MQ等，還需要結合中間件特性引入一些針對性的測試。
3. 單元測試
這個環節我目前所參與過的項目都是沒有做的，可能某些團隊有一些少量的要求，但是通常業務類的系統都不會要求的，需求可能經常會變，投入回報比太低。
另外，單元測試通常開發來做比較合適，但是工期往往都是很短，根本沒有時間去做單測。如果讓測試人員來做，那麼對測試人員的技能要求又是太高了些。
那麼是不是啥都做不了呢？
也不是，個人覺得條件允許的可以嘗試進行代碼走讀，好處如下：
- 更加清晰開發代碼的改動範圍
- 清楚具體代碼邏輯
- 倒逼自己學習
我個人目前也在嘗試做，中間會遇到一些寫法、封裝、設計模式等問題。有問題就需要去解決，解決了就學到了。
4. 代碼檢查
這裏可以引入一些工具來進行代碼檢查，目前經手的java項目會集成 SonarQube，在代碼提測的時候自動進行。
5. 自動化測試
這部分就很熱門了，現在也成了老生常談的話題。
目前我的項目裏是做了接口自動化集成，使用的是組內的一個平臺。但是個人覺得形式不重要，重要的是能否真正的提效。
實際中其實也發現有些人是爲了自動化而自動化，接口斷言不嚴謹，基本上檢查不出問題，那麼這種自動化用例就沒有存在的必要了。
其實除了自動化測試用例之外，某些場景下的高效造數據的腳本也是很有必要的。
6. 發佈監控
首先要注意平滑發佈。
另外在發佈的時候，通知相關開發人員一起進行監控。通常我會看應用日誌、以及對應服務器的指標狀況。
關於日誌，如果在測試過程中發現有些地方需要輸出日誌，可以提建議給開發。
7. 線上監控
發佈上線後，還是需要做一些措施來監控線上服務運行狀況。
目前公司是有統一的監控系統的，在裏面可以方便的查看應用的各項指標，比如：
- 請求量
- 失敗率
- CPU
- 內存
- JVM
...
如果公司還沒有一套完善的監控體系，那還是有必要建設一套的，有機會的話可以積極參與其中。
另外，必要的監控也是需要加上的。比如某個重要接口的調用量或錯誤率超過了設置的閾值，對應人員就可以收到警告，第一時間來關注解決問題。