背景
由于最近比較多暴露出來由于漏測導(dǎo)致在site測試階段才發(fā)現(xiàn)的bug，特別是一些涉及身份核查、認(rèn)證鑒權(quán)、支付、交易動賬之類的問題，產(chǎn)生的后果是非常嚴(yán)重的。因此，對bug漏測進(jìn)行一些思考,并進(jìn)行總結(jié)。

為龍海等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及龍海網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為網(wǎng)站制作、成都網(wǎng)站制作、龍海網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！

原因分析
BUG其實(shí)是任何產(chǎn)品都無法避免的一個問題，不是所有的bug都能被發(fā)現(xiàn)，包括資深測試，或多或少的會出現(xiàn)線上缺陷，誰也不能把軟件所有的功能操作、運(yùn)用場景想周全。雖說不能做到完全零缺陷，但是每次發(fā)布的產(chǎn)品，我們需要追求缺陷越來越少，產(chǎn)品投訴越來越少。
為什么會出現(xiàn)缺陷漏測，主要有以下幾點(diǎn)：
需求評審階段，對業(yè)務(wù)需求細(xì)節(jié)理解不明確，未深入挖掘隱含拓展需求
問題分析
在實(shí)際產(chǎn)品研發(fā)過程中，產(chǎn)品需求其實(shí)處于一個細(xì)化過程中，在需求prd文檔交互文檔輸出進(jìn)行評審時(shí)，未能把一些產(chǎn)品細(xì)節(jié)問題、隱含需求暴漏出來，而測試用例的編寫是基于prd交互文檔。
改進(jìn)措施
需求評審前，我們應(yīng)該先仔細(xì)閱讀prd及交互文檔，先形成自己對產(chǎn)品的思考，通過腦圖的方式列出對產(chǎn)品設(shè)計(jì)的疑問點(diǎn),從用戶或者從行業(yè)角度找出產(chǎn)品設(shè)計(jì)缺陷點(diǎn)；
需求評審會議中，帶著列出的疑問點(diǎn)向產(chǎn)品、開發(fā)溝通自己對產(chǎn)品的疑惑和質(zhì)疑點(diǎn)，多提幾個為什么？如何實(shí)現(xiàn)？數(shù)據(jù)獲取來源？超出預(yù)期的數(shù)據(jù)怎么處理？緩存處理機(jī)制如何？數(shù)據(jù)保存何處？邏輯由前端處理還是后端服務(wù)？后端服務(wù)邏輯是否跟第三方關(guān)聯(lián)？
需求評審?fù)瓿珊?，按照一定的功能，將需求拆分成若干大模塊，大模塊拆分成小功能點(diǎn)，然后考慮功能點(diǎn)的具體實(shí)現(xiàn)流程
測試用例覆蓋不全面，場景出現(xiàn)遺漏
問題分析
在測試用例設(shè)計(jì)過程中，容易出現(xiàn)思維受限或者需求盲區(qū)，我們不可能完全覆蓋用戶使用的所有場景，編寫測試用例的同事不可能把所有的場景都能想周全，把所有的場景下的情況都寫成測試用例這也是不大現(xiàn)實(shí)的。
改進(jìn)措施
用例設(shè)計(jì)開始之前，列思維導(dǎo)圖
通過思維導(dǎo)圖列出業(yè)務(wù)流程，前后端接口邏輯。然后按照prd和交互文檔，依照ui界面切分成大的功能塊，然后在大功能塊，然后在大功能塊再切成小功能塊，最后到功能點(diǎn)，每個功能點(diǎn)通過ui、基本功能、邊界、內(nèi)存、交互、網(wǎng)絡(luò)、異常、接口邏輯等維度開展用例設(shè)計(jì)導(dǎo)圖，并列出需找產(chǎn)品、開發(fā)確認(rèn)的疑點(diǎn)。
用例設(shè)計(jì)完成后組織用例評審
（1）組織開發(fā)、產(chǎn)品進(jìn)行測試用例評審，并拋出用例設(shè)計(jì)時(shí)的疑問，通過產(chǎn)品實(shí)現(xiàn)角度、數(shù)據(jù)存儲、產(chǎn)品體驗(yàn)角度對用例進(jìn)行評審?fù)晟啤?br />（2）如時(shí)間充裕，組織測試組內(nèi)用例評審也是非常必須的，特別是一些經(jīng)驗(yàn)老道或者業(yè)務(wù)熟悉的老司機(jī)們，可以在用例評審上快速的幫忙指出用例的遺漏點(diǎn)，有助于測試人員打開思路，盡可能多的覆蓋用戶場景，值得注意的是用例評審上遇到不確定的，應(yīng)立即記錄下來，結(jié)束后及時(shí)找相關(guān)人員確認(rèn)，避免猜測。
根據(jù)線上用戶反饋缺陷完善用例
產(chǎn)品測試發(fā)布上線后，對于用戶反饋的缺陷，如果缺陷是因?yàn)閳鼍霸O(shè)計(jì)不全引起的，我們先分析出現(xiàn)問題的場景是必現(xiàn)還是偶現(xiàn)，如果是必現(xiàn)，我們可以通過和技術(shù)接口人溝通，確認(rèn)該場景的一些具體復(fù)現(xiàn)步驟，確認(rèn)引入原因，解決方案。然后進(jìn)行測試用例完善：除了補(bǔ)充該場景case外，考慮一些和該場景相關(guān)聯(lián)的場景，將多種場景下測試用例及時(shí)完善、評審，增加到用例庫中去。
測試階段未嚴(yán)格按照測試用例執(zhí)行
問題分析
按照測試用例執(zhí)行測試，可以讓我們盡可能的不出現(xiàn)遺漏一些測試點(diǎn)。但是我們一些同學(xué)，不嚴(yán)格按照測試用例來執(zhí)行測試，這樣出現(xiàn)了一些遺漏BUG實(shí)在是不應(yīng)該。
改進(jìn)措施
測試用例不一定能保證所有的場景和功能點(diǎn)都能覆蓋到，但是嚴(yán)格按照測試用例執(zhí)行測試，能大程度上保證產(chǎn)品質(zhì)量，盡量避免出現(xiàn)缺陷。
另外養(yǎng)成測試紀(jì)錄習(xí)慣：對于測試阻塞用例、測試fail用例，應(yīng)該重點(diǎn)關(guān)注并記錄，在回歸測試階段進(jìn)行精準(zhǔn)回歸測試，確保修復(fù)bug導(dǎo)致關(guān)聯(lián)功能引入的新bug也能被發(fā)現(xiàn)。
測試環(huán)境、測試資源受限，導(dǎo)致缺陷漏測
問題分析
互聯(lián)網(wǎng)金融類產(chǎ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、還原客戶的實(shí)際環(huán)境（比如聯(lián)網(wǎng)核查mock，銀行卡鑒權(quán)mock），但是畢竟不是真實(shí)的環(huán)境，由于環(huán)境的差異，可能出現(xiàn)很多意想不到的問題，這些問題可能只在特性的環(huán)境、特定的操作步驟下才會暴露出來，在我們的測試環(huán)境還原不出來，只能基于生產(chǎn)環(huán)境來驗(yàn)證問題。
改進(jìn)措施
引入灰度發(fā)布（預(yù)發(fā)布）測試
測試組在預(yù)發(fā)布環(huán)境上進(jìn)行回歸測試，能基本模擬真實(shí)環(huán)境執(zhí)行測試環(huán)境無法測試的用例，又不影響線上用戶的正常使用。
生產(chǎn)驗(yàn)證環(huán)節(jié)做好case篩選
首先進(jìn)行生產(chǎn)驗(yàn)證case梳理，生產(chǎn)驗(yàn)證case除了篩選p0+p1級別case進(jìn)行回歸外，還應(yīng)該包含測試環(huán)境mock or擋板阻塞的測試case,以及后端接口對前端響應(yīng)的case，在生產(chǎn)回歸階段嚴(yán)格按照生產(chǎn)驗(yàn)證case執(zhí)行去覆蓋真實(shí)線上環(huán)境場景
加強(qiáng)后端及關(guān)聯(lián)方業(yè)務(wù)邏輯的了解
前端不僅需要了解前端與后端接口的交互業(yè)務(wù)邏輯，還需了解后端接口與其它關(guān)聯(lián)方的接×××互邏輯，對測試環(huán)境測試用例的覆蓋程度有整體的把控度，以確保生產(chǎn)環(huán)境的測試用例覆蓋做到全面性。
開發(fā)人員引入的新BUG
問題分析
有一些開發(fā)人員只會針對你所提交的BUG中問題的描敘步驟解決，并不會去排查該問題有可能涉及的所有點(diǎn)，有可能出現(xiàn)解決了這個問題，而引入了一個新的問題。

另外，一個不熟悉功能模塊的開發(fā)人員來修復(fù)BUG，因?yàn)闃I(yè)務(wù)不熟悉，考慮不周全導(dǎo)致無意識的引入新的BUG。
改進(jìn)措施
代碼review
從代碼管理層面：開發(fā)修復(fù)一個bug提交代碼自測通過準(zhǔn)備提測時(shí)，開發(fā)團(tuán)隊(duì)提交代碼進(jìn)行代碼review，引入新BUG的可能性較小。
精準(zhǔn)回歸測試
從測試自我修養(yǎng)層面：在開發(fā)提測后，通過diff代碼的方式，了解代碼改動點(diǎn)，精準(zhǔn)分析改動點(diǎn)對相關(guān)聯(lián)的功能點(diǎn)的影響，將開發(fā)人員修復(fù)的BUG確認(rèn)驗(yàn)證，并將相關(guān)聯(lián)的功能點(diǎn)盡可能的遍歷回歸測試到。
找開發(fā)聊聊開發(fā)是如何修復(fù)這個功能。
跟開發(fā)聊實(shí)現(xiàn)很容易從開發(fā)的設(shè)計(jì)中你可以把握到測試的注意點(diǎn)，并記錄體現(xiàn)在用例中。例如Ａ開發(fā)曾經(jīng)用某種方式做了ａ功能，出現(xiàn)了某個bug,現(xiàn)在b功能用了同樣方式實(shí)現(xiàn)，那么極有可能之前的bug還會出現(xiàn)在b功能。
ET測試（探索性測試）環(huán)節(jié)欠缺
問題分析
我們發(fā)現(xiàn)的很多BUG都不是按測試用例執(zhí)行發(fā)現(xiàn)出來的，都是在測試過程中隨意測試發(fā)現(xiàn)的，而這些步驟在測試用例中并未體現(xiàn)，我們的測試用例不可能覆蓋所有的場景
改進(jìn)措施
準(zhǔn)入測試通過后進(jìn)行ET測試
在測試準(zhǔn)入測試完成進(jìn)入SIT測試階段：一般來說，ET測試是最容易發(fā)現(xiàn)bug的，所以在測試準(zhǔn)入測試完成進(jìn)入SIT測試階段，先進(jìn)行一輪探索性測試，使的大部分的bug先在測試前期暴露出來，讓bug累計(jì)數(shù)量達(dá)到一定的峰值，盡早發(fā)現(xiàn)bug，質(zhì)量越高。
UAT測試之前進(jìn)行組內(nèi)ET測試
SIT測試進(jìn)入尾聲，UAT測試之前組織一次組內(nèi)ET測試,讓組內(nèi)不同的測試用不同的測試方式，測試思維，測試經(jīng)驗(yàn)，測試習(xí)慣進(jìn)行探索測試，能發(fā)現(xiàn)一些由于思維定勢局限原因?qū)е侣y的bug、詭異的bug或者使用不合理的地方
總結(jié)
缺陷漏測是不能杜絕的，缺陷漏測發(fā)生后，我們需要學(xué)會思考，吸取經(jīng)驗(yàn)教訓(xùn)，盡可能的降低缺陷的漏測量。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

分享題目：移動APP測試過程中對于BUG漏測的思考-創(chuàng)新互聯(lián)
分享網(wǎng)址：http://aaarwkj.com/article30/pgppo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供軟件開發(fā)、靜態(tài)網(wǎng)站、網(wǎng)站維護(hù)、虛擬主機(jī)、網(wǎng)站改版、響應(yīng)式網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)