答复--关于buglist的写法

 

Buglist存在的3个重要作用：

1.       提高解bug的效率；

2.       尽可能Cover住所有bug；

3.       给后续参考借鉴作用。

我非常看重第一点。下面我用简单的输入输出模型来解释一下：

Ø  输入：

1.       人员。各司其职。每个人要清楚这个项目对于自己的难点在哪？需要注意的地方在哪？这里可以体现在另外一个文档中《HW/SW/ME给测试的建议》，也可以集合到buglist中。比方说，NP13的项目，基于NP10C项目而来，对于SW来讲，有这些需要注意的地方：多了一个SATA-CDROM，上一版未澄清的bug（手动开关机的问题），或是其他。测试工程师在测试时就要重点关注这些地方，做到心中有数，游刃有余。

2.       PCBA/KEYPART。一是要说明数量，二是要说明种类。现在使用的buglist中有一个configuration项，不知大家注意到没，里面对一些配置做了相关说明，比如说哪家的内存，什么型号的，哪家的wifi，什么型号（接口）。有可能有多种型号，都要说明。还有一个很重要的是编号，每一块PCBA，每一种keypart都要编号，比如PCBA(P01开始)，memory(M01…),HDD(H01…),BATTERY(B01…),WIFI(W01…),等等。组成整机时也要编号，比如NOTEBOOK01都用编号为01的组。上述这些编号，需要在configuration里面一一说明具体型号。在填写buglist时，比如有交换内存的动作，可以直接写成“交换M01，M02，发生了什么？”

3.       测试规范。有特别的变化时，需要重新审定。针对一些特别的功能，做相关的应对措施。

Ø  过程：

1.       发现bug。测试工程师来描述bug的现象。参考《测试异常分析》中，细化问题，条件分析，环境分析，判断分析，归原分析。体现在buglist中，Detail Description项的填写要求，可能跟工程师的经验水平比较相关，如何量化成具体的操作模式，有待商讨。

2.       解bug。Debug工程师解bug的分析过程及结果和动作。Debug的过程无非是，先想出可能的原因，再去验证，再得出结果，再排除/找到原因。体现在buglist Analyse项的填写要求：1.可以写出为什么是这个原因，因为怀疑什么？2.怎么去验证的，细化的动作，比如换了哪颗器件，抓了哪些信号，软件上打开/关闭了什么功能等等？这里debug工程师一定要确认好自己的动作的正确性，不然就是个悲剧！3.然后得到的结果，比如无效，或是有其他的现象出现，或是抓下的图，或是……。

Ø  输出：

1.  总结。每个人经过一个项目，肯定都会遇到各种各样的问题，会吃各种各样的后悔药。那么下次呢？总结，尤其是文档性的总结，便是一个较好的方法。而且各人的总结，分享出来，那么每个人又多了不少教训。拒绝从历史中总结的人注定要重复它的悲剧。

2.  其它的一些东西。如 最终版BIOS/EC，buglist，重大bug的文档……。

 

再讲讲效率的问题，合理的buglist如何体现在效率上？

1.  尽量减少重复的验证动作；

2.  迅速理解他人意图。

 

以上可能跟buglist的填写规范这个主题，有点偏了。事物的发展规律是一个由简到繁，而后由繁到简的过程，现在处于第一个阶段，所以期待各位的奇思妙想。