cr 代碼_1

前沿拓展：

cr 代碼

CR2023電池CR代表扣式鋰錳電池的國際IEC編號，其中C以鋰金屬為負極，以二氧化錳為正極的化學電池體系，R表示電池的形狀為圓柱形屬3V扣式鋰錳電池。20代表此款電池的直徑是20mm，23代表此款電池的厚度為2.3mm，標稱電壓為3.0V。

1、前言

2、測試左移

2.1、左移實現步驟

2.2、左移過程改進

3、測試右移

3.1、右移實現步驟

3.2、右移過程改進

4、測試崗位要求

測試左移以及測試右移，能夠讓測試擁有更多的主動權，有更充足的時間進行測試，同時不會像之前因為質量差風險高每次都延期上線，并且產品的線上質量也能有保證。

不管是測試左移還是測試右移，都是為產品質量服務。不要把提測認為是測試活動的開始，上線是測試活動的結束，更不要認為質量只是測試同學需要關注的。

如下圖所示：

大部分的問題在編碼階段引入。編碼階段引入問題的原因可能是代碼問題，需求理解問題，異常處理cover不到，集成階段，多團隊合作對接過程等。

在集成階段發現問題的修復成本是編碼階段修復成本的40倍。

從編碼、單元測試、功能測試、系統測試、發布的不同階段，修復一個bug的成本在不同階段有著天壤差別。不僅從成本上，從修復難度，引入新問題的可能性，溝通成本，團隊狀態也會有很大的影響。

造成修復成本高的原因有幾類：

1、出現一個線上問題，如何定位，多團隊如何配合，如何確定根因？

2、線上問題，集成問題，牽扯到多個模塊，如何復現？如何模擬真實環境？多線程的場景？

3、如何確定修復方案，誰來修，臨時方案還是長久方案，是否是架構問題，多個模塊都需要修復會增加再一次間接引入問題成本，修復會不會引入其他問題？

左移后，bug早發現早解決，修復成本下降。

測試左移的思想，本質是越早的發現不合理的地方出問題的幾率就越低。

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

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

2.1、左移實現步驟

1、編寫單元測試，通過單元測試提前進行測試

2、Code Review，通過代碼走讀發現一些基礎的問題

3、參與需求評審，提出需求不清晰、不合理、遺漏等意見，了解開發的實現方式

4、參與研發需求分解，協助梳理分解遺漏點

5、參與概要、接口設計評審，協助梳理遺漏邏輯

6、提早輸出測試導圖，開發編碼前進行評審

7、部分功能提測，提早開始測試

8、自動化測試，用于回歸確保舊版本功能正確性

2.2、左移過程改進

對于測試左移，進行了相應的嘗試后，也發現了測試左移實踐的問題：

1、測試要求提供概要設計、接口文檔

2、測試要求單元測試必須通過

3、測試干預需求設計

很多人都認為是測試在要求完成一些沒必要的事情，測試在干預我的工作。

其實問題的矛盾點在于前面說過的一句話：不管是測試左移還是測試右移，都是為產品質量服務。

不要把提測認為是測試活動的開始，上線是測試活動的結束，更不要認為質量只是測試人員需要關注的。

對于測試左移的落實，最重要的就是全員質量服務意識的培養。

測試左移其實我們還有很多東西要做，就好像前面說到的都是為產品質量服務，那么在研發流程中的任何角色、人員都要為質量服務。

1、提高質量上限

（1）健康的項目流程（合理并且嚴格遵守的項目流程）

（2）合理的需求分析（評估需求的質量，分析需求的合理性以及完整性）

（3）出色的系統架構

（4）充分利用靜態代碼掃描

（5）進行研發標準的定義

2、提高質量下限

（1）健康的測試流程

（2）優秀的測試用例

（3）合理的測試計劃

（4）合適的自動化

（5）適當的探索式測試

（6）開發自測（TDD、BDD，測試提供更好的用例、技術支持）

（7）盡早的測試

（8）團隊質量意識的培養

對于測試左移，也需要一個重要的基礎，工程習慣，SDLC成熟度，測試分層，持續集成，鏈路上延展發布的節奏，縱深上需要貼合業務的專精領域的深度探索，代碼掃描（規范，問題，安全，異常等），CR，代碼提交行為分析，test double（mock，fake，stub，dummy），UT，自動化，驗收測試等。左移需要工程效率具備不亞于研發的代碼能力。

因此對于測試左移，可以圍繞質量服務思想展開，參與人員則不僅僅局限于測試人員。

左移是往測試之前的開發階段移，右移是往發布之后移。

也就是產品上線了之后也可以進行一些測試活動。當然在生產環境直接做測試是不推薦的，但是我們可以在生產環境做監控，監控線上性能和可用率，一旦線上發生任何問題，盡快反應，提前反應，給用戶良好的體驗。

技術人員要比業務方先發現問題，如果業務方已經發現業務量明顯下降，說明問題已經很嚴重。

測試右移其實還可以理解為如果線上發生任何問題，我們有沒有能力第一時間發現問題并解決問題，并保證線上數據的一致性或盡可能少的影響線上用戶，以及并且實時獲取用戶反饋。

3.1、右移實現步驟

1、閉環的線上問題反饋檢查解決更新流程

2、更便捷的日志查看、回傳服務

3、豐富有效的log，便于問題的快速定位

4、豐富的監控指標（例如業務異常點指標）

5、成本監控（例如短信發送等）

6、關鍵指標每日監控（服務器指標）

7、生產數據監控（警報）（通過sql語句實現生產數據監控，例如是否有多個訂單號一樣的訂單出現等）

因此對于測試右移，可以圍繞問題反饋、發現、定位、監控展開，參與人員則不僅僅局限于運維人員。

3.2、右移過程改進

一樣的，實踐起來也是存在問題，除了技術問題之外，還有例如：

1、線上監控搭建后使用率不高

2、線上問題反饋機制，業務人員不配合等等

3、監控指標不合理，反而被認為增加服務器負載

4、測試右移的落實，除了質量服務的培養，更加重要的反而可能是：完善的反饋、發現、定位，在監控架構完善后，怎么更好的與項目工作(流程)結合，不要讓其成為累贅

這里所列舉的要求，其實是“理想型”或者是“全能型”的測試

1、會寫代碼，如Java、Python等

2、會用市面上常用的自動化測試工具，無論是Selenium, Appium, QTP（UFT）, Cucumber, JMeter, LoadRunnder, 統統可以上手

3、掌握運維人員使用的工具，如Jenkins、Docker、K8S等

4、會做性能測試，并可進行性能分析

5、對產品功能了如指掌

6、對測試理論，測試管理理念有深入的理解

7、細心，會溝通

8、最關鍵的問題是，熱愛測試工作，愿意無窮盡的找bug

公眾號：AllTests軟件測試

拓展知識：