同樣的測試人員一樣的工資，一樣的工作範圍，工作目標，但跟開發人員合作時的工作效率就是不一樣。
為什麼呢？其實提交BUG是有技巧的。定位BUG更是有方法。不管是開發人員還是測試人員能快速定位BUG在這個行業來說是提高工作效率的有效方向之一。為什麼我們認為定位問題非常重要呢？
1、如果一個項目中提交的BUG沒有一個是無效的BUG，可以增加開發和測試的信任度。
2、如果能夠明確BUG的原因，對應的開發人員看到BUG就知道用最簡單快速的方法解決問題，他們也不會推卸責任，同時也能提高缺陷的修改速度。
3、自己在定位問題過程中能學到平時學不到的知識，同時有助於理解產品業務邏輯，理解數據流，日誌流。隨著對產品業務邏輯的熟悉日益成熟，反而又會促進對問題的定位更加精準。
分享一些常用的定位BUG的方法：
- 需求對比法。測試人員會通過編寫測試用例把需求的要求加工成預期結果，把執行之後的實際結果與預期結果進行比較，這樣很快就能明確是不是BUG。
- 經驗推測法。測試人員測試的項目平時會總結開發人員容易出錯的地方，一般執行的時候會重點去關注易錯點。
- 日誌分析法。測試人員在執行測試的時候，除了關注業務流，也會關注日誌流或是數據流。日誌中能明確問題的位置和原因。
- 返回狀態碼分析法。狀態碼反應的問題是可以從開發文檔中理現出來的，比如，4一般代碼是前端的問題，我們在看到4開頭的狀態碼時，會把重心放在前端。那如果有明確說明4是什麼原因產生那就更加容易定位了。一般情況下在開發文檔狀態碼說明中是很明確的。
- 抓包分析法。使用抓包軟體抓包進行分析。如fiddler請求前中斷分析填寫的內容和網絡上傳輸的內容是否一致。響應後中斷分析網絡上響應結果是否和預期結果一致。
- 調試腳本分析法。這種方法也叫斷點分析法。開發人員或是測試人員用得比較多。在腳本中增加一些特殊的日誌分析BUG的位置或是原因。
- 版本回滾分析法。有時候新版本中有BUG，老版本中沒有BUG，那麼我們就會要求開發人員回滾到前一個版本對比腳本，查看問題出在哪裡。
- 注釋腳本分析法。就是把干擾的腳本注釋掉，只測試認為可能出現問題的腳本，發現問題的時間會縮短。
- 排除分析法。出現某個問題時，我們頭腦中會出可能的多個原因，記錄下來，一條一條的做減法操作。
- 求助解決。如果你把上面9種方法都用完了，還是不能定位問題，請求助於網絡，同事，老師，同學，同行。
找問題，分析問題，重現問題是測試人員的主要工作，測試人員可以從中獲得工作帶來的成就感，滿足感。也希望 這些方法能幫助到你，為你的工作助力。