怎样描述一个bug?

发布网友 发布时间：2022-04-25 10:53

我来回答

共2个回答

懂视网 时间：2022-04-14 22:16

1. 拿到一个新 bug, 首先要重现问题. 这对 code 问题是必须的, 对客户的 data 问题, 几乎也是必须的. 如果是 code 问题, 不重现就没办法修改代码, 改好了也无法验证是不是改对了. 客户的 data 出问题, 多数情况也是能够重现的. 毕竟客户是用我们的系统操作的

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

热心网友 时间：2022-04-14 19:24

描述bug是测试工程师最重要的工作之一，描述好一个bug，不仅可以减少测试和开发的沟通时间，还有用于这个bug的解决。怎样描述一个bug呢？小编工作中提的bug一般都包含以下几个要素。很多负责任的开发工程师，都会用心看bug描述，然后会自己去复现一下（测试工程师忙碌的时候也可以要求他们自己去复现），bug描述清楚的话，他们就不会频繁地叨扰你了。

1.项目

bug发现的项目名称，一般就写个通用的简称就可以了。对于项目多的公司，这项非常重要，不写，开发人员必定要来询问的。

2.版本

版本包含发现bug的软件版本和硬件版本信息，需要写清楚版本号和具体的Image路径。

3.模块

哪个模块发现的bug，模块尽可能写的细致些。比如音乐播放器列表下没有看到歌曲名称，你可以在bug中写成音乐模块，但如果你写“media scan”则更准确。有一定的业务水平和log分析能力之后，才能更准确地定位出细致的模块。

4.标题

用一句非常简洁的语言将问题的核心描述出来，不要有歧义，字数最好不要超过20个，保证一眼看完描述，不要换行。项目、版本、模块简称也可以写在标题前面，一般测试报告中会包含bug标题，将这些信息放在bug标题中方便领导查阅。

5.复现步骤

复现步骤尽可能写得详细些，必要时可以贴上截图和录制的视频。需要包含测试预置条件和操作步骤，尽可能用简洁的文字将每一个步骤都描述清楚，加上项目符号，保证再次看这个步骤时能够一目了然。详细的步骤不仅是写给开发看的，也是写给自己看的，有些同学提了bug，一段时间后，再次尝试复现bug时，却忘了自己当初时怎么发现的，复现不了，何其尴尬。

6.现象/测试结果

现象/测试结果相当于是标题的详细描述，要尽可能描述准确，切不可模棱两可，重点写出与期望结果不相同的部分。如果可能的话，可以把自己分析出来不正常的log也贴出来。

7.期望结果

用一两句话简洁地描述期望结果，也就是操作步骤正常应该看到的结果。

8. log路径/测试资源

log路径和测试资源路径切记填一个公共服务器的路径，以保证研发人员能够访问得了。

9.出现频率

概率性地问题，最好是写好复现的概率。概率有两种写法，一种是百分制，比如50%；另一种用分数，例如3/5，表示执行了5次，3次看到了bug，另外2次测试结果是正常的。

10.严重性

说明bug的重要性，是非解不可的bug，还是显示上的一点不美观，等等。每个公司都有不同的词汇来说明这个。当bug很严重时，一定要记得标记好这个要素。

11.优先级

优先级的高低主要是为了方便开发人员过滤bug的，一般优先级高的会先被解决掉。这个要素和严重性紧密相关，一般严重的问题，优先级就高一些。

以上就是描述bug的一些基本要素，想要描述好bug，还需要多了解一些软件测试知识，提高业务能力和log分析能力，这样才能更准确地描述好bug。