【個人日誌，通用性較小，如果理論性學習，可以跳過此篇文章】
今天寫了乙個報表查詢語句，結果開發站和測試站正確性不一致。測試站中查詢結果有重複資料，開發站中資料結果是正確的，但是查詢結果資料特別多，無法逐條核對，因此只能通過其他方法定位問題。
剛開始以為自己sql語句寫錯了，但看了下其實查詢sql很簡單的，應該不會出現問題：
select ***x,yyyy,....
from `withhold`
left join `asset` `a` on a.asset_id = withhold_asset_id
left join `bank_info` `b` on withhold_bank_card_code = bank_info_code;
開始懷疑 asset，或者bank_info 不是一對一的關係，存在一對多的關係（從業務來說是不應該的）；首先遮蔽了asset 的左連線，結果查詢結果還是錯誤的，接著遮蔽了bank_info的左連線，結果顯示正確了，沒有重複資料。那就說明問題出在 withhold和bank_info之間。
select withhold_id, withhold_bank_card_code, count(*)
from withhold
left join bank_info on withhold_bank_card_code = bank_info_code
group by withhold_id
order by count(*) desc;
發現確實有的withhold_id對應的count(*)確實為2，那問題基本可以確定，問題出在bank_info 表，然後檢視bank_info表，發現果然有兩個銀行，共用同乙個code。經核實原來是在測試站中，測試人員誤操作所致。問題通過修改測試站bank表解決。
實際處理中，解決過程遠遠沒有這麼輕鬆，首先這個問題只有測試站重現，在開發站不會重現。在再三猜測修改**，提交測試站之後，問題還是沒有解決， 此時測試mm已經不耐煩，無奈之下，只能匯出測試站的資料匯出匯入到本地開發站（long time），很奇怪，本地匯入測試站的資料，錯誤結果還是沒有重現，
事後分析，由於在匯入資料的時候，本地資料庫本身有資料，在insert資料的時候，遇到主鍵衝突的時候跳過，本地正確的bankcode表得意保留，測試站錯誤的code值事實上沒有插入資料庫，所以本地開發站重新測試，錯誤結果不會重現。
經過再三協商之後，最後只能出大招，登入測試站資料庫查詢問題（公司規定開發登入測試的流程比較麻煩），才得以用開始說明的方法定位問題，而且問題很快定位解決（前後不到十分鐘）。
從以上經歷可以總結如下經驗：
1. bug的定位，以及日常測試，資料很重要。
2. 定位問題最好從問題生成的系統環境查詢，就算有規章制度限制，交流成本的限制，測試站的問題最好通過測試站的資料庫和日誌查詢解決。匯出資料再匯入資料是費力不討好的方法
定位bug日誌
1 開啟終端輸入以下路徑 回車執行 2 開啟以上路徑資料夾，輸入命令 open 可以看到下 件夾。將symbolicatecrash檔案拷出。這個檔案是xcode自帶分析crash的程式檔案 4 輸入以下命令 cd 目標資料夾 的路徑，比如 cd users laynewang desktop 未命...
Bug定位體會
有的時候，當出現一些自己不認為不可能出現的錯誤的時候，在反覆檢查 的過程中，也沒有發現問題，這個時候，就不用太糾結在自己的 上。要知道，你認為的 沒有問題，那只是你認為，有的時候，一些顯而易見的錯誤，自己檢查 的時候，可能定位一整天也定位不到，但是其實是乙個很小的問題。這個時候，就需要實際執行除錯，...
採用git bisect 定位bug
背景 在開發zigbee閘道器的時候，最新版本 發現控制反應很慢，在最初sdk測試時是確定沒有這個問題的，所以肯定是某一處修改引入了問題，於是想辦法確認提交出問題的版本，之前就了解到git 有乙個工具可以採用二分方法定位，效率很高 git bisect start 開始使用 git bisect g...