如何做好開發自測

• 2019 年 10 月 15 日
• 筆記

  最近做研發品質分析，大家共同提到了一個改進措施：加強開發自測！

  但是如何加強開發自測、怎麼做好開發自測？帶著這個問題，進入我們今天的分享：

一、開發測試小記

  開發同學功能開發完成後，簡單自測通過後，填寫提交單提交測試，然後：

  製作的修補程式，打到測試環境，發現丟了一些SQL、Dll、配置，然後提交單被測試無情地打回。   

  即便修補程式更新成功，扛不住測試用例的第一輪飽和測試，出現影響測試進展的Bug，或者Bug太多，滿足打回標準，提交單繼續被無情打回。

  提交單打回後，開發同學集中修復了Bug，再次提交測試。正常情況下，第二輪功能測試發現的Bug會大幅減少，如果重新提交的修補程式品質不佳，修復Bug的同時，帶來了更多新的Bug，提交單還是有可能繼續被打回。

  功能測試通過後，進行性能測試，並發壓力上來後，功能被打爆、資料庫被打爆、MQ被打爆，提交單再次被打回。 

     ……

  上面的場景，大家都很熟悉，很多開發、測試同學通過都經歷過。我們如何用真正的行動來加強開發自測，提升交付品質？我們需要有一套開發自測方法論：

二、開發自測方法論

 我們詳細展開講一下：

   1. 思想意識上，提升對自測的重視程度

• • 開發階段不僅是程式碼開發完成，編譯通過，更重要的是自測通過。
  • 自測工作投入應該占開發階段整體投入的30%，如果保證不了資源投入，自測只是一個形式；
  • 自測工作必須覆蓋全面的自測場景：正向、逆向、正常、異常、並發性能等等；
  • 自測是開發階段最重要的一環，如果不重視自測，測試階段可能會產生大量的Bug、提交單被打回、直接影響研發進度。
  • 自測直接決定了產品的品質。

   2. 自測的PDCA之-Plan計劃

   開發階段，要加強自測工作的詳細規劃和資源投入：

   這裡我們用的Scrum 迭代研發，以下是自測任務計劃情況：

       自測工作在迭代拆分計劃時，要儘可能的覆蓋環境搭建、單元測試、聯調測試等工作，併合理估計投入時間。

       同時具備完整的自測表，功能覆蓋度儘可能全。

   3. 自測的PDCA之-Do執行

      自測環境搭建：本機自測環境、Docker聯調環境

      單元測試：保證核心方法、介面、場景都能覆蓋到，必須有完整的斷言。主要包含：

• • 測試數據準備、準備Mock方法
  • 主流程正向測試
  • 主流程逆向測試
  • 詳細功能-正常場景測試
  • 詳細功能-異常場景測試
  • 並發性能測試
  • 測試數據清理

      介面自動化測試：基於介面自動化測試工具，實現介面的自動化測試

      集成測試：修補程式更新後全面功能測試，前後端聯調，保證自測功能表上所有功能都能自測通過。

      同時，自測儘可能的保證自動化、可重複執行！

    3. 自測的PDCA之-Check評估

     如何評估、衡量自測的品質：以關鍵結果為導向！

      測試Bug檢出率：

• • 通過測試發現的Bug，要低於自測發現的Bug
  • 如果測試檢出率過高，需要詳細做5why分析，為什麼自測未發現

      單元測試程式碼覆蓋度

• • 核心方法是否都通過了單元測試
  • 單元測試程式碼覆蓋度

      單元測試通過率

• • 所有單元測試必須包含完整的斷言
  • 所有單元測試必須全部測試通過

      自測功能覆蓋度

• • 自測表是否覆蓋所有的功能點
  • 自測表功能測試全部通過

   4. 自測的PDCA之-Act處理、完善

• • 完善單元測試：增加核心方法測試覆蓋、測試數據覆蓋、單元測試場景覆蓋
  • 增加自測功能覆蓋度：覆蓋更多自測功能，很多沒想到的測試點，增加到自測功能點中
  • 增加資源投入和工作規劃：通過實際評估，合理加大自測資源投入和工作規劃
  • 結對測試：自己開發的功能很多Bug可能測試不出來，結對測試，可以發現更多的Bug
  • 功能演示&Review：以用戶的視角、需求的視角，Review已實現的功能，發現更多的Bug，完善到自測場景中。

    其實還有很多其他的方法和討論來提升開發自測，同時提升自測的品質是一個不斷完善和改進的過程！

    以上是近期做開發自測的總結，歡迎大家繼續補充。

周國慶

2019/10/15