1套啤、背景

漏測蚯舱，指在產(chǎn)品缺陷在測試過程中沒有被發(fā)現(xiàn)（尤其是測試環(huán)境可以重現(xiàn)的缺陷）英支，而是在版本發(fā)布后或者在用戶使用后發(fā)現(xiàn)并反饋回來的缺陷胶哲。
生命不息，BUG不止潭辈，在對產(chǎn)品測試過程中鸯屿，自己也難免出現(xiàn)一些BUG的漏測，因此把敢，對BUG漏測進行一些思考,并進行總結(jié)寄摆。

2、原因分析

BUG其實是任何產(chǎn)品都會有的一個問題修赞，不是所有的BUG都能被發(fā)現(xiàn)婶恼，包括資深測試桑阶，或多或少的會出現(xiàn)線上缺陷，誰也不能把軟件所有的功能操作勾邦、運用場景想周全蚣录。雖說不能做到完全零缺陷，但是每次發(fā)布的產(chǎn)品眷篇，我們需要追求缺陷越來越少萎河，產(chǎn)品質(zhì)量越來越高。

為什么會出現(xiàn)缺陷漏測蕉饼，主要有以下幾點：

2.1需求評審階段虐杯，對業(yè)務(wù)需求細節(jié)理解不明確，未深入挖掘隱含拓展需求

問題分析

在實際產(chǎn)品研發(fā)過程中昧港，產(chǎn)品需求其實處于一個細化過程中擎椰，在需求prd文檔交互文檔輸出進行評審時，未能把一些產(chǎn)品細節(jié)問題创肥、隱含需求暴漏出來达舒，而測試用例的編寫是基于prd交互文檔。

改進措施

• 需求評審前叹侄，我們應該先仔細閱讀prd及交互文檔休弃，先形成自己對產(chǎn)品的思考，通過腦圖的方式列出對產(chǎn)品設(shè)計的疑問點,從用戶或者從行業(yè)角度找出產(chǎn)品設(shè)計缺陷點圈膏；
• 需求評審會議中塔猾，帶著列出的疑問點向產(chǎn)品、開發(fā)溝通自己對產(chǎn)品的疑惑和質(zhì)疑點稽坤，多提幾個為什么丈甸？如何實現(xiàn)？數(shù)據(jù)獲取來源尿褪？超出預期的數(shù)據(jù)怎么處理睦擂？緩存處理機制如何？數(shù)據(jù)保存何處杖玲？邏輯由前端處理還是后端服務(wù)顿仇？后端服務(wù)邏輯是否跟第三方關(guān)聯(lián)？
• 需求評審完成后摆马，按照一定的功能臼闻，將需求拆分成若干大模塊，大模塊拆分成小功能點囤采，然后考慮功能點的具體實現(xiàn)流程
  ??????????????????????????????????通過思維導圖細分模塊功能述呐、從頁面、交互蕉毯、邊界處理乓搬、接口邏輯等維度進行梳理需求思犁，盡可能挖掘隱含可拓展需求點，然后進行一次測試組內(nèi)需求評審进肯，讓組內(nèi)成員一起補充隱含需求激蹲，使得產(chǎn)品設(shè)計缺陷盡早且最大化地暴露出來。

2.2測試用例覆蓋不全面江掩，場景出現(xiàn)遺漏

問題分析

在測試用例設(shè)計過程中学辱，容易出現(xiàn)思維受限或者需求盲區(qū)，我們不可能完全覆蓋用戶使用的所有場景频敛，編寫測試用例的同事不可能把所有的場景都能想周全，把所有的場景下的情況都寫成測試用例這也是不大現(xiàn)實的馅扣。

改進措施

• 用例設(shè)計開始之前斟赚，列思維導圖

通過思維導圖列出業(yè)務(wù)流程，前后端接口邏輯差油。然后按照prd和交互文檔拗军，依照ui界面切分成大的功能塊，然后在大功能塊蓄喇，然后在大功能塊再切成小功能塊发侵，最后到功能點，每個功能點通過ui妆偏、基本功能刃鳄、邊界、內(nèi)存钱骂、交互叔锐、網(wǎng)絡(luò)、異常见秽、接口邏輯等維度開展用例設(shè)計導圖愉烙，并列出需找產(chǎn)品、開發(fā)確認的疑點解取。

• 用例設(shè)計完成后組織用例評審

（1）組織開發(fā)步责、產(chǎn)品進行測試用例評審，并拋出用例設(shè)計時的疑問禀苦，通過產(chǎn)品實現(xiàn)角度蔓肯、數(shù)據(jù)存儲、產(chǎn)品體驗角度對用例進行評審完善振乏。
（2）如時間充裕省核，組織測試組內(nèi)用例評審也是非常必須的，特別是一些經(jīng)驗老道或者業(yè)務(wù)熟悉的老司機們昆码，可以在用例評審上快速的幫忙指出用例的遺漏點气忠，有助于測試人員打開思路邻储，盡可能多的覆蓋用戶場景，值得注意的是用例評審上遇到不確定的旧噪，應立即記錄下來吨娜，結(jié)束后及時找相關(guān)人員確認，避免猜測淘钟。

• 根據(jù)線上用戶反饋缺陷完善用例

產(chǎn)品測試發(fā)布上線后宦赠，對于用戶反饋的缺陷，如果缺陷是因為場景設(shè)計不全引起的米母，我們先分析出現(xiàn)問題的場景是必現(xiàn)還是偶現(xiàn)勾扭，如果是必現(xiàn)，我們可以通過和技術(shù)接口人溝通铁瞒，確認該場景的一些具體復現(xiàn)步驟妙色，確認引入原因，解決方案慧耍。然后進行測試用例完善：除了補充該場景case外身辨，考慮一些和該場景相關(guān)聯(lián)的場景，將多種場景下測試用例及時完善芍碧、評審煌珊，增加到用例庫中去。

2.3測試階段未嚴格按照測試用例執(zhí)行

問題分析

按照測試用例執(zhí)行測試泌豆，可以讓我們盡可能的不出現(xiàn)遺漏一些測試點定庵。但是我們一些同學，不嚴格按照測試用例來執(zhí)行測試踪危，這樣出現(xiàn)了一些遺漏BUG實在是不應該洗贰。

改進措施

測試用例不一定能保證所有的場景和功能點都能覆蓋到，但是嚴格按照測試用例執(zhí)行測試陨倡，能最大程度上保證產(chǎn)品質(zhì)量敛滋，盡量避免出現(xiàn)缺陷。
另外養(yǎng)成測試紀錄習慣：對于測試阻塞用例兴革、測試fail用例绎晃，應該重點關(guān)注并記錄，在回歸測試階段進行精準回歸測試杂曲，確保修復bug導致關(guān)聯(lián)功能引入的新bug也能被發(fā)現(xiàn)庶艾。

2.4測試環(huán)境、測試資源受限擎勘，導致缺陷漏測

問題分析

互聯(lián)網(wǎng)金融類產(chǎn)品的環(huán)境是及其復雜的咱揍，業(yè)務(wù)系統(tǒng)不是孤立存在的，關(guān)聯(lián)方環(huán)環(huán)相扣棚饵，而且關(guān)聯(lián)系統(tǒng)常常出現(xiàn)不穩(wěn)定的情況煤裙，另外涉及身份證掩完、銀行卡等稀缺資源的使用有限，往往測試完一個有效數(shù)據(jù)廢棄一個有效數(shù)據(jù)硼砰，所以我們可以盡可能通過mock且蓬、還原客戶的實際環(huán)境（比如聯(lián)網(wǎng)核查mock，銀行卡鑒權(quán)mock）题翰，但是畢竟不是真實的環(huán)境恶阴，由于環(huán)境的差異，可能出現(xiàn)很多意想不到的問題豹障，這些問題可能只在特性的環(huán)境冯事、特定的操作步驟下才會暴露出來，在我們的測試環(huán)境還原不出來血公，只能基于生產(chǎn)環(huán)境來驗證問題昵仅。

改進措施

• 引入灰度發(fā)布（預發(fā)布）測試

測試組在預發(fā)布環(huán)境上進行回歸測試，能基本模擬真實環(huán)境執(zhí)行測試環(huán)境無法測試的用例坞笙，又不影響線上用戶的正常使用岩饼。

• 生產(chǎn)驗證環(huán)節(jié)做好case篩選

首先進行生產(chǎn)驗證case梳理荚虚，生產(chǎn)驗證case除了篩選p0+p1級別case進行回歸外薛夜，還應該包含測試環(huán)境mock or擋板阻塞的測試case,以及后端接口對前端響應的case，在生產(chǎn)回歸階段嚴格按照生產(chǎn)驗證case執(zhí)行去覆蓋真實線上環(huán)境場景

• 加強后端及關(guān)聯(lián)方業(yè)務(wù)邏輯的了解

前端不僅需要了解前端與后端接口的交互業(yè)務(wù)邏輯版述，還需了解后端接口與其它關(guān)聯(lián)方的接口交互邏輯梯澜，對測試環(huán)境測試用例的覆蓋程度有整體的把控度，以確保生產(chǎn)環(huán)境的測試用例覆蓋做到全面性渴析。

2.5開發(fā)人員引入的新BUG

問題分析

有一些開發(fā)人員只會針對你所提交的BUG中問題的描敘步驟解決晚伙，并不會去排查該問題有可能涉及的所有點，有可能出現(xiàn)解決了這個問題俭茧，而引入了一個新的問題咆疗。
　　
　　另外，一個不熟悉功能模塊的開發(fā)人員來修復BUG母债，因為業(yè)務(wù)不熟悉午磁，考慮不周全導致無意識的引入新的BUG。

改進措施

• 代碼review

從代碼管理層面：開發(fā)修復一個bug提交代碼自測通過準備提測時毡们，開發(fā)團隊提交代碼進行代碼review迅皇，引入新BUG的可能性較小。

• 精準回歸測試

從測試自我修養(yǎng)層面：在開發(fā)提測后衙熔，通過diff代碼的方式登颓，了解代碼改動點，精準分析改動點對相關(guān)聯(lián)的功能點的影響红氯，將開發(fā)人員修復的BUG確認驗證框咙，并將相關(guān)聯(lián)的功能點盡可能的遍歷回歸測試到咕痛。

• 找開發(fā)聊聊開發(fā)是如何修復這個功能。

跟開發(fā)聊實現(xiàn)很容易從開發(fā)的設(shè)計中你可以把握到測試的注意點扁耐，并記錄體現(xiàn)在用例中暇检。例如Ａ開發(fā)曾經(jīng)用某種方式做了ａ功能，出現(xiàn)了某個bug,現(xiàn)在b功能用了同樣方式實現(xiàn)婉称，那么極有可能之前的bug還會出現(xiàn)在b功能块仆。

2.6、ET測試（探索性測試）環(huán)節(jié)欠缺

問題分析

我們發(fā)現(xiàn)的很多BUG都不是按測試用例執(zhí)行發(fā)現(xiàn)出來的王暗，都是在測試過程中隨意測試發(fā)現(xiàn)的悔据，而這些步驟在測試用例中并未體現(xiàn)，我們的測試用例不可能覆蓋所有的場景

改進措施

• 準入測試通過后進行ET測試

在測試準入測試完成進入SIT測試階段：一般來說俗壹，ET測試是最容易發(fā)現(xiàn)bug的科汗，所以在測試準入測試完成進入SIT測試階段，先進行一輪探索性測試绷雏，使的大部分的bug先在測試前期暴露出來头滔，讓bug累計數(shù)量達到一定的峰值，盡早發(fā)現(xiàn)bug涎显，質(zhì)量越高坤检。

• UAT測試之前進行組內(nèi)ET測試

SIT測試進入尾聲，UAT測試之前組織一次組內(nèi)ET測試,讓組內(nèi)不同的測試用不同的測試方式期吓，測試思維早歇，測試經(jīng)驗，測試習慣進行探索測試讨勤，能發(fā)現(xiàn)一些由于思維定勢局限原因?qū)е侣y的bug箭跳、詭異的bug或者使用不合理的地方

3、總結(jié)

缺陷漏測發(fā)生后我們需要深入分析漏測的BUG潭千，思考自己哪方面做的不夠谱姓、確保類似的BUG都能已經(jīng)被預防而不容易產(chǎn)生，從而盡可能的降低缺陷的產(chǎn)生刨晴，提高產(chǎn)品質(zhì)量屉来。