bug报告编写的大概流程

今天正式进入一个project，由于Leader今天请假，导致没有case给我执行，再加上又出了一个需求版本，结果我一边看Build 1技术文档上说的功能点一边看需求……真不是一般的累。

 PM叫我做测试……我狂汗，没人跟，叫开发给我讲讲，然后叫我自己找bug，然后要写bug报告。下午找了半天，发现几个貌似bug的bug，问了问开发那边，有几个都是需求理解不正确，最后只有一个是bug……还好，没有空手而归。需求的理解真不容易……尤其是对新手来说。

 接着我旁边那个人告诉我bug报告的模版要注意事项，我们公司用的是IBM的LOTOS NOTES，然后基于DOMINO开发的DB，好复杂……我现在都没有搞清楚那个具体干什么，东西太多，又全是英文的。

 一个BUG报告，标题要描写清楚，让开发人员能从标题找到那里出现了问题。其实这个标题很多地方都提到过，具体的编写方法也有人说，只是自己想做好那就是另外一回事了。接着是B的版本，Bug的编号。软硬件环境，Server和Client的配置。

 Bug的状态其实就那么多，只要熟悉了就好了，知道那个流程。其实我们有权利修改的状态还是很少的……大多都要经过PM的手。优先级自己凭感觉给吧……这里存在两个：缺陷的优先级，有修改的优先级。

 主要的体现还是在bug的重现步骤上面，如何准确的重现bug，具体到你每一步如何操作的，知道出现了现象为止。最好把每一步都写得很详细，比如有什么样权限的用户登录，你点击了什么菜单，点击什么按钮。预期结果是说正确的操作后应该出现什么样的情况。实际结果是说这个bug会出现什么样的情况，最好截图说明。尤其是有的bug不会经常出现的，记得每次有bug先截图吧~~

大概就是这样了……说起来也不难，只是需要理解，还有编写的时候多注意。

原文转自：http://www.ltesting.net