一、背景

漏測(cè)Bug是指產(chǎn)品邏輯缺陷在測(cè)試過(guò)程中沒(méi)有被發(fā)現(xiàn)（尤其是測(cè)試環(huán)境可以重現(xiàn)的缺陷），上線版本發(fā)布后或者在用戶使用體驗(yàn)后發(fā)現(xiàn)并反饋回來(lái)的缺陷?？赡茉斐删€上故障或者資損，在對(duì)產(chǎn)品測(cè)試過(guò)程中，自己也難免出現(xiàn)一些Bug的漏測(cè)，因此對(duì)Bug漏測(cè)進(jìn)行一些思考，并進(jìn)行總結(jié)。

二、原因分析

Bug其實(shí)是任何應(yīng)用產(chǎn)品都會(huì)有的一個(gè)問(wèn)題，不是所有的Bug都能被發(fā)現(xiàn)，包括資深測(cè)試，或多或少的會(huì)出現(xiàn)線上缺陷，誰(shuí)也不能把軟件所有的功能操作、運(yùn)用場(chǎng)景想周全。雖說(shuō)不能做到完全零缺陷，但是每次發(fā)布的產(chǎn)品，我們需要追求缺陷越來(lái)越少，產(chǎn)品質(zhì)量越來(lái)越高，減少線上問(wèn)題的反饋。 為什么會(huì)出現(xiàn)缺陷漏測(cè)，主要有以下幾點(diǎn)：

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

問(wèn)題分析

在實(shí)際產(chǎn)品研發(fā)過(guò)程中，產(chǎn)品需求其實(shí)處于一個(gè)細(xì)化、優(yōu)化、下鉆過(guò)程中，在需求PRD文檔交互文檔輸出進(jìn)行評(píng)審時(shí)，未能把一些產(chǎn)品細(xì)節(jié)問(wèn)題、隱含需求暴露出來(lái)，而測(cè)試用例的編寫是基于PRD、交互文檔以及自己對(duì)該需求經(jīng)驗(yàn)理解所涉及測(cè)試用例。

改進(jìn)措施

需求評(píng)審前，我們應(yīng)該先仔細(xì)閱讀PRD及交互文檔，先形成自己對(duì)產(chǎn)品的思考，通過(guò)腦圖的方式列出對(duì)產(chǎn)品設(shè)計(jì)的疑問(wèn)點(diǎn),從用戶或者從行業(yè)角度找出產(chǎn)品設(shè)計(jì)缺陷點(diǎn)。

需求評(píng)審會(huì)議中，帶著列出的疑問(wèn)點(diǎn)向產(chǎn)品、開發(fā)溝通自己對(duì)產(chǎn)品的疑惑和質(zhì)疑點(diǎn)，多提幾個(gè)為什么？如何實(shí)現(xiàn)？數(shù)據(jù)獲取來(lái)源？超出預(yù)期的數(shù)據(jù)怎么處理？緩存處理機(jī)制如何？數(shù)據(jù)保存何處？邏輯由前端處理還是后端服務(wù)？后端服務(wù)邏輯是否跟第三方關(guān)聯(lián)？

需求評(píng)審?fù)瓿珊螅凑找欢ǖ墓δ?，將需求拆分成若干大模塊，大模塊拆分成小功能點(diǎn)，然后考慮功能點(diǎn)的具體實(shí)現(xiàn)流程，通過(guò)思維導(dǎo)圖細(xì)分模塊功能、從頁(yè)面、交互、邊界處理、接口邏輯、環(huán)境配置等維度進(jìn)行梳理需求，盡可能挖掘隱含可拓展需求點(diǎn)，然后進(jìn)行一次測(cè)試組內(nèi)需求評(píng)審和技術(shù)復(fù)盤，讓協(xié)作成員一起補(bǔ)充隱含需求，使得產(chǎn)品設(shè)計(jì)缺陷盡早且最大化地暴露出來(lái)。

在后期技術(shù)評(píng)審時(shí)，探討邏輯交互以及上下游數(shù)據(jù)走向和消息發(fā)送流轉(zhuǎn)，串聯(lián)技術(shù)側(cè)疑問(wèn)點(diǎn)。

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

問(wèn)題分析

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

改進(jìn)措施

用例設(shè)計(jì)開始之前，列思維導(dǎo)圖

通過(guò)思維導(dǎo)圖列出業(yè)務(wù)流程，前、后端接口邏輯。然后按照PRD和交互文檔，依照UI界面切分成大的功能塊，然后在大功能塊，然后在大功能塊再切成小功能塊，最后到功能點(diǎn)，每個(gè)功能點(diǎn)通過(guò)UI、基本功能、邊界、內(nèi)存、數(shù)據(jù)、交互、接口邏輯等維度開展用例設(shè)計(jì)導(dǎo)圖，并列出需找產(chǎn)品、開發(fā)確認(rèn)的疑點(diǎn)。

用例設(shè)計(jì)完成后組織用例評(píng)審

a. 組織開發(fā)、產(chǎn)品進(jìn)行測(cè)試用例評(píng)審，并拋出用例設(shè)計(jì)時(shí)的疑問(wèn)，通過(guò)產(chǎn)品實(shí)現(xiàn)角度、數(shù)據(jù)存儲(chǔ)、用戶、產(chǎn)品體驗(yàn)角度對(duì)用例進(jìn)行評(píng)審?fù)晟蒲a(bǔ)充。

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

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

a. 產(chǎn)品測(cè)試發(fā)布上線后，對(duì)于用戶反饋的缺陷，如果缺陷是因?yàn)閳?chǎng)景設(shè)計(jì)不全引起的，我們先分析出現(xiàn)問(wèn)題的場(chǎng)景是必現(xiàn)還是偶現(xiàn)，如果是必現(xiàn)，我們可以通過(guò)和技術(shù)同學(xué)溝通，確認(rèn)該場(chǎng)景的一些具體復(fù)現(xiàn)步驟，確認(rèn)引入原因，解決方案。

b. 對(duì)于線上如果出現(xiàn)缺陷需要對(duì)測(cè)試用例完善：除了補(bǔ)充該場(chǎng)景case外，考慮一些和該場(chǎng)景相關(guān)聯(lián)的場(chǎng)景，將多種場(chǎng)景下測(cè)試用例及時(shí)完善、評(píng)審，增加到用例庫(kù)中去。

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

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

問(wèn)題分析

按照測(cè)試用例執(zhí)行測(cè)試，可以讓我們盡可能的不出現(xiàn)遺漏一些測(cè)試點(diǎn)。不能因?yàn)槟骋粋€(gè)人或者對(duì)某一塊業(yè)務(wù)熟悉簡(jiǎn)化其測(cè)試用例，不嚴(yán)格按照測(cè)試用例來(lái)執(zhí)行測(cè)試，這樣出現(xiàn)了一些遺漏Bug實(shí)在是不應(yīng)該。

改進(jìn)措施

測(cè)試用例不一定能保證所有的場(chǎng)景和功能點(diǎn)都能覆蓋到，但是嚴(yán)格按照測(cè)試用例執(zhí)行測(cè)試，能最大程度上保證產(chǎn)品質(zhì)量，盡量避免出現(xiàn)缺陷。

養(yǎng)成測(cè)試紀(jì)錄習(xí)慣：對(duì)于測(cè)試阻塞用例、測(cè)試Fail用例，應(yīng)該重點(diǎn)關(guān)注并記錄，在回歸測(cè)試階段進(jìn)行精準(zhǔn)回歸測(cè)試，確保修復(fù)Bug導(dǎo)致關(guān)聯(lián)功能引入的新Bug也能被發(fā)現(xiàn)。

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

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

問(wèn)題分析

對(duì)于現(xiàn)階段得物的測(cè)試環(huán)境問(wèn)題是及其復(fù)雜的，業(yè)務(wù)系統(tǒng)不是孤立存在的，關(guān)聯(lián)方環(huán)環(huán)相扣，而且關(guān)聯(lián)系統(tǒng)常常出現(xiàn)不穩(wěn)定的情況，另外涉及身份證、銀行卡等稀缺資源的使用有限，往往測(cè)試完一個(gè)有效數(shù)據(jù)廢棄一個(gè)有效數(shù)據(jù)，所以我們可以盡可能通過(guò)mock、還原客戶的實(shí)際環(huán)境問(wèn)題。

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

改進(jìn)措施

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

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

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

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

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

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

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

問(wèn)題分析

有一些開發(fā)人員只會(huì)針對(duì)你所提交的Bug中問(wèn)題的描述步驟解決，并不會(huì)去排查該問(wèn)題有可能涉及的所有點(diǎn)，有可能出現(xiàn)解決了這個(gè)問(wèn)題，而引入了一個(gè)新的問(wèn)題。一個(gè)不熟悉功能模塊的開發(fā)人員來(lái)修復(fù)Bug，因?yàn)闃I(yè)務(wù)不熟悉，考慮不周全導(dǎo)致無(wú)意識(shí)的引入新的Bug。

改進(jìn)措施

1）代碼review

從代碼管理層面：開發(fā)修復(fù)一個(gè)Bug提交代碼自測(cè)通過(guò)準(zhǔn)備提測(cè)時(shí)，開發(fā)團(tuán)隊(duì)提交代碼進(jìn)行代碼review，引入新Bug的可能性概率就會(huì)較小，降低風(fēng)險(xiǎn)存在。

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

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

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

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

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

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

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

問(wèn)題分析

我們發(fā)現(xiàn)的很多Bug都不是按測(cè)試用例執(zhí)行發(fā)現(xiàn)出來(lái)的，都是在測(cè)試過(guò)程中隨意測(cè)試發(fā)現(xiàn)的，而這些步驟在測(cè)試用例中并未體現(xiàn)，我們的測(cè)試用例不可能覆蓋所有的場(chǎng)景。

改進(jìn)措施

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

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

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

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

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

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

精準(zhǔn)測(cè)試的核心技術(shù)要點(diǎn)是測(cè)試用例與代碼的追溯技術(shù)。這項(xiàng)技術(shù)簡(jiǎn)單來(lái)說(shuō)就是當(dāng)功能執(zhí)行完成以后對(duì)應(yīng)的整體代碼執(zhí)行情況就會(huì)立即產(chǎn)生，即當(dāng)點(diǎn)擊一個(gè)測(cè)試用例，就立即追蹤到對(duì)應(yīng)的代碼和模塊。

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

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

3.1 自測(cè)背景

開發(fā)人員做好自測(cè)，非常必要，也是大趨勢(shì)。前期都是開發(fā)自測(cè)，后期才是用戶體驗(yàn)方面的測(cè)試。從成本和時(shí)間上分析，Bug越晚發(fā)現(xiàn)修復(fù)成本越高；從修改的效率來(lái)講，越早處理會(huì)越快。一個(gè)優(yōu)秀的開發(fā)者，自測(cè)的Bug一定會(huì)多于測(cè)試發(fā)現(xiàn)的Bug，也就是輪到測(cè)試的時(shí)候Bug數(shù)量相當(dāng)少。

3.2 疑難問(wèn)題思考

時(shí)間和進(jìn)度太緊張，排期緊湊。

對(duì)自己代碼過(guò)于自信，自認(rèn)為有很強(qiáng)的健壯性，不忍心去修改。

認(rèn)為這是測(cè)試的責(zé)任，多度依賴測(cè)試。

不知如何有效的做好自測(cè)，覆蓋全面。

開發(fā)冒煙測(cè)試對(duì)于QA創(chuàng)建指定的用例理解不透徹，執(zhí)行簡(jiǎn)約。

3.3 思維轉(zhuǎn)變

代碼質(zhì)量、項(xiàng)目質(zhì)量均是我們的責(zé)任。

測(cè)試和開發(fā)人員思考問(wèn)題不同，開發(fā)是在制造軟件，測(cè)試是在破壞軟件，想辦法去找出問(wèn)題。

任何功能都有正常場(chǎng)景和異常場(chǎng)景，多數(shù)使用等價(jià)類和邊界值去選擇數(shù)據(jù)，覆蓋全面。

不要相信任何開發(fā)的代碼是無(wú)Bug。

走出具體實(shí)現(xiàn)時(shí)用的開發(fā)思維，站在需求和用戶的角度去自測(cè)是否通過(guò)，假如自己是用戶去測(cè)試你的功能。

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

需求遺漏：一旦被用戶發(fā)現(xiàn)此問(wèn)題，用戶印象會(huì)大打折扣，可能直接從開始使用即放棄使用，將帶來(lái)非常大的客戶流失。

功能事故：主流程功能沒(méi)有測(cè)試到位，或者異常場(chǎng)景沒(méi)有測(cè)試到位，導(dǎo)致線上頻繁報(bào)錯(cuò)，體驗(yàn)極度不好，直接認(rèn)為就是事故。

需求延期上線：如果自測(cè)不充分，測(cè)試花大量的時(shí)間去溝通低等級(jí)bug，甚至主流程走不下去，這樣無(wú)疑會(huì)給開發(fā)帶來(lái)返工、重復(fù)測(cè)試、耗時(shí)、需求延期、項(xiàng)目延期等一系列問(wèn)題。

3.5 制定自測(cè)報(bào)告規(guī)范

功能模塊介紹及背景介紹

功能、背景介紹

使用用戶群體介紹

環(huán)境信息

版本號(hào)

Hosts、代碼發(fā)布分支

預(yù)發(fā)or正式

功能設(shè)計(jì)文檔以及UI設(shè)計(jì)圖等

數(shù)據(jù)庫(kù)數(shù)據(jù)同步、環(huán)境配置、開關(guān)設(shè)定等

梳理好的自測(cè)點(diǎn)

編寫代碼時(shí)候記錄的業(yè)務(wù)點(diǎn)和測(cè)試點(diǎn)

需求變更的自測(cè)點(diǎn)

正向、逆向、異常場(chǎng)景測(cè)試點(diǎn)

兼容性

開發(fā)此功能是否會(huì)對(duì)其他功能造成影響，一行代碼是否會(huì)引發(fā)新的問(wèn)題出現(xiàn)

自測(cè)實(shí)際結(jié)果：

高等級(jí)Bug數(shù)量、影響冒煙核心流程

中等級(jí)Bug數(shù)量、串聯(lián)流程鏈路

低等級(jí)Bug數(shù)量、頁(yè)面展示UI效果

開發(fā)冒煙自測(cè)階段覆蓋率

一輪、集成階段覆蓋率

期望結(jié)果：

符合測(cè)試SOP規(guī)定準(zhǔn)出標(biāo)準(zhǔn)

冒煙自測(cè)以及集成階段覆蓋率標(biāo)準(zhǔn)

測(cè)試階段Bug數(shù)量的控制

上線后Bug數(shù)量的控制，質(zhì)量月復(fù)盤滿足數(shù)量控制標(biāo)準(zhǔn)

四、總結(jié)

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