拿到一個新 bug 怎樣分析

   1. 拿到一個新 bug, 首先要重現問題. 這對 code 問題是必須的, 對客戶的 data 問題, 幾乎也是必須的. 如果是 code 問題, 不重現就沒辦法修改代碼, 改好了也無法驗證是不是改對了. 客戶的 data 出問題, 多數情況也是能夠重現的. 畢竟客戶是用我們的系統操作的, 只要拿到客戶的曆史資料, 對照著是可以自己做出同樣的資料. 以前我遇到 data fix 的時候不喜歡重現, 都是憑感覺給出指令碼. 但這樣常常忽略一些重要的資料, 容易出錯. 如果確定是 data fix, 我們就預設 code 是沒有問題的, 給出的指令碼就應該和在系統上正確操作得到的結果保持一致.

   2. 重現了 bug, 熟悉了整個流程, 就知道問題出在哪兒, 正確的行為應該是怎樣的. 這時不是急急忙忙的去分析, 而是去尋找. 找什麼呢? 就是找以前的人是不是遇到過同樣的問題. 尋找主要是在 Bug 系統裡面, 和 Support 網站上. Bug 系統裡面有所有 bug 的曆史資料, 根據關鍵詞可以找到類似甚至相同的 bug. 可以看看之前是怎樣解決的. 這對 data fix 尤其好用, 因為同一個問題出現 data 問題的幾率相對比較高, 參考之前給出的指令碼能減少很多勞動. Support 網站上有很多開發和 support 寫的 Note, 尋找關鍵字可以找到類似的問題. 這個對 code fix 非常好用. 如果之前已經解決這個 code 問題的話, 直接根據 note 打補丁就好了.

   3. 如果 code fix 是不能重現的, 那麼多數情況下, 這個問題已經被改過了. 客戶由於檔案版本較低, 還存在這個問題. 去上面兩個網站去找相應的補丁. 

   4. 如果在這兩個網站都沒有找到相似的 bug, 那麼恭喜你, 遇到了一個新的問題, 你要從頭開始自己分析了.

   5. 分析的工具無非就是 log. 看 log, 可以跟蹤代碼走到了哪裡. 對我們 INV team 來說, 幾個常用的 log 是: 

   a) INV log

      INV log 記錄了伺服器端代碼的流程, 就是 .pls 檔案的 log. 如果在檔案開頭的地方有讀取 FND_PROFILE.VALUE('INV_DEBUG_TRACE') 的話, 那麼這個檔案的日誌就是記錄在 INV log 裡面的. 拿到這個日誌, 對於分析代碼走到了哪一步非常有用.

   b) RTP log

      RTP log 是記錄系統跑 concurrent request: receiving transaction processor 所記錄下的日誌. 如果打過 9184617:R12.PO.A 這個patch, 也就是 rvtpt.lpc的版本要高於這個版本120.19.12000000.25  , 那麼就可以在 INV log 裡面看到RTP 的 log 了. 如果沒有打過這個patch, 那麼就只能用老辦法去收集了. 收集的辦法是記錄下 RTP id, 然後用下面的 SQL: 

    select module, to_char(timestamp,'DD-MON-YYYY HH24:MI:SS'), message_text    from fnd_log_messages    where timestamp > sysdate - 2/24    and process_id = ( select os_process_id from fnd_concurrent_requests where request_id = &request_id)    and module like 'po%'

   c) FRD log

      FRD 的全稱是 forms runtime diagnostics, 就是記錄 form 運行時候所有觸發器的日誌. 這個裡面可以清楚的看到觸發器觸發的順序, 以及在裡面做了什麼事情. 如果客戶的 bug 是屬於 form runtime 進程報錯的話, 裡面就會顯示在那個觸發器裡面報的錯, 然後要做的事情就是看代碼了.

   d) SQL trace

      SQL trace 記錄的是資料庫所有的操作的日誌. 包括所有的動作陳述式, 綁定值, 效能問題, 還有 SQL 報錯. 只要看報什麼錯, 找到那句 SQL, 差不多就解決了一半問題了.

   e) fnd_new_messages

      這是資料庫的一個表, 記錄了所有的錯誤資訊. 如果客戶報了一個錯, 可以通過下面的 SQL 去找到對應的錯誤記錄

select * from fnd_new_messages where message_text like 'Quantity entered should be less than or equal to available quantity%'

   然後到代碼裡面去找到報錯的地方就好了. 通常一個錯誤資訊只在一個地方報出來, 所有很容易找到對應的代碼.

   通過上面的幾個日誌, 差不多能夠定位到 bug 發生的代碼了. 接下來的事情就是去 code fix 或者給客戶提供指令碼. 

   最後重要的一點就是, 無論 code fix 還是提供 data fix script, 都要讓其他開發 review 一下, 以免出現問題.