對於出現漏測的緣由、和規避方法的想法

出現漏測的緣由、解決方法

在產品週期的任何階段，都有可能出現測試遺漏，測試沒法保證百分之一百的窮舉覆蓋，只能根據必定的測試方法，好比邊界值，進行抽取測試

而這邊的漏測主要指的是在業務上，因爲業務分析不全面致使的漏測

 

出現的緣由可能有如下幾點：

①、需求評審階段：對業務需求瞭解不透徹，沒有深刻挖掘隱藏的需求點；

>>>改進方法：
     需求評審前，提早了解需求文檔與原型，先造成本身對產品的思考，能夠藉助腦圖來列出對產品設計的疑問點，產品設計的缺點，能夠從測試或者產品或者用戶的角度來點評產品功能；
其次，需求評審期間，針對本身的疑問提出，與開發、產品，多問爲何，多確認....好比功能如何實現，超過預期如何處理數據來源、邏輯處理是客戶端處理仍是服務端處理、緩存機制、是否新增接口或新增字段、是否存在新舊版
兼容問題
     需求評審會後，整理開會梳理的疑問點，開始接下來的需求分析階段.....

 

②、需求分析階段：測試用例設計不全面，致使場景遺漏

 

>>>改進方法：
     需求評審後，根據梳理的疑問點，對需求進行分模塊，再將模塊拆分紅功能點，再根據合理使用測試用例的設計方法，來進行需求分析。
     測試用例或分析完畢後，有必要進行組織用例評審（或組內用例評審）：一方面是組內若是有業務老司機，能夠在用例評審上快速指出遺漏之處，有助於測試人員打開思路，
儘量多的覆蓋測試點，評審過程當中，若是有發現不肯定的，必定要及時記錄下來，不要盲目猜想，所以若是有產品在場就更好了。
     根據測試用例執行上線後，若發現有用戶反饋問題，首先要確認是否必現、偶現，若是是必現，就要考慮是不是用例設計時場景沒有考慮全面引發的，若是是必現，
咱們能夠經過和技術接口人溝通，確認該場景的一些具體復現步驟，確認引入緣由，解決方案。而後進行測試用例完善：除了補充該場景case外，考慮一些和該場景相關聯的場景，
將多種場景下測試用例及時完善、評審，增長到用例庫中去。

 

 

 

③、測試階段：未徹底按照測試用例執行

 

>>>改進方法：
     測試用例沒法保證百分之百覆蓋全部的場景和細枝末節，可是能夠最大程度的保證產品質量，儘可能避免出現缺陷，前提是要嚴格按照測試用例執行。
     其次，執行時，要養成邊記錄邊執行的習慣，一輪執行下來，哪些經過、失敗（緣由）、阻塞（緣由）、有些實際結果與預期結果不一致，但產品不予解決，也要標註
這樣，在迴歸測試覆盤時，才能更有目的的測試迴歸，確保修復bug致使關聯功能引入的新bug也能被發現。
同時，這一份用例執行記錄，也就是很好的體現你這個模塊的覆蓋程度+完成度

 

 

 

④、測試階段：因爲測試資源、測試環境限制，致使沒法覆蓋場景

 

>>>改進方法：
  部分場景，在正式環境沒法模擬（沒法造數據），但測試環境又不能準確模擬，所以，就須要開發一個灰度發佈環境（預覽環境），既能知足測試任意造數據最大限度模擬線上，但又不影響線上正式數據

 

 

 

⑤、迴歸階段：開發人員引入新bug

 

>>>改進方法
   開發方面：從代碼管理層面，及時review代碼，開發修復一個bug提交代碼自測經過準備提測時，開發團隊提交代碼進行代碼review，引入新BUG的可能性較小。
   測試方面：精準迴歸，經過diff代碼的方式，瞭解代碼改動點，精準分析改動點對相關聯的功能點的影響，將開發人員修復的BUG確認驗證，並將相關聯的功能點儘量在app測試階段經過遍歷迴歸測試到。