身為測試工程師，總有一道繞不過去的坎就是定位bug，這其實是非常花費時間的。

也許有很多人不以為然，覺得無非就是發現bug後提交bug管理系統，描述操作步驟，預期結果和實際結果哪裡不一致，然後繼續測試。並不是說這樣做的不對，只是說這樣做的不夠好，看似節約了測試時間，實則對於專案的進度沒有起到應有的推動作用。

接著我就來具體分析一下吧：

1. 如果是一個多人開發的系統，不能明確定位到這個bug是誰造成的，容易提交給錯誤的開發人員，於是bug會像皮球一樣被開發踢來踢去，耽誤開發解決bug的時間。

2. 即便提交給對的開發，開發也未必能查到bug產生的原因和程式碼有問題的地方，因此不一定能修復bug，往往修改了自己認為可能有問題的地方，然後測試發現還有問題，繼續發回給開發，開發繼續查，來來回回耽誤解決bug的時間。

3. 再退一步來說，如果開發水平很高，沒有1和2的問題，對於測試來說也很容易提交重複的bug，因為可能很多bug都是由於一個地方引起的，只是表現出問題不一樣，但本質卻是一樣的，這樣也是耽誤了測試時間。

當然能遇到的遠遠不止以上3種情況，所以對於測試來說僅僅提交bug是不夠的，無論對於測試自身的提高積累，還是對於專案進度推進都是非常重要的。

那麼問題來了，要怎麼樣才能定位bug呢？雖然說一言難盡，還是想提供一些個人的思路和方法。

當bug出現時，一般來說分大致3種情況，

1. 資料庫層面的：可能少某個欄位，或者欄位值為空等等，這些可能在設計資料庫時就埋下了錯誤的種子，導致程式呼叫資料庫錯誤的資料產生bug，這一類問題不算普遍，但也是最容易忽視的一種情況，有時候從資料庫入手定位bug說不定還能發現數據庫的設計缺陷呢。

2. 網路層面的：通常這種都是網路情況較差的時候產生的，比如手機的行動網路訊號不好，又或是公司網路不穩定，導致js/css未載入完全或者請求超時等等，這種問題其實非程式bug造成的，可以不用提交bug，也不用讓開發毫無頭緒的去查程式碼的問題。當然如果可以的話也可以當優化建議提給開發，讓他優化程式碼，比如壓縮js/css，增加超時時間，超時後的重試機制。

3. 程式碼層面的：普遍的bug基本都是程式碼有問題造成的，排除掉1和2剩下後就可以確定是程式bug了。對於瞭解網路架構的人來說，其實程式也分前端和後端的，一般對於介面顯示有問題直接可以判斷是前端的問題，比如系統相容性，瀏覽器相容性。

   而對於資料或者邏輯上的問題，則需要通過抓包工具來進行分析 ：

   1）請求未返回資料，可能是client請求資料錯誤，可能是server端處理錯誤。

   2）請求返回錯誤的資料，那就是server端處理錯誤。

   3）請求返回正確的資料，那就是前端處理server端返回資料有錯誤

定位bug就像這樣抽絲剝繭一層層排除，從而把最後剩下的可能性給找出來，說難其實也不難，但需要有足夠的邏輯思維能力來推斷，也需要足夠的耐心去尋找bug的根源。

有些人覺得，定位修復BUG是開發做的事情。測試去幹不是浪費時間嗎？不要覺得這是浪費時間，把精力花在有用的點上總比花在和開發無意義的拉扯上好。而且定位出問題所在不但可以對開發更有說服力，也方便開發解決問題，開發能解決問題對於測試來說也能減少重複的沒效果的驗證過程。

從巨集觀的角度來看，這也是節約測試時間的一種方式，你說是不是呢？