身為測試工程師，總有一道繞不過去的坎就是定位bug，這其實是非常花費時間的。
也許有很多人不以為然，覺得無非就是發現bug後提交bug管理系統，描述操作步驟，預期結果和實際結果**不一致，然後繼續測試。並不是說這樣做的不對，只是說這樣做的不夠好，看似節約了測試時間，實則對於專案的進度沒有起到應有的推動作用。
接著我就來具體分析一下吧：
如果是乙個多人開發的系統，不能明確定位到這個bug是誰造成的，容易提交給錯誤的開發人員，於是bug會像皮球一樣被開發踢來踢去，耽誤開發解決bug的時間。
即便提交給對的開發，開發也未必能查到bug產生的原因和**有問題的地方，因此不一定能修復bug，往往修改了自己認為可能有問題的地方，然後測試發現還有問題，繼續發回給開發，開發繼續查，來來回回耽誤解決bug的時間。
再退一步來說，如果開發水平很高，沒有1和2的問題，對於測試來說也很容易提交重複的bug，因為可能很多bug都是由於乙個地方引起的，只是表現出問題不一樣，但本質卻是一樣的，這樣也是耽誤了測試時間。
當然能遇到的遠遠不止以上3種情況，所以對於測試來說僅僅提交bug是不夠的，無論對於測試自身的提高積累，還是對於專案進度推進都是非常重要的。
那麼問題來了，要怎麼樣才能定位bug呢？雖然說一言難盡，還是想提供一些個人的思路和方法。
當bug出現時，一般來說分大致3種情況，
資料庫層面的：可能少某個字段，或者字段值為空等等，這些可能在設計資料庫時就埋下了錯誤的種子，導致程式呼叫資料庫錯誤的資料產生bug，這一類問題不算普遍，但也是最容易忽視的一種情況，有時候從資料庫入手定位bug說不定還能發現資料庫的設計缺陷呢。
網路層面的：通常這種都是網路情況較差的時候產生的，比如手機的流動網路訊號不好，又或是公司網路不穩定，導致js/css未載入完全或者請求超時等等，這種問題其實非程式bug造成的，可以不用提交bug，也不用讓開發毫無頭緒的去查**的問題。當然如果可以的話也可以當優化建議提給開發，讓他優化**，比如壓縮js/css，增加超時時間，超時後的重試機制。
**層面的：普遍的bug基本都是**有問題造成的，排除掉1和2剩下後就可以確定是程式bug了。對於了解網路架構的人來說，其實程式也分前端和後端的，一般對於介面顯示有問題直接可以判斷是前端的問題，比如系統相容性，瀏覽器相容性。
而對於資料或者邏輯上的問題，則需要通過抓包工具來進行分析 ：
1）請求未返回資料，可能是client請求資料錯誤，可能是server端處理錯誤。
2）請求返回錯誤的資料，那就是server端處理錯誤。
3）請求返回正確的資料，那就是前端處理server端返回資料有錯誤
定位bug就像這樣抽絲剝繭一層層排除，從而把最後剩下的可能性給找出來，說難其實也不難，但需要有足夠的邏輯思維能力來推斷，也需要足夠的耐心去尋找bug的根源。
有些人覺得，定位修復bug是開發做的事情。測試去幹不是浪費時間嗎？不要覺得這是浪費時間，把精力花在有用的點上總比花在和開發無意義的拉扯上好。而且定位出問題所在不但可以對開發更有說服力，也方便開發解決問題，開發能解決問題對於測試來說也能減少重複的沒效果的驗證過程。
從巨集觀的角度來看，這也是節約測試時間的一種方式，你說是不是呢？
關於測試工程師的角色定位
如果把乙個專案組比喻為一家餐館，那麼管賬的是老闆，也就是專案經理，他決定做什麼，有多少人多少資源來做多大，有多大的風險，當然他這個決定不是他乙個人拿主意，因為需要所有人對計畫的認可，但是最後他對專案成敗負的責任是很大的。其次系統架構設計就是主廚，他設計具體做法，程式設計師就是其他的廚師，配置管理員,...
軟體測試工程師的角色定位
經理 系統分析師 程式設計師 測試工程師 質量保證人員等。可見，軟體測試工程師只是軟體專案開發中的乙個角色而已。戲劇舞台上的生 旦 醜是不同的角色，其表演方式具有明顯的特徵，這是由於角色決定的。同樣，軟體測試工程師的角色，在軟體專案開發中也存在如何定位和表現自身的行為和責任的問題。此處討論測試工程師...
軟體測試工程師的角色定位
經理 系統分析師 程式設計師 測試工程師 質量保證人員等。可見，軟體測試工程師只是軟體專案開發中的乙個角色而已。戲劇舞台上的生 旦 醜是不同的角色，其表演方式具有明顯的特徵，這是由於角色決定的。同樣，軟體測試工程師的角色，在軟體專案開發中也存在如何定位和表現自身的行為和責任的問題。此處討論測試工程師...