為什么需要測試左移，測試右移？
測試可以保證產品質量，重要性不言而喻。但，要做好測試也比較困難，需要克服很多挑戰。尤其是，持續交付、敏捷開發等開發模式為傳統 軟件測試方式帶來了更大的時間壓力。
我們先來看看下面這種熟悉的測試方式都有什么問題：測試人員接到項目后參與需求評審，然后根據需求文檔寫用例、准備腳本，等開發提測之后正式開始測試、提 Bug、回歸，測試通過后就結束了，項目交給運維上線，之后投入下一個項目繼續重復這樣的流程。
這樣的流程看似沒什么錯，但有兩大問題：
測試人員非常被動。當需求質量、開發質量較差的時候，測試人員只能被動接受。
但同時，測試又被認為是質量的責任人。如果因為需求質量、開發提測質量差而導致上線延期，大家通常會首先怪罪測試團隊。
這些問題，在新的開發模式下愈發嚴重。因為這些新的開發模式有一個共同點，就是要縮短產品的交付周期，對自動化的要求越來越高，能夠專門留給傳統豎井流程中測試環節的時間越來越短，自然更難保證質量。在極端的情況下，比如在持續部署的模式下，所有測試都是自動化的，已經完全沒有留給測試人員專門進行手工測試的時間了。與此同時，測試的能力和質量又是這些開發模式成功的關鍵。否則，即使可以頻繁地構建產品，質量不過關價值也為零。所以，在快速開發模式的挑戰下，測試左移、測試右移就應運而生了。這些測試模式，能讓測試人員擁有更多主動權，以及更多的時間進行測試。
那，到底什么是測試左移和測試右移呢？
什么是測試左移和測試右移？
測試左移和右移，就是把測試的范圍從傳統測試的節點中釋放出來，向左和右擴展。
向左擴展，就是讓測試介入代碼提測之前的部分。比如，擴展到開發階段，在架構設計時就考慮產品的可測試性，並盡量進行開發自測等。另外，測試可以更進一步擴展到需求評審階段，讓測試人員不只是了解需求，更要評估需求的質量，比如分析需求的合理性以及完整性等。
類似的，測試右移，是讓測試介入代碼提測之后的部分。比如，測試人員在產品上線過程中，利用線上的真實環境測試。另外產品上線之后，測試人員仍然介入，通過線上監控和預警，及時發現問題並跟進解決，將影響范圍降到最低。這樣一來，測試人員不但有更多的時間進行測試，還能發現在非生產環境中難以發現的問題。
測試左移的原則和實踐
1、調整團隊對測試的態度；
2、把測試添加到開發和產品需求步驟中；
3、頻繁測試，快速測試。
測試左移原則一：調整團隊對測試的態度
調整團隊對測試的態度，打破豎井的工作方式，是測試左移的前提。一個有效的辦法是，按照功能的維度管理團隊，讓整個功能團隊對產品負責。也就是說，如果產品質量出現問題，不只是測試團隊“背鍋”，而是會影響整個功能團隊的績效。同時，讓質量問題的直接責任人承擔更多的責任，來進一步增強團隊成員的責任心。這種利益綁定的辦法，雖然簡單但非常有效，只不過出現質量問題時要記得進行根因分析，以避免再次出現類似問題。
另外，還要改變團隊成員對測試工作的認知。傳統的工作方式中，我們通常認為發現 Bug 最重要，但其實為了提高產品質量，更重要的是預防 Bug。所以說，在測試左移的過程中，我們應該更聚焦在預防 Bug 上。
測試左移原則二：把測試添加到開發和產品需求步驟中
測試左移的第一步，是把測試工作融入到開發步驟中。常用的辦法是，讓測試人員參與到開發階段的方案設計中，了解開發的實現方式。因為很多開發人員可能只熟悉他負責的那一部分，而測試人員往往對全局更加了解，所以測試人員要評估改動范圍以及是否有遺漏的模塊和系統。
另外一個比較徹底，也很有效的方法是全棧開發，通過運維團隊提供工具和支持，讓開發人員盡量參與到運維工作中去。對於測試來說，也是同樣的道理。我們可以讓測試團隊轉型，進行工具開發，並更多地去支持專項測試，比如性能測試、安全測試等，通過“使能”的辦法，讓開發人員完成功能測試，包括單元測試、集成測試等。
說到讓開發人員完成部分測試工作，常常會聽到很多質疑聲。反對者認為，測試人員的心理模型跟開發人員不一樣，他們更傾向於去找問題。而開發人員面對自己開發的產品，潛意識里就不願意去找問題，比如，他們不願意專門嘗試各種邊界輸入進行測試，而把自己開發的功能搞崩潰。所以，開發人員和測試人員更適合分開。
這種觀念，在 10 年前瀑布開發模式盛行時就深入人心。我曾經也非常認同，但在 Facebook 工作了 5 年后改變了看法。如果你能夠把開發人員的責任界定得很清楚，誰開發的產品誰要保證質量，那么開發人員自然而然地就會去嘗試做好測試，比如進行邊界測試。而且，開發人員最了解自己寫的代碼，所以他能夠最高效地對自己的代碼進行測試。
當然，做全棧開發的同時我們仍會保留一部分功能測試人員，畢竟從豎井模式轉變到全棧模式是一個循序漸進的長期過程。不過 Facebook 做到了極致，完全沒有了功能測試人員，也就是我們所說的“去 QA”。
測試左移到了開發階段之后，再往左移一步就到了產品設計階段，在這里，測試人員除了解需求外，更重要的是評估需求的質量。
我推薦使用 BDD（Behavior Driven Development，行為驅動開發）的方法進行開發，促進團隊在需求評審時更多地考慮測試。BDD 是通過特定的框架，用自然語言或類自然語言，按照編寫用戶故事或者用例的方式，從功能使用者的視角描述並編寫測試用例，從而讓業務人員、開發人員和測試人員着眼於代碼要實現的業務行為，並以此為依據通過測試用例進行驗證。
測試左移原則三：頻繁測試，快速測試
測試左移的第三個重要原則是，頻繁測試、快速測試。在測試左移之前，我們需要等待提測，比較被動，不能頻繁測試。但測試左移到開發階段之后，我們就有了很大的自由度去頻繁運行測試，從而更好地發揮測試的作用，盡早發現更多的問題。
這里最重要的方法就是，我在講持續開發時提到的幾個關於驗證的操作，具體包括：
規范化、自動化化本地檢查；
建設並自動化代碼入庫前的檢查流程；
提供快速反饋，促進增量開發。
另外，為了能夠順利、頻繁地運行測試，我們還要提升測試運行的速度。給測試提速的常見辦法包括：
- 並行運行。比如把測試用例放到多台機器上運行，用資源換時間。
- 提高構建速度。比如使用精准構建，因為通常構建之后才能運行測試。
- 精准測試，也就是只運行跟改動最相關的測試。可以建立需求與代碼的關系，以及需求與測試用例的關系，從而在代碼改動時重點關注與之最相關的測試用例。
- 分層測試，即不同情況運行不同測試用例集合。
- 減少不必要的用例。比如，識別不穩定的用例，對其刪除或者優化。