如何作好開發自測

  最近作研發質量分析，你們共同提到了一個改進措施：增強開發自測！

  可是如何增強開發自測、怎麼作好開發自測？帶着這個問題，進入咱們今天的分享：

1、開發測試小記

  開發同窗功能開發完成後，簡單自測經過後，填寫提交單提交測試，而後：

  製做的補丁，打到測試環境，發現丟了一些SQL、Dll、配置，而後提交單被測試無情地打回。   

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

  提交單打回後，開發同窗集中修復了Bug，再次提交測試。正常狀況下，第二輪功能測試發現的Bug會大幅減小，若是從新提交的補丁質量不佳，修復Bug的同時，帶來了更多新的Bug，提交單仍是有可能繼續被打回。

  功能測試經過後，進行性能測試，併發壓力上來後，功能被打爆、數據庫被打爆、MQ被打爆，提交單再次被打回。 

     ……

  上面的場景，你們都很熟悉，不少開發、測試同窗經過都經歷過。咱們如何用真正的行動來增強開發自測，提高交付質量？咱們須要有一套開發自測方法論：

2、開發自測方法論

 

  

 咱們詳細展開講一下：

   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