測試左移和測試右移理解

測試的理解：

1、測試在團隊中是成本中心，什么叫做成本中心？就是一般從上級的角度，或者從公司高管的角度來看，測試團隊里的人越少越好。

2、我們怎樣給測試團隊爭取到更多的利益或者更好的發展前景呢？那就需要我們對老板的認知進行一些拓展：讓老板從把測試團隊當做一個必須付出的成本，變為認可測試團隊也可以帶來更多的價值。

就是測試是否一定要等到最后才去做一些必要的檢查呢？如果我們只做必要的檢查，那么老板願意在測試方面付出的錢是非常少的。但是如果我們告訴老板說：我們可以把測試往左移、往前推，我們可以幫助產品經理提高所輸出需求的質量；讓項目中用更少的產品經理，給出更高質量的需求，讓用戶更加滿意——那么這個價值就會大很多。

拉通上級管理的痛點，明確團隊的目標 ，既要做好  研發領導溝通，產品領導、項目經理溝通向下團隊的溝通【測試領導視界】

溝通的前提不是PK音量，而是拿出事實依據，用數據來分析，聰明的領導都是冷靜的溝通。

 

測試左移測試右移：

對軟件產品而言，傳統的質量模式通過測試左移和測試右移被賦予更多的內涵，也承擔起更多的職責。

 

■ 測試左移：測試左移，本質上是借助工具和測試手段更早地發現問題和預防問題。

• 需求：對需求、架構和設計模型的測試；
• 開發：着重增加對單元、組件和服務層的測試；
• 持續測試：自動化測試。

■ 測試右移：對測試同學來說，版本上線后需要持續關注線上監控和預警，及時發現問題並跟進解決，將影響范圍降到最低。

• 灰度發布：新版本線上測試；
• 監控：合理的性能監測、數據監控和預警機制；
• 用戶反饋：線上問題處理、跟蹤機制。

測試可輸出方向：

1. 測試任務跟蹤

2. 建立代碼分支管理規范

3.代碼質量檢測

4. 持續測試：基於XX平台實現接口自動化

測試左移的原則支持測試團隊在軟件開發周期早期和所有干系人合作。因此他們能清晰地理解需求以及設計測試用例去幫助軟件“快速失敗”，促使團隊更早的修改所有的bug。

參與和理解會使測試人員獲取產品完整的知識，徹底想清楚各種場景，根據軟件行為設計實時的場景，這些都會幫助團隊在編碼完成之前識別出一些缺陷

有哪些活動可以提高質量上限（舉例）：

健康的項目流程（合理並且嚴格遵守的項目流程）
合理的需求分析（評估需求的質量，分析需求的合理性以及完整性）
出色的系統架構
完整的系統設計（評估設計的質量，分析需求的合理性以及完整性）
充分利用靜態代碼掃描
進行研發標准的定義
更早的測試分析（先於開發完成需求的分析，做好各種評審的准備）
盡早的測試執行（提早參與測試執行，在集成前就發現一些問題）
有哪些活動可以提高質量下限（舉例）：

健康的測試流程
優秀的測試用例
合理的測試計划
合適的自動化
適當的探索式測試
開發自測（TDD、BDD，測試提供更好的用例、技術支持）
團隊質量意識的培養

對於測試右移，線上監控可以是突破點，舉例：

閉環的線上問題反饋-檢查-解決-更新流程
更便捷的日志查看、回傳服務
豐富有效的log，便於問題的快速定位
豐富的監控指標（例如業務異常點指標）
成本監控（例如短信發送等）
關鍵指標每日監控（服務器指標）
生產數據監控（警報）（通過sql語句實現生產數據監控，例如是否有多個訂單號一樣的訂單出現等）
因此對於測試右移，我認為可以圍繞問題反饋、發現、定位、監控展開，參與人員則不僅僅局限於運維人員