移動APP測試過程中對於BUG漏測的思考

標籤：bug側漏

背景
由於最近比較多暴露出來由於漏測導致在site測試階段才發現的bug，特別是一些涉及身份核查、認證鑒權、支付、交易動賬之類的問題，產生的後果是非常嚴重的。因此，對bug漏測進行一些思考,並進行總結。

原因分析
　　BUG其實是任何產品都無法避免的一個問題，不是所有的bug都能被發現，包括資深測試，或多或少的會出現線上缺陷，誰也不能把軟體所有的功能操作、運用情境想周全。雖說不能做到完全零缺陷，但是每次發布的產品，我們需要追求缺陷越來越少，產品投訴越來越少。
　　為什麼會出現缺陷漏測，主要有以下幾點：
需求評審階段，對業務需求細節理解不明確，未深入挖掘隱含拓展需求
問題分析
在實際產品研發過程中，產品需求其實處於一個細化過程中，在需求prd文檔互動文檔輸出進行評審時，未能把一些產品細節問題、隱含需求暴漏出來，而測試案例的編寫是基於prd互動文檔。
改進措施
需求評審前，我們應該先仔細閱讀prd及互動文檔，先形成自己對產品的思考，通過腦圖的方式列出對產品設計的疑問點,從使用者或者從行業角度找出產品設計缺陷點；
需求評審會議中，帶著列出的疑問點向產品、開發溝通自己對產品的疑惑和質疑點，多提幾個為什嗎？如何?？資料擷取來源？超出預期的資料怎麼處理？緩衝處理機制如何？資料儲存何處？邏輯由前端處理還是後端服務？後端服務邏輯是否跟第三方關聯？
需求評審完成後，按照一定的功能，將需求拆分成若干大模組，大模組拆分成小功能點，然後考慮功能點的具體實現流程
測試案例覆蓋不全面，情境出現遺漏
問題分析
　　在測試案例設計過程中，容易出現思維受限或者需求盲區，我們不可能完全覆蓋使用者使用的所有情境，編寫測試案例的同事不可能把所有的情境都能想周全，把所有的情境下的情況都寫成測試案例這也是不大現實的。
改進措施
用例設計開始之前，列思維導圖
通過思維導圖列出商務程序，前後端介面邏輯。然後按照prd和互動文檔，依照ui介面切分成大的功能塊，然後在大功能塊，然後在大功能塊再切成小功能塊，最後到功能點，每個功能點通過ui、準系統、邊界、記憶體、互動、網路、異常、介面邏輯等維度開展用例設計導圖，並列出需找產品、開發確認的疑點。
用例設計完成後組織用例評審
（1）組織開發、產品進行測試案例評審，並拋出用例設計時的疑問，通過產品實現角度、資料存放區、產品體驗角度對用例進行評審完善。
（2）如時間充裕，組織測試組內用例評審也是非常必須的，特別是一些經驗老道或者業務熟悉的老司機們，可以在用例評審上快速的幫忙指出用例的遺漏點，有助於測試人員開啟思路，儘可能多的覆蓋使用者情境，值得注意的是用例評審上遇到不確定的，應立即記錄下來，結束後及時找相關人員確認，避免猜測。
根據線上使用者反饋缺陷完善用例
產品測試發布上線後，對於使用者反饋的缺陷，如果缺陷是因為情境設計不全引起的，我們先分析出現問題的情境是必現還是偶現，如果是必現，我們可以通過和技術介面人溝通，確認該情境的一些具體複現步驟，確認引入原因，解決方案。然後進行測試案例完善：除了補充該情境case外，考慮一些和該情境相關聯的情境，將多種情境下測試案例及時完善、評審，增加到用例庫中去。
測試階段未嚴格按照測試案例執行
問題分析
按照測試案例執行測試，可以讓我們儘可能的不出現遺漏一些測試點。但是我們一些同學，不嚴格按照測試案例來執行測試，這樣出現了一些遺漏BUG實在是不應該。
改進措施
測試案例不一定能保證所有的情境和功能點都能覆蓋到，但是嚴格按照測試案例執行測試，能最大程度上保證產品品質，盡量避免出現缺陷。
另外養成測試紀錄習慣：對於測試阻塞用例、測試fail用例，應該重點關注並記錄，在迴歸測試階段進行精準迴歸測試，確保修複bug導致關聯功能引入的新bug也能被發現。
測試環境、測試資源受限，導致缺陷漏測
問題分析
　　互連網金融類產品的環境是及其複雜的，業務系統不是孤立存在的，關聯方環環相扣，而且關聯絡統常常出現不穩定的情況，另外涉及身份證、銀行卡等稀缺資源的使用有限，往往測試完一個有效資料廢棄一個有效資料，所以我們可以儘可能通過mock、還原客戶的實際環境（比如連網核查mock，銀行卡鑒權mock），但是畢竟不是真實的環境，由於環境的差異，可能出現很多意想不到的問題，這些問題可能只在特性的環境、特定的操作步驟下才會暴露出來，在我們的測試環境還原不出來，只能基於生產環境來驗證問題。
改進措施
引入灰階發布（預發布）測試
測試組在預發布環境上進行迴歸測試，能基本類比真實環境執行測試環境無法測試的用例，又不影響線上使用者的正常使用。
生產驗證環節做好case篩選
首先進行生產驗證case梳理，生產驗證case除了篩選p0+p1層級case進行迴歸外，還應該包含測試環境mock or擋板阻塞的測試case,以及後端介面對前端響應的case，在生產迴歸階段嚴格按照生產驗證case執行去覆蓋真實線上環境情境
加強後端及關聯方商務邏輯的瞭解
前端不僅需要瞭解前端與後端介面的互動商務邏輯，還需瞭解後端介面與其它關聯方的介面互動邏輯，對測試環境測試案例的覆蓋程度有整體的把控度，以確保生產環境的測試案例覆蓋做到全面性。
開發人員引入的新BUG
問題分析
　　有一些開發人員只會針對你所提交的BUG中問題的描敘步驟解決，並不會去排查該問題有可能涉及的所有點，有可能出現解決了這個問題，而引入了一個新的問題。
　　
　　另外，一個不熟悉功能模組的開發人員來修複BUG，因為業務不熟悉，考慮不周全導致無意識的引入新的BUG。
改進措施
代碼review
從代碼管理層面：開發修複一個bug提交代碼自測通過準備提測時，Team Dev提交代碼進行代碼review，引入新BUG的可能性較小。
精準迴歸測試
從測試自我修養層面：在開發提測後，通過diff代碼的方式，瞭解代碼改動點，精準分析改動點對相關聯的功能點的影響，將開發人員修複的BUG確認驗證，並將相關聯的功能點儘可能的遍曆迴歸測試到。
找開發聊聊開發是如何修複這個功能。
跟開發聊實現很容易從開發的設計中你可以把握到測試的注意點，並記錄體現在用例中。例如Ａ開發曾經用某種方式做了ａ功能，出現了某個bug,現在b功能用了同樣方式實現，那麼極有可能之前的bug還會出現在b功能。
ET測試（探索性測試）環節欠缺
問題分析
我們發現的很多BUG都不是按測試案例執行發現出來的，都是在測試過程中隨意測試發現的，而這些步驟在測試案例中並未體現，我們的測試案例不可能覆蓋所有的情境
改進措施
准入測試通過後進行ET測試
在測試准入測試完成進入SIT測試階段：一般來說，ET測試是最容易發現bug的，所以在測試准入測試完成進入SIT測試階段，先進行一輪探索性測試，使的大部分的bug先在測試前期暴露出來，讓bug累計數量達到一定的峰值，儘早發現bug，品質越高。
UAT測試之前進行組內ET測試
SIT測試進入尾聲，UAT測試之前組織一次組內ET測試,讓組內不同的測試用不同的測試方式，測試思維，測試經驗，測試習慣進行探勘測試，能發現一些由于思維定勢局限原因導致漏測的bug、詭異的bug或者使用不合理的地方
總結
　　缺陷漏測是不能杜絕的，缺陷漏測發生後，我們需要學會思考，吸取經驗教訓，儘可能的降低缺陷的漏測量。

移動APP測試過程中對於BUG漏測的思考