為什么我把測試工作做得挺好的，線上環境還會出Bug？這些Bug可能是因為當初設計時就有的漏洞，也可能是部署不當帶來的問題。
測試就不能做點什么改變這種被動的現狀嗎？有，你需要踐行測試左移和測試右移。
一、傳統測試流程
1、測試流程
大家熟悉的測試工作是接到項目后參與需求評審，然后根據需求文檔寫用例和准備腳本，等開發提測之后正式開始測試、提Bug、回歸，測試通過后就結束了，項目交給運維上線，之后投入下一個項目繼續重復這樣的流程
2、流程弊端
這樣的流程看似沒什么問題，但缺點是：
-
測試過程是在一定時間間隔內發生的，測試人員必須等待產品完全構建才能找到錯誤和故障。不可否認，花費的時間超過了可以商定的時間，等待代碼成為測試人員的瓶頸。
-
測試同學非常被動：當需求質量、開發質量差的時候，你只能被動接受，結果就是你會經歷漫長痛苦的測試過程以及因為質量差而導致上線延期；
-
Bug的成本在后期是非常高的，需要花費很多精力和時間去修復。甚至嚴重的情況是產品都不能按時發布，造成很大的損失。
-
有可能一個線上問題裸奔了幾個月，最后是業務方先發現才排查到是Bug導致，由於影響時間過長給公司造成的損失巨大，還被質疑為什么這么明顯簡單的問題上線之后沒人發現。
不管是測試左移還是測試右移，都是為產品質量服務。不要把提測認為是測試活動的開始，上線是測試活動的結束，更不要認為質量只是測試同學需要關注的。
二、測試左移
1、是什么？
測試左移的思想本質是越早的發現不合理的地方，出問題的幾率就越低。測試左移的原則支持測試團隊在軟件開發周期早期和所有干系人合作。因此他們能清晰地理解需求以及設計測試用例去幫助軟件“快速失敗”，促使團隊更早的修改所有的bug。
參與和理解會使測試人員獲取產品完整的知識，徹底想清楚各種場景，根據軟件行為設計實時的場景，這些都會幫助團隊在編碼完成之前識別出一些缺陷。
2、怎么樣？
從不重視代碼質量的第一天開始，就埋下了問題修復，定位的成本和修復問題再次引入問題的成本。
當測試在周期的早期開始時，團隊會更專注於質量，並且“讓我們在第一時間獲得正確的編碼”前景。這有助於節省大量時間，並減少軟件開發團隊必須為特定代碼執行的迭代次數。因此需要提高質量上限和質量下限。
提高質量上限：通過一系列活動，來避免問題或者本身就讓我們起步就變得很好的，一句話：良好的開始是成功的一半。
提高質量下限：通過一系列的活動，讓我們的質量成果得以保證。
測試左移，其實就是通過一系列的活動，能提高質量的上限，縮短測試的周期，提高質量的下限，這樣我們就可以在不斷提高下限的過程中，始終將質量穩定在一個水平線上，而和團隊一起追求更高的目標。
3、怎么做？
在團隊的Devops開發下，對於測試左移進行的操作：
-
編寫單元測試，通過單元測試提前進行測試；
-
Code Review，通過代碼走讀發現一些基礎的問題；
-
參與需求評審，提出需求不清晰、不合理、遺漏等意見，了解開發的實現方式；
-
參與研發需求分解，協助梳理分解遺漏點；
-
參與概要、接口設計評審，協助梳理遺漏邏輯；
-
提早輸出測試導圖，開發編碼前進行評審；
-
部分功能提測，提早開始測試；
-
自動化測試，用於回歸確保舊版本功能正確性；
對於測試左移，進行了相應的嘗試后，也發現了測試左移實踐的問題：
-
測試要求提供概要設計、接口文檔；
-
測試要求單元測試必須通過；
-
測試干預需求設計；
很多人都認為是測試在要求完成一些沒必要的事情，測試在干預我的工作。
其實問題的矛盾點在於前面說過的一句話：不管是測試左移還是測試右移，都是為產品質量服務。不要把提測認為是測試活動的開始，上線是測試活動的結束，更不要認為質量只是測試人員需要關注的。對於測試左移的落實，最重要的就是全員質量服務意識的培養。
4、測試需要關注什么？
對於測試左移其實我們還有很多東西要做，就好像前面說到的都是為產品質量服務，那么在研發流程中的任何角色、人員都要為質量服務。
-
了解和評估需求，發掘需求的不合理之處，提供針對性的建議，提高需求的質量。
-
了解和評估產品設計方案，發現設計的漏洞，並及時反饋給產品人員，避免問題到了測試階段才暴露出來，影響產品按時發布。
-
了解產品的技術實現，通過查看開發文檔，接口文檔等，執行靜態測試發掘問題，檢查代碼問題。
提高質量上限：
-
健康的項目流程（合理並且嚴格遵守的項目流程）；
-
合理的需求分析（評估需求的質量，分析需求的合理性以及完整性）；
-
出色的系統架構；
-
充分利用靜態代碼掃描；
-
進行研發標准的定義；
提高質量下限：
-
健康的測試流程；
-
優秀的測試用例；
-
合理的測試計划；
-
合適的自動化；
-
適當的探索式測試；
-
開發自測（TDD、BDD，測試提供更好的用例、技術支持）；
-
盡早的測試；
-
團隊質量意識的培養；
對於測試左移，也需要一個重要的基礎，工程習慣，SDLC成熟度，測試分層，持續集成，鏈路上延展發布的節奏，縱深上需要貼合業務的專精領域的深度探索，代碼掃描（規范，問題，安全，異常等），CR， 代碼提交行為分析，test double（mock ， fake， stub，dummy）， UT， 自動化，驗收測試等。左移需要工程效率具備不亞於研發的代碼能力。因此對於測試左移，可以圍繞質量服務思想展開，參與人員則不僅僅局限於測試人員。
三、測試右移
1、是什么？
左移是往測試之前的開發階段移，右移是往發布之后移。也就是產品上線了之后也可以進行一些測試活動。當然在生產環境直接做測試是不推薦的，但是我們可以在生產環境做監控，監控線上性能和可用率，一旦線上發生任何問題，盡快反應，提前反應，給用戶良好的體驗。技術人員要比業務方先發現問題，如果業務方已經發現業務量明顯下降，說明問題已經很嚴重了。
測試右移其實還可以理解為如果線上發生任何問題，我們有沒有能力第一時間發現問題並解決問題，並保證線上數據的一致性或盡可能少的影響線上用戶，以及並且實時獲取用戶反饋。
2、怎么樣？
實踐起來也是存在問題，除了技術問題之外，還有例如：
-
線上監控搭建后使用率不高；
-
線上問題反饋機制，業務人員不配合等等；
-
監控指標不合理，反而被認為增加服務器負載；
-
測試右移的落實，除了質量服務的培養，更加重要的反而可能是：完善的反饋、發現、定位，在監控- 架構完善后，怎么更好的與項目工作(流程)結合，不要讓其成為累贅。
3、怎么做？
對於測試右移，線上監控可以是突破點：
-
閉環的線上問題反饋-檢查-解決-更新流程；
-
更便捷的日志查看、回傳服務；
-
豐富有效的log，便於問題的快速定位；
-
豐富的監控指標（例如業務異常點指標）；
-
成本監控（例如短信發送等）；
-
關鍵指標每日監控（服務器指標）；
-
生產數據監控（警報）（通過sql語句實現生產數據監控，例如是否有多個訂單號一樣的訂單出現等）；
-
因此對於測試右移，可以圍繞問題反饋、發現、定位、監控展開，參與人員則不僅僅局限於運維人員。
4、測試需要關注什么？
軟件一經發布，就要對線上日志監控和預警。及早發現問題，及早修復，將損失降到最低。而不是等用戶反饋了，才去解決。如果等到用戶反饋問題，說明問題影響反饋已經很大了。
-
測試上線及時驗證，有問題，開發快速回滾代碼
-
上線后開發監控服務日志，日志報錯，代碼回滾
-
xdcs監控服務流量，出現流量報警快速定位問題
-
關鍵指標每日監控（服務器指標）
-
生產數據監控（警報）
-
用戶反饋問題及時跟進，針對缺陷，通知開發盡快解決，針對體驗，通知產品打磨細節，更好的服務用戶。
灰度發布，數據隔離，線上監控，線上驗收。當業務方由於環境等原因，有些功能必須在線上驗收。線上驗收的原則是盡可能的不要影響到原有功能和使用業務的用戶，這個就需要做好很好的隔離，所以從研發一開始的設計就從線上可測性角度就需要考慮到這一點，功能做好隔離，數據做好隔離，一旦出現問題，我們有相對應的風險預案，如何清除臟數據，如何將功能降級等，前期的設計都要考慮好，發布完成以后我們還需要考慮運營層面的事情。
采集線上數據，包括業務數據和性能數據，建立一個健康的產品數據模型。業務數據可以通過數據挖掘，生成用戶畫像，有助於產品人員做出相應的決策，包括改進現有功能，開發新功能滿足用戶需求，砍掉某些不合適的功能等。性能數據，最直接的作用就是運維人員做出相應的硬件調整，包括硬件擴容，整合閑置資源等。也可以給架構師提供一些系統架構設計上的調整。
四、總結
測試左移的落實，最重要的就是全員質量服務意識的培養。測試右移的落實，除了質量服務的培養，更加重要的是：完善的反饋、發現、定位問題，提升用戶體驗。相比較，測試左移的價值更高，盡早發現並解決問題，成本更低。
無論是測試左移還是測試右移，測試人員開始從質量控制轉變成質量保證，從被動發現軟件問題到主動提高軟件質量，從團隊的邊緣人物轉變成團隊的活躍分子，這都值得為之踐行。
