一、背景
漏測Bug是指產品邏輯缺陷在測試過程中沒有被發現（尤其是測試環境可以重現的缺陷），上線版本釋出後或者在使用者使用體驗後發現並反饋回來的缺陷。可能造成線上故障或者資損，在對產品測試過程中，自己也難免出現一些Bug的漏測，因此對Bug漏測進行一些思考，並進行總結。
二、原因分析
Bug其實是任何應用產品都會有的一個問題，不是所有的Bug都能被發現，包括資深測試，或多或少的會出現線上缺陷，誰也不能把軟體所有的功能操作、運用場景想周全。雖說不能做到完全零缺陷，但是每次釋出的產品，我們需要追求缺陷越來越少，產品質量越來越高，減少線上問題的反饋。
為什麼會出現缺陷漏測，主要有以下幾點：
2.1 需求評審階段，對業務需求細節理解不明確，設計存在不合理，未深入挖掘隱含擴充需求
問題分析
在實際產品研發過程中，產品需求其實處於一個細化、最佳化、下鑽過程中，在需求PRD文件互動文件輸出進行評審時，未能把一些產品細節問題、隱含需求暴露出來，而測試用例的編寫是基於PRD、互動文件以及自己對該需求經驗理解所涉及測試用例。
改進措施
- 需求評審前，我們應該先仔細閱讀PRD及互動文件，先形成自己對產品的思考，透過腦圖的方式列出對產品設計的疑問點,從使用者或者從行業角度找出產品設計缺陷點。
- 需求評審會議中，帶著列出的疑問點向產品、開發溝通自己對產品的疑惑和質疑點，多提幾個為什麼？如何實現？資料獲取來源？超出預期的資料怎麼處理？快取處理機制如何？資料儲存何處？邏輯由前端處理還是後端服務？後端服務邏輯是否跟第三方關聯？
- 需求評審完成後，按照一定的功能，將需求拆分成若干大模組，大模組拆分成小功能點，然後考慮功能點的具體實現流程，透過思維導圖細分模組功能、從頁面、互動、邊界處理、介面邏輯、環境配置等維度進行梳理需求，儘可能挖掘隱含可擴充需求點，然後進行一次測試組內需求評審和技術覆盤，讓協作成員一起補充隱含需求，使得產品設計缺陷儘早且最大化地暴露出來。
- 在後期技術評審時，探討邏輯互動以及上下游資料走向和訊息傳送流轉，串聯技術側疑問點。
2.2 測試用例覆蓋不全面，場景出現遺漏
問題分析
在測試用例設計過程中，容易出現思維受限或者需求盲區，我們不可能完全覆蓋使用者使用的所有場景，編寫測試用例的時不可能把所有的場景都能想周全，把所有的場景下的情況都寫成測試用例去模擬、去覆蓋這也是不太現實的。
改進措施
用例設計開始之前，列思維導圖
透過思維導圖列出業務流程，前、後端介面邏輯。然後按照PRD和互動文件，依照UI介面切分成大的功能塊，然後在大功能塊，然後在大功能塊再切成小功能塊，最後到功能點，每個功能點透過UI、基本功能、邊界、記憶體、資料、互動、介面邏輯等維度開展用例設計導圖，並列出需找產品、開發確認的疑點。
用例設計完成後組織用例評審
a. 組織開發、產品進行測試用例評審，並丟擲用例設計時的疑問，透過產品實現角度、資料儲存、使用者、產品體驗角度對用例進行評審完善補充。
b. 組織測試組內提前預審測試用例也是非常必須的，對於正式用例評審前會組內進行預審，在版本結束後組織全量用例集合入也會進行串講用例，特別是一些經驗老道或者業務熟悉的老司機們，可以在用例評審上快速的幫忙指出用例的遺漏點，有助於測試人員開啟思路，儘可能多的覆蓋使用者場景，值得注意的是用例評審上遇到不確定的，應立即記錄下來作為待辦項，結束後及時找相關人員確認，避免猜測不確定。
總結使用者反饋、完善測試用例流程-下鑽測試用例構建以有備無患
a. 產品測試釋出上線後，對於使用者反饋的缺陷，如果缺陷是因為場景設計不全引起的，我們先分析出現問題的場景是必現還是偶現，如果是必現，我們可以透過和技術同學溝通，確認該場景的一些具體復現步驟，確認引入原因，解決方案。
b. 對於線上如果出現缺陷需要對測試用例完善：除了補充該場景case外，考慮一些和該場景相關聯的場景，將多種場景下測試用例及時完善、評審，增加到用例庫中去。
c. 針對線上缺陷分析其具體原因做覆盤總結，關注線上問題反饋群，及時發現問題、定位問題、分析原因，判斷是否為老邏輯引入還是新功能引發問題，精準化補充對應的用例，針對特別場景補充介面自動化、防資損資料狗校驗、全量用例集合BVT用例。
2.3 測試階段未嚴格按照測試用例執行
問題分析
按照測試用例執行測試，可以讓我們儘可能的不出現遺漏一些測試點。不能因為某一個人或者對某一塊業務熟悉簡化其測試用例，不嚴格按照測試用例來執行測試，這樣出現了一些遺漏Bug實在是不應該。
改進措施
- 測試用例不一定能保證所有的場景和功能點都能覆蓋到，但是嚴格按照測試用例執行測試，能最大程度上保證產品質量，儘量避免出現缺陷。
- 養成測試紀錄習慣：對於測試阻塞用例、測試Fail用例，應該重點關注並記錄，在迴歸測試階段進行精準迴歸測試，確保修復Bug導致關聯功能引入的新Bug也能被發現。
雖然測試流程很規範，但是軟體質量還是不如意。
2.4 測試環境、測試資源受限，導致缺陷漏測
問題分析
對於現階段得物的測試環境問題是及其複雜的，業務系統不是孤立存在的，關聯方環環相扣，而且關聯絡統常常出現不穩定的情況，另外涉及身份證、銀行卡等稀缺資源的使用有限，往往測試完一個有效資料廢棄一個有效資料，所以我們可以儘可能透過mock、還原客戶的實際環境問題。
現實畢竟不是真實的環境，由於環境的差異，可能出現很多意想不到的問題，例如：配置問題、資料來源問題、以及資料同步問題，這些都是可能只在特性的環境、特定的操作步驟下才會暴露出來，在我們的測試環境還原不出來，只能基於預發環境或者生產環境來驗證問題，導致質量可能出現風險隱患。
改進措施
1）引入灰度釋出測試
測試組在預釋出環境上進行迴歸測試，能基本模擬真實環境執行測試環境無法測試的用例，又不影響線上使用者的正常使用。
2）生產驗證環節做好case篩選
首先進行生產驗證case梳理，生產驗證case除了篩選p0+p1級別case進行迴歸外，還應該包含測試環境mock or 擋板阻塞的測試case，以及後端介面對前端響應的case，在生產迴歸階段嚴格按照生產驗證case執行去覆蓋真實線上環境場景。
3）加強後端以及關聯方業務邏輯的瞭解
前端不僅需要了解前端與後端介面的互動業務邏輯，還需瞭解後端介面與其它關聯方的介面互動邏輯，校驗判斷其給的介面資料是否正確，對測試環境測試用例的覆蓋程度有整體的把控度，以確保生產環境的測試用例覆蓋做到全面性。
2.5 開發人員引入的新Bug
問題分析
有一些開發人員只會針對你所提交的Bug中問題的描述步驟解決，並不會去排查該問題有可能涉及的所有點，有可能出現解決了這個問題，而引入了一個新的問題。一個不熟悉功能模組的開發人員來修復Bug，因為業務不熟悉，考慮不周全導致無意識的引入新的Bug。
改進措施
1）程式碼review
- 從程式碼管理層面：開發修復一個Bug提交程式碼自測透過準備提測時，開發團隊提交程式碼進行程式碼review，引入新Bug的可能性機率就會較小，降低風險存在。
2）精準迴歸測試
- 從測試自我修養層面：在開發提測後，瞭解程式碼改動點，精準分析改動點對相關聯的功能點的影響，將開發人員修復的Bug確認驗證，並將相關聯的功能點儘可能的遍歷迴歸測試到
3）找開發聊聊開發是如何修復這個功能*
- 跟開發聊實現很容易從開發的設計中你可以把握到測試的注意點，並記錄體現在用例中。例如Ａ開發曾經用某種方式做了B功能，出現了某個Bug，現在B功能用了同樣方式實現，那麼極有可能之前的Bug還會出現在C功能。
4）覆蓋率的實踐和應用
- 增加開發冒煙執行程式碼覆蓋率，根據覆蓋率資料分析有那些冒煙用例未覆蓋到，是方法未覆蓋到、還是類未覆蓋到或者是異常邏輯的校驗未迴歸到，用開發自測和覆蓋率的方式降低其新Bug的引入。
2.6 探索性測試環節欠缺
問題分析
我們發現的很多Bug都不是按測試用例執行發現出來的，都是在測試過程中隨意測試發現的，而這些步驟在測試用例中並未體現，我們的測試用例不可能覆蓋所有的場景。
改進措施
1）准入測試透過後進行ET測試
- 在測試准入測試完成進入SIT測試階段：一般來說，ET測試是最容易發現Bug的，所以在測試准入測試完成進入SIT測試階段，先進行一輪探索性測試，使的大部分的Bug先在測試前期暴露出來，讓Bug累計數量達到一定的峰值，儘早發現Bug，質量越高。
2）UAT 測試之前進行組內ET測試
- SIT測試進入尾聲，UAT測試之前組織一次組內ET測試，讓組內不同的測試用不同的測試方式，測試思維，測試經驗，測試習慣進行探索測試，能發現一些由於思維定勢侷限原因導致漏測的Bug、詭異的Bug或者使用不合理的地方。
3）精準化測試
- 精準測試的測試用例聚類分析功能，可以有效地發現“測試的錯誤”。例如一個用例執行步驟錯誤，它的聚類結果必然會發生變化，管理者透過系統分析的結果就可以發現並糾正這一類的錯誤，而之前可能需要在現場迴歸反覆的確認。
- 精準測試的核心技術要點是測試用例與程式碼的追溯技術。這項技術簡單來說就是當功能執行完成以後對應的整體程式碼執行情況就會立即產生，即當點選一個測試用例，就立即追蹤到對應的程式碼和模組。
- 精準測試測試漏洞分析功能，適用於敏捷測試。它可以基於程式靜態資料和動態執行資料，自動分析軟體缺陷最高風險的位置，引導首先對於高風險的模組完成覆蓋，在有限時間內完成最具有風險的模組的覆蓋測試。
三、對於開發角度側思考
3.1 自測背景
開發人員做好自測，非常必要，也是大趨勢。前期都是開發自測，後期才是使用者體驗方面的測試。從成本和時間上分析，Bug越晚發現修復成本越高；從修改的效率來講，越早處理會越快。一個優秀的開發者，自測的Bug一定會多於測試發現的Bug，也就是輪到測試的時候Bug數量相當少。
3.2 疑難問題思考
- 時間和進度太緊張，排期緊湊。
- 對自己程式碼過於自信，自認為有很強的健壯性，不忍心去修改。
- 認為這是測試的責任，多度依賴測試。
- 不知如何有效的做好自測，覆蓋全面。
- 開發冒煙測試對於QA建立指定的用例理解不透徹，執行簡約。
3.3 思維轉變
- 程式碼質量、專案質量均是我們的責任。
- 測試和開發人員思考問題不同，開發是在製造軟體，測試是在破壞軟體，想辦法去找出問題。
- 任何功能都有正常場景和異常場景，多數使用等價類和邊界值去選擇資料，覆蓋全面。
- 不要相信任何開發的程式碼是無Bug。
- 走出具體實現時用的開發思維，站在需求和使用者的角度去自測是否透過，假如自己是使用者去測試你的功能。
3.4 不仔細認真自測帶來的痛處和隱患
- 需求遺漏：一旦被使用者發現此問題，使用者印象會大打折扣，可能直接從開始使用即放棄使用，將帶來非常大的客戶流失。
- 功能事故：主流程功能沒有測試到位，或者異常場景沒有測試到位，導致線上頻繁報錯，體驗極度不好，直接認為就是事故。
- 需求延期上線：如果自測不充分，測試花大量的時間去溝通低等級bug，甚至主流程走不下去，這樣無疑會給開發帶來返工、重複測試、耗時、需求延期、專案延期等一系列問題。
3.5 制定自測報告規範
- 功能模組介紹及背景介紹
- 功能、背景介紹
- 使用使用者群體介紹
- 環境資訊
- 版本號
- Hosts、程式碼釋出分支
- 預發or正式
- 功能設計文件以及UI設計圖等
- 資料庫資料同步、環境配置、開關設定等
- 梳理好的自測點
- 編寫程式碼時候記錄的業務點和測試點
- 需求變更的自測點
- 正向、逆向、異常場景測試點
- 相容性
- 開發此功能是否會對其他功能造成影響，一行程式碼是否會引發新的問題出現
- 自測實際結果：
- 高等級Bug數量、影響冒煙核心流程
- 中等級Bug數量、串聯流程鏈路
- 低等級Bug數量、頁面展示UI效果
- 開發冒煙自測階段覆蓋率
- 一輪、整合階段覆蓋率
- 期望結果：
- 符合測試SOP規定準出標準
- 冒煙自測以及整合階段覆蓋率標準
- 測試階段Bug數量的控制
- 上線後Bug數量的控制，質量月覆盤滿足數量控制標準
四、總結
缺陷漏測發生後我們需要深入分析漏測的Bug，思考哪方面做的不夠，是業務邏輯理解誤差？用例評測遺漏？技術方案存在不合理？思考設計用例方向出現了偏差？多問一些幾個為什麼，換位思考角度想問題，合理設計評測。確保類似的Bug能被預防提前發現暴露出來，從而儘可能的降低缺陷的產生，提高產品質量。在每個不同階段做好用例測試計劃執行，增加精細化測試以及探索性測試環節，需要開拓新的測試思想思維，走出慣用常規的測試思想。同時也要站在開發側、編寫程式碼設計的思維邏輯去考慮，降低可能在測試階段出現Bug漏測、遺漏的出現，開發側也需嚴格執行自測和覆蓋率SOP要求準出。
*文 /Viki
要是覺得文章對你有幫助的話，歡迎評論轉發點贊～