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 一下, 以免出现问题.