把問題聚焦到某一個點上，而不是焦躁的瞎搞，這樣效率極低 1，看改動的地方 2，看文檔；官方文檔或者接口文檔。 3，google不到的話，也試試百度中文搜索。 4，看格式反常的地方 5，反思 反常的地 ...

摘要： Source Map還是很神奇的。 原文：線上出bug了？別怕，這么定位！ 公眾號：前端小苑 Fundebug經授權轉載並修改，版權歸原作者所有。 工作中，生產環境代碼是編譯后代碼，搜集到報錯信息的行和列無法在源碼中對應，很多時候只能靠“經驗”去猜，本文針對這種情況 ...

1.發現bug之后，重現bug的時候使用fiddler抓包去分析 2.如果前端提交的數據在fiddler中顯示有誤，那么就是前端的bug 3.如果在前端提交的數據在fiddler中顯示無誤，那么就是后台的bug 4.除了fiddler等抓包工具外，還可以通過后台的日志去判斷 ...

定位問題大致思路：用戶層面問題-->web頁面/軟件界面-->中間件-->后端服務-->代碼-->數據庫 1.用戶層面問題：用戶自己的環境問題或操作問題，比如環境不通或者操作不正確。這種問題一般不是bug,如果要考慮構建更加健壯的軟件，那么可以根據實際情況來決定 ...

一、對系統整體的了解 Server端：jsp+Servlet+json 數據庫：sql、MySQL、oracle等 前台： 涉及到 jstl，jsp，js，css，htm等方面 后台：serv ...

舉個例子來說明 WEB頁面上數據顯示錯誤，本來應該顯示38, 結果顯示35，這個時候你怎么去定位這個問題出在哪里？ 1、通過fiddler抓包工具（或者其他抓包工具）， 分析接口返回的數據是35還是38， 如果返回的是正確的，那就是前端的問題， 如果返回就是錯誤的， 你還得看看我們請求的參數 ...

一、monkey事件類型 數字 對應量 解釋0 ...

如何去區分一個功能測試工程師的水平高和低？ 可以從很多個方面去檢查，比如測試的思路， 比如測試用例的覆蓋度？，比如測試出bug是否能夠定位到根因？ 上面說的各個方面都很合理，那我們平常如何如更深的定位問題的根因呢？ 1、通過我們的測試的經驗 這個有點不容易掌握，也不容易 ...