日历

« 2008-10-11  
日 一 二 三 四 五 六
   1234
567891011
12131415161718
19202122232425
262728293031 

统计信息

  • 访问量: 623
  • 日志数: 2
  • 文件数: 33
  • 建立时间: 2007-08-14
  • 更新时间: 2007-12-22

RSS订阅

r软件测试

我的最新日志

  • BUGZILLA的使用

    2007-12-22

     

                BUGZILLA的使用

     


    目   录

     

    1  用户登录及设置流程：. 3

    2  BUG处理流程. 4

    3  Bug的提交过程. 5

    4  对于Bug的不同处理情况. 7

    5、关于权限的说明. 8

    6  查询. 9

    7 消遣一下吧. 13

    8 Bugzilla管理员操作指南. 14

     

    Bugzilla的使用

    1        用户登录及设置流程：

    打开浏览器，进入Bugzilla主页面。

    进入主页面后，点击【新建帐号】，进入注册页面。

    在注册页面中输入E-Mail和真实姓名（为了统一，这里我们都使用计算机名），然后，点击【Create Account】，随后，你将收到一封包含初始密码的E-Mail。

    在收到E-Mail之后，点击【登录】，在帐号栏输入注册时使用的E-Mail地址，在密码栏输入邮件里通知的初始密码，然后，点击【Login】。

    如忘记密码，在登陆页面中输入注册用户名，点击【Submit Request】,根据收到的邮件进行重新设置密码。

    成功登录后，点击【Edit属性】->【帐号设置】，进行密码修改。

    点击【Edit属性】->【邮件设置】，进行邮件通知设置。

    点击【Edit属性】->【权限】，进行权限查询。

    注意：在登陆使用之后，一定要退出登陆，这不仅是一个好不好习惯的问题，在bugzilla中将成为一个隐患——当你没有退出登陆而关闭页面，当用同一台机器再次访问的时候，系统会以上次登陆的用户访问——小心你的权限被错误使用哦！

     

    2  BUG处理流程

    ①     测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。

    ②     项目组长根据具体情况，重新reassigned分配给bug所属的开发者。

    ③ 开发者收到Email信息后，判断是否为自己的修改范围.
    　1） 若不是,重新reassigned分配给项目组长或应该分配的开发者。
    　2） 若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充说明）
    ④ 测试人员查询开发者已修改的bug，进行重新测试。（可创建test case附件）
    　1） 经验证无误后，修改状态为VERIFIED。待整个产品发布后，修改为CLOSED。
    　2） 还有问题，REOPENED，状态重新变为“New"，并发邮件通知。
    ⑤ 如果这个BUG一周内一直没被处理过。Bugzilla就会一直用email骚扰它的属主，直到采取行 动。管理员可以设定最迟采取行动的期限，比如说3天，系统默认为7天。

    Bug开始

    初始状态

    指派处理人员

    二次指派

    处理Bug

    确认处理

    关闭

    Bug结束

    重新

    打开

    3        Bug的提交过程

    Ⅰ要先进行查询

    ◎确认要提交的bug报告不会在原有纪录中存在，若已经存在，不要提交，若有什么建议，可在原有纪录中增加注释，告知其属主。

    ◎确认你发现的Bug是否在最新的版本中所发生的。

     

    Ⅱ若Bug不存在，原谅自己的无情了,添加吧！！

    操作：

    点击【新建】—〉选择发现的bug所在的产品名称。

    在选择的产品bug提交页面中，选择或者输入bug信息。

    ◎模块：点“模块”两个字，可以查看关于这个产品的模块的详细信息。

    ◎平台、操作系统：可以根据发现bug的实际情况来选择，如果确定这个bug可以发生在所有的平台，选择all好了！

    ◎优先级：P1至P5优先级逐渐减弱。

    ◎严重级：blocker到enhancement严重程度降低。

      Blocker:阻碍了项目开发或者测试的继续进行。

      Critical:冲突，数据丢失和严重的内存泄漏等问题。

      Major:较大的功能缺陷。

      Minor:较小的功能缺陷。

      Trivial:拼写、对齐类的错误。

      Enhancement:需要改进的。

    ◎初始状态：开发人员的默认状态为“unconfirmed”(这个要由管理员设置，参见管理员操作指南)，测试人员或者管理员此处为可选状态：unconfirmed和new.

    ◎Assigned to: 为空时默认为管理员指定的 owner, 也可手工制定。

    ◎CC: 可为多人，需用"，"隔开。

    ◎URL: bug的定位（可选）。

    ◎注释：是对bug的概述（必须填写）。

    ◎Desription中要详细说明下列情况：
    1    ） 发现问题的步骤

    2） 执行上述步骤后出现的情况
    3    ） 期望应出现的正确结果

    ◎关键字：单击“关键字”三个字，会显示管理员已经设定的关键字，选择其一，便于以查询。注意：此处不可以随意添加，必须使用已经存在的关键字才好。另外，如果管理员没有创建关键字的话，那么此项缺省。

    ◎依赖：直接输入与当前bug有依赖关系的bug的编号。简单地说，比如说这里输入“3”，那么就是说当前提交的bug有依赖关系，不是由于3导致了当前bug，就是当前bug导致了bug3。

    确认无误后，“commit”!

    提交之后，系统会提示：bug 已经提交。在此页面的下半部分，会再次显示刚才提交的bug的详细信息，你可以在这里进行修改，重新commit,也可以在此增加新的附件或是附加说明来进一步说明bug。

    ◎投票：可以查看票数,只要点击【显示这个bug的票数】，也可以参加投票，【为这个bug投票】—〉在“票数”一栏中直接输入票数—〉【change my votes】.

    需要说明的是：票数并不是任意的，管理员为每一个用户设置了可以投票的最大数目和每个用户为某个bug投票的最大数目。

    建议：一次只投一票，多投也没什么意义。

     

    Ⅲ 冲突

    当两个或几个人同时修改一个bug提交信息的时候，bugzilla会有弹出 Mid- air collision!提示，并且列出解决冲突的选择：◎提交修改，但是会导致覆盖别人所做的修改。

    ◎不改了，返回。

    建议选择返回，看看别人修改了什么，不同的话，添加一个附加说明来补充吧！！

    以上各项可能会因为权限的关系，有所缺省。

    4  对于Bug的不同处理情况

    4.1 Bug的属主 (owner) 处理问题，提出解决意见及方法。
    给出解决方法并填写附加说明（Additional Comments），还可创建附件（如：更改提交单）。
    填表提示：
    　FIXED 描述的问题已经修改，    该bug已经修复并检查过，源文件已经检入CVS库。

    INVALID 描述的问题不是一个bug (输入错误后，通过此项来取消)
    　　WONTFIX 描述的问题将永远不会被修复。
    　　LATER 描述的问题将不会在产品的这个版本中解决。
    　　DUPLICATE 描述的问题是一个存在的bug的复件。
    　　WORKSFORME 所有要重新产生这个bug的企图是无效的。如果有更多的信息出现，请重新分配这个bug，而现在只把它归档。

     

    4.2 项目组长或开发者重新指定Bug的属主。
    ①bug不属于自己的范围，可置为 Assigned ,等待测试人员重新指定。
    ②bug不属于自己的范围，但知道谁应该负责，在    Reassign bug to的输入框中直接输入被指定人的Email。　　

    ③操作结果：此时bug状态又变为New，此bug的owner变为被指定的人。

     

    4.3 测试人员确认开发人员报告的Bug是否存在.

    查询状态为“Unconfirmed"的Bug,

    测试人员对开发人员提交的Bug进行确认，确认Bug存在。

    具体操作：选中“Confirm bug(change status to New)"后，进行commit.

    操作结果：状态变为“New".

     

    4.4 测试人员验证已修改的 Bug
    ① 测试人员查询开发者已修改的bug，即Status为"Resolved", Resolution为"Fixed".进行重新测试。（可创建test case附件）
    ② 经验证无误后，修改Resolution为VERIFIED。待整个产品发布后，修改为CLOSED。
    　若测试之后发现还有问题，REOPENED，状态重新变为“New"，并发邮件通知。

    5、关于权限的说明

    ◎组内成员对bug具有查询的权利,但不能进行修改。

    ◎ Bug的owner 和 reporter 具有修改的权利。
    ◎ 具有特殊权限的用户具有修改的权利。

    6        查询

    6.1 登录Bugzilla缺陷跟踪系统后，点击查询（如上图），可以按照指定的一个或者多个查询条件进行查询。

    ◎摘要(Summary)：下拉列表框选择查询规约。在其后的输入框中输入包含的信息，此信息的指定与提交bug时的注释信息相一致。

    ◎产品(Product)：选择所要查找的bugs所在的产品。

    ◎模块(Component)：选择bugs所在的模块。

    ◎版本(Version)：选择bugs版本。

    ◎注释(Comments)：可在下拉列表框中选择将要输入的包含信息的规约，其后指定包含的信息。此信息的指定根据提交bugs时所填写的描述信息。

    ◎URL： 指定关于bugs所在的URL。

    ◎关键字(Keywords)：指定包含或不包含该关键字的bugs。每个bug可以被指定关键字，bugs报告人或者管理员可以编辑关键字。

    ◎状态(Status)：选择bugs状态。

    ◎处理(Resolution)：选择bugs处理的结果。

    ◎严重性(Severity)：选择bugs的严重级别。

    ◎优先级(Priority)：选择bugs的优先级别。

    ◎硬件(Platform)：选择存在bugs程序运行的平台。

    ◎操作系统(OpSystem)：选择存在bugs程序所运行的操作系统。

     

    6.2 邮箱和编号     

    查看(40) 评论(0)

    邮件和编号

    <TD style="BORDER-RIGHT: #ece9d8; PADDING-RIGHT: 0cm; BORDER-TOP: #ece9d8; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: #ece9d8; WIDTH: 122pt; PADDING-TOP: 0cm; BORDER-BOTTOM: #ece9

    任意: