一、測試左移與測試右移的定義
通俗的講：左移是往開發階段移，右移是往發布之后移。
正常測試：提測后的測試工作——到——發布驗證完成階段。
測試左移：提測之前的測試。如：代碼單元測試，代碼質量檢測，代碼接口持續測試 等。
測試右移：發布驗證之后的測試。如：灰度發布測試的問題，生產服務監測處理，用戶反饋問題處理，對客戶的技術支持等。
1、什么是測試左移？
測試左移的思想本質是越早的發現不合理的地方，出問題的幾率就越低。
測試左移的原則支持測試團隊在軟件開發周期早期和所有干系人合作，因此他們能清晰地理解需求以及設計測試用例去幫助軟件“快速失敗”，促使團隊更早的修改所有的bug。
參與和理解會使測試人員獲取產品完整的知識，徹底想清楚各種場景，根據軟件行為設計實時的場景，這些都會幫助團隊在編碼完成之前識別出一些缺陷。
2、什么是測試右移？
測試右移是產品上線了之后也可以進行一些測試活動。當然在生產環境直接做測試是不推薦的，但是我們可以在生產環境做監控，監控線上性能和可用率，一旦線上發生任何問題，盡快反應，提前反應，給用戶良好的體驗。盡量做到技術人員要比業務方先發現問題。
測試右移其實還可以理解為如果線上發生任何問題，我們有沒有能力第一時間發現問題並解決問題，並保證線上數據的一致性或盡可能少的影響線上用戶，以及並且實時獲取用戶反饋。
■ 測試左移：測試左移，本質上是借助工具和測試手段更早地發現問題和預防問題。
- 需求：對需求、架構和設計模型的測試；
- 開發：着重增加對單元、組件和服務層的測試；
- 持續測試：自動化測試。
■ 測試右移：對測試同學來說，版本上線后需要持續關注線上監控和預警，及時發現問題並跟進解決，將影響范圍降到最低。
- 灰度發布：新版本線上測試；
- 監控：合理的性能監測、數據監控和預警機制；
- 用戶反饋：線上問題處理、跟蹤機制。
二、測試左移內容
2.1 PRD評審
這一點相信很多測試同學都有參與過，需求的PRD評審，但是很多時候可能只是局限於聽需求，而缺少了分析or測試需求的部分。測試一方面是熟悉需求的內容，另一方面也是找出需求的問題，確認需求的合理性，判斷需求是否全面、正確，上下文具備不二性。
2.2 研發設計評審
這一點當我們測試在做測試方案、用例設計的時候，研發也在做研發設計，做好了之后通常會有研發設計的評審。測試在這個階段是非常有必要參與研發設計的評審的。
有的同學可能會覺得，研發設計評審說的都是研發如何實現整個需求，自己去聽也聽不太懂，浪費時間。其實不然，雖然不一定我們能全部聽懂所有的研發技術，但是至少我們能聽到研發去開發整個需求的整體設計思路，聽完對於我們熟悉整個需求的架構圖非常有幫助，也就能幫助測試更好的去設計對應的測試用例，提高測試用例的覆蓋率。
避免純粹從黑盒的角度去設計測試用例，導致有一些個別情況下的缺失測試用例覆蓋的情況。當然，如果測試具備走讀研發代碼的能力，參與研發的設計評審，對於提升測試用例覆蓋率，會更加的事半功倍！
2.3 單元測試
這一點現在應該只有一些大廠會執行得好一些，很多中小公司都沒有嚴格要求研發必須做單元測試。一方面是中小公司流程上要求普遍不會那么嚴格，另一方面也是需求開發時間越來越短，導致研發們普遍都沒有很多的時間去執行單元測試的工作，為保障按時交貨，都直接開發完成就扔給測試去做相應的測試。
在這一點上我依然堅持研發為主、測試為輔的思路。測試輔助研發更好的完成單元測試。為什么不是測試直接去做單元測試呢？因為這一方面需要測試具備白盒測試
這一點我們測試可以做一個mock平台或者mock服務提供給研發，幫助研發可以快速mock接口內容，提高聯調測試的效率。
2.5 代碼規范檢查
這一點也是提高研發提測質量的手段，可以通過各類代碼檢查工具來規范提高研發的代碼質量。比如Java系比較流行的SonarQube, 可以結合進CICD的流程，作為代碼提測的必查項。
2.6 代碼復雜度檢查
這一點也一樣，只是很多公司目前不太在意這一點。其實越復雜的代碼，也就意味着其存在bug的可能性越高。同樣代碼越復雜，也意味着編碼質量可能不高或者后期代碼維護成本的升高。SonarQube目前也能掃描代碼的復雜度，編譯器Idea的也有類似的插件提供該項檢查，因此這一點也可以列為流程中的必查項。
2.7 自動化測試
這一點就是測試最熟悉的了，自動化測試，目前主要包括UI自動化和接口自動化，實現的方式也是多種多樣，編寫腳本的方式、錄制回放的方式，用平台、不用平台都OK。重點在於選擇適合自身組織的方式，以及如何自動化是否真的提升了測試的效率，避免為了自動化而自動化。
三、測試右移內容
3.1 灰度發布
項目上線后仍然需要關注服務的運行情況，以便在出現系統問題時能夠快速做出反應。這一點主要是測試可以右移參與線上環境監控工具的部署，讓整個線上的監控體系更加完善。
即使部署的工作都是運維在做，監控體系已經非常完善，測試也可以接入告警，當業務接口出錯或者調用量超過閾值時，測試可以接收到對應的告警信息，和研發一起定位解決問題。
3.3 用戶反饋
測試參與到線上用戶反饋的問題中去，幫助復現和定位各類線上用戶反饋的問題，既可以解決問題，也可以更多的了解用戶實際使用過程中的問題和需求，幫助后續更好的做好需求評審和測試覆蓋工作。
3.4 混沌工程
類似於“故障演練”，通過構造各類異常，驗證系統在碰到這些異常時是否有做好對應的監控告警、預案處理，針對性地進行加固，防范，從而避免故障發生時所帶來的嚴重后果。通過對各類異常提前做好監控告警和預案處理，增強系統的健壯性，增強分布式系統的信心。目前已經成為各大廠測試右移
ABTest 實驗，其實本質上就是把平台的流量均勻分為幾個組，每個組添加不同的策略，然后根據這幾個組的用戶數據指標，例如：留存、人均觀看時長、基礎互動率等等核心指標，最終選擇一個最好的組上線。常用於驗證不同的方案設計、算法設計的效果。
四、我們可以做什么
1，測試左移，我們可以做什么
1. 在需求評審時不只是了解需求，更是要去評估需求的質量，分析需求的合理性以及完整性。
2. 代碼掃描，代碼質量檢查，進行單元測試，測試驅動開發，這些都是在開發階段就引入測試的手段。
3. 測試人員盡早介入測試，參加需求分析，評審。
4. 持續測試：自動化測試。
對於測試左移其實我們還有很多東西要做，就好像一開始說到的都是為產品質量服務，那么在研發流程中的任何角色、人員都要為質量服務。
有哪些活動可以提高質量上限（舉例）？
- 健康的項目流程（合理並且嚴格遵守的項目流程）
- 合理的需求分析（評估需求的質量，分析需求的合理性以及完整性）
- 出色的系統架構
- 完整的系統設計（評估設計的質量，分析需求的合理性以及完整性）
- 充分利用靜態代碼掃描
- 進行研發標准的定義
- 更早的測試分析（先於開發完成需求的分析，做好各種評審的准備）
- 盡早的測試執行（提早參與測試執行，在集成前就發現一些問題）
有哪些活動可以提高質量下限（舉例）？
- 健康的測試流程
- 優秀的測試用例
- 合理的測試計划
- 合適的自動化
- 適當的探索式測試
- 開發自測（TDD、BDD，測試提供更好的用例、技術支持）
- 團隊質量意識的培養
對於測試左移，也需要一個重要的基礎，工程習慣，SDLC成熟度，測試分層，持續集成，鏈路上延展發布的節奏，縱深上需要貼合業務的專精領域的深度探索，代碼掃描（規范，問題，安全，異常等），CR， 代碼提交行為分析，test double（mock ， fake， stub，dummy）， UT， 自動化，驗收測試等。左移需要工程效率具備不亞於研發的代碼能力。
因此對於測試左移，筆者認為可以圍繞質量服務思想展開，參與人員則不僅僅局限於測試人員
當然實踐起來會存在一些問題，例如筆者團隊實踐起來，就出現了
- 測試要求提供概要設計、接口文檔！！！
- 測試要求單元測試必須通過！！！
- 測試干預需求設計！！！
很多人都認為是測試在要求完成一些沒必要的事情，測試在干預我的工作。
其實問題的矛盾點在於前面說過的一句話：不管是測試左移還是測試右移，都是為產品質量服務。不要把提測認為是測試活動的開始，上線是測試活動的結束，更不要認為質量只是測試同學需要關注的。對於測試左移的落實，最重要的就是全員質量服務意識的培養
2，測試右移，我們可以做什么
- 測試上線及時驗證，有問題，開發快速回滾代碼
- 上線后開發監控服務日志，日志報錯，代碼回滾
- 監控服務流量，出現流量報警快速定位問題
- 閉環的線上問題反饋-檢查-解決-更新流程
- 更便捷的日志查看、回傳服務
- 豐富有效的log，便於問題的快速定位
- 豐富的監控指標（例如業務異常點指標）
- 成本監控（例如短信發送等）
- 關鍵指標每日監控（服務器指標）
- 生產數據監控（警報）（通過sql語句實現生產數據監控，例如是否有多個訂單號一樣的訂單出現等）
- 用戶反饋問題及時跟進，針對缺陷，通知開發盡快解決，針對體驗，通知產品打磨細節。
因此對於測試右移，我認為可以圍繞問題反饋、發現、定位、監控展開，參與人員則不僅僅局限於運維人員
當然一樣的，實踐起來也是存在問題，除了技術問題之外，還有例如：
- 線上監控搭建后無人使用
- 線上問題反饋機制，業務人員不配合等等
- 監控指標不合理，反而被認為增加服務器負載
測試右移的落實，除了質量服務的培養，更加重要的反而可能是：完善的反饋、發現、定位，在監控架構完善后，怎么更好的與項目流程結合，不要讓其成為累贅。