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