一般來說bug大多數(shù)存在于三個模塊:
一、前臺界面,包括界面的顯示,兼容性,數(shù)據(jù)提交的判斷,頁面的跳轉(zhuǎn)等等,這些bug基本都是一眼可見的,不太需要定位,當(dāng)然也不排除一些特殊情況,本身數(shù)據(jù)傳過來的時候就有問題,所以顯示會出問題的情況。
二、后臺程序,包括前臺調(diào)用的接口,中間層緩存和轉(zhuǎn)發(fā)數(shù)據(jù),定時任務(wù)腳本異步處理數(shù)據(jù),程序之間的關(guān)聯(lián)調(diào)用等等,而這些bug往往都是不可見的,可能在功能上體現(xiàn),也有可能隱藏在深處不易發(fā)現(xiàn),這時候就要通過一些輔助工具以及人工的判斷去定位了。
三、數(shù)據(jù)庫,包括表中缺少字段,字段定義錯誤,字段長度限制,數(shù)據(jù)重復(fù)等等,這些bug需要通過數(shù)據(jù)庫工具以及一些基本的數(shù)據(jù)庫查詢語句來定位,當(dāng)然前提是要對每個表,每個字段提前進行了解.
排除一些顯而易見以及可以直接判斷的bug,很多不容易判斷的bug該如何定位呢?
這就需要借助一些工具來一個個排除了,也許還是會覺得云里霧里,那么就舉一個常見的例子來講解:
比如在提交正常的表單發(fā)生了錯誤導(dǎo)致提交失敗,那么如何進行定位呢?
1、首先要打開抓包工具,然后提交正常的表單,看是調(diào)用后臺接口的時候傳的參數(shù)是否和之前填寫的一致,比如表單填的是數(shù)字,而接口需要傳的是字符串,那么就是前臺傳的問題,如果一致說明不是前臺問題,繼續(xù)往下查。
2、需要一方面繼續(xù)看抓包的數(shù)據(jù),接口返回的錯誤是什么,如果能明確看到錯誤原因的消息,也就定位到問題,如果不能看到則要繼續(xù)連接測試服務(wù)器查看日志,看是程序處理到哪一步有問題,
3、如果從程序的角度發(fā)現(xiàn)沒問題,那繼續(xù)往下查,看是否連接的數(shù)據(jù)庫不對,或是超過數(shù)據(jù)庫字段限制的長度等等。就這樣隨著程序執(zhí)行的軌跡一步一步去排查,最終基本都能定位到問題。
案例1: 有一個提現(xiàn)余額的功能,實際提現(xiàn)金額到賬了,但余額卻沒有扣除。
首先要對提現(xiàn)功能做一個拆解:
1、前臺發(fā)起提現(xiàn)申請
2、后臺接受申請后凍結(jié)提現(xiàn)金額
3、定時任務(wù)處理提現(xiàn)(調(diào)用第三方支付轉(zhuǎn)賬接口)
4、接受到轉(zhuǎn)賬成功回調(diào)
5、將余額減去提現(xiàn)凍結(jié)的金額
6、前臺余額展示提現(xiàn)后的余額
因為實際提現(xiàn)金額到賬了,那么基本可以排除3和1了,然后覺得最有可能出問題的是4.就是沒有收到轉(zhuǎn)賬成功的回調(diào),可以查看后臺日志是否收到回調(diào)。如果沒收到回調(diào),那么基本就是回調(diào)地址不對或者網(wǎng)絡(luò)超時等錯誤,問題就定位到了。
如果收到回調(diào)了,那么最有可能的就是余額未扣除提現(xiàn)凍結(jié)金額,那么就是2和5.對于2來說可以查數(shù)據(jù)庫是否提現(xiàn)金額被凍結(jié)。
如果未凍結(jié)那就是步驟2出錯了,如果凍結(jié)了,繼續(xù)查5余額是否扣除了提現(xiàn)凍結(jié)金額(這個可能需要開發(fā)配合查程序邏輯了)。
如果5也沒有問題,那么剩下的可能性只有6了,再對6進行驗證。如果還沒問題可能就是其他異常導(dǎo)致的,需要更深入去思考有沒有遺漏的點或者數(shù)據(jù)庫上的特殊性導(dǎo)致的。
案例2: 有一個BS架構(gòu)的系統(tǒng),銷售統(tǒng)計報表中的金額不正確?這個時候我們怎么通過流程分析法去精確找到問題的根因呢?
1、分析金額的計算方法
2、分析金額是在那個地方生成的?前臺通過js自動計算出來的還是服務(wù)器端就生成的?
3、通過抓包工具(如fiddler)檢查瀏覽器請求的參數(shù)和返回的結(jié)果是否正確?
4、如果這些都沒有問題,檢查數(shù)據(jù)庫中和金額相關(guān)的字段的存儲數(shù)據(jù)是否正確?
5、如果金額不正確,說明我們的問題可能不是報表統(tǒng)計,而是其它地方出現(xiàn)了這個問題
6、如果金額正確,說明服務(wù)器內(nèi)部運算可能出問題了,我們可以檢查服務(wù)器的日志,查看是否有錯誤
以上bug定位方式期望能夠給大家在工作帶來收獲!