一、背景

漏測Bug是指產(chǎn)品邏輯缺陷在測試過程中沒有被發(fā)現(xiàn)（尤其是測試環(huán)境可以重現(xiàn)的缺陷）翎迁，上線版本發(fā)布后或者在用戶使用體驗后發(fā)現(xiàn)并反饋回來的缺陷栋猖。可能造成線上故障或者資損汪榔，在對產(chǎn)品測試過程中蒲拉，自己也難免出現(xiàn)一些Bug的漏測，因此對Bug漏測進(jìn)行一些思考，并進(jìn)行總結(jié)雌团。

二燃领、原因分析

Bug其實是任何應(yīng)用產(chǎn)品都會有的一個問題，不是所有的Bug都能被發(fā)現(xiàn)锦援，包括資深測試猛蔽，或多或少的會出現(xiàn)線上缺陷，誰也不能把軟件所有的功能操作灵寺、運用場景想周全曼库。雖說不能做到完全零缺陷，但是每次發(fā)布的產(chǎn)品略板，我們需要追求缺陷越來越少毁枯，產(chǎn)品質(zhì)量越來越高，減少線上問題的反饋叮称。
為什么會出現(xiàn)缺陷漏測种玛，主要有以下幾點：

2.1 需求評審階段，對業(yè)務(wù)需求細(xì)節(jié)理解不明確颅拦，設(shè)計存在不合理蒂誉，未深入挖掘隱含拓展需求

• 問題分析

  在實際產(chǎn)品研發(fā)過程中教藻，產(chǎn)品需求其實處于一個細(xì)化距帅、優(yōu)化、下鉆過程中括堤，在需求PRD文檔交互文檔輸出進(jìn)行評審時碌秸，未能把一些產(chǎn)品細(xì)節(jié)問題、隱含需求暴露出來悄窃，而測試用例的編寫是基于PRD讥电、交互文檔以及自己對該需求經(jīng)驗理解所涉及測試用例。

• 改進(jìn)措施

1. 需求評審前轧抗，我們應(yīng)該先仔細(xì)閱讀PRD及交互文檔恩敌，先形成自己對產(chǎn)品的思考，通過腦圖的方式列出對產(chǎn)品設(shè)計的疑問點,從用戶或者從行業(yè)角度找出產(chǎn)品設(shè)計缺陷點横媚。
2. 需求評審會議中纠炮，帶著列出的疑問點向產(chǎn)品、開發(fā)溝通自己對產(chǎn)品的疑惑和質(zhì)疑點灯蝴，多提幾個為什么恢口？如何實現(xiàn)？數(shù)據(jù)獲取來源穷躁？超出預(yù)期的數(shù)據(jù)怎么處理耕肩？緩存處理機(jī)制如何？數(shù)據(jù)保存何處？邏輯由前端處理還是后端服務(wù)猿诸？后端服務(wù)邏輯是否跟第三方關(guān)聯(lián)婚被？
3. 需求評審?fù)瓿珊螅凑找欢ǖ墓δ苁崴洌瑢⑿枨蟛鸱殖扇舾纱竽K摔寨，大模塊拆分成小功能點，然后考慮功能點的具體實現(xiàn)流程怖辆，通過思維導(dǎo)圖細(xì)分模塊功能是复、從頁面、交互竖螃、邊界處理淑廊、接口邏輯、環(huán)境配置等維度進(jìn)行梳理需求特咆，盡可能挖掘隱含可拓展需求點季惩，然后進(jìn)行一次測試組內(nèi)需求評審和技術(shù)復(fù)盤，讓協(xié)作成員一起補(bǔ)充隱含需求腻格，使得產(chǎn)品設(shè)計缺陷盡早且最大化地暴露出來画拾。
4. 在后期技術(shù)評審時，探討邏輯交互以及上下游數(shù)據(jù)走向和消息發(fā)送流轉(zhuǎn)菜职，串聯(lián)技術(shù)側(cè)疑問點青抛。

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

• 問題分析

  在測試用例設(shè)計過程中酬核，容易出現(xiàn)思維受限或者需求盲區(qū)蜜另，我們不可能完全覆蓋用戶使用的所有場景，編寫測試用例的時不可能把所有的場景都能想周全嫡意，把所有的場景下的情況都寫成測試用例去模擬举瑰、去覆蓋這也是不太現(xiàn)實的。

• 改進(jìn)措施

1. 用例設(shè)計開始之前蔬螟，列思維導(dǎo)圖

   通過思維導(dǎo)圖列出業(yè)務(wù)流程此迅，前、后端接口邏輯旧巾。然后按照PRD和交互文檔耸序，依照UI界面切分成大的功能塊，然后在大功能塊菠齿，然后在大功能塊再切成小功能塊佑吝，最后到功能點，每個功能點通過UI绳匀、基本功能芋忿、邊界炸客、內(nèi)存、數(shù)據(jù)戈钢、交互痹仙、接口邏輯等維度開展用例設(shè)計導(dǎo)圖，并列出需找產(chǎn)品殉了、開發(fā)確認(rèn)的疑點开仰。

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

   a. 組織開發(fā)、產(chǎn)品進(jìn)行測試用例評審薪铜，并拋出用例設(shè)計時的疑問众弓，通過產(chǎn)品實現(xiàn)角度、數(shù)據(jù)存儲隔箍、用戶谓娃、產(chǎn)品體驗角度對用例進(jìn)行評審?fù)晟蒲a(bǔ)充。

   b. 組織測試組內(nèi)提前預(yù)審測試用例也是非常必須的蜒滩，對于正式用例評審前會組內(nèi)進(jìn)行預(yù)審滨达，在版本結(jié)束后組織全量用例集合入也會進(jìn)行串講用例，特別是一些經(jīng)驗老道或者業(yè)務(wù)熟悉的老司機(jī)們俯艰，可以在用例評審上快速的幫忙指出用例的遺漏點捡遍，有助于測試人員打開思路，盡可能多的覆蓋用戶場景竹握，值得注意的是用例評審上遇到不確定的画株，應(yīng)立即記錄下來作為待辦項，結(jié)束后及時找相關(guān)人員確認(rèn)涩搓，避免猜測不確定污秆。

3. 總結(jié)用戶反饋、完善測試用例流程-下鉆測試用例構(gòu)建以有備無患

   a. 產(chǎn)品測試發(fā)布上線后昧甘，對于用戶反饋的缺陷，如果缺陷是因為場景設(shè)計不全引起的战得，我們先分析出現(xiàn)問題的場景是必現(xiàn)還是偶現(xiàn)充边，如果是必現(xiàn)，我們可以通過和技術(shù)同學(xué)溝通常侦，確認(rèn)該場景的一些具體復(fù)現(xiàn)步驟浇冰，確認(rèn)引入原因，解決方案聋亡。

   b. 對于線上如果出現(xiàn)缺陷需要對測試用例完善：除了補(bǔ)充該場景case外肘习，考慮一些和該場景相關(guān)聯(lián)的場景，將多種場景下測試用例及時完善坡倔、評審漂佩，增加到用例庫中去脖含。

   c. 針對線上缺陷分析其具體原因做復(fù)盤總結(jié)，關(guān)注線上問題反饋群投蝉，及時發(fā)現(xiàn)問題养葵、定位問題、分析原因瘩缆，判斷是否為老邏輯引入還是新功能引發(fā)問題关拒，精準(zhǔn)化補(bǔ)充對應(yīng)的用例，針對特別場景補(bǔ)充接口自動化庸娱、防資損數(shù)據(jù)狗校驗着绊、全量用例集合BVT用例。

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

• 問題分析

  按照測試用例執(zhí)行測試熟尉，可以讓我們盡可能的不出現(xiàn)遺漏一些測試點畔柔。不能因為某一個人或者對某一塊業(yè)務(wù)熟悉簡化其測試用例，不嚴(yán)格按照測試用例來執(zhí)行測試臣樱，這樣出現(xiàn)了一些遺漏Bug實在是不應(yīng)該靶擦。

• 改進(jìn)措施

  • 測試用例不一定能保證所有的場景和功能點都能覆蓋到，但是嚴(yán)格按照測試用例執(zhí)行測試雇毫，能最大程度上保證產(chǎn)品質(zhì)量玄捕，盡量避免出現(xiàn)缺陷。
  • 養(yǎng)成測試紀(jì)錄習(xí)慣：對于測試阻塞用例棚放、測試Fail用例枚粘，應(yīng)該重點關(guān)注并記錄，在回歸測試階段進(jìn)行精準(zhǔn)回歸測試飘蚯，確保修復(fù)Bug導(dǎo)致關(guān)聯(lián)功能引入的新Bug也能被發(fā)現(xiàn)馍迄。

雖然測試流程很規(guī)范，但是軟件質(zhì)量還是不如意局骤。

2.4 測試環(huán)境攀圈、測試資源受限，導(dǎo)致缺陷漏測

• 問題分析

對于現(xiàn)階段得物的測試環(huán)境問題是及其復(fù)雜的峦甩，業(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)境問題。

現(xiàn)實畢竟不是真實的環(huán)境诫欠，由于環(huán)境的差異涵卵，可能出現(xiàn)很多意想不到的問題浴栽，例如：配置問題、數(shù)據(jù)源問題缘厢、以及數(shù)據(jù)同步問題吃度，這些都是可能只在特性的環(huán)境、特定的操作步驟下才會暴露出來贴硫，在我們的測試環(huán)境還原不出來椿每，只能基于預(yù)發(fā)環(huán)境或者生產(chǎn)環(huán)境來驗證問題，導(dǎo)致質(zhì)量可能出現(xiàn)風(fēng)險隱患英遭。

• 改進(jìn)措施

1）引入灰度發(fā)布測試

測試組在預(yù)發(fā)布環(huán)境上進(jìn)行回歸測試间护，能基本模擬真實環(huán)境執(zhí)行測試環(huán)境無法測試的用例，又不影響線上用戶的正常使用挖诸。

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

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

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

前端不僅需要了解前端與后端接口的交互業(yè)務(wù)邏輯狼荞，還需了解后端接口與其它關(guān)聯(lián)方的接口交互邏輯辽装，校驗判斷其給的接口數(shù)據(jù)是否正確，對測試環(huán)境測試用例的覆蓋程度有整體的把控度相味，以確保生產(chǎn)環(huán)境的測試用例覆蓋做到全面性拾积。

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

• 問題分析

有一些開發(fā)人員只會針對你所提交的Bug中問題的描述步驟解決，并不會去排查該問題有可能涉及的所有點丰涉，有可能出現(xiàn)解決了這個問題拓巧，而引入了一個新的問題。一個不熟悉功能模塊的開發(fā)人員來修復(fù)Bug一死，因為業(yè)務(wù)不熟悉肛度，考慮不周全導(dǎo)致無意識的引入新的Bug。

• 改進(jìn)措施

1）代碼review

• 從代碼管理層面：開發(fā)修復(fù)一個Bug提交代碼自測通過準(zhǔn)備提測時摘符，開發(fā)團(tuán)隊提交代碼進(jìn)行代碼review贤斜，引入新Bug的可能性概率就會較小，降低風(fēng)險存在逛裤。

2）精準(zhǔn)回歸測試

• 從測試自我修養(yǎng)層面：在開發(fā)提測后，了解代碼改動點猴抹，精準(zhǔn)分析改動點對相關(guān)聯(lián)的功能點的影響带族，將開發(fā)人員修復(fù)的Bug確認(rèn)驗證，并將相關(guān)聯(lián)的功能點盡可能的遍歷回歸測試到

3）找開發(fā)聊聊開發(fā)是如何修復(fù)這個功能*

• 跟開發(fā)聊實現(xiàn)很容易從開發(fā)的設(shè)計中你可以把握到測試的注意點蟀给，并記錄體現(xiàn)在用例中蝙砌。例如Ａ開發(fā)曾經(jīng)用某種方式做了B功能阳堕，出現(xiàn)了某個Bug，現(xiàn)在B功能用了同樣方式實現(xiàn)择克，那么極有可能之前的Bug還會出現(xiàn)在C功能恬总。

4）覆蓋率的實踐和應(yīng)用

• 增加開發(fā)冒煙執(zhí)行代碼覆蓋率，根據(jù)覆蓋率數(shù)據(jù)分析有那些冒煙用例未覆蓋到肚邢，是方法未覆蓋到壹堰、還是類未覆蓋到或者是異常邏輯的校驗未回歸到，用開發(fā)自測和覆蓋率的方式降低其新Bug的引入骡湖。

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

• 問題分析

我們發(fā)現(xiàn)的很多Bug都不是按測試用例執(zhí)行發(fā)現(xiàn)出來的贱纠，都是在測試過程中隨意測試發(fā)現(xiàn)的，而這些步驟在測試用例中并未體現(xiàn)响蕴，我們的測試用例不可能覆蓋所有的場景谆焊。

• 改進(jìn)措施

1）準(zhǔn)入測試通過后進(jìn)行ET測試

• 在測試準(zhǔn)入測試完成進(jìn)入SIT測試階段：一般來說，ET測試是最容易發(fā)現(xiàn)Bug的浦夷，所以在測試準(zhǔn)入測試完成進(jìn)入SIT測試階段辖试，先進(jìn)行一輪探索性測試，使的大部分的Bug先在測試前期暴露出來劈狐，讓Bug累計數(shù)量達(dá)到一定的峰值罐孝，盡早發(fā)現(xiàn)Bug，質(zhì)量越高懈息。

2）UAT 測試之前進(jìn)行組內(nèi)ET測試

• SIT測試進(jìn)入尾聲肾档，UAT測試之前組織一次組內(nèi)ET測試，讓組內(nèi)不同的測試用不同的測試方式辫继，測試思維怒见，測試經(jīng)驗，測試習(xí)慣進(jìn)行探索測試姑宽，能發(fā)現(xiàn)一些由于思維定勢局限原因?qū)е侣y的Bug遣耍、詭異的Bug或者使用不合理的地方。

3）精準(zhǔn)化測試

1. 精準(zhǔn)測試的測試用例聚類分析功能炮车，可以有效地發(fā)現(xiàn)“測試的錯誤”舵变。例如一個用例執(zhí)行步驟錯誤，它的聚類結(jié)果必然會發(fā)生變化瘦穆，管理者通過系統(tǒng)分析的結(jié)果就可以發(fā)現(xiàn)并糾正這一類的錯誤纪隙，而之前可能需要在現(xiàn)場回歸反復(fù)的確認(rèn)。

2. 精準(zhǔn)測試的核心技術(shù)要點是測試用例與代碼的追溯技術(shù)扛或。這項技術(shù)簡單來說就是當(dāng)功能執(zhí)行完成以后對應(yīng)的整體代碼執(zhí)行情況就會立即產(chǎn)生绵咱，即當(dāng)點擊一個測試用例，就立即追蹤到對應(yīng)的代碼和模塊熙兔。

3. 精準(zhǔn)測試測試漏洞分析功能悲伶，適用于敏捷測試艾恼。它可以基于程序靜態(tài)數(shù)據(jù)和動態(tài)運行數(shù)據(jù)，自動分析軟件缺陷最高風(fēng)險的位置麸锉，引導(dǎo)首先對于高風(fēng)險的模塊完成覆蓋钠绍，在有限時間內(nèi)完成最具有風(fēng)險的模塊的覆蓋測試。

三花沉、對于開發(fā)角度側(cè)思考

3.1 自測背景

開發(fā)人員做好自測柳爽，非常必要，也是大趨勢主穗。前期都是開發(fā)自測泻拦，后期才是用戶體驗方面的測試。從成本和時間上分析忽媒，Bug越晚發(fā)現(xiàn)修復(fù)成本越高争拐；從修改的效率來講，越早處理會越快晦雨。一個優(yōu)秀的開發(fā)者架曹，自測的Bug一定會多于測試發(fā)現(xiàn)的Bug，也就是輪到測試的時候Bug數(shù)量相當(dāng)少闹瞧。

3.2 疑難問題思考

1. 時間和進(jìn)度太緊張绑雄，排期緊湊。
2. 對自己代碼過于自信奥邮，自認(rèn)為有很強(qiáng)的健壯性万牺，不忍心去修改。
3. 認(rèn)為這是測試的責(zé)任洽腺，多度依賴測試脚粟。
4. 不知如何有效的做好自測，覆蓋全面蘸朋。
5. 開發(fā)冒煙測試對于QA創(chuàng)建指定的用例理解不透徹核无，執(zhí)行簡約。

3.3 思維轉(zhuǎn)變

1. 代碼質(zhì)量藕坯、項目質(zhì)量均是我們的責(zé)任团南。
2. 測試和開發(fā)人員思考問題不同，開發(fā)是在制造軟件炼彪，測試是在破壞軟件吐根，想辦法去找出問題。
3. 任何功能都有正常場景和異常場景辐马，多數(shù)使用等價類和邊界值去選擇數(shù)據(jù)佑惠，覆蓋全面。
4. 不要相信任何開發(fā)的代碼是無Bug齐疙。
5. 走出具體實現(xiàn)時用的開發(fā)思維膜楷，站在需求和用戶的角度去自測是否通過，假如自己是用戶去測試你的功能贞奋。

3.4 不仔細(xì)認(rèn)真自測帶來的痛處和隱患

1. 需求遺漏：一旦被用戶發(fā)現(xiàn)此問題赌厅，用戶印象會大打折扣，可能直接從開始使用即放棄使用轿塔，將帶來非常大的客戶流失特愿。
2. 功能事故：主流程功能沒有測試到位，或者異常場景沒有測試到位勾缭，導(dǎo)致線上頻繁報錯揍障，體驗極度不好，直接認(rèn)為就是事故俩由。
3. 需求延期上線：如果自測不充分毒嫡，測試花大量的時間去溝通低等級bug，甚至主流程走不下去幻梯，這樣無疑會給開發(fā)帶來返工兜畸、重復(fù)測試、耗時碘梢、需求延期咬摇、項目延期等一系列問題。

3.5 制定自測報告規(guī)范

• 功能模塊介紹及背景介紹

1. 功能煞躬、背景介紹
2. 使用用戶群體介紹

• 環(huán)境信息

1. 版本號
2. Hosts肛鹏、代碼發(fā)布分支
3. 預(yù)發(fā)or正式
4. 功能設(shè)計文檔以及UI設(shè)計圖等
5. 數(shù)據(jù)庫數(shù)據(jù)同步、環(huán)境配置恩沛、開關(guān)設(shè)定等

• 梳理好的自測點

1. 編寫代碼時候記錄的業(yè)務(wù)點和測試點
2. 需求變更的自測點
3. 正向在扰、逆向、異常場景測試點
4. 兼容性
5. 開發(fā)此功能是否會對其他功能造成影響复唤，一行代碼是否會引發(fā)新的問題出現(xiàn)

• 自測實際結(jié)果：

1. 高等級Bug數(shù)量健田、影響冒煙核心流程
2. 中等級Bug數(shù)量、串聯(lián)流程鏈路
3. 低等級Bug數(shù)量佛纫、頁面展示UI效果
4. 開發(fā)冒煙自測階段覆蓋率
5. 一輪妓局、集成階段覆蓋率

• 期望結(jié)果：

1. 符合測試SOP規(guī)定準(zhǔn)出標(biāo)準(zhǔn)
2. 冒煙自測以及集成階段覆蓋率標(biāo)準(zhǔn)
3. 測試階段Bug數(shù)量的控制
4. 上線后Bug數(shù)量的控制，質(zhì)量月復(fù)盤滿足數(shù)量控制標(biāo)準(zhǔn)

四呈宇、總結(jié)

缺陷漏測發(fā)生后我們需要深入分析漏測的Bug好爬，思考哪方面做的不夠，是業(yè)務(wù)邏輯理解誤差甥啄？用例評測遺漏存炮？技術(shù)方案存在不合理？思考設(shè)計用例方向出現(xiàn)了偏差？多問一些幾個為什么穆桂，換位思考角度想問題宫盔，合理設(shè)計評測。確保類似的Bug能被預(yù)防提前發(fā)現(xiàn)暴露出來享完，從而盡可能的降低缺陷的產(chǎn)生灼芭，提高產(chǎn)品質(zhì)量。在每個不同階段做好用例測試計劃執(zhí)行般又，增加精細(xì)化測試以及探索性測試環(huán)節(jié)彼绷，需要開拓新的測試思想思維，走出慣用常規(guī)的測試思想茴迁。同時也要站在開發(fā)側(cè)寄悯、編寫代碼設(shè)計的思維邏輯去考慮，降低可能在測試階段出現(xiàn)Bug漏測堕义、遺漏的出現(xiàn)猜旬，開發(fā)側(cè)也需嚴(yán)格執(zhí)行自測和覆蓋率SOP要求準(zhǔn)出

原文：https://segmentfault.com/a/1190000042883339